微服務(wù)正在博客、社交媒體討論組和會(huì)議演講中獲得越來(lái)越多的關(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í)施提供巨大的幫助怀浆。
首先我們看看為什么要使用微服務(wù)谊囚。
開(kāi)發(fā)單體式應(yīng)用
假設(shè)你正準(zhǔn)備開(kāi)發(fā)一款與Uber和Hailo競(jìng)爭(zhēng)的出租車調(diào)度軟件，經(jīng)過(guò)初步會(huì)議和需求分析执赡，你可能會(huì)手動(dòng)或者使用基于Rails镰踏、Spring Boot、Play或者M(jìn)aven的生成器開(kāi)始這個(gè)新項(xiàng)目沙合，它的六邊形架構(gòu)是模塊化的 奠伪，架構(gòu)圖如下：
應(yīng)用核心是業(yè)務(wù)邏輯，由定義服務(wù)首懈、域?qū)ο蠛褪录哪K完成绊率。圍繞著核心的是與外界打交道的適配器。適配器包括數(shù)據(jù)庫(kù)訪問(wèn)組件究履、生產(chǎn)和處理消息的消息組件滤否，以及提供API或者UI訪問(wèn)支持的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)用開(kāi)發(fā)風(fēng)格很常見(jiàn)剑逃，因?yàn)镮DE和其它工具都擅長(zhǎng)開(kāi)發(fā)一個(gè)簡(jiǎn)單應(yīng)用浙宜，這類應(yīng)用也很易于調(diào)試，只需要簡(jiǎn)單運(yùn)行此應(yīng)用蛹磺，用Selenium鏈接 UI就可以完成端到端測(cè)試梆奈。單體式應(yīng)用也易于部署，只需要把打包應(yīng)用拷貝到服務(wù)器端称开，通過(guò)在負(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中， 開(kāi)發(fā)團(tuán)隊(duì)都會(huì)面對(duì)新“故事”焰轻，然后開(kāi)發(fā)許多新代碼臭觉。幾Year后，這個(gè)小而簡(jiǎn)單的應(yīng)用會(huì)變成了一個(gè)巨大的怪物辱志。這兒有一個(gè)例子蝠筑，我最近和一個(gè)開(kāi)發(fā)者討論，他正在 寫一個(gè)工具揩懒，用來(lái)分析他們一個(gè)擁有數(shù)百萬(wàn)行代碼的應(yīng)用中JAR文件之間的依賴關(guān)系什乙。我很確信這個(gè)代碼正是很多開(kāi)發(fā)者經(jīng)過(guò)多Year努力開(kāi)發(fā)出來(lái)的一個(gè)怪物。
一旦你的應(yīng)用變成一個(gè)又大又復(fù)雜的怪物已球，那開(kāi)發(fā)團(tuán)隊(duì)肯定很痛苦臣镣。敏捷開(kāi)發(fā)和部署舉步維艱，其中最主要問(wèn)題就是這個(gè)應(yīng)用太復(fù)雜智亮，以至于任何單個(gè)開(kāi) 發(fā)者都不可能搞懂它忆某。因此，修正bug和正確的添加新功能變的非常困難阔蛉，并且很耗時(shí)弃舒。另外，團(tuán)隊(duì)士氣也會(huì)走下坡路状原。如果代碼難于理解棒坏，就不可能被正確的修 改。最終會(huì)走向巨大的遭笋、不可理解的泥潭。
單體式應(yīng)用也會(huì)降低開(kāi)發(fā)速度徒探。應(yīng)用越大瓦呼，啟動(dòng)時(shí)間會(huì)越長(zhǎng)。比如测暗，最近的一個(gè)調(diào)查表明央串，有時(shí)候應(yīng)用的啟動(dòng)時(shí)間居然超過(guò)了12分鐘。我還聽(tīng)說(shuō)某些應(yīng)用需要40分鐘啟動(dòng)時(shí)間碗啄。如果開(kāi)發(fā)者需要經(jīng)常重啟應(yīng)用质和，那么大部分時(shí)間就要在等待中渡過(guò)，生產(chǎn)效率受到極大影響稚字。
另外饲宿，復(fù)雜而巨大的單體式應(yīng)用也不利于持續(xù)性開(kāi)發(fā)厦酬。今天，SaaS應(yīng)用常態(tài)就是每天會(huì)改變很多次瘫想，而這對(duì)于單體式應(yīng)用模式非常困難仗阅。另外，這種變化帶來(lái)的影響并沒(méi)有很好的被理解国夜，所以不得不做很多手工測(cè)試减噪。那么接下來(lái)，持續(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è)問(wèn)題是可靠性豪治。因?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è)想你有兩百萬(wàn)行采用XYZ框架寫的代碼键菱。如果想改成ABC框架谬墙，無(wú)論是時(shí)間還是成本都是非常昂貴的，即使ABC框架更好经备。因此拭抬，這是一個(gè)無(wú)法逾越的鴻溝。你不得不在最初選擇面前低頭侵蒙。
總結(jié)一下：一開(kāi)始你有一個(gè)很成功的關(guān)鍵業(yè)務(wù)應(yīng)用造虎，后來(lái)就變成了一個(gè)巨大的，無(wú)法理解的怪物纷闺。因?yàn)椴捎眠^(guò)時(shí)的算凿，效率低的技術(shù)份蝴，使得雇傭有潛力的開(kāi)發(fā)者很困難。應(yīng)用無(wú)法擴(kuò)展澎媒，可靠性很低搞乏，最終，敏捷性開(kāi)發(fā)和部署變的無(wú)法完成戒努。
那么如何應(yīng)對(duì)呢请敦？
微處理架構(gòu)——處理復(fù)雜事物
許多公司，比如Amazon储玫、eBay和NetFlix侍筛，通過(guò)采用微處理結(jié)構(gòu)模式解決了上述問(wèn)題。其思路不是開(kāi)發(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ù)開(kāi)放一個(gè)REST API娜睛，許多服務(wù)本身也采用了其它服務(wù)提供的API。比如冕杠，駕駛員管理使用了告知駕駛員一個(gè)潛在需求的通知服務(wù)。UI服務(wù)激活其它服務(wù)來(lái)更新Web頁(yè)面酸茴。所有服務(wù)都是采用異步的分预，基于消息的通訊。微服務(wù)內(nèi)部機(jī)制將會(huì)在后續(xù)系列中討論薪捍。
一些REST API也對(duì)乘客和駕駛員采用的移動(dòng)應(yīng)用開(kāi)放笼痹。這些應(yīng)用并不直接訪問(wèn)后臺(tái)服務(wù)配喳，而是通過(guò)API Gateway來(lái)傳遞中間消息。API Gateway負(fù)責(zé)負(fù)載均衡凳干、緩存晴裹、訪問(wèn)控制、API 計(jì)費(fèi)監(jiān)控等等任務(wù)救赐，可以通過(guò)NGINX方便實(shí)現(xiàn)涧团，后續(xù)文章將會(huì)介紹到API Gateway。
·微服務(wù)架構(gòu)模式在上圖中對(duì)應(yīng)于代表可擴(kuò)展Scale Cube的Y軸经磅，這是一個(gè)在《The Art of Scalability》書中描述過(guò)的三維擴(kuò)展模型泌绣。另外兩個(gè)可擴(kuò)展軸，X軸由負(fù)載均衡器后端運(yùn)行的多個(gè)應(yīng)用副本組成预厌，Z軸是將需求路由到相關(guān)服務(wù)阿迈。
應(yīng)用基本可以用以上三個(gè)維度來(lái)表示，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ù)帶來(lái)的好處燕垃，每個(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ù)昨悼。
表面上看來(lái)，微服務(wù)架構(gòu)模式有點(diǎn)像SOA跃洛，他們都由多個(gè)服務(wù)構(gòu)成率触。但是，可以從另外一個(gè)角度看此問(wèn)題，微服務(wù)架構(gòu)模式是一個(gè)不包含Web服務(wù) （WS-）和ESB服務(wù)的SOA。微服務(wù)應(yīng)用樂(lè)于采用簡(jiǎn)單輕量級(jí)協(xié)議刊头，比如REST硝皂，而不是WS-，在微服務(wù)內(nèi)部避免使用ESB以及ESB類似功能。微服 務(wù)架構(gòu)模式也拒絕使用canonical schema等SOA概念。
微服務(wù)架構(gòu)的好處
微服務(wù)架構(gòu)模式有很多好處。首先悼凑，通過(guò)分解巨大單體式應(yīng)用為多個(gè)服務(wù)方法解決了復(fù)雜性問(wèn)題。在功能不變的情況下璧瞬，應(yīng)用被分解為多個(gè)可管理的分支 或服務(wù)户辫。每個(gè)服務(wù)都有一個(gè)用RPC-或者消息驅(qū)動(dòng)API定義清楚的邊界。微服務(wù)架構(gòu)模式給采用單體式編碼方式很難實(shí)現(xiàn)的功能提供了模塊化的解決方案嗤锉，由 此渔欢，單個(gè)服務(wù)很容易開(kāi)發(fā)、理解和維護(hù)瘟忱。
第二奥额，這種架構(gòu)使得每個(gè)服務(wù)都可以有專門開(kāi)發(fā)團(tuán)隊(duì)來(lái)開(kāi)發(fā)。開(kāi)發(fā)者可以自由選擇開(kāi)發(fā)技術(shù)访诱，提供API服務(wù)垫挨。當(dāng)然，許多公司試圖避免混亂触菜，只提供某 些技術(shù)選擇九榔。然后，這種自由意味著開(kāi)發(fā)者不需要被迫使用某項(xiàng)目開(kāi)始時(shí)采用的過(guò)時(shí)技術(shù)，他們可以選擇現(xiàn)在的技術(shù)帚屉。甚至于，因?yàn)榉?wù)都是相對(duì)簡(jiǎn)單漾峡，即使用現(xiàn)在 技術(shù)重寫以前代碼也不是很困難的事情攻旦。
第三，微服務(wù)架構(gòu)模式是每個(gè)微服務(wù)獨(dú)立的部署生逸。開(kāi)發(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ī)模來(lái)部署滿足需求的規(guī)模。甚至于乾戏，你可以使用更適合于服務(wù)資源需求的硬件迂苛。 比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服務(wù)鼓择，而在EC2 memory-optimized instances上部署內(nèi)存數(shù)據(jù)庫(kù)三幻。
微服務(wù)架構(gòu)的不足
Fred Brooks在30Year前寫道，“there are no silver bullets”呐能，像任何其它科技一樣念搬，微服務(wù)架構(gòu)也有不足。其中一個(gè)跟他的名字類似摆出，『微服務(wù)』強(qiáng)調(diào)了服務(wù)大小朗徊，實(shí)際上，有一些開(kāi)發(fā)者鼓吹建立稍微大一 些的懊蒸，10-100 LOC服務(wù)組荣倾。盡管小服務(wù)更樂(lè)于被采用，但是不要忘了這只是終端的選擇而不是最終的目的骑丸。微服務(wù)的目的是有效的拆分應(yīng)用舌仍，實(shí)現(xiàn)敏捷開(kāi)發(fā)和部署。
另外一個(gè)主要的不足是通危，微服務(wù)應(yīng)用是分布式系統(tǒng)铸豁，由此會(huì)帶來(lái)固有的復(fù)雜性。開(kāi)發(fā)者需要在RPC或者消息傳遞之間選擇并完成進(jìn)程間通訊機(jī)制菊碟。更甚 于节芥，他們必須寫代碼來(lái)處理消息傳遞中速度過(guò)慢或者不可用等局部失效問(wèn)題。當(dāng)然這并不是什么難事，但相對(duì)于單體式應(yīng)用中通過(guò)語(yǔ)言層級(jí)的方法或者進(jìn)程調(diào)用头镊，微 服務(wù)下這種技術(shù)顯得更復(fù)雜一些蚣驼。
另外一個(gè)關(guān)于微服務(wù)的挑戰(zhàn)來(lái)自于分區(qū)的數(shù)據(jù)庫(kù)架構(gòu)。商業(yè)交易中同時(shí)給多個(gè)業(yè)務(wù)分主體更新消息很普遍相艇。這種交易對(duì)于單體式應(yīng)用來(lái)說(shuō)很容易颖杏，因?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ì)開(kāi)發(fā)者提出了更高的要求和挑戰(zhàn)活喊。
測(cè)試一個(gè)基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)丐膝。比如，采用流行的Spring Boot架構(gòu)钾菊，對(duì)一個(gè)單體式web應(yīng)用尤误，測(cè)試它的REST API，是很容易的事情结缚。反過(guò)來(lái)损晤，同樣的服務(wù)測(cè)試需要啟動(dòng)和它有關(guān)的所有服務(wù)（至少需要這些服務(wù)的stubs）。再重申一次红竭，不能低估了采用微服務(wù)架構(gòu)帶 來(lái)的復(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宫莱，NetFlix 有大約600個(gè)服務(wù)丈攒。每個(gè)服務(wù)都有多個(gè)實(shí)例。這就造成許多需要配置授霸、部署巡验、擴(kuò)展和監(jiān)控的部分，除此之外碘耳，你還需要完成一個(gè)服務(wù)發(fā)現(xiàn)機(jī)制（后續(xù)文章中發(fā) 表）显设，以用來(lái)發(fā)現(xiàn)與它通訊服務(wù)的地址（包括服務(wù)器地址和端口）。傳統(tǒng)的解決問(wèn)題辦法不能用于解決這么復(fù)雜的問(wèn)題辛辨。接續(xù)而來(lái)捕捂，成功部署一個(gè)微服務(wù)應(yīng)用需要開(kāi) 發(fā)者有足夠的控制部署方法，并高度自動(dòng)化斗搞。
總結(jié)
構(gòu)建復(fù)雜的應(yīng)用真的是非常困難。單體式的架構(gòu)更適合輕量級(jí)的簡(jiǎn)單應(yīng)用。如果你用它來(lái)開(kāi)發(fā)復(fù)雜應(yīng)用姚淆，那真的會(huì)很糟糕孕蝉。微服務(wù)架構(gòu)模式可以用來(lái)構(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ì)源碼參考來(lái)源：http://minglisoft.cn/technology?歡迎大家一起學(xué)習(xí)研究相關(guān)技術(shù)媒惕，源碼獲取請(qǐng)加求求（企鵝）:1370869617
