在之前的文章中，我們已經充分了解了應用部署的4種常見模式（金絲雀部署、藍綠部署、滾動部署及影子部署）。隨著雲原生技術逐步成熟，企業追求更為靈活和可擴充套件的系統，微服務架構大行其道。
微服務固然有諸多優點，但也給架構及運維工程師帶來了新的挑戰。在單體架構中，應用的設計、部署以及擴充套件都是作為一個單元進行，而當企業採用微服務時，可能有許多用不同語言和框架構建的相互連線的服務，從而導致部署變得更加複雜。
因此，企業需要採用不同的部署策略，使應用程式部署更絲滑且保證其完整性並擁有最佳效能。
部署模式
微服務架構可以採用不同型別的部署模式，並且每種設計都能為不同的功能和非功能需求提供解決方案。因此，服務可以用各種程式語言或框架編寫。同樣，它們也可以用同一程式語言或框架的不同版本來編寫。
每個微服務都包含幾個不同的服務例項，比如UI、資料庫以及後端等。微服務必須獨立部署和可擴充套件的。服務例項必須彼此隔離，並且每個服務都能夠快速構建和部署，還可以合理分配計算資源。因此，部署環境必須是可靠的，服務必須被監控。
微服務部署模式
微服務部署模式包含若干種，但基本能分為以下三大類：
- 每臺主機的單個服務例項
- 每臺主機的多個服務例項
- 無伺服器部署
在下文中，我們將詳細介紹每種服務部署模式。
每臺主機的多個服務例項
當採取這一模式時，使用者需要配置一個或多個實體/虛擬的主機並在每個主機上執行多個服務例項。這是一種傳統的應用部署方法。每個服務例項在一個或多個主機上的埠執行。
下圖展示了該模式的架構：
這一模式有幾個變體。一個變體是每個服務例項可以是一個流程或者一個流程組。例如，可以將一個Java服務例項部署為 Apache Tomcat 伺服器上的一個Web 應用程式。一個 Node.js 服務例項可能由一個父程式和一個或多個子程式組成。
該模式的其他變體還有在同一個程式或程式組內部執行多個服務例項。例如，你可以在相同的 Apache Tomcat 伺服器上部署多個 Java Web 應用或者在相同的 OSGI 容器中執行多個 OSGI bundle。
每臺主機執行多個伺服器例項的模式有其優劣。最主要的優勢之一是它的資源利用率較為高效。多個服務例項共享一臺伺服器及其作業系統。如果一個流程或一個流程組執行多個服務例項，這樣的資源利用效率則更為高效。另外，我們還可以使用指令碼，透過一些配置來自動啟動和關閉程式。配置會有不同的部署相關資訊，比如版本號。
每臺主機的單個服務例項
在很多情況下，微服務需要它們自己的空間以及一個被清晰分隔開的部署環境。在此類狀況下，它們不能與其他服務或服務例項共享部署環境。這可能會導致資源衝突或是資源緊張，還有存在版本之間互相沖突的語言和框架的情況。
在此類情況下，一個服務例項只能部署在它自己的主機上。該主機既可以是物理的也可以是虛擬機器。那麼，此時將不會與其他服務產生衝突，並且該服務完全保持隔離狀態。所有VM的資源都可用於該服務的消耗，並且易於監控。
唯一的問題是這一部署模式會消耗更多資源。
每臺VM的單個服務例項
微服務架構必須健壯且可以快速啟動和停止。同樣的，也需要快速擴容和縮容。因此不能與其他服務共享任何資源，也要避免與其他服務的衝突。在這一模式中，你將把每個微服務打包為VM的映象，每個服務例項就是一個虛擬機器，它可以使用VM映象來啟動。
以下圖例展示了這一模式的架構：
開發人員可以透過增加服務例項的數量來輕鬆擴充套件服務。這一部署模式可以讓服務例項單獨擴容，允許每個服務尤其專屬的資源，使得程式設計師可以基於應用程式的使用模式根據需要進行擴縮容。
每個服務例項的隔離是最重要的優勢之一。此外，開發人員可以使用雲基礎設施的功能，包括負載均衡和自動伸縮。但這種模式最顯著的缺點是，消耗了大量的資源，需要相當長的時間來構建和管理虛擬機器。
每個容器的單個服務例項
這一部署模式擁有虛擬機器模式的優勢，同時還具備更輕量、更高效的優點。在這一模式下，微服務例項執行在它們自己的容器中。
容器對於微服務來說是十分理想的環境，因為它不需要佔用太多記憶體和CPU。它使用 Docker 容器執行時並支援在一個容器內部部署微服務的多個例項。這可以讓資源利用更高效，並且可以根據需要擴縮容，減少不必要的開支。
每個容器中執行微服務的其中一個例項是一種最簡單、無縫的部署方式。這意味著每個容器都有自己的資料庫，並在其程式中執行。
容器可以讓應用快速啟動和擴充套件並且比起虛擬機器所需的資源更少。
該模式為簡化可擴充套件性和部署提供支援，同時隔離服務例項。更進一步的是，使用者可以快速構建容器映象，並且也可以輕鬆地管理容器。當然，這種方法也有其缺陷：
-
為了充分利用新版本的新特性和漏洞修復，程式設計師需要手動更新容器。如果你正在單個容器中執行微服務的多個例項，一次性更新它們會很耗時並且易出錯
-
部署更新有時會出現問題：如果在應用程式實時執行時應用更新，可能會對使用者體驗產生不利影響，比如停機或資料丟失
-
儘管事實上容器技術在快速迭代發展，但是他們依舊不如虛擬機器那樣成熟和安全，因為容器們共享作業系統核心
無伺服器（Serverless）部署
在某些情況下，微服務可能不需要了解底層部署基礎設施，那麼部署服務就會被承包給第三方供應商，他們通常是雲服務提供商。企業對底層資源完全不在意，它所要做的就是在一個平臺上執行微服務。它根據每次執行服務需要從平臺上呼叫的資源來支付給服務提供商。服務提供商為每個請求挑選程式碼並執行。執行可能發生在任何執行沙盒中，如容器、虛擬機器或其他，但它隱藏在服務本身之外。
服務提供商負責配置、擴充套件、負載均衡、打補丁和保障底層基礎設施安全，目前最為常用的有：AWS Lambda、Google Functions等。
無伺服器部署平臺的基礎設施是非常有彈性的，該平臺會自動擴充套件服務以承受負載。進而花在管理低階別的基礎設施上的時間會被節省下來。由於微服務提供者只需為每次呼叫所消耗的資源付費，因此支出也會降低。
總結
微服務部署模式和產品在不斷髮展，未來有可能會有更多的部署模式跟進。上面提到的許多模式目前都非常流行，並且被大多數微服務提供者所使用，它們是非常成功和可靠的。但隨著技術的演進，業界也在思考創新的解決方案。在之後的文章，我們還將介紹如何保障應用部署的安全，請保持關注！