【51CTO.com快譯】在過去的幾年中，由于微服務(wù)架構(gòu)(Microservices architecture)能夠提供高級別的軟件可擴(kuò)展性，因此十分流行。盡管大多數(shù)組織都能夠接受這種架構(gòu)模式，但是他們也或多或少地遇到了，諸如如何將應(yīng)用程序分解成為基于微服務(wù)的模式等多方面的挑戰(zhàn)。

過去，我們曾經(jīng)幫助美國最大的電信公司等客戶，成功地實(shí)現(xiàn)了基于REST的微服務(wù)應(yīng)用部署。我們在降低運(yùn)營成本的同時(shí)，提高了整體服務(wù)的可用性。下面，我們將分享四種受歡迎的微服務(wù)部署策略，并在此基礎(chǔ)上和您討論：企業(yè)應(yīng)該如何利用微服務(wù)來獲得更高的敏捷性、靈活性、以及可擴(kuò)展性。

微服務(wù)部署的挑戰(zhàn)

通常，部署單體(monolithic)應(yīng)用意味著您需要配置多臺物理服務(wù)器或虛擬機(jī)，并在每臺服務(wù)器上運(yùn)行某個(gè)大型應(yīng)用程序的多個(gè)實(shí)例。這樣的部署方式雖然簡單直接，但是對于微服務(wù)應(yīng)用卻并不一定適合。

首先，在部署微服務(wù)應(yīng)用之前，您必須熟悉編寫此類服務(wù)所涉及到的各種框架和語言。由于每一項(xiàng)服務(wù)都可能涉及到其特定的部署，不同的資源要求，以及擴(kuò)展和監(jiān)控方面的需求，因此這往往是最大的挑戰(zhàn)之一。其次，就企業(yè)的角度而言，他們希望部署服務(wù)的過程盡量實(shí)現(xiàn)快速、可靠、且具有一定的成本效益?？梢?，我們需要通過靈活、可擴(kuò)展的多種微服務(wù)部署模式，來應(yīng)對廣泛的組件集成請求。

微服務(wù)的部署策略

1.基于主機(jī)(物理機(jī)或虛機(jī))的多服務(wù)實(shí)例

“基于主機(jī)的多服務(wù)實(shí)例”模式是最為傳統(tǒng)的應(yīng)用程序部署方法。在該模式下，軟件開發(fā)人員可以提供單個(gè)或多個(gè)物理機(jī)或虛機(jī)，同時(shí)在每個(gè)主機(jī)上運(yùn)行多個(gè)服務(wù)實(shí)例。此模式有幾種不同的實(shí)現(xiàn)形式，其中包括：將每一個(gè)服務(wù)實(shí)例都作為一個(gè)單獨(dú)的進(jìn)程，或是在同一進(jìn)程中運(yùn)行多個(gè)服務(wù)實(shí)例。

優(yōu)點(diǎn)

由于多個(gè)服務(wù)實(shí)例使用的是同一服務(wù)器、及其操作系統(tǒng)，因此它們的資源使用效率相對較高。

由于您只需要將服務(wù)復(fù)制到主機(jī)上，即可運(yùn)行之，因此服務(wù)實(shí)例的部署也相對較快。例如：如果某個(gè)服務(wù)是由Java編寫的，那么您只需要復(fù)制JAR或WAR文件;而如果它是用Node.js或Ruby編寫的，則復(fù)制源代碼便可。

如果某個(gè)服務(wù)本身帶有進(jìn)程，您可以直接啟動(dòng)之;當(dāng)然也可以將其動(dòng)態(tài)地部署到某個(gè)容器中。而如果該服務(wù)屬于某個(gè)容器進(jìn)程(或進(jìn)程組)，而且正運(yùn)行在多個(gè)實(shí)例里，那么您可以直接對它進(jìn)行重啟。

挑戰(zhàn)

除非每個(gè)實(shí)例都是一個(gè)單獨(dú)的進(jìn)程，否則您對服務(wù)實(shí)例的實(shí)際控制權(quán)并不大。而且，您無法限制每個(gè)實(shí)例能夠使用到的資源比例。這將帶來主機(jī)內(nèi)存被大量消耗的隱患。

如果多個(gè)服務(wù)實(shí)例在同一進(jìn)程中運(yùn)行，它們之間會缺乏隔離關(guān)系。這通常會導(dǎo)致在相同進(jìn)程中，某個(gè)行為異常的服務(wù)能夠直接影響、甚至中斷其他的服務(wù)。

由于運(yùn)營團(tuán)隊(duì)需要了解服務(wù)的詳細(xì)信息，因此在部署期間，他們可能發(fā)生人為錯(cuò)誤的風(fēng)險(xiǎn)較高。顯然，開發(fā)和運(yùn)營團(tuán)隊(duì)之間需要通過必要的信息交換，來盡可能地消除復(fù)雜性。

2.基于主機(jī)(物理機(jī)或虛機(jī))的服務(wù)實(shí)例

此類微服務(wù)的部署方法能夠讓您在對應(yīng)的主機(jī)上單獨(dú)地運(yùn)行每一個(gè)實(shí)例。此處的實(shí)例包括：基于單個(gè)虛擬機(jī)的服務(wù)實(shí)例，和基于單個(gè)容器的服務(wù)實(shí)例。

基于單個(gè)虛擬機(jī)的服務(wù)實(shí)例模式，能夠讓您將每個(gè)服務(wù)打包成為諸如Amazon EC2 AMI的虛擬機(jī)(VM)鏡像。此處的實(shí)例就是指那些通過既有鏡像運(yùn)行起來的VM。目前，使用該模式的一個(gè)典型應(yīng)用便是Netflix的視頻流服務(wù)。為了構(gòu)建自己的VM，您可以配置諸如Jenkins之類的連續(xù)集成服務(wù)器，當(dāng)然也可以直接使用packer.io。

優(yōu)點(diǎn)

基于虛擬機(jī)的服務(wù)實(shí)例有著一項(xiàng)顯著的優(yōu)點(diǎn)：由于是獨(dú)立運(yùn)行，它的內(nèi)存使用數(shù)量是受限的，并且無法從其他服務(wù)中竊取額外的資源。

您可以利用諸如AWS之類成熟的云基礎(chǔ)架構(gòu)，來實(shí)現(xiàn)負(fù)載平衡和自動(dòng)擴(kuò)展。

由于一旦服務(wù)被打包成為了VM，那么在某種程度上說，該服務(wù)就會變成黑匣子，也就是實(shí)現(xiàn)了對于服務(wù)的封裝，因此部署的整個(gè)過程會變得更加簡單和可靠。

挑戰(zhàn)

由于在典型的公共IaaS中，VM的大小通常是固定的，因此用戶使用起來并不太方便。而隨著資源利用率的低下，部署的成本則會反而升高。畢竟IaaS提供商收取VM費(fèi)用時(shí)，是不會顧及VM的真正使用率的。

由于VM鏡像的大小各不相同，它們在創(chuàng)建和實(shí)例化的速度上會有所差異，因此這可能會直接導(dǎo)致新版本部署進(jìn)程的緩慢。不過，用戶通?？梢酝ㄟ^使用輕量級的VM，來克服此類缺陷。

在管理上，基于單個(gè)虛擬機(jī)的服務(wù)實(shí)例模式，往往需要運(yùn)營團(tuán)隊(duì)通過使用工具來構(gòu)建和管理虛擬機(jī)，以節(jié)省運(yùn)維的時(shí)間。當(dāng)然，您也可以通過使用諸如Box fuse之類的解決方案。

3.基于容器的服務(wù)實(shí)例

眾所周知，常見的容器技術(shù)包括：Docker和Solaris Zones。在這種部署模式下，每個(gè)服務(wù)實(shí)例都運(yùn)行在其各自的容器中，因此也被稱為操作系統(tǒng)級別的虛擬化機(jī)制。

為了使用該模式，您需要將服務(wù)打包成為一個(gè)文件系統(tǒng)類型的鏡像(通常被稱為容器鏡像)，其中包含執(zhí)行該服務(wù)所需的應(yīng)用程序、及其庫文件。在完成打包之后，您需要啟動(dòng)一到多個(gè)容器，并在物理機(jī)或虛擬機(jī)上運(yùn)行它們。為了管理多個(gè)容器，許多開發(fā)人員都會選擇使用諸如Kubernetes或Marathon之類的集群管理器。

優(yōu)點(diǎn)

類似前面基于虛擬機(jī)的服務(wù)實(shí)例模式，該模式也可以獨(dú)立運(yùn)作。您可以跟蹤每個(gè)容器當(dāng)前使用到的資源數(shù)量。不過與前者相比，該模式的最大優(yōu)勢在于容器往往是輕量級的，而且其構(gòu)建的速度非?？臁４送?，由于不涉及到任何操作系統(tǒng)的啟動(dòng)機(jī)制，因此容器的啟動(dòng)也非常迅速。

挑戰(zhàn)

盡管此類基礎(chǔ)架構(gòu)日趨成熟，但是基于容器的服務(wù)實(shí)例仍然落后于虛擬機(jī)架構(gòu)。并且由于它們共享主機(jī)操作系統(tǒng)的內(nèi)核，因此在安全性上也不及虛擬機(jī)。

同樣與虛擬機(jī)所面臨的挑戰(zhàn)一樣，您需要花時(shí)間從事較為繁重的容器鏡像管理工作。也就是說，如果沒有使用諸如Amazon EC2 Container Service(ECS)之類的托管容器解決方案的話，您必須手動(dòng)管理容器，乃至虛擬機(jī)的基礎(chǔ)架構(gòu)。

此外，由于大多數(shù)針對容器的部署都是遵循基于虛擬機(jī)的定價(jià)模式，這就會導(dǎo)致用戶必須增加額外的部署成本，以及進(jìn)行超額的虛擬機(jī)配置，從而應(yīng)對突發(fā)的負(fù)載高峰。

4.無服務(wù)器部署

作為微服務(wù)部署的第四種策略，無服務(wù)器部署技術(shù)能夠支持Java、Node.js和Python服務(wù)。AWS Lambda是全球開發(fā)人員使用最多的無服務(wù)技術(shù)。在該部署模式下，您需要將服務(wù)打包成為一個(gè)ZIP文件，然后將其上傳到Lambda函數(shù)(即一種無狀態(tài)服務(wù))中。

同時(shí)，您需要提供各種元數(shù)據(jù)，這些元數(shù)據(jù)帶有在處理請求時(shí)所調(diào)用到的不同函數(shù)名稱。Lambda函數(shù)需要自動(dòng)運(yùn)行足夠多的微服務(wù)實(shí)例，以處理不同的請求。而作為用戶，您只需根據(jù)所花費(fèi)的時(shí)間、以及消耗的內(nèi)存，為每個(gè)請求支付費(fèi)用便可。

優(yōu)點(diǎn)

由于您只需根據(jù)服務(wù)器的工作量付費(fèi)，因此無服務(wù)器部署的最大優(yōu)勢便是價(jià)格。

由于能夠從虛擬機(jī)、容器等IT架構(gòu)方面解放出來，因此您可以有更多時(shí)間去專注于應(yīng)用程序的開發(fā)。

挑戰(zhàn)

無服務(wù)器部署的最大挑戰(zhàn)是：它不能被用于那些長期運(yùn)行的服務(wù)中。所有請求都必須在300秒內(nèi)完成。

由于Lambda函數(shù)可能會為每個(gè)請求運(yùn)行不同的實(shí)例，因此您的服務(wù)也必須是無狀態(tài)的。

您的服務(wù)必須使用其支持的語言進(jìn)行編寫，并且必須能夠快速啟動(dòng)，否則將會面臨超時(shí)或被終止的危險(xiǎn)。

總結(jié)

眾所周知，如果沒有正確的策略，微服務(wù)應(yīng)用的部署可能會寸步難行。而在選擇適合本企業(yè)的部署策略之前，我們需要全面考慮當(dāng)前服務(wù)是由何種語言編寫而成，其對應(yīng)的框架，相應(yīng)的部署、擴(kuò)展與管理要求等方面。鑒于上述四種微服務(wù)部署方式，我們常用到的是通過平臺即服務(wù)(Platform as a Service)的方式，將原有的單體應(yīng)用程序遷移到無服務(wù)器的架構(gòu)之中。

原文標(biāo)題：Right Strategies for Microservices Deployment，作者：Rahul Singh 

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】