摘要: 微處理架構(gòu)——處理復(fù)雜事物 　　許多公司慎皱，比如Amazon老虫、eBay和NetFlix，通過采用微處理結(jié)構(gòu)模式解決了上述問題茫多。其思路不是開發(fā)一個巨大的單體式的應(yīng)用祈匙，而是將應(yīng)用分解為小的、互相連接的微服務(wù)。

微服務(wù)正在博客夺欲、社交媒體討論組和會議演講中獲得越來越多的關(guān)注跪帝，在Gartner的2014 Hype Cycle上它的排名非常靠前些阅。同時伞剑，軟件社區(qū)中也有不少持懷疑論者，認(rèn)為微服務(wù)不是什么新東西市埋。Naysayers認(rèn)為這就是SOA架構(gòu)的重新包裝黎泣。然 而，盡管存在著不同的爭論缤谎，微服務(wù)架構(gòu)模式卻正在為敏捷部署以及復(fù)雜企業(yè)應(yīng)用實(shí)施提供巨大的幫助抒倚。

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

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

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

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

盡管也是模塊化邏輯，但是最終它還是會打包并部署為單體式應(yīng)用公罕。具體的格式依賴于應(yīng)用語言和框架器紧。例如，許多Java應(yīng)用會被打包為WAR格 式楼眷，部署在Tomcat或者Jetty上铲汪，而另外一些Java應(yīng)用會被打包成自包含的JAR格式，同樣罐柳，Rails和Node.js會被打包成層級目錄掌腰。

這種應(yīng)用開發(fā)風(fēng)格很常見，因?yàn)镮DE和其它工具都擅長開發(fā)一個簡單應(yīng)用张吉，這類應(yīng)用也很易于調(diào)試齿梁，只需要簡單運(yùn)行此應(yīng)用，用Selenium鏈接 UI就可以完成端到端測試。單體式應(yīng)用也易于部署勺择，只需要把打包應(yīng)用拷貝到服務(wù)器端创南，通過在負(fù)載均衡器后端運(yùn)行多個拷貝就可以輕松實(shí)現(xiàn)應(yīng)用擴(kuò)展。在早期這 類應(yīng)用運(yùn)行的很好酵幕。

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

不幸的是扰藕，這種簡單方法卻有很大的局限性。一個簡單的應(yīng)用會隨著時間推移逐漸變大芳撒。在每次的sprint中邓深， 開發(fā)團(tuán)隊(duì)都會面對新“故事”，然后開發(fā)許多新代碼笔刹。幾Year后芥备，這個小而簡單的應(yīng)用會變成了一個巨大的怪物。這兒有一個例子舌菜，我最近和一個開發(fā)者討論萌壳，他正在 寫一個工具，用來分析他們一個擁有數(shù)百萬行代碼的應(yīng)用中JAR文件之間的依賴關(guān)系日月。我很確信這個代碼正是很多開發(fā)者經(jīng)過多Year努力開發(fā)出來的一個怪物袱瓮。

一旦你的應(yīng)用變成一個又大又復(fù)雜的怪物，那開發(fā)團(tuán)隊(duì)肯定很痛苦爱咬。敏捷開發(fā)和部署舉步維艱尺借，其中最主要問題就是這個應(yīng)用太復(fù)雜，以至于任何單個開 發(fā)者都不可能搞懂它精拟。因此燎斩，修正bug和正確的添加新功能變的非常困難，并且很耗時蜂绎。另外栅表，團(tuán)隊(duì)士氣也會走下坡路。如果代碼難于理解师枣，就不可能被正確的修 改怪瓶。最終會走向巨大的、不可理解的泥潭践美。

單體式應(yīng)用也會降低開發(fā)速度洗贰。應(yīng)用越大，啟動時間會越長拨脉。比如哆姻，最近的一個調(diào)查表明，有時候應(yīng)用的啟動時間居然超過了12分鐘玫膀。我還聽說某些應(yīng)用需要40分鐘啟動時間矛缨。如果開發(fā)者需要經(jīng)常重啟應(yīng)用，那么大部分時間就要在等待中渡過，生產(chǎn)效率受到極大影響箕昭。

另外灵妨，復(fù)雜而巨大的單體式應(yīng)用也不利于持續(xù)性開發(fā)。今天落竹，SaaS應(yīng)用常態(tài)就是每天會改變很多次泌霍，而這對于單體式應(yīng)用模式非常困難。另外述召，這種變化帶來的影響并沒有很好的被理解朱转，所以不得不做很多手工測試。那么接下來积暖，持續(xù)部署也會很艱難藤为。

單體式應(yīng)用在不同模塊發(fā)生資源沖突時，擴(kuò)展將會非常困難夺刑。比如缅疟，一個模塊完成一個CPU敏感邏輯，應(yīng)該部署在AWS EC2 Compute Optimized instances遍愿，而另外一個內(nèi)存數(shù)據(jù)庫模塊更合適于EC2 Memory-optimized instances存淫。然而，由于這些模塊部署在一起沼填，因此不得不在硬件選擇上做一個妥協(xié)桅咆。

單體式應(yīng)用另外一個問題是可靠性。因?yàn)樗心K都運(yùn)行在一個進(jìn)程中倾哺，任何一個模塊中的一個bug轧邪，比如內(nèi)存泄露刽脖，將會有可能弄垮整個進(jìn)程羞海。除此之外，因?yàn)樗袘?yīng)用實(shí)例都是唯一的曲管，這個bug將會影響到整個應(yīng)用的可靠性却邓。

最后，單體式應(yīng)用使得采用新架構(gòu)和語言非常困難院水。比如腊徙，設(shè)想你有兩百萬行采用XYZ框架寫的代碼。如果想改成ABC框架檬某，無論是時間還是成本都是非常昂貴的撬腾，即使ABC框架更好。因此恢恼，這是一個無法逾越的鴻溝民傻。你不得不在最初選擇面前低頭。

總結(jié)一下：一開始你有一個很成功的關(guān)鍵業(yè)務(wù)應(yīng)用，后來就變成了一個巨大的漓踢，無法理解的怪物牵署。因?yàn)椴捎眠^時的，效率低的技術(shù)喧半，使得雇傭有潛力的開發(fā)者很困難奴迅。應(yīng)用無法擴(kuò)展，可靠性很低挺据，最終取具，敏捷性開發(fā)和部署變的無法完成。

那么如何應(yīng)對呢扁耐？

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

許多公司者填，比如Amazon、eBay和NetFlix做葵，通過采用微處理結(jié)構(gòu)模式解決了上述問題占哟。其思路不是開發(fā)一個巨大的單體式的應(yīng)用，而是將應(yīng)用分解為小的酿矢、互相連接的微服務(wù)榨乎。

一個微服務(wù)一般完成某個特定的功能，比如下單管理瘫筐、客戶管理等等蜜暑。每一個微服務(wù)都是微型六角形應(yīng)用，都有自己的業(yè)務(wù)邏輯和適配器策肝。一些微服務(wù)還 會發(fā)布API給其它微服務(wù)和應(yīng)用客戶端使用肛捍。其它微服務(wù)完成一個Web UI，運(yùn)行時之众，每一個實(shí)例可能是一個云VM或者是Docker容器拙毫。

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

每一個應(yīng)用功能區(qū)都使用微服務(wù)完成棺禾，另外缀蹄，Web應(yīng)用會被拆分成一系列簡單的Web應(yīng)用（比如一個對乘客，一個對出租車駕駛員）膘婶。這樣的拆分對于不同用戶缺前、設(shè)備和特殊應(yīng)用場景部署都更容易。

每一個后臺服務(wù)開放一個REST API悬襟，許多服務(wù)本身也采用了其它服務(wù)提供的API衅码。比如，駕駛員管理使用了告知駕駛員一個潛在需求的通知服務(wù)脊岳。UI服務(wù)激活其它服務(wù)來更新Web頁面逝段。所有服務(wù)都是采用異步的筛璧，基于消息的通訊。微服務(wù)內(nèi)部機(jī)制將會在后續(xù)系列中討論惹恃。

一些REST API也對乘客和駕駛員采用的移動應(yīng)用開放夭谤。這些應(yīng)用并不直接訪問后臺服務(wù)，而是通過API Gateway來傳遞中間消息巫糙。API Gateway負(fù)責(zé)負(fù)載均衡朗儒、緩存、訪問控制参淹、API 計(jì)費(fèi)監(jiān)控等等任務(wù)醉锄，可以通過NGINX方便實(shí)現(xiàn)，后續(xù)文章將會介紹到API Gateway浙值。

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

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

運(yùn)行時畜疾，行程管理服務(wù)由多個服務(wù)實(shí)例構(gòu)成。每一個服務(wù)實(shí)例都是一個Docker容器印衔。為了保證高可用啡捶，這些容器一般都運(yùn)行在多個云VM上。服務(wù)實(shí)例前是 一層諸如NGINX的負(fù)載均衡器当编，他們負(fù)責(zé)在各個實(shí)例間分發(fā)請求届慈。負(fù)載均衡器也同時處理其它請求徒溪，例如緩存忿偷、權(quán)限控制、API統(tǒng)計(jì)和監(jiān)控臊泌。

這種微服務(wù)架構(gòu)模式深刻影響了應(yīng)用和數(shù)據(jù)庫之間的關(guān)系鲤桥，不像傳統(tǒng)多個服務(wù)共享一個數(shù)據(jù)庫，微服務(wù)架構(gòu)每個服務(wù)都有自己的數(shù)據(jù)庫渠概。另外茶凳，這種思路也影響到了企業(yè)級數(shù)據(jù)模式嫂拴。同時，這種模式意味著多份數(shù)據(jù)贮喧，但是筒狠，如果你想獲得微服務(wù)帶來的好處，每個服務(wù)獨(dú)有一個數(shù)據(jù)庫是必須的箱沦，因?yàn)檫@種架構(gòu)需要這種松耦合辩恼。下面的圖演示示例應(yīng)用數(shù)據(jù)庫架構(gòu)。

每種服務(wù)都有自己的數(shù)據(jù)庫谓形，另外灶伊，每種服務(wù)可以用更適合自己的數(shù)據(jù)庫類型，也被稱作多語言一致性架構(gòu)寒跳。比如聘萨，駕駛員管理（發(fā)現(xiàn)哪個駕駛員更靠近乘客），必須使用支持地理信息查詢的數(shù)據(jù)庫童太。

表面上看來米辐，微服務(wù)架構(gòu)模式有點(diǎn)像SOA，他們都由多個服務(wù)構(gòu)成书释。但是儡循，可以從另外一個角度看此問題，微服務(wù)架構(gòu)模式是一個不包含Web服務(wù) （WS-）和ESB服務(wù)的SOA征冷。微服務(wù)應(yīng)用樂于采用簡單輕量級協(xié)議择膝，比如REST，而不是WS-检激，在微服務(wù)內(nèi)部避免使用ESB以及ESB類似功能肴捉。微服 務(wù)架構(gòu)模式也拒絕使用canonical schema等SOA概念。

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

微服務(wù)架構(gòu)模式有很多好處叔收。首先齿穗，通過分解巨大單體式應(yīng)用為多個服務(wù)方法解決了復(fù)雜性問題。在功能不變的情況下饺律，應(yīng)用被分解為多個可管理的分支 或服務(wù)窃页。每個服務(wù)都有一個用RPC-或者消息驅(qū)動API定義清楚的邊界。微服務(wù)架構(gòu)模式給采用單體式編碼方式很難實(shí)現(xiàn)的功能提供了模塊化的解決方案复濒，由 此脖卖，單個服務(wù)很容易開發(fā)、理解和維護(hù)巧颈。

第二畦木，這種架構(gòu)使得每個服務(wù)都可以有專門開發(fā)團(tuán)隊(duì)來開發(fā)。開發(fā)者可以自由選擇開發(fā)技術(shù)砸泛，提供API服務(wù)十籍。當(dāng)然蛆封，許多公司試圖避免混亂，只提供某 些技術(shù)選擇勾栗。然后惨篱，這種自由意味著開發(fā)者不需要被迫使用某項(xiàng)目開始時采用的過時技術(shù)，他們可以選擇現(xiàn)在的技術(shù)围俘。甚至于妒蛇，因?yàn)榉?wù)都是相對簡單，即使用現(xiàn)在 技術(shù)重寫以前代碼也不是很困難的事情楷拳。

第三绣夺，微服務(wù)架構(gòu)模式是每個微服務(wù)獨(dú)立的部署。開發(fā)者不再需要協(xié)調(diào)其它服務(wù)部署對本服務(wù)的影響欢揖。這種改變可以加快部署速度陶耍。UI團(tuán)隊(duì)可以采用AB測試，快速的部署變化她混。微服務(wù)架構(gòu)模式使得持續(xù)化部署成為可能烈钞。

最后，微服務(wù)架構(gòu)模式使得每個服務(wù)獨(dú)立擴(kuò)展坤按。你可以根據(jù)每個服務(wù)的規(guī)模來部署滿足需求的規(guī)模毯欣。甚至于，你可以使用更適合于服務(wù)資源需求的硬件臭脓。 比如酗钞，你可以在EC2 Compute Optimized instances上部署CPU敏感的服務(wù)，而在EC2 memory-optimized instances上部署內(nèi)存數(shù)據(jù)庫来累。

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

Fred Brooks在30Year前寫道砚作，“there are no silver bullets”，像任何其它科技一樣嘹锁，微服務(wù)架構(gòu)也有不足葫录。其中一個跟他的名字類似，『微服務(wù)』強(qiáng)調(diào)了服務(wù)大小领猾，實(shí)際上米同，有一些開發(fā)者鼓吹建立稍微大一 些的，10-100 LOC服務(wù)組摔竿。盡管小服務(wù)更樂于被采用面粮，但是不要忘了這只是終端的選擇而不是最終的目的。微服務(wù)的目的是有效的拆分應(yīng)用拯坟，實(shí)現(xiàn)敏捷開發(fā)和部署但金。

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

另外一個關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構(gòu)。商業(yè)交易中同時給多個業(yè)務(wù)分主體更新消息很普遍冗恨。這種交易對于單體式應(yīng)用來說很容易答憔，因?yàn)橹?有一個數(shù)據(jù)庫。在微服務(wù)架構(gòu)應(yīng)用中掀抹，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫虐拓。使用分布式交易并不一定是好的選擇，不僅僅是因?yàn)镃AP理論傲武，還因?yàn)榻裉旄邤U(kuò) 展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這一需求蓉驹。最終你不得不使用一個最終一致性的方法，從而對開發(fā)者提出了更高的要求和挑戰(zhàn)揪利。

測試一個基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)态兴。比如，采用流行的Spring Boot架構(gòu)疟位，對一個單體式web應(yīng)用瞻润，測試它的REST API，是很容易的事情甜刻。反過來敢订，同樣的服務(wù)測試需要啟動和它有關(guān)的所有服務(wù)（至少需要這些服務(wù)的stubs）。再重申一次罢吃，不能低估了采用微服務(wù)架構(gòu)帶 來的復(fù)雜性楚午。

另外一個挑戰(zhàn)在于，微服務(wù)架構(gòu)模式應(yīng)用的改變將會波及多個服務(wù)尿招。比如矾柜，假設(shè)你在完成一個案例，需要修改服務(wù)A就谜、B怪蔑、C，而A依賴B丧荐，B依賴C缆瓣。 在單體式應(yīng)用中，你只需要改變相關(guān)模塊虹统，整合變化弓坞，部署就好了隧甚。對比之下，微服務(wù)架構(gòu)模式就需要考慮相關(guān)改變對不同服務(wù)的影響渡冻。比如戚扳，你需要更新服務(wù)C， 然后是B族吻，最后才是A帽借，幸運(yùn)的是，許多改變一般只影響一個服務(wù)超歌，而需要協(xié)調(diào)多服務(wù)的改變很少砍艾。

部署一個微服務(wù)應(yīng)用也很復(fù)雜，一個分布式應(yīng)用只需要簡單在復(fù)雜均衡器后面部署各自的服務(wù)器就好了巍举。每個應(yīng)用實(shí)例是需要配置諸如數(shù)據(jù)庫和消息中間件等基礎(chǔ)服務(wù)脆荷。相對比，一個微服務(wù)應(yīng)用一般由大批服務(wù)構(gòu)成禀综。例如简烘，根據(jù)Adrian Cockcroft，NetFlix 有大約600個服務(wù)定枷。每個服務(wù)都有多個實(shí)例孤澎。這就造成許多需要配置、部署欠窒、擴(kuò)展和監(jiān)控的部分覆旭，除此之外，你還需要完成一個服務(wù)發(fā)現(xiàn)機(jī)制（后續(xù)文章中發(fā) 表）岖妄，以用來發(fā)現(xiàn)與它通訊服務(wù)的地址（包括服務(wù)器地址和端口）型将。傳統(tǒng)的解決問題辦法不能用于解決這么復(fù)雜的問題。接續(xù)而來荐虐，成功部署一個微服務(wù)應(yīng)用需要開 發(fā)者有足夠的控制部署方法七兜，并高度自動化。

一種自動化方法是使用PaaS服務(wù)福扬，例如Cloud Foundry腕铸。 PaaS給開發(fā)者提供一個部署和管理微服務(wù)的簡單方法，它把所有這些問題都打包內(nèi)置解決了铛碑。同時狠裹，配置PaaS的系統(tǒng)和網(wǎng)絡(luò)專家可以采用最佳實(shí)踐和策略來 簡化這些問題。另外一個自動部署微服務(wù)應(yīng)用的方法是開發(fā)對于你來說最基礎(chǔ)的PaaS系統(tǒng)汽烦。一個典型的開始點(diǎn)是使用一個集群化方案涛菠，比如配合Docker使 用Mesos或者Kubernetes。后面的系列我們會看看如何基于軟件部署方法例如NGINX，可以方便的在微服務(wù)層面提供緩存俗冻、權(quán)限控制礁叔、API統(tǒng) 計(jì)和監(jiān)控。

總結(jié)

構(gòu)建復(fù)雜的應(yīng)用真的是非常困難言疗。單體式的架構(gòu)更適合輕量級的簡單應(yīng)用晴圾。如果你用它來開發(fā)復(fù)雜應(yīng)用颂砸，那真的會很糟糕噪奄。微服務(wù)架構(gòu)模式可以用來構(gòu)建復(fù)雜應(yīng)用，當(dāng)然人乓，這種架構(gòu)模型也有自己的缺點(diǎn)和挑戰(zhàn)勤篮。

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

愿意了解框架技術(shù)或者源碼的朋友直接求求交流分享技術(shù)：2042849237

更多詳細(xì)源碼參考來源：http://minglisoft.cn/technology