本文出自Nginx官網(wǎng)，是微服務(wù)介紹系列文章的第六篇。原文地址：https://www.nginx.com/blog/deploying-microservices/

1.介紹

在第一篇文章中我們比較了微服務(wù)架構(gòu)應(yīng)用和單體應(yīng)用的差異，討論了微服務(wù)架構(gòu)的優(yōu)點(diǎn)與缺點(diǎn)；第二篇文章和第三篇文章討論了進(jìn)程間通信相關(guān)的問題；第四篇文章討論服務(wù)發(fā)現(xiàn)問題；第五篇文章介紹了如何使用事件驅(qū)動架構(gòu)處理分布式數(shù)據(jù)管理；在本篇文章中我們討論微服務(wù)的部署策略。

2.動機(jī)

單體應(yīng)用一般會部署多個(gè)副本，通常在多臺物理機(jī)或虛擬機(jī)上部署多個(gè)應(yīng)用實(shí)例來實(shí)現(xiàn)，這比微服務(wù)應(yīng)用的部署簡單多了。

微服務(wù)架構(gòu)的應(yīng)用由幾十甚至幾百個(gè)服務(wù)組成，服務(wù)使用的開發(fā)語言和技術(shù)框架可能各不相同，每個(gè)服務(wù)都是獨(dú)立應(yīng)用，有自己獨(dú)有的部署方式、資源需求、伸縮特性和監(jiān)控需求。有可能需要根據(jù)某個(gè)服務(wù)的具體需求，運(yùn)行特定數(shù)量的實(shí)例；每個(gè)服務(wù)有不同的CPU、內(nèi)存和IO需求；除了這些復(fù)雜性之外，更具挑戰(zhàn)性的需求是服務(wù)部署必須快速、可靠、低成本。下面介紹幾種不同的部署模式。

3.單主機(jī)多服務(wù)實(shí)例模式

該種模式是應(yīng)用部署的傳統(tǒng)模式，在每個(gè)物理機(jī)或者虛擬機(jī)上使用知名端口部署多個(gè)服務(wù)實(shí)例，下圖展示了該種模式：

這種模式有很多變種，一種變種是每個(gè)服務(wù)實(shí)例是一個(gè)進(jìn)程或者進(jìn)程組：你可能使用Tomcat以Web應(yīng)用的形式部署服務(wù)；Node.js的服務(wù)實(shí)例可能包含一個(gè)父進(jìn)程、一個(gè)或者多個(gè)子進(jìn)程。

另外一種變種是在一個(gè)進(jìn)程內(nèi)或者進(jìn)程組內(nèi)運(yùn)行多個(gè)服務(wù)實(shí)例，比如，在一個(gè)Tomcat服務(wù)器上部署多個(gè)Web應(yīng)用；在一個(gè)OSGI容器中運(yùn)行多個(gè)OSGI包。

這種模式的主要好處是資源利用比較高效，多個(gè)服務(wù)實(shí)例共享服務(wù)器和操作系統(tǒng)；在一個(gè)進(jìn)程或者進(jìn)程組中運(yùn)行多個(gè)服務(wù)實(shí)例資源利用會更高效，比如多個(gè)Web應(yīng)用共享一個(gè)Tomcat和JVM。

另外一個(gè)優(yōu)點(diǎn)是部署服務(wù)速度快，只用把服務(wù)拷貝到服務(wù)器上啟動即可：服務(wù)可能是Java編譯成的JAR或者WAR文件，也可能是Node.js或者Ruby的源代碼；不管哪種，需要通過網(wǎng)絡(luò)傳遞的數(shù)據(jù)量不大。

這種模式下，啟動速度通常比較快。如果服務(wù)本身是進(jìn)程，簡單啟動即可；如果服務(wù)是容器進(jìn)程或者容器進(jìn)程組的實(shí)例，將實(shí)例動態(tài)部署到容器進(jìn)程或者重啟容器進(jìn)程即可。

這種模式的缺點(diǎn)是除了服務(wù)實(shí)例自身作為進(jìn)程之外，其他情況下服務(wù)實(shí)例不是相互獨(dú)立的。也許你能精確監(jiān)測每個(gè)服務(wù)的資源占用率，卻不能限制每個(gè)服務(wù)的資源使用；某個(gè)異常服務(wù)可能會消耗光主機(jī)的CPU和內(nèi)存資源。

如果多個(gè)服務(wù)運(yùn)行在同一個(gè)進(jìn)程中，那服務(wù)就沒有一點(diǎn)兒獨(dú)立性了。所有的服務(wù)實(shí)例共享JVM堆棧，某個(gè)異常服務(wù)會影響同進(jìn)程中的其他服務(wù)；更嚴(yán)重的是，你根本沒有辦法監(jiān)測每個(gè)服務(wù)實(shí)例的資源占用。

另外一個(gè)問題是部署人員需要了解更多細(xì)節(jié)，不同服務(wù)可能使用不同的語言和框架，這意味著開發(fā)團(tuán)隊(duì)需要跟部署團(tuán)隊(duì)共享很多細(xì)節(jié)，這增加了部署工作的復(fù)雜度，給部署工作帶來了風(fēng)險(xiǎn)。

4.單主機(jī)單服務(wù)實(shí)例模式

在這種模式下，服務(wù)實(shí)例獨(dú)立運(yùn)行在它自己的主機(jī)上，有兩種形式：單虛擬機(jī)單服務(wù)實(shí)例和單容器單服務(wù)實(shí)例。

單虛擬機(jī)單服務(wù)實(shí)例

該種模式下，將服務(wù)打包成虛擬機(jī)映像文件，如Amazon EC2 AMI；每個(gè)服務(wù)實(shí)例都是一個(gè)虛機(jī)，如下圖所示：

Netflix使用這種方式部署視頻流服務(wù)，它使用Aminator將每個(gè)服務(wù)打包成虛機(jī)映像文件（EC2 AMI），每個(gè)服務(wù)實(shí)例都是個(gè)EC2實(shí)例。

有許多工具可用來進(jìn)行虛擬機(jī)打包，可以使用持續(xù)集成服務(wù)器（像Jenkins），由它調(diào)用Aminator自動將服務(wù)打包成EC2 AMI；Packer.io是另外一個(gè)自動打包工具，它支持更多的虛擬化技術(shù)，像EC2、DigitalOcean、VirtualBox、VMware等。

Boxfuse提供另外一種選擇，它將java應(yīng)用打包成輕量級的虛擬機(jī)映像文件；這種映像文件支持快速打包、快速啟動，有更高的安全性。

CloudNative公司的Bakery產(chǎn)品提供創(chuàng)建亞馬遜虛擬機(jī)（EC2 AMIs）的SaaS服務(wù)，你可以配置持續(xù)集成服務(wù)器調(diào)用Bakery打包服務(wù)，生成虛機(jī)映像文件AMI。使用Bakery的好處是，你不用浪費(fèi)時(shí)間設(shè)置創(chuàng)建AMI的環(huán)境。

單虛擬機(jī)單服務(wù)實(shí)例模式的最大好處是服務(wù)實(shí)例之間完全獨(dú)立，每個(gè)實(shí)例有固定數(shù)量的CPU和內(nèi)存，不會占用其他服務(wù)的資源；另外一個(gè)好處是可以充分利用成熟的云架構(gòu)，像AWS就能提供負(fù)載均衡、自動伸縮等有用功能；還有一個(gè)好處是服務(wù)打包成VM之后，成了黑盒，外界無法得知服務(wù)采用的技術(shù)，部署和管理完全使用虛擬機(jī)管理的API，簡化了部署工作。

單虛擬機(jī)單服務(wù)實(shí)例的缺點(diǎn)是資源利用率低，每一個(gè)服務(wù)獨(dú)占VM，需要單獨(dú)的操作系統(tǒng)，一般的云平臺提供幾種固定大小的內(nèi)存、CPU等，這會造成資源浪費(fèi)；另外，雖然云平臺支持自動伸縮特性，但是很難快速適應(yīng)變化，這就需要部署人員不斷手工調(diào)整VM配置，增加了部署工作量；另外一個(gè)缺點(diǎn)是部署速度慢，因?yàn)閂M映像文件大，打包、實(shí)例化、啟動速度都慢，當(dāng)然這不是絕對的，也有些輕量級VM解決方案（如Boxfuse）；還有一個(gè)缺點(diǎn)是創(chuàng)建和管理VM需要進(jìn)行大量的重復(fù)工作，這些工作會分散精力，讓你不能專注于核心業(yè)務(wù)。

單容器單服務(wù)實(shí)例

這種模式下，服務(wù)運(yùn)行在自己的容器中。容器是一種操作系統(tǒng)層面的虛擬化技術(shù)，可以包含一個(gè)或幾個(gè)運(yùn)行在沙箱中的進(jìn)程；容器中的進(jìn)程擁有獨(dú)立的端口號和文件系統(tǒng)，可以限制容器可使用的CPU和內(nèi)存資源，有些還支持限定I/O速率；常用的容器技術(shù)有Docker和Solaris Zones。下圖展示了這種模式：

使用這種模式，應(yīng)用被打包成容器映像文件。映像文件包括服務(wù)文件和運(yùn)行服務(wù)需要的庫文件。有些容器映像文件包括完整的linux文件系統(tǒng)，有些更輕量級一些。假設(shè)需要部署一個(gè)Java服務(wù)，映像文件需要包括Java運(yùn)行時(shí)環(huán)境（可能是Tomcat）和編譯后的Java應(yīng)用。

打包成映像文件之后，就可以將映像文件部署到一個(gè)或幾個(gè)主機(jī)（物理或虛擬）上，可以使用類似Kubernetes和Marathon的集群管理工具來管理容器。集群管理工具將主機(jī)（物理或虛擬）看做資源池，它根據(jù)容器的資源需求和每個(gè)主機(jī)的可用資源來決定將容器部署到哪個(gè)主機(jī)上。

這種模式類似單服務(wù)單主機(jī)，優(yōu)點(diǎn)是服務(wù)實(shí)例之間相互獨(dú)立，很容易監(jiān)控每個(gè)服務(wù)實(shí)例的資源占用；封裝了服務(wù)實(shí)現(xiàn)，外部不容易獲得服務(wù)的技術(shù)細(xì)節(jié)；可以使用容器管理API管理服務(wù)，部署簡單。這種模式跟單服務(wù)單主機(jī)模式的不同點(diǎn)是，容器映像文件小，打包、啟動速度都特別快。

單服務(wù)單容器模式的缺點(diǎn)是容器的基礎(chǔ)設(shè)施沒有VM的基礎(chǔ)設(shè)施成熟；另外由于同一臺主機(jī)上的多個(gè)容器需要共享同一套操作系統(tǒng)內(nèi)核，容器沒有VM安全。另外一個(gè)缺點(diǎn)是需要做大量的重復(fù)性工作來管理容器映像文件；此外，除非使用托管容器解決方案（如Google Container Engine或Amazon EC2 Container Service（ECS）），否則必須手動管理容器基礎(chǔ)設(shè)施以及VM的基礎(chǔ)設(shè)施。

無服務(wù)器部署

AWS Lambda是一種無服務(wù)器部署技術(shù)，支持Java、Node.js和Python編寫的服務(wù)。服務(wù)部署時(shí)需要打成ZIP包，上傳到AWS Lambda；還需要提供元數(shù)據(jù)，定義響應(yīng)請求的方法名稱。?AWS?Lambda自動運(yùn)行適當(dāng)數(shù)量的服務(wù)實(shí)例處理服務(wù)請求，你只需要按照請求花費(fèi)的時(shí)間和內(nèi)存付費(fèi)。這種技術(shù)也有局限性，但是對于開發(fā)人員和部署人員而言，不用關(guān)心物理服務(wù)器、虛機(jī)、容器，還是很有吸引力。

Lambda方法是無狀態(tài)服務(wù)，一般通過調(diào)用AWS服務(wù)來處理請求。比如，當(dāng)用戶向S3 bucket上傳一個(gè)圖像文件時(shí)，調(diào)用Lambda方法向DynamoDB的圖像表中插入一條數(shù)據(jù)，并向Kinesis stream發(fā)布圖像處理事件。Lambda方法也能調(diào)用第三方的Web服務(wù)。

調(diào)用Lambda方法有四種方法：1.使用服務(wù)請求直接調(diào)用；2.消費(fèi)AWS服務(wù)發(fā)布的事件時(shí)，自動調(diào)用；3.AWS API網(wǎng)關(guān)處理客戶端請求時(shí)，自動調(diào)用；4.類似Cron計(jì)劃，定期調(diào)用。

AWS?Lambda是部署微服務(wù)的簡便方法，基于請求付費(fèi)意味著你只用在服務(wù)真正運(yùn)行時(shí)花錢；另外，由于不用關(guān)心IT基礎(chǔ)設(shè)施，你可以集中精力處理業(yè)務(wù)邏輯。

AWS?Lambda有明顯的局限性：它不適合部署運(yùn)行時(shí)間長的服務(wù)，比如消費(fèi)第三方消息的服務(wù)，一次服務(wù)必須在300秒內(nèi)完成；服務(wù)必須是無狀態(tài)的；服務(wù)必須支持快速啟動，否則可能因?yàn)槌瑫r(shí)而被終止。

5.總結(jié)

部署微服務(wù)架構(gòu)的應(yīng)用是件困難的工作，因?yàn)閼?yīng)用可能包含數(shù)十個(gè)甚至數(shù)百個(gè)服務(wù)，每個(gè)服務(wù)可能使用不同的語言和架構(gòu)，每個(gè)服務(wù)都是一個(gè)小型應(yīng)用（有自己獨(dú)特的部署需求、資源需求、伸縮性和監(jiān)控需求）。有幾種服務(wù)部署模式：單主機(jī)單服務(wù)、單容器單服務(wù)、無服務(wù)部署（AWS?Lambda）。在第七篇，也就是本系列的最后一篇文章中，我們將討論如何將單體應(yīng)用遷移到微服務(wù)架構(gòu)。