編者的話|本文來自 Nginx 官方博客庵芭，是微服務(wù)系列文章的第一篇敬肚，主要探討了傳統(tǒng)的單體式應(yīng)用的不足，以及微服務(wù)架構(gòu)的優(yōu)勢與挑戰(zhàn)。
作者介紹：Chris Richardson兴溜，是世界著名的軟件大師，經(jīng)典技術(shù)著作《POJOS IN ACTION》一書的作者益愈，也是 cloudfoundry.com 最初的創(chuàng)始人扣囊，Chris Richardson 與 Martin Fowler、Sam Newman悔橄、Adrian Cockcroft 等并稱為世界十大軟件架構(gòu)師靶累。
微服務(wù)在當(dāng)下引起廣泛關(guān)注腺毫，成為文章、博客挣柬、社交媒體討論和大會演講的熱點潮酒；在 Gartner 的 “Hype Cycle” 上排名也非常靠前邪蛔。與此同時急黎，在軟件社區(qū)也有人質(zhì)疑微服務(wù)并非新事物。反對者認(rèn)為微服務(wù)只是 SOA （Service Oriented Architecture）的二度包裝侧到。然而勃教，無論是追捧還是質(zhì)疑，微服務(wù)架構(gòu)擁有巨大優(yōu)勢匠抗，尤其是它讓敏捷開發(fā)和復(fù)雜的企業(yè)應(yīng)用交付成為可能故源。
本系列包含 7 篇文章，介紹了微服務(wù)的設(shè)計戈咳、構(gòu)建和部署心软，并與傳統(tǒng)的單體架構(gòu)進行了比較。本系列將分析微服務(wù)架構(gòu)的各種因素著蛙，你也將了解微服務(wù)架構(gòu)模型的優(yōu)劣删铃、是否適合你的項目，以及如何應(yīng)用踏堡。
Chris Richardson 微服務(wù)系列全 7 篇：
1. 微服務(wù)架構(gòu)概念解析(本篇文章)
2. 構(gòu)建微服務(wù)架構(gòu)：使用 API Gateway
3. 深入微服務(wù)架構(gòu)的進程間通信
4. 服務(wù)發(fā)現(xiàn)的可行方案以及實踐案例
5. 微服務(wù)的事件驅(qū)動數(shù)據(jù)管理
6. 選擇微服務(wù)部署策略
7. 將單體應(yīng)用改造為微服務(wù)
首先讓我們了解為何要將微服務(wù)納入考量猎唁。
構(gòu)建單體應(yīng)用
假設(shè)我們要開發(fā)一款全新的與 Uber 和 Hailo 競爭的打車軟件。在前期的會議和需求整理后顷蟆，你要么需要手動創(chuàng)建一個新項目诫隅，要么可以使用 Rails、Spring Boot帐偎、Play 或者 Maven 來生成逐纬。這個新應(yīng)用可能采用了六邊形架構(gòu)模塊，如下圖所示：
應(yīng)用的核心是商業(yè)邏輯削樊，它由定義服務(wù)豁生、域?qū)ο蠛褪录髂K來完成。各種適配器圍繞核心與外部交互漫贞。適配器包括數(shù)據(jù)庫訪問組件甸箱、生產(chǎn)和消費 信息的消息組件，以及提供 API 或者 UI 訪問支持的 web 模塊迅脐。
盡管擁有邏輯縝密的模塊化設(shè)計芍殖，整個應(yīng)用仍然以整體打包和部署，實際格式依賴于應(yīng)用的語言和框架谴蔑。譬如豌骏，許多 Java 應(yīng)用被打包為 WAR 文件龟梦，部署在 Tomcat 或者 Jetty 這樣的應(yīng)用服務(wù)器。有些 Java 應(yīng)用本身就是包涵 JARs 的軟件包肯适。與此類似变秦，Rails 和 Node.js 應(yīng)用也通過目錄層級打包。
采用此種風(fēng)格的應(yīng)用非常普遍框舔。由于 IDE 和其他工具擅長構(gòu)建單一應(yīng)用蹦玫，這類應(yīng)用也易于部署。這類應(yīng)用也非常容易測試刘绣。你可以非常輕松地進行端到端測試樱溉，使用 Selenium 測試 UI 。整體應(yīng)用也便于部署纬凤，只需將軟件包復(fù)制到服務(wù)器福贞。你也可以通過運行多個包和負(fù)載均衡實現(xiàn)擴展。在項目早期這么做非常有效停士。
踏入單體架構(gòu)的地獄
很不幸挖帘，這一簡單的方法有著巨大的局限。成功的應(yīng)用最終會隨著時間變得巨大恋技。在每個 sprint 階段拇舀，開發(fā)團隊都會新加許多行代碼。幾年后蜻底，原本小而簡單的應(yīng)用會變得臃腫骄崩。舉個極端的例子，我最近與一位開發(fā)者交流薄辅，他正在開發(fā)一款小工具要拂，來分析他們應(yīng)用（包括幾百萬行代碼）中的幾千個 JARs 的依賴。我相信每年都會有大量開發(fā)者不遺余力地對付這種麻煩站楚。
一旦你的應(yīng)用變得龐大脱惰、復(fù)雜，你的開發(fā)團隊將飽受折磨窿春，苦苦掙扎于敏捷開發(fā)和交付拉一。一大原因就是應(yīng)用已經(jīng)格外復(fù)雜，龐大到任何一個開發(fā)者都無法完全理解谁尸。最后，修復(fù) bug 和實施新功能也就極其困難且耗時頗多纽甘。更可怕的是良蛮，這是一個向下的螺旋發(fā)展。代碼庫越難理解悍赢，正確的修改就越難决瞳。最后你會深陷龐大的货徙、無法估量的泥淖之中。
而這種應(yīng)用的尺寸也會拖慢開發(fā)進度皮胡。應(yīng)用越大痴颊，啟動時間越長。譬如在最近的調(diào)查中屡贺，不少開發(fā)者指出啟動時間長達(dá) 12 分鐘蠢棱。我也聽說有的應(yīng)用啟動時間居然得 40 分鐘。如果開發(fā)者不得不頻繁重啟應(yīng)用服務(wù)器甩栈，那大量時間就被浪費泻仙，生產(chǎn)效率也飽受其害。
龐大且復(fù)雜的單體應(yīng)用的另一大問題就是難以進行持續(xù)部署×棵唬現(xiàn)在玉转， SaaS 應(yīng)用的發(fā)展水平足以在單日內(nèi)多次將修改推送到生產(chǎn)環(huán)境。然而要讓復(fù)雜的單個應(yīng)用達(dá)到此水平卻極為棘手殴蹄。想更新應(yīng)用的單個部分究抓，必須重新部署整個應(yīng)用，漫長的啟動時間更是雪上加霜袭灯。另外刺下，由于不能完全預(yù)見修改的影響，你不得不提前進行大量人工測試妓蛮。結(jié)果就是怠李，持續(xù)部署變得不可能。
如果單體應(yīng)用的不同模塊在資源需求方面有沖突的話蛤克，那應(yīng)用的擴展也很難捺癞。比如，模塊之一需要執(zhí)行 CPU-intensive 圖像處理邏輯构挤，最好部署到 AWS 的 EC2 Compute Optimized instances髓介；而另一模塊需要內(nèi)存數(shù)據(jù)庫，最好適配 EC2 Memory-optimized instances筋现。由于這兩個模塊需要共同部署唐础，你不得不在在硬件選擇方面做妥協(xié)。
單體應(yīng)用的另一問題就是可靠性矾飞。由于所有模塊都運行在同一進程中一膨，任何模塊中的一個 bug，比如內(nèi)存泄漏都可能弄垮整個進程洒沦；此外豹绪，由于應(yīng)用中的所有實例都是唯一，這個 bug 將影響整個應(yīng)用的可用性申眼。
最后瞒津，單體應(yīng)用會讓采用新框架和語言極其困難蝉衣。舉例來說，你有兩百萬行使用 XYZ 框架的代碼巷蚪，如果要使用 ABC 框架重寫代碼病毡，無論時間還是成本都將非常高昂，即便新框架更好屁柏。這也就成為使用新技術(shù)的阻礙啦膜。
總結(jié)：這個一開始曾經(jīng)成功關(guān)鍵業(yè)務(wù)應(yīng)用，最終卻變成一個臃腫的前联、無法理解的龐然大物功戚。它使用老舊、陳腐似嗤、低效的技術(shù)啸臀，幾乎吸引不到出色的開發(fā)者。這個應(yīng)用非常難于擴展烁落，也不穩(wěn)定可靠乘粒。最終，敏捷開發(fā)和交付幾乎成為不可能伤塌。
你該何去何從灯萍？
微服務(wù)--直擊痛點
諸如亞馬遜、eBay每聪、Netflix 等公司已經(jīng)通過采用微服務(wù)架構(gòu)范式解決了上文（第一部分）提到的問題旦棉。不同于構(gòu)建單一、龐大的應(yīng)用药薯，微服務(wù)架構(gòu)將應(yīng)用拆分為一套小且互相關(guān)聯(lián)的服務(wù)绑洛。
一個微服務(wù)一般完成某個特定的功能，比如訂單管理童本、客戶管理等真屯。每個微服務(wù)都是一個微型應(yīng)用，有著自己六邊形架構(gòu)穷娱，包括商業(yè)邏輯和各種接口绑蔫。有的微服務(wù)通過暴露 API 被別的微服務(wù)或者應(yīng)用客戶端所用；有的微服務(wù)則通過網(wǎng)頁 UI 實現(xiàn)泵额。在運行時配深，每個實例通常是一個云虛擬機或者 Docker 容器。
對于前文所述的系統(tǒng)嫁盲，一種可能的系統(tǒng)分解圖如下：
應(yīng)用的每個功能區(qū)都由其自身微服務(wù)實施篓叶。此外，整個網(wǎng)頁應(yīng)用被拆分為一套簡單的網(wǎng)頁應(yīng)用（比如我們的打車軟件拆分為乘客應(yīng)用和司機應(yīng)用），從而能夠輕松地針對特定用戶澜共、設(shè)備或者用戶案例進行單獨部署。
每個后端服務(wù)包括一個 REST API 和由其它服務(wù)提供的服務(wù)消耗 API锥腻。例如嗦董，司機管理服務(wù)使用“通知”服務(wù)器來告知司機即將的行程。UI 服務(wù)喚醒其它服務(wù)瘦黑，從而呈現(xiàn)網(wǎng)頁京革。這些服務(wù)也可能用到基于信息的異步通信。內(nèi)部服務(wù)通信會在本系列文章中詳述幸斥。
有的 REST API 也對司機和乘客的移動應(yīng)用開放匹摇。這些應(yīng)用并不能直接訪問后端服務(wù)器，相反甲葬，通信由名為 API Gateway 的中間人調(diào)解廊勃。API Gateway 負(fù)責(zé)負(fù)載均衡、緩存经窖、訪問控制坡垫、API 計費、監(jiān)控等画侣，通過 NGINX 高效實施冰悠。本系列的后續(xù)文章將會講解 API Gateway。
上圖是 Scale Cube 的 3D 模型配乱，來自《The Art of Scalability》 一書溉卓。微服務(wù)架構(gòu)范式對應(yīng) Y 軸，X 軸由負(fù)載均衡器后端運行的多個應(yīng)用副本組成搬泥，Z 軸（數(shù)據(jù)分割）將需求路由到相關(guān)服務(wù)桑寨。
應(yīng)用通常同時使用這三種不同類型的擴展。Y 軸擴展將應(yīng)用分解為如圖一所示的微服務(wù)佑钾。在運行時維度西疤，X 軸擴展在輸出和可用性的負(fù)載均衡后運行多個實例。部分應(yīng)用會使用 Z 軸擴展來對服務(wù)進行數(shù)據(jù)分割休溶。下圖展示了行程管理服務(wù)（Trip Management）是如何使用 Docker 部署到 AWS EC2 上的代赁。
在運行時，行程管理服務(wù)包括多個服務(wù)實例兽掰，每個服務(wù)實例都是一個 Docker 容器芭碍。為了實現(xiàn)高可用性，這些容器運行在多個云虛擬機上孽尽。在應(yīng)用實例前面是 NGINX 這樣的負(fù)載均衡窖壕，將請求分發(fā)給全部實例。負(fù)載均衡也可以處理緩存、訪問控制瞻讽、 API 測量和監(jiān)控等鸳吸。
微服務(wù)架構(gòu)范式對應(yīng)用和數(shù)據(jù)庫的關(guān)系影響巨大。每個服務(wù)都有自身的數(shù)據(jù)庫計劃速勇，而不與其它服務(wù)共享同一個數(shù)據(jù)庫晌砾。一方面，這個方法類似企業(yè)級數(shù)據(jù)模型烦磁。同時养匈，它也導(dǎo)致部分?jǐn)?shù)據(jù)的重復(fù)。然而都伪，要想從微服務(wù)中獲益呕乎，為每個服務(wù)提供單個的數(shù)據(jù)庫計劃就非常必要，這能保證松散耦合陨晶。下面的圖表展示了示例應(yīng)用的數(shù)據(jù)庫架構(gòu)猬仁。
每個服務(wù)都有其自己的數(shù)據(jù)庫。此外先誉，單個服務(wù)可以使用符合自己需要的特定類型的數(shù)據(jù)庫逐虚，即多語言一致性架構(gòu)。例如谆膳，為了發(fā)現(xiàn)附近乘客叭爱，駕駛員管理服務(wù)必須使用高效支持地理位置請求的數(shù)據(jù)庫。
表面上看漱病，微服務(wù)架構(gòu)范式與 SOA 非常類似买雾，這兩種架構(gòu)都包括一套服務(wù)。然而杨帽，微服務(wù)架構(gòu)范式被看作不包含某些功能的 SOA 漓穿。這些功能包括網(wǎng)絡(luò)服務(wù)說明（ WS-* ）和 Enterprise Service Bus (ESB) 的商品化和請求包∽⒂基于微服務(wù)的應(yīng)用更青睞 REST 這樣簡單的晃危、輕量級的協(xié)議，而不是 WS-* 老客。他們也極力避免在微服務(wù)中使用 ESBs 及類似功能僚饭。微服務(wù)架構(gòu)范式也拒絕 SOA 的其它部分，比如 canonical schema 的概念胧砰。
微服務(wù)架構(gòu)的好處
微服務(wù)架構(gòu)模式有很多好處鳍鸵。首先，通過分解巨大單體應(yīng)用為多個服務(wù)方法解決了復(fù)雜性問題尉间。在功能不變的情況下偿乖，應(yīng)用被分解為多個可管理的分支或服務(wù)击罪。每個服務(wù)都有一個用 RPC- 或者消息驅(qū)動 API 定義清楚的邊界。微服務(wù)架構(gòu)模式給采用單體式編碼方式很難實現(xiàn)的功能提供了模塊化的解決方案贪薪，由此媳禁，單個服務(wù)很容易開發(fā)、理解和維護画切。
第二损话，這種架構(gòu)使得每個服務(wù)都可以有專門開發(fā)團隊來開發(fā)。開發(fā)者可以自由選擇開發(fā)技術(shù)槽唾，提供 API 服務(wù)。當(dāng)然光涂，許多公司試圖避免混亂庞萍，只提供某些技術(shù)選擇。然后忘闻，這種自由意味著開發(fā)者不需要被迫使用某項目開始時采用的過時技術(shù)钝计，他們可以選擇現(xiàn)在的技術(shù)。甚至于齐佳，因為服務(wù)都是相對簡單私恬，即使用現(xiàn)在技術(shù)重寫以前代碼也不是很困難的事情。
第三炼吴，微服務(wù)架構(gòu)模式使得每個微服務(wù)獨立部署本鸣，開發(fā)者不再需要協(xié)調(diào)其它服務(wù)部署對本服務(wù)的影響。這種改變可以加快部署速度硅蹦，譬如 UI 團隊可以采用 AB 測試并快速部署變化荣德。微服務(wù)架構(gòu)模式使得持續(xù)化部署成為可能。
最后童芹，微服務(wù)架構(gòu)模式使得每個服務(wù)獨立擴展涮瞻。你可以根據(jù)每個服務(wù)的規(guī)模來部署滿足需求的實利。甚至于假褪，你可以使用更適合于服務(wù)資源需求的硬件署咽。比如，你可以在 EC2 Compute Optimized instances 上部署 CPU 敏感的服務(wù)生音，而在 EC2 memory-optimized instances 上部署內(nèi)存數(shù)據(jù)庫宁否。
微服務(wù)架構(gòu)的不足
Fred Brooks 在 30 年前寫道 “there are no silver bullets”，像任何其它科技一樣缀遍，微服務(wù)架構(gòu)也有不足家淤。其中一個跟他的名字類似，“微服務(wù)”強調(diào)了服務(wù)大小瑟由，實際上絮重，有一些開發(fā)者鼓吹建立稍微大一些的冤寿，10-100 LOC服務(wù)組。盡管小服務(wù)更樂于被采用青伤，但是不要忘了微服務(wù)只是結(jié)果督怜，而不是最終目的。微服務(wù)的目的是有效的拆分應(yīng)用狠角，實現(xiàn)敏捷開發(fā)和部署号杠。
另外一個不足之處在于，微服務(wù)應(yīng)用是分布式系統(tǒng)丰歌，由此會帶來固有的復(fù)雜性姨蟋。開發(fā)者需要在 RPC 或者消息傳遞之間選擇并完成進程間通訊機制。此外立帖，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題眼溶。當(dāng)然這并不是什么難事，但相對于單體式應(yīng)用中通過語言層級的方法或者進程調(diào)用晓勇，微服務(wù)下這種技術(shù)顯得更復(fù)雜一些堂飞。
另外一個關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構(gòu)。同時更新多個業(yè)務(wù)主體的事務(wù)很普遍绑咱。這種事務(wù)對于單體式應(yīng)用來說很容易绰筛，因為只有一個數(shù)據(jù)庫。在微服務(wù)架構(gòu)應(yīng)用中描融，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫铝噩。使用分布式事務(wù)并不一定是好的選擇，不僅僅是因為 CAP 理論窿克，還因為當(dāng)前高擴展性的 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硅卢。幸運的是，許多改變一般只影響一個服務(wù)藏杖，而需要協(xié)調(diào)多服務(wù)的改變很少将塑。
部署一個微服務(wù)應(yīng)用也很復(fù)雜，一個單體應(yīng)用只需要在復(fù)雜均衡器后面部署各自的服務(wù)器就好了蝌麸。每個應(yīng)用實例是需要配置諸如數(shù)據(jù)庫和消息中間件等基礎(chǔ)服務(wù)点寥。相比之下，一個微服務(wù)應(yīng)用一般由大批服務(wù)構(gòu)成来吩。根據(jù) Adrian Cockcroft 的分享敢辩，Hailo 由 160 個不同服務(wù)構(gòu)成，而 NetFlix 則超過 600 個服務(wù)弟疆。每個服務(wù)都有多個實例戚长，這就形成大量需要配置、部署怠苔、擴展和監(jiān)控的部分同廉。除此之外，你還需要完成一個服務(wù)發(fā)現(xiàn)機制（后續(xù)文章中發(fā)表）柑司，以用來發(fā)現(xiàn)與它通訊服務(wù)的地址（包括服務(wù)器地址和端口）迫肖。傳統(tǒng)的解決問題辦法并不能解決這么復(fù)雜的問題。最終攒驰，成功部署一個微服務(wù)應(yīng)用需要開發(fā)者有足夠的控制部署方法蟆湖，并高度自動化。
自動化的方法之一是使用譬如 Cloud Foundry 這樣的 PaaS 服務(wù)玻粪。PaaS 能讓開發(fā)者輕松部署和管理微服務(wù)隅津，讓他們無需為獲取并配置 IT 資源勞神诬垂。同時，配置 PaaS 的系統(tǒng)和網(wǎng)絡(luò)專家可以采用最佳實踐和策略來簡化這些問題饥瓷。另外一個自動部署微服務(wù)應(yīng)用的方法是開發(fā)自己的基礎(chǔ) PaaS 系統(tǒng)剥纷。通常的起步方式是 Mesos 或 Kubernetes 這樣的集群管理方案，配合 Docker 使用呢铆。作為一種基于軟件的應(yīng)用交付方法晦鞋，NGINX 能夠方便地在微服務(wù)層面提供緩沖、權(quán)限控制棺克、API 統(tǒng)計悠垛、以及監(jiān)控。我們會在后續(xù)的文章中分析它如何解決這些問題娜谊。
總結(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)模型也有自己的缺點和挑戰(zhàn)搀缠。
在后續(xù)的博客中，我會深入探索微服務(wù)架構(gòu)模式近迁，并討論多個話題艺普，包括服務(wù)發(fā)現(xiàn)、服務(wù)部署選擇鉴竭、以及將單體應(yīng)用拆分為多個服務(wù)的策略歧譬。
文章轉(zhuǎn)載至：http://blog.daocloud.io/microservices-1/
