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

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

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

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

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

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

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

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

優(yōu)點

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

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

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

挑戰(zhàn)

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

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

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

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

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

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

優(yōu)點

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

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

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

挑戰(zhàn)

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

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

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

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

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

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

優(yōu)點

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

挑戰(zhàn)

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

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

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

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

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

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

優(yōu)點

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

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

挑戰(zhàn)

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

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

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

總結(jié)

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

原文標題：Right Strategies for Microservices Deployment，作者：Rahul Singh 

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