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

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

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

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

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

微服務的部署策略

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

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

優(yōu)點

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

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

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

挑戰(zhàn)

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

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

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

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

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

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

優(yōu)點

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

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

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

挑戰(zhàn)

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

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

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

3.基于容器的服務實例

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

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

優(yōu)點

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

挑戰(zhàn)

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

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

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

4.無服務器部署

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

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

優(yōu)點

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

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

挑戰(zhàn)

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

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

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

總結

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

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

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