導讀
四個關鍵部署模式，如何工作以及他們的優缺點
- 程式設計語言特定的釋出包格式
- 将服務部署為虛拟機
- 将服務部署為容器
- Serverless部署
使用Kubernetes部署
使用服務網格把服務釋出環節與服務部署環節分開
使用AWS Lambda部署服務
選擇部署模式
從20世紀90年代末開始開發企業應用以來，部署的流程和架構都發生了根本性的變化。早先開發人員将代碼扔給運維人員進行手動部署的曆史已經一去不複返了，生産環境的部署過程已經變得高度自動化。如圖12-1所示，之前由實體機組成的生産環境已被越來越多輕量級和短生命周期的計算基礎設施所取代。
回到20世紀90年代，那時如果你想将應用程式部署到生産環境中，第一步就是将應用程式與一組部署指南交給運維團隊。例如，你可能會送出部署工單，要求運維人員部署應用程式。接下來發生的事情完全是運維的職責，除非他們遇到問題需要你幫助來進行修複。通常運維部門購買并安裝昂貴且重量級的應用伺服器，如WebLogic或WebSphere。然後，他們将登入到應用程式伺服器的控制台，并部署你的應用程式。他們會非常關心這些機器，就好像對待寵物一樣，定期為它們安裝更新檔并更新軟體。
在21世紀頭10年中期，昂貴的應用程式伺服器被替換為開源的輕量級Web容器，如Apache Tomcaat和Jetty。你仍然可以在每個Web容器上運作多個應用程式，但同時也可以讓每個Web容器隻運作一個應用程式。此外，虛拟機開始取代實體機。但機器仍然被視為心愛的寵物，部署仍然基本上是手動的。
今天的部署模式則完全不同。采納DevOps意味着開發團隊需要肩負部署應用程式或者服務的職責，而不是将代碼交給單獨的運維團隊。在某些組織中，運維人員為開發人員提供了用于部署代碼的控制台，或者，更好的是一旦通過測試，部署流水線就會自動将代碼部署到生産環境中。
生産環境中使用的計算資源也随着實體機器的抽象而發生了根本性的變化。在高度自動化的雲上運作虛拟機已經取代了長生命周期、寵物般的實體機和虛拟機。今天的虛拟機是不可變的（immutable），被視為一次性的資源而不再是寵物，使用過後就被丢棄或者重建，而不是重新配置。容器是虛拟機之上的一個更輕量級的抽象層，是一種越來越流行的部署應用程式的方式。對于許多場景，你甚至可以使用更輕量級額的Serverless部署平台。
部署流程和架構的更新換代，與微服務架構的日益普及幾乎同時發生，這絕非一個巧合。應用程式可能有數十種或數百種以各種語言和架構編寫的服務。因為每個服務都是一個應用程式都是一個小應用程式，這意味着你在生産環境中有數十或數百個應用程式。是以讓系統管理者手動配置伺服器和服務已經不再可行。如果要大規模部署微服務，則需要高度自動化的部署流程和基礎設施。
圖12-2顯示了一個生産環境的抽象視圖。生産環境使開發人員能夠配置和管理他們的服務、使用部署流水線部署新版本的服務，以及使用者通路這些服務實作的功能。
生産環境必須實作四個關鍵功能：
服務管理接口：使開發人員能夠建立、更新和配置服務。理想情況下，這個接口是個可供指令行和圖形部署工具調用的 REST API
運作時服務管理：確定始終運作着所需數量的服務執行個體。如果服務執行個體崩潰或由于某種原因無法處理請求，則生産環境必須重新啟動它。如果運作服務的主機發生崩潰則必須在其他主機上重新啟動這些服務執行個體。
監控：讓開發人員深入了解服務正在做什麼,包括日志檔案和各種應用名額。如果出現問題，必須提醒開發人員。
請求路由:将使用者的請求路由到服務。
部署模式：程式設計語言特定的釋出包格式
假設你要部署一個基于Spring Boot的Java應用程式。部署此服務的一種方法是使用特定于程式設計語言的軟體包部署服務。使用此模式時，生産環境中部署的内容以及服務運作時管理的内容都是特定于語言的釋出包中的服務。在Restaurant service的場景下，它是可執行的JAR檔案或WAR檔案。對于其他語言，例如Nodejs，服務是源代碼和子產品的目錄。對于某些語言，例如GoLang，服務是特定于作業系統某個路徑下的可執行檔案。
模式:程式設計語言特定的釋出包格式
使用特定于程式設計語言的軟體釋出包将服務部署到生産環境。
要在計算機上部署Java應用程式，首先要安裝必要的運作時，在本例中為JDK。如果它是WAR檔案，則還需要安裝Web容器，例如Apache Tomcat。配置完計算機後，将程式釋出包複制到計算機并啟動該服務。每個服務執行個體都作為JVM程序運作。理想情況下，你已經設定好部署流水線，它會自動将服務部署到生産環境。部署流水線建構可執行的JAR檔案或WAR檔案，然後它們調用生産環境的服務管理接口來部署新版本。
服務執行個體通常是單個程序，但有時可能是一組程序。例如，Java服務執行個體是運作JVM的程序。 Node js服務可能會生成多個工作程序，以便同時處理請求。某些語言支援在同一程序中部署多個服務執行個體。
有時，可以在計算機上部署單個服務執行個體，同時保留在同一台計算機上部署多個服務執行個體的選項。如圖12-4所示，可以在一台計算機上運作多個JVM，每個JVM都運作個服務執行個體。
某些語言還允許在單個程序中運作多個服務執行個體。例如，如圖12-5所示，可以在單個 Apache Tomcat上運作多個Java服務。
在傳統的昂貴、重量級的應用程式伺服器（如WebLogic和WebSphere）上部署應用程式通常會使用此方法。将服務作為特定于語言的釋出包進行部署的模式有好處也有弊端。
我們先來看看好處。
使用程式設計語言特定的釋出包格式進行部署的好處
将服務作為特定于程式設計語言的釋出包進行部署有以下好處:
- 快速部署。
- 高效的資源利用，尤其是在同一台機器上或同一程序中運作多個執行個體時。
我們來逐一分析。
快速部署
這種模式的一個主要好處是部署服務執行個體的速度相對較快:将服務複制到主機并啟動它。如果服務是用Java編寫的，則複制JAR或WAR檔案。對于其他語言，例如js或Ruby，可以複制源代碼。在任何一種情況下，需要通過網絡複制的位元組數相對較小。此外，啟動服務耗時很短。如果服務運作于自己獨占的程序，則啟動它。否則，如果服務是在同一Web容器（例如Tomcat）程序中運作的多個執行個體之一，則可以将其動态部署到Web容器中，也可以重新啟動Web容器。由于沒有額外的開銷，是以啟動服務通常很快。
高效的資源利用
這種模式的另一個主要好處是它可以相對高效地使用資源。多個服務執行個體共享機器及其作業系統。如果多個服務執行個體在同一程序中運作，則效率更高。例如，多個Web應用程式可以共享相同的 Apache Tomcat伺服器和JVM。
使用程式設計語言特定的釋出包格式進行部署的弊端
盡管極具吸引力，但把服務作為特定于程式設計語言的釋出包進行部署的模式有幾個顯著的
- 缺乏對技術棧的封裝。
- 無法限制服務執行個體消耗的資源。
- 在同一台計算機上運作多個服務執行個體時缺少隔離。
- 很難自動判定放置服務執行個體的位置。
我們來逐一分析。
缺乏對技術棧的封裝
運維團隊必須了解部署每個服務的具體細節每個服務都需要特定版本的運作時。例如， Java Web應用程式需要特定版本的 Apache Tomcat和JDK運維團隊必須安裝每個所需軟體包的正确版本。
更糟糕的是，服務可以用各種語言和架構編寫。它們也可能用這些語言和架構的多個版本編寫。是以，開發團隊必須（以人工的方式）與運維團隊分享許多細節。這種溝通的複雜性增加了部署期間出錯的風險。例如，機器可能安裝錯誤的語言運作時版本。
無法限制服務執行個體消耗的資源
另一個缺點是你無法限制服務執行個體所消耗的資源。一個程序可能會消耗機器的所有CPU或記憶體，争用其他服務執行個體和作業系統的資源。例如，出現某個錯誤，這種情況極有可能會發生。
在同一台計算機上運作多個服務執行個體時缺少隔離
在同一台計算機上運作多個執行個體時，問題更嚴重。缺乏隔離意味着行為不當的服務執行個體可能會影響其他服務執行個體。是以，應用程式存在不可靠的風險，尤其是在同一台計算機上運作多個服務執行個體時。
很難自動判定放置服務執行個體的位置
在同一台計算機上運作多個服務執行個體的另一個挑戰是确定服務執行個體的位置。每台機器都有一組固定的資源、CPU、記憶體等，每個服務執行個體都需要一定的資源。以一種有效使用機器而不會使它們過載的方式将服務執行個體配置設定給機器非常重要。正如我稍後解釋的那樣，基于虛拟機的雲主機和容器編排架構會自動處理這個問題。在本地部署服務時，你可能需要手動确定放置位置。
正如你所看到的，服務作為特定于語言的釋出包進行部署的模式具有一些顯著的弊端。應該盡量避免使用這種方法，除非所獲效率的價值遠在其他所有考量之上。
将服務部署為虛拟機
模式:将服務部署為虛拟機
将作為虛拟機鏡像打包的服務部署到生産環境中。每個服務執行個體都是一個虛拟機。
虛拟機鏡像由服務的部署流水線建構。部署流水線運作虛拟機鏡像建構器，這個建構器建立包含服務代碼和服務運作所需的任何軟體的虛拟機鏡像。例如，服務的安裝JDK和服務的可執行JAR的虛拟機建構器。虛拟機鏡像建構器使用 Linux的init系統（如 upstart）将虛拟機鏡像配置成在虛拟機引導時運作該應用程式。
部署流水線可以使用各種工具來建構虛拟機鏡像。一個早期建立EC2AMI的工具是由 netflix aminator （ https://github. com/netflix/a ） Netflix AWS開發的Aminatorhtp:github.cm/netflix/aminator），netflix使用它在aws上部署其視訊流服務 packer （ https://www.packer. io ）是一個更現代的虛拟機鏡像建構器，與 Aminator不同，它支援各種虛拟化技術，包括EC2 Digital Ocean、 Virtual Box和 VMware要使用 Packer建立AMI，你需要編寫一個配置檔案，用于指定基礎鏡像和一組安裝軟體并配置AMI的配置程式。
關于它的好處和弊端
将服務部署為虛拟機的好處
- 虛拟機鏡像封裝了技術棧。
- 隔離的服務執行個體。
- 使用成熟的雲計算基礎設施。
我們來逐一分析。
虛拟機鏡像封裝了技術棧
此模式的一個重要好處是虛拟機鏡像包含服務及其所有依賴項。它消除了錯誤來源，確定正确安裝和設定服務運作所需的軟體。一旦服務被打包為虛拟機，它就會變成一個黑盒子，封裝服務的技術棧。虛拟機鏡像可以無須修改地部署在任何地方。用于部署服務的API成為虛拟機管理API。部署變得更加簡單和可靠。
隔離的服務執行個體
虛拟機的另一個好處是每個服務執行個體都以完全隔離的方式運作。畢竟，這是虛拟機技術的主要目标之一。每台虛拟機都有固定數量的CPU和記憶體，不能從其他服務中竊取資源。
使用成熟的雲計算基礎設施
将微服務部署為虛拟機時，可以利用成熟且高度自動化的雲計算基礎設施。AWS等公共雲試圖以避免機器過載的方式在實體機上排程虛拟機。它們還提供有價值的功能，例如跨虛拟機的流量負載均衡和自動擴充。
将服務部署為虛拟機的弊端
- 資源利用效率較低
- 部署速度相對較慢
- 系統管理的額外開銷
資源利用效率較低
每個服務執行個體擁有一整台虛拟機的開銷，包括其作業系統。此外，典型的公共IaaS虛拟機提供有限的虛拟機配置組合，是以虛拟機可能未得到充分利用。這不太可能成為基于Java的服務的問題，因為它們一般都相對較重。但這種模式可能是部署輕量級 Nodejs和 GoLang服務的低效方式。
部署速度相對較慢
由于虛拟機的大小，建構虛拟機鏡像通常需要幾分鐘。有很多内容要通過網絡傳輸。此外，由于必須通過網絡傳輸完整的虛拟機鏡像檔案，從鏡像執行個體化虛拟機是非常耗時的。在虛拟機内部運作的作業系統也需要一些時間來啟動，盡管慢速是一個相對的術語。這個過程可能需要幾分鐘，比傳統的部署過程要快得多。但它比你即将學習的更輕量級的部署模式要慢得多。
系統管理的額外開銷
你不得不擔負起給作業系統和運作時打更新檔的責任。這對于部署軟體時的系統管理似乎是不可避免的，但在後面的12.5節中，我Serverless将描述部署，它消除了這種系統管理的方式。
現在讓我們看一下部署微服務更加輕量但仍每一個容器都是隔離程序的沙箱具有虛拟機諸多優點的替代方法。
将服務部署為容器
容器是一種更現代、更輕量級的部署機制，是一種作業系統級的虛拟化機制。容器通常包含一個或多個在沙箱中運作的程序，這個沙箱将它們與其他容器隔離。例如，運作Java服務的容器通常由JVM程序組成。
從在容器中運作的程序的角度來看，它就好像在自己的機器上運作一樣。它通常有自己的機器IP位址，可以消除端口沖突。例如，所有Java由所有容器共享程序都可以偵聽端口8080。每個容器也有自己的根檔案系統。容器運作時使用作業系統機制将容器彼此隔離。
建立容器時，可以指定它的CPU和記憶體資源，以及依賴于容器實作的I/O資源等。容器運作時強制執行這些限制，并防止容器占用其機器的資源。使用 Docker編排架構（如 Kubernetes）時，指定容器的資源尤為重要。這是因為編排架構使用容器請求的資源來選擇運作容器的底層機器，進而確定機器不會過載。
在建構服務時，部署流水線使用容器鏡像建構工具，該工具讀取服務代碼和鏡像描述，以建立容器鏡像并将其存儲在鏡像倉庫中。在運作時，從鏡像倉庫中拉取容器鏡像，并用于建立容器。
使Docker用部署服務
要将服務部署為容器，必須将其打包為容器鏡像。容器鏡像是由應用程式和運作服務所需的依賴軟體組成的檔案系統鏡像。它通常是一個完整的 Linux根檔案系統，但更輕量級的鏡像也可以使用。例如，要部署基于 Spring Boot的服務，需要建構一個容器鏡像，其中包含服務的可執行JAR和正确的JDK版本。同樣，部署 Java Web應用程式，需要建構一個包含WAR檔案 Apache、 Tomcat和JDK的容器鏡像。主要分為以下步驟：
- 建構 Docker鏡像
- 将Docker鏡像推送到鏡像倉庫
- 運作Docker容器
将服務部署為容器的好處
将服務部署為容器有幾個好處。首先，容器具有虛拟機的許多好處:
- 封裝技術棧，可以用容器的API實作對服務的管理。
- 服務執行個體是隔離的。
- 服務執行個體的資源受到限制。
但與虛拟機不同，容器是一種輕量級技術容器鏡像通常可以很快建構。例如，隻需幾秒就可以将 Spring Boot應用程式打包為容器鏡像。通過網絡傳輸容器鏡像也相對較快主要是因為僅傳輸所需要的鏡像層的子集。（這是因為 Docker鏡像具有所謂的分層檔案系統，使得 Docker隻需要通過網絡傳輸部分鏡像。鏡像的作業系統、Java運作時和應用程式位于不同的層中。 Docker隻需要傳輸鏡像倉庫中不存在的那些層。是以，當 Docker隻需移動應用程式層時，通過網絡傳輸鏡像特别快）。容器也可以很快啟動，因為沒有冗長的作業系統啟動過程。當容器啟動時，所運作的就是服務。
将服務部署為容器的弊端
容器的一個顯著弊端是，你需要承擔大量的容器鏡像管理工作。你必須負責給作業系統和運作時打更新檔。此外，除非使用托管容器解決方案（如 Google Container Engine或awsECS），否則你必須管理容器基礎設施以及容器運作可能需要的虛拟機基礎設施。
使用Kubernetes部署應用程式
什麼是Kubernetes
Kubernetes是一個容器編排架構。将運維容器的一組計算機視為資源池，隻需要告訴它運作你的服務N個執行個體，它就會自動把其餘的事情搞定。主要有三個功能：
- 資源管理：将一組計算機視為CPU、記憶體和存儲卷構成的資源池，将計算機叢集視為一台計算機。
- 排程：選擇要運作容器的機器。預設情況下，排程考慮容器的資源需求和每個節點的可用資源。還可以實作在同一節點上部署具有親和性的容器，或者確定特定的幾個容器分散部署在不同的節點上（反親和性）。
- 服務管理：實作命名和版本化服務的概念，這個概念可以直接映射到微服務架構中的具體服務。確定始終運作所需數量的執行個體，并實作負載均衡，也支援滾動更新和復原。
Kuberntes的架構
Kubernets如圖所示，是一個叢集架構，其中分為主節點和普通節點（也稱工作節點）。
主節點運作如下多個元件：
- API伺服器：用于部署和管理服務的REST API，例如被kubectl指令行使用。
- Etcd：存儲叢集資料鍵值的NoSQL資料庫。
- 排程器：選擇要運作Pod的節點，Pod是Kubernets的部署單元，由一組容器組成。
- 控制器：確定叢集狀态與預期狀态比對。
普通節點運作的元件如下：
- Kubelet：建立和管理節點上運作的Pod。
- Kube-Proxy：管理網絡，包括跨Pod負載均衡。
- Pods：應用程式服務。
Kubernetes的關鍵概念：Pod、Deployment、Service、ConfigMap
Pod 是可以在 Kubernetes 中建立和管理的、最小的可部署的計算單元。
Pod（就像在鲸魚莢或者豌豆莢中）是一組（一個或多個） 容器； 這些容器共享存儲、網絡、以及怎樣運作這些容器的聲明。 Pod 中的内容總是并置（colocated）的并且一同排程，在共享的上下文中運作。 Pod 所模組化的是特定于應用的 “邏輯主機”，其中包含一個或多個應用容器， 這些容器相對緊密地耦合在一起。 在非雲環境中，在相同的實體機或虛拟機上運作的應用類似于在同一邏輯主機上運作的雲應用。
除了應用容器，Pod 還可以包含在 Pod 啟動期間運作的 Init 容器。 你也可以在叢集支援臨時性容器的情況下， 為調試的目的注入臨時性容器。
一個 Deployment 為 Pod 和 ReplicaSet 提供聲明式的更新能力。
你負責描述 Deployment 中的 目标狀态，而 Deployment 控制器（Controller） 以受控速率更改實際狀态， 使其變為期望狀态。你可以定義 Deployment 以建立新的 ReplicaSet，或删除現有 Deployment， 并通過新的 Deployment 收養其資源。
服務（Service）是将運作在一組Pods上的應用程式公開為網絡服務的抽象方法。
使用 Kubernetes，你無需修改應用程式去使用不熟悉的服務發現機制。 Kubernetes 為 Pod 提供自己的 IP 位址，并為一組 Pod 提供相同的 DNS 名， 并且可以在它們之間進行負載均衡。
ConfigMap 是一種 API 對象，用來将非機密性的資料儲存到鍵值對中。使用時， Pods 可以将其用作環境變量、指令行參數或者存儲卷中的配置檔案。
ConfigMap 将你的環境配置資訊和容器鏡像解耦，便于應用配置的修改。
在Kubernetes上部署應用
要在Kubernetes上部署服務，需要定義一個工作負載，例如Deployment對象，最簡單的方法是寫一個YAML檔案：
容器定義中指定了服務名稱、容器鏡像和環境變量，以及健康檢查。
liveness：是否應終止或重新開機服務執行個體。判斷服務是否啟動成功。
readiness：确定是否将流量路由到服務。等待服務初始化後，再路由流量進入。
建立Deployment後，還需要建立Service對象，為Deployment中部署的服務提供穩定的網絡通路端點（具有IP和DNS名稱），對該Service的通路将負載均衡到Deployment管理的Pod中。
kubernetes提供了kubectl指令行工具和聲明式風格API，隻需要執行下面的指令即可建立Deployment和Service對象：
kubectl apply -f xxx.yaml 執行後，即可在kubernetes叢集内使用http://ftgo-restaurant-service:8080通路REST API。
部署API Gateway
API Gateway的作用是将來自外部世界的流量路由到這個服務，Service預設的ClusterIP類型僅支援叢集内通路，不過還有兩種類型可以支援外部通路：NodePort和LoadBalancer。
API Gateway在叢集中使用URL http://ftgo-api-gateway:8080，在叢集外使用URL http://<node-ip-address>:3000/，其中<node-ip-address>是叢集内某個節點的IP。
零停機部署（滾動更新）
使用Kubernetes更新服務隻需要三步：
- 建構新的容器鏡像并推送至鏡像倉庫，鏡像需要用不同的版本标簽标記
- 更新Deployment YAML檔案，引用新的鏡像版本标簽
- kubectl apply -f xxx.yaml
Kubernetes會自動執行滾動更新過程，利用readinessProbe機制來確定新的Pod就緒後，再停止舊的Pod，確定一直有可用的Pod提供不間斷服務。
當一切正常時，經過有限時間（根據配置不同，大約幾秒到幾分鐘）所有Pod将更新到新版本；
當遇到報錯，Pod無法啟動時，會自動停止更新，這時可以在修複後，再次走一遍新的apply過程，再次更新鏡像版本；
如果都啟動成功了，但服務有問題，那就需要快速復原版本：
kubectl rollout undo deployment <name> 使用服務網格分隔部署和釋出流程
為了更好可靠性，我們可以借助服務網格，将部署和釋出兩個動作分開：
部署：讓服務開始在生産環境中運作
釋出：使最終使用者可以使用新的服務
使用以下詳細步驟進行生産環境的部署和釋出：
- 将新版本部署到生産環境，但不向其路由任何請求
- 在生産中測試
- 将其釋出給少數使用者
- 逐漸将其釋出給越來越多的使用者，直至處理所有請求
- 上述任何環節有問題，立即恢複舊版本
istio服務網格的内容還是比較複雜的，需要後續另開一篇詳說~
部署模式：Serviceless部署
之前的三種部署方式的共同點：
- 都會存在資源浪費的情況，例如即使處于閑置狀态，也需要為容器和虛拟機付費
- 需要負責系統管理，必須承擔作業系統和軟體打更新檔的工作
Serverless提供一種受限制的程式設計模型，以換取最小化的系統管理開銷，且不需要擔心伺服器、容器的任何方面，這一理念非常先進。
以AWS Lambda為例，隻需要将應用程式打包為ZIP或者JAR檔案，上載到AWS Lamdba，并指定相應請求的函數名稱。AWS Lambda會自動運作你的微服務執行個體來影響請求，隻需要為所花費的時間和消耗的記憶體付費。
但如果需要更加精細化的管理基礎設施，那麼就不要選擇Serverless。
好處：
- 消除系統管理任務
- 彈性，不需要預測負載，而判斷執行個體數量。AWS Lamdba會幫忙處理。
- 基于使用情況定價
弊端：
- 長尾延遲。AWS需要花費時間來配置應用程式執行個體和啟動應用程式，可能導緻某些請求具有高延遲。
- 基于有限事件與請求的程式設計模型。不适應長時間運作的服務，例如消息代理服務。
本章小結
- 你應該選擇支援服務要求的最輕量部署模式。按以下順序評估選項：Serverless、容器、虛拟機和特定于語言的程式包。
- Serverless部署不适合每項服務，因為長尾延遲和使用基于事件／請求的程式設計模型的要求。但是，當适合部署應用時，Serverless部署是一個非常有競争力的選擇，因為它消除了管理作業系統和運作時的必要，并提供自動彈性配置和基于請求的定價。
- Docker 容器是一種輕量級作業系統級虛拟化技術，比Serverless部署更靈活，并且具
- 有更可預測的延遲。最好使用Docker編排架構，例如Kubernetes，它管理機器叢集上的容器。使用容器的缺點是你必須管理作業系統和運作時，并且很可能也需要管理Docker編排架構及其底層運作的虛拟機。
- 第三個部署選項是将你的服務部署為虛拟機。一方面，虛拟機是重量級的部署選項，是以部署速度較慢，并且很可能比第二個選項使用更多資源。另一方面，AmazonEC2等現代雲是高度自動化的，并提供了豐富的功能。是以，使用虛拟機部署小型簡單應用程式有時可能比設定Docker編排架構更容易。
- 除非你隻有少量服務，否則通常最好避免将服務部署為特定于程式設計語言的釋出包。例如，如第13章所述，當你開始使用微服務時，你可能會使用與單體應用程式相同的機制來部署服務，而且很可能是此選項。隻有開發了一些服務後，你才應該考慮建立一個複雜的部署基礎設施，如Kubernetes。
- 使用服務網格（一種網絡層，調節進出服務的所有網絡流量）的衆多好處之一是，它使你能夠在生産環境中部署服務，對其進行測試，然後才将生産流量路由到更新後的服務。将部署與釋出隔離可以提高新版本服務的可靠性。