編者的話(huà)｜本文來(lái)自 Nginx 官方博客，是微服務(wù)系列文章的第一篇功戚，主要探討了傳統(tǒng)的單體式應(yīng)用的不足娶眷，以及微服務(wù)架構(gòu)的優(yōu)勢(shì)與挑戰(zhàn)。
作者介紹：Chris Richardson啸臀，是世界著名的軟件大師届宠，經(jīng)典技術(shù)著作《POJOS IN ACTION》一書(shū)的作者，也是 cloudfoundry.com 最初的創(chuàng)始人乘粒，Chris Richardson 與 Martin Fowler豌注、Sam Newman、Adrian Cockcroft 等并稱(chēng)為世界十大軟件架構(gòu)師灯萍。
Chris Richardson 所著所有文章已獨(dú)家授權(quán) DaoCloud 翻譯并刊載轧铁。
本系列包含 7 篇文章，介紹了微服務(wù)的設(shè)計(jì)旦棉、構(gòu)建和部署齿风，并與傳統(tǒng)的單體架構(gòu)進(jìn)行了比較药薯。本系列將分析微服務(wù)架構(gòu)的各種因素，你也將了解微服務(wù)架構(gòu)模型的優(yōu)劣救斑、是否適合你的項(xiàng)目童本，以及如何應(yīng)用。
Chris Richardson 微服務(wù)系列全 7 篇：
本期內(nèi)容
微服務(wù)在當(dāng)下引起廣泛關(guān)注脸候，成為文章穷娱、博客、社交媒體討論和大會(huì)演講的熱點(diǎn)运沦；在 Gartner 的 “Hype Cycle” 上排名也非潮枚睿靠前。與此同時(shí)携添，在軟件社區(qū)也有人質(zhì)疑微服務(wù)并非新事物嫁盲。反對(duì)者認(rèn)為微服務(wù)只是 SOA （Service Oriented Architecture）的二度包裝。然而薪寓，無(wú)論是追捧還是質(zhì)疑亡资，微服務(wù)架構(gòu)擁有巨大優(yōu)勢(shì)，尤其是它讓敏捷開(kāi)發(fā)和復(fù)雜的企業(yè)應(yīng)用交付成為可能向叉。
首先讓我們了解為何要將微服務(wù)納入考量锥腻。
構(gòu)建單體應(yīng)用
假設(shè)我們要開(kāi)發(fā)一款全新的與 Uber 和 Hailo 競(jìng)爭(zhēng)的打車(chē)軟件。在前期的會(huì)議和需求整理后母谎，你要么需要手動(dòng)創(chuàng)建一個(gè)新項(xiàng)目瘦黑，要么可以使用 Rails、Spring Boot奇唤、Play 或者 Maven 來(lái)生成幸斥。這個(gè)新應(yīng)用可能采用了六邊形架構(gòu)模塊，如下圖所示：
應(yīng)用的核心是商業(yè)邏輯咬扇，它由定義服務(wù)甲葬、域?qū)ο蠛褪录髂K來(lái)完成。各種適配器圍繞核心與外部交互懈贺。適配器包括數(shù)據(jù)庫(kù)訪(fǎng)問(wèn)組件经窖、生成和 consume 信息的消息組件，以及提供 API 或者 UI 訪(fǎng)問(wèn)支持的 web 模塊梭灿。
盡管擁有邏輯縝密的模塊化設(shè)計(jì)画侣，整個(gè)應(yīng)用仍然以整體打包和部署，實(shí)際格式依賴(lài)于應(yīng)用的語(yǔ)言和框架堡妒。譬如配乱，許多 Java 應(yīng)用被打包為 WAR 文件，部署在 Tomcat 或者 Jetty 這樣的應(yīng)用服務(wù)器。有些 Java 應(yīng)用本身就是包涵 JARs 的軟件包搬泥。與此類(lèi)似桑寨，Rails 和 Node.js 應(yīng)用也通過(guò)目錄層級(jí)打包。
采用此種風(fēng)格的應(yīng)用非常普遍佑钾。由于 IDE 和其他工具擅長(zhǎng)構(gòu)建單一應(yīng)用西疤，這類(lèi)應(yīng)用也易于部署。這類(lèi)應(yīng)用也非常容易測(cè)試休溶。你可以非常輕松地進(jìn)行端到端測(cè)試，使用 Selenium 測(cè)試 UI 扰她。整體應(yīng)用也便于部署兽掰，只需將軟件包復(fù)制到服務(wù)器。你也可以通過(guò)運(yùn)行多個(gè)包和負(fù)載均衡實(shí)現(xiàn)擴(kuò)展徒役。在項(xiàng)目早期這么做非常有效孽尽。
踏入單體架構(gòu)的地獄
很不幸，這一簡(jiǎn)單的方法有著巨大的局限忧勿。成功的應(yīng)用最終會(huì)隨著時(shí)間變得巨大杉女。在每個(gè) sprint 階段，開(kāi)發(fā)團(tuán)隊(duì)都會(huì)新加許多行代碼鸳吸。幾年后熏挎，原本小而簡(jiǎn)單的應(yīng)用會(huì)變得臃腫。舉個(gè)極端的例子晌砾，我最近與一位開(kāi)發(fā)者交流坎拐，他正在開(kāi)發(fā)一款小工具，來(lái)分析他們應(yīng)用（包括幾百萬(wàn)行代碼）中的幾千個(gè) JARs 的依賴(lài)养匈。我相信每年都會(huì)有大量開(kāi)發(fā)者不遺余力地對(duì)付這種麻煩哼勇。
一旦你的應(yīng)用變得龐大、復(fù)雜呕乎，你的開(kāi)發(fā)團(tuán)隊(duì)將飽受折磨积担，苦苦掙扎于敏捷開(kāi)發(fā)和交付。一大原因就是應(yīng)用已經(jīng)格外復(fù)雜猬仁，龐大到任何一個(gè)開(kāi)發(fā)者都無(wú)法完全理解帝璧。最后，修復(fù) bug 和實(shí)施新功能也就極其困難且耗時(shí)頗多逐虚。更可怕的是聋溜，這是一個(gè)向下的螺旋發(fā)展。代碼庫(kù)越難理解叭爱，正確的修改就越難撮躁。最后你會(huì)深陷龐大的、無(wú)法估量的泥淖之中买雾。
而這種應(yīng)用的尺寸也會(huì)拖慢開(kāi)發(fā)進(jìn)度把曼。應(yīng)用越大杨帽，啟動(dòng)時(shí)間越長(zhǎng)。譬如在最近的調(diào)查中嗤军，不少開(kāi)發(fā)者指出啟動(dòng)時(shí)間長(zhǎng)達(dá) 12 分鐘注盈。我也聽(tīng)說(shuō)有的應(yīng)用啟動(dòng)時(shí)間居然得 40 分鐘。如果開(kāi)發(fā)者不得不頻繁重啟應(yīng)用服務(wù)器叙赚，那大量時(shí)間就被浪費(fèi)老客，生產(chǎn)效率也飽受其害。
龐大且復(fù)雜的單體應(yīng)用的另一大問(wèn)題就是難以進(jìn)行持續(xù)部署≌鸲＃現(xiàn)在胧砰， SaaS 應(yīng)用的發(fā)展水平足以在單日內(nèi)多次將修改推送到生產(chǎn)環(huán)境。然而要讓復(fù)雜的單個(gè)應(yīng)用達(dá)到此水平卻極為棘手苇瓣。想更新應(yīng)用的單個(gè)部分尉间，必須重新部署整個(gè)應(yīng)用，漫長(zhǎng)的啟動(dòng)時(shí)間更是雪上加霜击罪。另外哲嘲，由于不能完全預(yù)見(jiàn)修改的影響，你不得不提前進(jìn)行大量人工測(cè)試媳禁。結(jié)果就是眠副，持續(xù)部署變得不可能。
如果單體應(yīng)用的不同模塊在資源需求方面有沖突的話(huà)损话，那應(yīng)用的擴(kuò)展也很難侦啸。比如，模塊之一需要執(zhí)行 CPU-intensive 圖像處理邏輯丧枪，最好部署到 AWS 的 EC2 Compute Optimized instances光涂；而另一模塊需要內(nèi)存數(shù)據(jù)庫(kù)，最好適配 EC2 Memory-optimized instances拧烦。由于這兩個(gè)模塊需要共同部署忘闻，你不得不在在硬件選擇方面做妥協(xié)。
單體應(yīng)用的另一問(wèn)題就是可靠性恋博。由于所有模塊都運(yùn)行在同一進(jìn)程中齐佳，任何模塊中的一個(gè) bug，比如內(nèi)存泄漏都可能弄垮整個(gè)進(jìn)程债沮；此外炼吴，由于應(yīng)用中的所有實(shí)例都是唯一，這個(gè) bug 將影響整個(gè)應(yīng)用的可用性疫衩。
最后硅蹦，單體應(yīng)用會(huì)讓采用新框架和語(yǔ)言極其困難。舉例來(lái)說(shuō)，你有兩百萬(wàn)行使用 XYZ 框架的代碼童芹，如果要使用 ABC 框架重寫(xiě)代碼涮瞻，無(wú)論時(shí)間還是成本都將非常高昂，即便新框架更好假褪。這也就成為使用新技術(shù)的阻礙署咽。
總結(jié)：這個(gè)一開(kāi)始曾經(jīng)成功關(guān)鍵業(yè)務(wù)應(yīng)用，最終卻變成一個(gè)臃腫的生音、無(wú)法理解的龐然大物宁否。它使用老舊、陳腐缀遍、低效的技術(shù)家淤，幾乎吸引不到出色的開(kāi)發(fā)者。這個(gè)應(yīng)用非常難于擴(kuò)展瑟由，也不穩(wěn)定可靠。最終冤寿，敏捷開(kāi)發(fā)和交付幾乎成為不可能歹苦。
你該何去何從？
微服務(wù)——直擊痛點(diǎn)
諸如亞馬遜督怜、eBay殴瘦、Netflix 等公司已經(jīng)通過(guò)采用微服務(wù)架構(gòu)范式解決了上文（第一部分）提到的問(wèn)題。不同于構(gòu)建單一号杠、龐大的應(yīng)用蚪腋，微服務(wù)架構(gòu)將應(yīng)用拆分為一套小且互相關(guān)聯(lián)的服務(wù)。
一個(gè)微服務(wù)一般完成某個(gè)特定的功能姨蟋，比如訂單管理屉凯、客戶(hù)管理等。每個(gè)微服務(wù)都是一個(gè)微型應(yīng)用眼溶，有著自己六邊形架構(gòu)悠砚，包括商業(yè)邏輯和各種接口。有的微服務(wù)通過(guò)暴露 API 被別的微服務(wù)或者應(yīng)用客戶(hù)端所用堂飞；有的微服務(wù)則通過(guò)網(wǎng)頁(yè) UI 實(shí)現(xiàn)灌旧。在運(yùn)行時(shí)，每個(gè)實(shí)例通常是一個(gè)云虛擬機(jī)或者 Docker 容器绰筛。
對(duì)于前文所述的系統(tǒng)枢泰，一種可能的系統(tǒng)分解圖如下：
應(yīng)用的每個(gè)功能區(qū)都由其自身微服務(wù)實(shí)施。此外铝噩，整個(gè)網(wǎng)頁(yè)應(yīng)用被拆分為一套簡(jiǎn)單的網(wǎng)頁(yè)應(yīng)用（比如我們的打車(chē)軟件拆分為乘客應(yīng)用和司機(jī)應(yīng)用）衡蚂，從而能夠輕松地針對(duì)特定用戶(hù)、設(shè)備或者用戶(hù)案例進(jìn)行單獨(dú)部署。
每個(gè)后端服務(wù)包括一個(gè) REST API 和由其它服務(wù)提供的服務(wù)消耗 API讳窟。例如让歼，司機(jī)管理服務(wù)使用“通知”服務(wù)器來(lái)告知司機(jī)即將的行程。UI 服務(wù)喚醒其它服務(wù)丽啡，從而呈現(xiàn)網(wǎng)頁(yè)谋右。這些服務(wù)也可能用到基于信息的異步通信。內(nèi)部服務(wù)通信會(huì)在本系列文章中詳述补箍。
有的 REST API 也對(duì)司機(jī)和乘客的移動(dòng)應(yīng)用開(kāi)放改执。這些應(yīng)用并不能直接訪(fǎng)問(wèn)后端服務(wù)器，相反坑雅，通信由名為 API Gateway 的中間人調(diào)解辈挂。AIP Gateway 負(fù)責(zé)負(fù)載均衡、緩存裹粤、訪(fǎng)問(wèn)控制终蒂、API 計(jì)費(fèi)、監(jiān)控等遥诉，通過(guò) NGINX 高效實(shí)施拇泣。本系列的后續(xù)文章將會(huì)講解 API Gateway。
上圖是 Scale Cube 的 3D 模型矮锈，來(lái)自《The Art of Scalability》 一書(shū)霉翔。微服務(wù)架構(gòu)范式對(duì)應(yīng) Y 軸，X 軸由負(fù)載均衡器后端運(yùn)行的多個(gè)應(yīng)用副本組成苞笨，Z 軸（數(shù)據(jù)分割）將需求路由到相關(guān)服務(wù)债朵。
應(yīng)用通常同時(shí)使用這三種不同類(lèi)型的擴(kuò)展。Y 軸擴(kuò)展將應(yīng)用分解為如圖一（https://www.nginx.com/wp-content/uploads/2015/05/Graph-031-e1431992337817.png）所示的微服務(wù)瀑凝。在運(yùn)行時(shí)維度序芦，X 軸擴(kuò)展在輸出和可用性的負(fù)載均衡后運(yùn)行多個(gè)實(shí)例。部分應(yīng)用會(huì)使用 Z 軸擴(kuò)展來(lái)對(duì)服務(wù)進(jìn)行數(shù)據(jù)分割猜丹。下圖展示了行程管理服務(wù)（Trip Management）是如何使用 Docker 部署到 AWS EC2 上的芝加。
在運(yùn)行時(shí)，行程管理服務(wù)包括多個(gè)服務(wù)實(shí)例射窒，每個(gè)服務(wù)實(shí)例都是一個(gè) Docker 容器藏杖。為了實(shí)現(xiàn)高可用性，這些容器運(yùn)行在多個(gè)云虛擬機(jī)上脉顿。在應(yīng)用實(shí)例前面是 NGINX 這樣的負(fù)載均衡蝌麸，將請(qǐng)求分發(fā)給全部實(shí)例。負(fù)載均衡也可以處理緩存艾疟、訪(fǎng)問(wèn)控制来吩、 API 測(cè)量和監(jiān)控等敢辩。
微服務(wù)架構(gòu)范式對(duì)應(yīng)用和數(shù)據(jù)庫(kù)的關(guān)系影響巨大。每個(gè)服務(wù)都有自身的數(shù)據(jù)庫(kù)計(jì)劃弟疆，而不與其它服務(wù)共享同一個(gè)數(shù)據(jù)庫(kù)戚长。一方面，這個(gè)方法類(lèi)似企業(yè)級(jí)數(shù)據(jù)模型怠苔。同時(shí)同廉，它也導(dǎo)致部分?jǐn)?shù)據(jù)的重復(fù)。然而柑司，要想從微服務(wù)中獲益迫肖，為每個(gè)服務(wù)提供單個(gè)的數(shù)據(jù)庫(kù)計(jì)劃就非常必要，這能保證松散耦合攒驰。下面的圖表展示了示例應(yīng)用的數(shù)據(jù)庫(kù)架構(gòu)蟆湖。
每個(gè)服務(wù)都有其自己的數(shù)據(jù)庫(kù)。此外玻粪，單個(gè)服務(wù)可以使用符合自己需要的特定類(lèi)型的數(shù)據(jù)庫(kù)隅津，即多語(yǔ)言一致性架構(gòu)。例如劲室，為了發(fā)現(xiàn)附近乘客饥瓷，駕駛員管理服務(wù)必須使用高效支持地理位置請(qǐng)求的數(shù)據(jù)庫(kù)。
表面上看痹籍，微服務(wù)架構(gòu)范式與 SOA 非常類(lèi)似，這兩種架構(gòu)都包括一套服務(wù)晦鞋。然而蹲缠，微服務(wù)架構(gòu)范式被看作不包含某些功能的 SOA 。這些功能包括網(wǎng)絡(luò)服務(wù)說(shuō)明（ WS-* ）和 Enterprise Service Bus (ESB) 的商品化和請(qǐng)求包悠垛∠叨ǎ基于微服務(wù)的應(yīng)用更青睞 REST 這樣簡(jiǎn)單的、輕量級(jí)的協(xié)議确买，而不是 WS-* 斤讥。他們也極力避免在微服務(wù)中使用 ESBs 及類(lèi)似功能。微服務(wù)架構(gòu)范式也拒絕 SOA 的其它部分湾趾，比如 canonical schema 的概念芭商。
微服務(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ù)都可以有專(zhuān)門(mén)開(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ù)重寫(xiě)以前代碼也不是很困難的事情。
第三靴拱，微服務(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)部署滿(mǎn)足需求的實(shí)利。甚至于陌知，你可以使用更適合于服務(wù)資源需求的硬件他托。比如，你可以在 EC2 Compute Optimized instances 上部署 CPU 敏感的服務(wù)仆葡，而在 EC2 memory-optimized instances 上部署內(nèi)存數(shù)據(jù)庫(kù)赏参。
微服務(wù)架構(gòu)的不足
Fred Brooks 在 30 年前寫(xiě)道 “there are no silver bullets”，像任何其它科技一樣沿盅，微服務(wù)架構(gòu)也有不足把篓。其中一個(gè)跟他的名字類(lèi)似，“微服務(wù)”強(qiáng)調(diào)了服務(wù)大小腰涧，實(shí)際上纸俭，有一些開(kāi)發(fā)者鼓吹建立稍微大一些的，10-100 LOC服務(wù)組南窗。盡管小服務(wù)更樂(lè)于被采用揍很，但是不要忘了微服務(wù)只是結(jié)果郎楼，而不是最終目的。微服務(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ī)制。此外聋庵，他們必須寫(xiě)代碼來(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)。同時(shí)更新多個(gè)業(yè)務(wù)主體的事務(wù)很普遍脱货。這種事務(wù)對(duì)于單體式應(yīng)用來(lái)說(shuō)很容易岛都，因?yàn)橹挥幸粋€(gè)數(shù)據(jù)庫(kù)。在微服務(wù)架構(gòu)應(yīng)用中振峻，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫(kù)臼疫。使用分布式事務(wù)并不一定是好的選擇，不僅僅是因?yàn)?CAP 理論扣孟，還因?yàn)楫?dāng)前高擴(kuò)展性的 NoSQL 數(shù)據(jù)庫(kù)和消息傳遞中間件并不支持這一需求烫堤。最終你不得不使用一個(gè)最終一致性的方法，從而對(duì)開(kāi)發(fā)者提出了更高的要求和挑戰(zhàn)凤价。
測(cè)試一個(gè)基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)塔逃。比如，對(duì)于采用流行的 Spring Boot 架構(gòu)的單體式 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 依賴(lài) B，B 依賴(lài) 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)用只需要在復(fù)雜均衡器后面部署各自的服務(wù)器就好了段化。每個(gè)應(yīng)用實(shí)例是需要配置諸如數(shù)據(jù)庫(kù)和消息中間件等基礎(chǔ)服務(wù)嘁捷。相比之下，一個(gè)微服務(wù)應(yīng)用一般由大批服務(wù)構(gòu)成显熏。根據(jù) Adrian Cockcroft 的分享雄嚣，Hailo 由 160 個(gè)不同服務(wù)構(gòu)成，而 NetFlix 則超過(guò) 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)題。最終棘脐，成功部署一個(gè)微服務(wù)應(yīng)用需要開(kāi)發(fā)者有足夠的控制部署方法斜筐，并高度自動(dòng)化。
自動(dòng)化的方法之一是使用譬如 Cloud Foundry 這樣的 PaaS 服務(wù)蛀缝。PaaS 能讓開(kāi)發(fā)者輕松部署和管理微服務(wù)顷链，讓他們無(wú)需為獲取并配置 IT 資源勞神。同時(shí)屈梁，配置 PaaS 的系統(tǒng)和網(wǎng)絡(luò)專(zhuān)家可以采用最佳實(shí)踐和策略來(lái)簡(jiǎn)化這些問(wèn)題嗤练。另外一個(gè)自動(dòng)部署微服務(wù)應(yīng)用的方法是開(kāi)發(fā)自己的基礎(chǔ) PaaS 系統(tǒng)榛了。通常的起步方式是 Mesos 或 Kubernetes 這樣的集群管理方案，配合 Docker 使用潭苞。作為一種基于軟件的應(yīng)用交付方法忽冻，NGINX 能夠方便地在微服務(wù)層面提供緩沖、權(quán)限控制此疹、API 統(tǒng)計(jì)僧诚、以及監(jiān)控。我們會(huì)在后續(xù)的文章中分析它如何解決這些問(wèn)題蝗碎。
總結(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)模式捎废，并討論多個(gè)話(huà)題笑窜，包括服務(wù)發(fā)現(xiàn)、服務(wù)部署選擇登疗、以及將單體應(yīng)用拆分為多個(gè)服務(wù)的策略排截。
