微服務(wù)實(shí)戰(zhàn)（一）：微服務(wù)架構(gòu)的優(yōu)勢(shì)與不足

這篇文章作者是Chris Richardson碉钠，他是早期基于Java的Amazonite EC2 PaaS平臺(tái)CloudFoundry.com的創(chuàng)始人〈锊迹現(xiàn)在他為企業(yè)提供如何開發(fā)和部署應(yīng)用的咨詢服務(wù)。他也經(jīng)常在http://microservices.io上發(fā)表有關(guān)微服務(wù)的文章。

微服務(wù)正在博客砰识、社交媒體討論組和會(huì)議演講中獲得越來越多的關(guān)注柱搜，在Gartner的2014 Hype Cycle上它的排名非常靠前癣蟋。同時(shí)透硝，軟件社區(qū)中也有不少持懷疑論者，認(rèn)為微服務(wù)不是什么新東西疯搅。Naysayers認(rèn)為這就是SOA架構(gòu)的重新包裝濒生。然而，盡管存在著不同的爭(zhēng)論幔欧，微服務(wù)架構(gòu)模式卻正在為敏捷部署以及復(fù)雜企業(yè)應(yīng)用實(shí)施提供巨大的幫助罪治。

這篇博客是關(guān)于如何設(shè)計(jì)、開發(fā)和部署微服務(wù)的七篇系列文章中的第一篇礁蔗。讀者將會(huì)從中學(xué)到方法觉义，并且和單體式架構(gòu)模式（譯者注：本文中會(huì)將 Monolithic翻譯為單體）進(jìn)行對(duì)比。這一系列文章將描述微服務(wù)架構(gòu)中不同元素浴井。你將了解到微服務(wù)架構(gòu)模式的優(yōu)缺點(diǎn)需纳，以便決定是否更好的將微服務(wù)架構(gòu)應(yīng)用到自己的項(xiàng)目中意荤，以及如何應(yīng)用這一模式港令。

首先我們看看為什么要考慮使用微服務(wù)毙石。

開發(fā)單體式應(yīng)用

假設(shè)你正準(zhǔn)備開發(fā)一款與Uber和Hailo競(jìng)爭(zhēng)的出租車調(diào)度軟件，經(jīng)過初步會(huì)議和需求分析，你可能會(huì)手動(dòng)或者使用基于Rails、Spring Boot、Play或者M(jìn)aven的生成器開始這個(gè)新項(xiàng)目崭参，這個(gè)新應(yīng)用將會(huì)有一個(gè)模塊叫：六邊形架構(gòu) ，架構(gòu)圖如下：

應(yīng)用核心是業(yè)務(wù)邏輯款咖，由定義服務(wù)何暮、域?qū)ο蠛褪录哪K完成。圍繞著核心的是與外界打交道的適配器铐殃。適配器包括數(shù)據(jù)庫(kù)訪問組件海洼、生產(chǎn)和處理消息的消息組件，以及提供API或者UI訪問支持的web模塊等富腊。

盡管也是模塊化邏輯坏逢，但是最終它還是會(huì)打包并部署為單體式應(yīng)用。具體的格式依賴于應(yīng)用語(yǔ)言和框架赘被。例如是整，許多Java應(yīng)用會(huì)被打包為WAR格式，部署在Tomcat或者Jetty上民假，而另外一些Java應(yīng)用會(huì)被打包成自包含的JAR格式浮入，同樣，Rails和Node.js會(huì)被打包成層級(jí)目錄羊异。

這種應(yīng)用開發(fā)風(fēng)格很常見事秀，因?yàn)镮DE和其它工具都擅長(zhǎng)開發(fā)一個(gè)簡(jiǎn)單應(yīng)用，這類應(yīng)用也很易于調(diào)試野舶，只需要簡(jiǎn)單運(yùn)行此應(yīng)用易迹，用Selenium鏈接UI就可以完成端到端測(cè)試。單體式應(yīng)用也易于部署筒愚，只需要把打包應(yīng)用拷貝到服務(wù)器端赴蝇，通過在負(fù)載均衡器后端運(yùn)行多個(gè)拷貝就可以輕松實(shí)現(xiàn)應(yīng)用擴(kuò)展菩浙。在早期這類應(yīng)用運(yùn)行的很好巢掺。

單體式應(yīng)用的不足

不幸的是，這種簡(jiǎn)單方法卻有很大的局限性劲蜻。一個(gè)簡(jiǎn)單的應(yīng)用會(huì)隨著時(shí)間推移逐漸變大陆淀。在每次的sprint中，開發(fā)團(tuán)隊(duì)都會(huì)面對(duì)新“故事”先嬉，然后開發(fā)許多新代碼轧苫。幾年后，這個(gè)小而簡(jiǎn)單的應(yīng)用會(huì)變成了一個(gè)巨大的怪物。這兒有一個(gè)例子含懊，我最近和一個(gè)開發(fā)者討論身冬，他正在寫一個(gè)工具，用來分析他們一個(gè)擁有數(shù)百萬行代碼的應(yīng)用中JAR文件之間的依賴關(guān)系岔乔。我很確信這個(gè)代碼正是很多開發(fā)者經(jīng)過多年努力開發(fā)出來的一個(gè)怪物酥筝。

一旦你的應(yīng)用變成一個(gè)又大又復(fù)雜的怪物，那開發(fā)團(tuán)隊(duì)肯定很痛苦雏门。敏捷開發(fā)和部署舉步維艱嘿歌，其中最主要問題就是這個(gè)應(yīng)用太復(fù)雜，以至于任何單個(gè)開發(fā)者都不可能搞懂它茁影。因此宙帝，修正bug和正確的添加新功能變的非常困難，并且很耗時(shí)募闲。另外步脓，團(tuán)隊(duì)士氣也會(huì)走下坡路。如果代碼難于理解浩螺，就不可能被正確的修改沪编。最終會(huì)走向巨大的、不可理解的泥潭年扩。

單體式應(yīng)用也會(huì)降低開發(fā)速度蚁廓。應(yīng)用越大，啟動(dòng)時(shí)間會(huì)越長(zhǎng)厨幻。比如相嵌，最近的一個(gè)調(diào)查表明，有時(shí)候應(yīng)用的啟動(dòng)時(shí)間居然超過了12分鐘况脆。我還聽說某些應(yīng)用需要40分鐘啟動(dòng)時(shí)間饭宾。如果開發(fā)者需要經(jīng)常重啟應(yīng)用，那么大部分時(shí)間就要在等待中渡過格了，生產(chǎn)效率受到極大影響看铆。

另外，復(fù)雜而巨大的單體式應(yīng)用也不利于持續(xù)性開發(fā)盛末。今天弹惦，SaaS應(yīng)用常態(tài)就是每天會(huì)改變很多次，而這對(duì)于單體式應(yīng)用模式非常困難悄但。另外棠隐，這種變化帶來的影響并沒有很好的被理解，所以不得不做很多手工測(cè)試檐嚣。那么接下來助泽，持續(xù)部署也會(huì)很艱難。

單體式應(yīng)用在不同模塊發(fā)生資源沖突時(shí)，擴(kuò)展將會(huì)非常困難嗡贺。比如隐解，一個(gè)模塊完成一個(gè)CPU敏感邏輯，應(yīng)該部署在AWS EC2 Compute Optimized instances诫睬，而另外一個(gè)內(nèi)存數(shù)據(jù)庫(kù)模塊更合適于EC2 Memory-optimized instances厢漩。然而，由于這些模塊部署在一起岩臣，因此不得不在硬件選擇上做一個(gè)妥協(xié)溜嗜。

單體式應(yīng)用另外一個(gè)問題是可靠性。因?yàn)樗心K都運(yùn)行在一個(gè)進(jìn)程中架谎，任何一個(gè)模塊中的一個(gè)bug炸宵，比如內(nèi)存泄露，將會(huì)有可能弄垮整個(gè)進(jìn)程谷扣。除此之外土全，因?yàn)樗袘?yīng)用實(shí)例都是唯一的，這個(gè)bug將會(huì)影響到整個(gè)應(yīng)用的可靠性会涎。

最后裹匙，單體式應(yīng)用使得采用新架構(gòu)和語(yǔ)言非常困難。比如末秃，設(shè)想你有兩百萬行采用XYZ框架寫的代碼概页。如果想改成ABC框架，無論是時(shí)間還是成本都是非常昂貴的练慕，即使ABC框架更好惰匙。因此，這是一個(gè)無法逾越的鴻溝铃将。你不得不在最初選擇面前低頭项鬼。

總結(jié)一下：一開始你有一個(gè)很成功的關(guān)鍵業(yè)務(wù)應(yīng)用，后來就變成了一個(gè)巨大的劲阎，無法理解的怪物绘盟。因?yàn)椴捎眠^時(shí)的，效率低的技術(shù)悯仙，使得雇傭有潛力的開發(fā)者很困難龄毡。應(yīng)用無法擴(kuò)展，可靠性很低雁比，最終稚虎，敏捷性開發(fā)和部署變的無法完成。

那么如何應(yīng)對(duì)呢偎捎？

微處理架構(gòu)——處理復(fù)雜事物

許多公司，比如Amazon、eBay和NetFlix茴她，通過采用微處理結(jié)構(gòu)模式解決了上述問題寻拂。其思路不是開發(fā)一個(gè)巨大的單體式的應(yīng)用，而是將應(yīng)用分解為小的丈牢、互相連接的微服務(wù)祭钉。

一個(gè)微服務(wù)一般完成某個(gè)特定的功能，比如下單管理己沛、客戶管理等等慌核。每一個(gè)微服務(wù)都是微型六角形應(yīng)用，都有自己的業(yè)務(wù)邏輯和適配器申尼。一些微服務(wù)還會(huì)發(fā)布API給其它微服務(wù)和應(yīng)用客戶端使用垮卓。其它微服務(wù)完成一個(gè)Web UI，運(yùn)行時(shí)师幕，每一個(gè)實(shí)例可能是一個(gè)云VM或者是Docker容器粟按。

比如，一個(gè)前面描述系統(tǒng)可能的分解如下：

每一個(gè)應(yīng)用功能區(qū)都使用微服務(wù)完成霹粥，另外灭将，Web應(yīng)用會(huì)被拆分成一系列簡(jiǎn)單的Web應(yīng)用（比如一個(gè)對(duì)乘客，一個(gè)對(duì)出租車駕駛員）后控。這樣的拆分對(duì)于不同用戶庙曙、設(shè)備和特殊應(yīng)用場(chǎng)景部署都更容易。

每一個(gè)后臺(tái)服務(wù)開放一個(gè)REST API浩淘，許多服務(wù)本身也采用了其它服務(wù)提供的API矾利。比如，駕駛員管理使用了告知駕駛員一個(gè)潛在需求的通知服務(wù)馋袜。UI服務(wù)激活其它服務(wù)來更新Web頁(yè)面男旗。所有服務(wù)都是采用異步的，基于消息的通訊欣鳖。微服務(wù)內(nèi)部機(jī)制將會(huì)在后續(xù)系列中討論察皇。

一些REST API也對(duì)乘客和駕駛員采用的移動(dòng)應(yīng)用開放。這些應(yīng)用并不直接訪問后臺(tái)服務(wù)泽台，而是通過API Gateway來傳遞中間消息什荣。API Gateway負(fù)責(zé)負(fù)載均衡、緩存怀酷、訪問控制稻爬、API 計(jì)費(fèi)監(jiān)控等等任務(wù)，可以通過NGINX方便實(shí)現(xiàn)蜕依，后續(xù)文章將會(huì)介紹到API Gateway桅锄。

微服務(wù)架構(gòu)模式在上圖中對(duì)應(yīng)于代表可擴(kuò)展Scale Cube的Y軸琉雳，這是一個(gè)在《The Art of Scalability》書中描述過的三維擴(kuò)展模型。另外兩個(gè)可擴(kuò)展軸友瘤，X軸由負(fù)載均衡器后端運(yùn)行的多個(gè)應(yīng)用副本組成翠肘，Z軸是將需求路由到相關(guān)服務(wù)。

應(yīng)用基本可以用以上三個(gè)維度來表示辫秧，Y軸代表將應(yīng)用分解為微服務(wù)束倍。運(yùn)行時(shí)，X軸代表運(yùn)行多個(gè)隱藏在負(fù)載均衡器之后的實(shí)例盟戏，提供吞吐能力绪妹。一些應(yīng)用可能還是用Z軸將服務(wù)分區(qū)。下面的圖演示行程管理服務(wù)如何部署在運(yùn)行于AWS EC2上的Docker上柿究。

運(yùn)行時(shí)邮旷，行程管理服務(wù)由多個(gè)服務(wù)實(shí)例構(gòu)成。每一個(gè)服務(wù)實(shí)例都是一個(gè)Docker容器笛求。為了保證高可用廊移，這些容器一般都運(yùn)行在多個(gè)云VM上。服務(wù)實(shí)例前是一層諸如NGINX的負(fù)載均衡器探入，他們負(fù)責(zé)在各個(gè)實(shí)例間分發(fā)請(qǐng)求狡孔。負(fù)載均衡器也同時(shí)處理其它請(qǐng)求，例如緩存蜂嗽、權(quán)限控制苗膝、API統(tǒng)計(jì)和監(jiān)控。

這種微服務(wù)架構(gòu)模式深刻影響了應(yīng)用和數(shù)據(jù)庫(kù)之間的關(guān)系植旧，不像傳統(tǒng)多個(gè)服務(wù)共享一個(gè)數(shù)據(jù)庫(kù)辱揭，微服務(wù)架構(gòu)每個(gè)服務(wù)都有自己的數(shù)據(jù)庫(kù)。另外病附，這種思路也影響到了企業(yè)級(jí)數(shù)據(jù)模式问窃。同時(shí)，這種模式意味著多份數(shù)據(jù)完沪，但是域庇，如果你想獲得微服務(wù)帶來的好處，每個(gè)服務(wù)獨(dú)有一個(gè)數(shù)據(jù)庫(kù)是必須的覆积，因?yàn)檫@種架構(gòu)需要這種松耦合听皿。下面的圖演示示例應(yīng)用數(shù)據(jù)庫(kù)架構(gòu)。

每種服務(wù)都有自己的數(shù)據(jù)庫(kù)宽档，另外尉姨，每種服務(wù)可以用更適合自己的數(shù)據(jù)庫(kù)類型，也被稱作多語(yǔ)言一致性架構(gòu)吗冤。比如又厉，駕駛員管理（發(fā)現(xiàn)哪個(gè)駕駛員更靠近乘客）九府，必須使用支持跨地域查詢的數(shù)據(jù)庫(kù)。

表面上看來馋没，微服務(wù)架構(gòu)模式有點(diǎn)像SOA昔逗，他們都由多個(gè)服務(wù)構(gòu)成降传。但是篷朵，可以從另外一個(gè)角度看此問題，微服務(wù)架構(gòu)模式是一個(gè)不包含Web服務(wù)（WS-）和ESB服務(wù)的SOA婆排。微服務(wù)應(yīng)用樂于采用簡(jiǎn)單輕量級(jí)協(xié)議声旺，比如REST，而不是WS-段只，在微服務(wù)內(nèi)部避免使用ESB以及ESB類似功能腮猖。微服務(wù)架構(gòu)模式也拒絕使用canonical schema等SOA概念。

微服務(wù)架構(gòu)的好處

微服務(wù)架構(gòu)模式有很多好處赞枕。首先澈缺，通過分解巨大單體式應(yīng)用為多個(gè)服務(wù)方法解決了復(fù)雜性問題。在功能不變的情況下炕婶，應(yīng)用被分解為多個(gè)可管理的分支或服務(wù)姐赡。每個(gè)服務(wù)都有一個(gè)用RPC-或者消息驅(qū)動(dòng)API定義清楚的邊界。微服務(wù)架構(gòu)模式給采用單體式編碼方式很難實(shí)現(xiàn)的功能提供了模塊化的解決方案柠掂，由此项滑，單個(gè)服務(wù)很容易開發(fā)、理解和維護(hù)涯贞。

第二枪狂，這種架構(gòu)使得每個(gè)服務(wù)都可以有專門開發(fā)團(tuán)隊(duì)來開發(fā)。開發(fā)者可以自由選擇開發(fā)技術(shù)宋渔，提供API服務(wù)州疾。當(dāng)然，許多公司試圖避免混亂皇拣，只提供某些技術(shù)選擇严蓖。然后，這種自由意味著開發(fā)者不需要被迫使用某項(xiàng)目開始時(shí)采用的過時(shí)技術(shù)审磁，他們可以選擇現(xiàn)在的技術(shù)谈飒。甚至于，因?yàn)榉?wù)都是相對(duì)簡(jiǎn)單态蒂，即使用現(xiàn)在技術(shù)重寫以前代碼也不是很困難的事情杭措。

第三，微服務(wù)架構(gòu)模式是每個(gè)微服務(wù)獨(dú)立的部署钾恢。開發(fā)者不再需要協(xié)調(diào)其它服務(wù)部署對(duì)本服務(wù)的影響手素。這種改變可以加快部署速度鸳址。UI團(tuán)隊(duì)可以采用AB測(cè)試，快速的部署變化泉懦。微服務(wù)架構(gòu)模式使得持續(xù)化部署成為可能稿黍。

最后，微服務(wù)架構(gòu)模式使得每個(gè)服務(wù)獨(dú)立擴(kuò)展崩哩。你可以根據(jù)每個(gè)服務(wù)的規(guī)模來部署滿足需求的規(guī)模巡球。甚至于，你可以使用更適合于服務(wù)資源需求的硬件邓嘹。比如酣栈，你可以在EC2 Compute Optimized instances上部署CPU敏感的服務(wù)，而在EC2 memory-optimized instances上部署內(nèi)存數(shù)據(jù)庫(kù)汹押。

微服務(wù)架構(gòu)的不足

Fred Brooks在30年前寫道矿筝，“there are no silver bullets”，像任何其它科技一樣棚贾，微服務(wù)架構(gòu)也有不足窖维。其中一個(gè)跟他的名字類似，『微服務(wù)』強(qiáng)調(diào)了服務(wù)大小妙痹，實(shí)際上铸史，有一些開發(fā)者鼓吹建立稍微大一些的，10-100 LOC服務(wù)組细诸。盡管小服務(wù)更樂于被采用沛贪，但是不要忘了這只是終端的選擇而不是最終的目的。微服務(wù)的目的是有效的拆分應(yīng)用震贵，實(shí)現(xiàn)敏捷開發(fā)和部署利赋。

另外一個(gè)主要的不足是，微服務(wù)應(yīng)用是分布式系統(tǒng)猩系，由此會(huì)帶來固有的復(fù)雜性媚送。開發(fā)者需要在RPC或者消息傳遞之間選擇并完成進(jìn)程間通訊機(jī)制。更甚于寇甸，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題塘偎。當(dāng)然這并不是什么難事，但相對(duì)于單體式應(yīng)用中通過語(yǔ)言層級(jí)的方法或者進(jìn)程調(diào)用拿霉，微服務(wù)下這種技術(shù)顯得更復(fù)雜一些吟秩。

另外一個(gè)關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫(kù)架構(gòu)。商業(yè)交易中同時(shí)給多個(gè)業(yè)務(wù)分主體更新消息很普遍绽淘。這種交易對(duì)于單體式應(yīng)用來說很容易涵防，因?yàn)橹挥幸粋€(gè)數(shù)據(jù)庫(kù)。在微服務(wù)架構(gòu)應(yīng)用中沪铭，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫(kù)壮池。使用分布式交易并不一定是好的選擇偏瓤，不僅僅是因?yàn)镃AP理論，還因?yàn)榻裉旄邤U(kuò)展性的NoSQL數(shù)據(jù)庫(kù)和消息傳遞中間件并不支持這一需求椰憋。最終你不得不使用一個(gè)最終一致性的方法厅克，從而對(duì)開發(fā)者提出了更高的要求和挑戰(zhàn)。

測(cè)試一個(gè)基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)橙依。比如证舟，采用流行的Spring Boot架構(gòu)，對(duì)一個(gè)單體式web應(yīng)用票编，測(cè)試它的REST API褪储，是很容易的事情卵渴。反過來慧域，同樣的服務(wù)測(cè)試需要啟動(dòng)和它有關(guān)的所有服務(wù)（至少需要這些服務(wù)的stubs）。再重申一次浪读，不能低估了采用微服務(wù)架構(gòu)帶來的復(fù)雜性昔榴。

另外一個(gè)挑戰(zhàn)在于，微服務(wù)架構(gòu)模式應(yīng)用的改變將會(huì)波及多個(gè)服務(wù)碘橘。比如互订，假設(shè)你在完成一個(gè)案例，需要修改服務(wù)A痘拆、B仰禽、C，而A依賴B纺蛆，B依賴C吐葵。在單體式應(yīng)用中，你只需要改變相關(guān)模塊桥氏，整合變化温峭，部署就好了。對(duì)比之下字支，微服務(wù)架構(gòu)模式就需要考慮相關(guān)改變對(duì)不同服務(wù)的影響凤藏。比如，你需要更新服務(wù)C堕伪，然后是B揖庄，最后才是A，幸運(yùn)的是欠雌，許多改變一般只影響一個(gè)服務(wù)蹄梢，而需要協(xié)調(diào)多服務(wù)的改變很少。

部署一個(gè)微服務(wù)應(yīng)用也很復(fù)雜桨昙，一個(gè)分布式應(yīng)用只需要簡(jiǎn)單在復(fù)雜均衡器后面部署各自的服務(wù)器就好了检号。每個(gè)應(yīng)用實(shí)例是需要配置諸如數(shù)據(jù)庫(kù)和消息中間件等基礎(chǔ)服務(wù)腌歉。相對(duì)比，一個(gè)微服務(wù)應(yīng)用一般由大批服務(wù)構(gòu)成齐苛。例如翘盖，根據(jù)Adrian Cockcroft，Hailo有160個(gè)不同服務(wù)構(gòu)成凹蜂，NetFlix有大約600個(gè)服務(wù)馍驯。每個(gè)服務(wù)都有多個(gè)實(shí)例。這就造成許多需要配置玛痊、部署汰瘫、擴(kuò)展和監(jiān)控的部分，除此之外擂煞，你還需要完成一個(gè)服務(wù)發(fā)現(xiàn)機(jī)制（后續(xù)文章中發(fā)表）混弥，以用來發(fā)現(xiàn)與它通訊服務(wù)的地址（包括服務(wù)器地址和端口）。傳統(tǒng)的解決問題辦法不能用于解決這么復(fù)雜的問題对省。接續(xù)而來蝗拿，成功部署一個(gè)微服務(wù)應(yīng)用需要開發(fā)者有足夠的控制部署方法，并高度自動(dòng)化蒿涎。

一種自動(dòng)化方法是使用PaaS服務(wù)哀托，例如Cloud Foundry。PaaS給開發(fā)者提供一個(gè)部署和管理微服務(wù)的簡(jiǎn)單方法劳秋，它把所有這些問題都打包內(nèi)置解決了仓手。同時(shí)，配置PaaS的系統(tǒng)和網(wǎng)絡(luò)專家可以采用最佳實(shí)踐和策略來簡(jiǎn)化這些問題玻淑。另外一個(gè)自動(dòng)部署微服務(wù)應(yīng)用的方法是開發(fā)對(duì)于你來說最基礎(chǔ)的PaaS系統(tǒng)嗽冒。一個(gè)典型的開始點(diǎn)是使用一個(gè)集群化方案，比如配合Docker使用Mesos或者Kubernetes岁忘。后面的系列我們會(huì)看看如何基于軟件部署方法例如NGINX辛慰，可以方便的在微服務(wù)層面提供緩存、權(quán)限控制干像、API統(tǒng)計(jì)和監(jiān)控帅腌。

總結(jié)

構(gòu)建復(fù)雜的應(yīng)用真的是非常困難。單體式的架構(gòu)更適合輕量級(jí)的簡(jiǎn)單應(yīng)用麻汰。如果你用它來開發(fā)復(fù)雜應(yīng)用速客，那真的會(huì)很糟糕。微服務(wù)架構(gòu)模式可以用來構(gòu)建復(fù)雜應(yīng)用五鲫，當(dāng)然溺职，這種架構(gòu)模型也有自己的缺點(diǎn)和挑戰(zhàn)。

在后續(xù)的博客中，我會(huì)深入探索微服務(wù)架構(gòu)模式浪耘，并討論諸如服務(wù)發(fā)現(xiàn)乱灵、服務(wù)部署選擇和如何分解一個(gè)分布式應(yīng)用為多個(gè)服務(wù)的策略。

待續(xù)七冲。痛倚。。澜躺。

DockOne.io

DockOne蝉稳，新圈子，新思路掘鄙，新視野耘戚。