更快的發布周期是微服務架構的主要優勢之一。但是，如果沒有良好的CI/CD流程，您將無法實現微服務所承諾的敏捷性。本文介紹了挑戰并提出了解決此問題的一些方法。

什么是CI/CD？

當我們談論CI/CD時，實際上是在談論幾個相關過程：持續集成、持續交付和持續部署。

• 持續集成。代碼更改經常合并到主分支中。自動化的構建和測試過程可確保主分支中的代碼始終具有生產質量。
• 持續交付。通過CI流程的所有代碼更改都將自動發布到生產環境中。部署到實時生產環境中可能需要手動批準，但否則會自動進行。目標是您的代碼應始終準備就緒，可以部署到生產中。
• 持續部署。通過前兩個步驟的代碼更改將自動部署到生產中。

以下是微服務架構的健壯CI/CD流程的一些目標：

• 每個團隊都可以獨立構建和部署自己擁有的服務，而不會影響或破壞其他團隊。
• 在將新版本的服務部署到生產中之前，會將其部署到開發/測試/QA環境中進行驗證。在每個階段都要執行質量關卡。
• 服務的新版本可以與先前版本并列部署。
• 有足夠的訪問控制策略。
• 對于容器化的工作負載，您可以信任部署到生產中的容器映像。

為什么強大的CI/CD管道很重要

 在傳統的整體應用程序中，只有一個構建管道，其輸出是應用程序可執行文件。所有開發工作都將饋入此管道。如果發現高優先級錯誤，則必須集成，測試和發布修補程序，這可能會延遲新功能的發布。您可以通過使用結構良好的模塊并使用功能分支來最大程度地減少代碼更改的影響來減輕這些問題。但是，隨著應用程序變得越來越復雜，并添加了更多功能，整裝件的發布過程往往變得更加脆弱，并可能會破裂。

遵循微服務理念，永遠不會有一個漫長的發布培訓，每個團隊都必須排隊。構建服務“A”的團隊可以隨時發布更新，而無需等待服務“B”中的更改被合并，測試和部署。

CI/CD整體圖

為了達到較高的釋放速度，您的釋放管道必須自動化且高度可靠，以最大程度地降低風險。如果您每天一次或多次發布產品，則回歸或服務中斷必定很少發生。同時，如果確實部署了錯誤的更新，則必須以可靠的方式快速回滾或前滾到服務的先前版本。

挑戰性

• 許多小的獨立代碼庫。每個團隊都負責使用自己的構建管道來構建自己的服務。在某些組織中，團隊可能使用單獨的代碼存儲庫。單獨的存儲庫可能會導致以下情況：如何構建系統的知識分散到各個團隊中，組織中沒有人知道如何部署整個應用程序。例如，如果您需要快速部署到新集群，在災難恢復方案中會發生什么？

緩解措施：建立統一的自動化管道來構建和部署服務，以使這些知識不會在每個團隊中“隱藏”。

• 多種語言和框架。每個團隊使用自己的技術組合，很難在整個組織中創建一個單一的構建過程。構建過程必須足夠靈活，以使每個團隊都可以根據其選擇的語言或框架對其進行調整。

緩解措施：容器化每個服務的構建過程。這樣，構建系統僅需要能夠運行容器。

• 集成和負載測試。隨著團隊按自己的進度發布更新，設計健壯的端到端測試可能是一個挑戰，特別是當服務依賴于其他服務時。而且，運行一個完整的生產集群可能會很昂貴，因此每個團隊不太可能會在生產規模上運行自己的完整集群，僅用于測試。
• 發布管理。每個團隊都應該能夠將更新部署到生產中。這并不意味著每個團隊成員都有權這樣做。但是具有集中的Release Manager角色可以降低部署速度。

緩解措施：CI/CD流程自動化和可靠的程度越高，對中央機構的需求就越少。也就是說，您可能有不同的策略來發布主要功能更新與次要錯誤修復。權力下放并不意味著零治理。

• 服務更新。將服務更新到新版本時，它不應破壞依賴于該服務的其他服務。

緩解措施：使用部署技術（例如藍綠色或Canary發布）進行不間斷的更改。要中斷API更改，請與以前的版本并排部署新版本。這樣，可以對使用先前API的服務進行更新并針對新API進行測試。請參閱下面的更新服務。

Monorepo vs.多倉庫

在創建CI/CD工作流之前，您必須了解代碼庫的結構和管理方式。

• 團隊是在單獨的存儲庫中還是在單個存儲庫（單個存儲庫）中工作？
• 您的分支策略是什么？
• 誰可以將代碼推送到生產環境？有發布經理角色嗎？

monorepo方法一直受到歡迎，但兩者都有優點和缺點。

更新服務

有多種策略可以更新已經投入生產的服務。在這里，我們討論三個常用選項：滾動更新、藍綠色部署和canary發布。

滾動更新

在滾動更新中，您將部署服務的新實例，新實例立即開始接收請求。隨著新實例的出現，以前的實例將被刪除。

例如，在Kubernetes中，當您更新Deployment的Pod規范時，滾動更新是默認行為。部署控制器為更新的Pod創建一個新的ReplicaSet。然后，它會按比例縮放新的ReplicaSet，同時按比例縮小舊的ReplicaSet，以保持所需的副本數。在新的Pod就緒之前，它不會刪除舊的Pod。Kubernetes保留更新的歷史記錄，因此您可以根據需要回滾更新。

例如，默認情況下，Azure Service Fabric使用滾動更新策略。此策略最適合在不更改現有API的情況下部署具有新功能的服務版本。Service Fabric通過將應用程序類型更新為節點的子集或更新域來啟動升級部署。然后，它將前滾到下一個更新域，直到所有域都升級。如果升級域更新失敗，則應用程序類型將在所有域中回滾到以前的版本。請注意，具有多個服務的應用程序類型（并且如果所有服務都作為一個升級部署的一部分進行更新）則很容易發生故障。如果一項服務更新失敗，則整個應用程序將回滾到以前的版本，而其他服務則不會更新。

滾動更新的一個挑戰是，在更新過程中，新舊版本的混合正在運行并接收流量。在此期間，任何請求都可以路由到兩個版本中的任何一個。

為了打破API更改，一個好的做法是并排支持兩個版本，直到更新了先前版本的所有客戶端為止。請參閱API版本控制。

藍綠色部署

在藍綠色部署中，您將新版本與先前版本一起部署。驗證新版本后，您可以一次將所有流量從以前的版本切換到新版本。切換之后，您可以監視應用程序是否存在任何問題。如果出現問題，您可以交換回舊版本。假設沒有問題，則可以刪除舊版本。

對于更傳統的單片或N層應用程序，藍綠色部署通常意味著預配兩個相同的環境。您可以將新版本部署到暫存環境，然后將客戶端流量重定向到暫存環境，例如，通過交換VIP地址。在微服務體系結構中，更新發生在微服務級別，因此您通常將更新部署到同一環境中，并使用服務發現機制進行交換。

例如，在Kubernetes中，您無需配置單獨的集群即可進行藍綠色部署。相反，您可以利用選擇器。使用新的pod規范和一組不同的標簽創建新的Deployment資源。創建此部署，而不刪除先前的部署或修改指向它的服務。新的Pod運行之后，您可以更新服務的選擇器以匹配新的部署。

藍綠色部署的一個缺點是，在更新期間，您正在運行該服務的Pod（當前和下一個）兩倍。如果Pod需要大量CPU或內存資源，則可能需要臨時擴展群集以處理資源消耗。

Canary發布

在Canary版本中，您向少數客戶端推出了更新版本。然后，在將新服務推廣到所有客戶端之前，您將監視新服務的行為。這樣一來，您就可以以受控方式進行緩慢的部署，觀察實際數據并在所有客戶都受到影響之前發現問題。

Canary版本比藍綠色更新或滾動更新更復雜，因為您必須將請求動態路由到服務的不同版本。

例如，在Kubernetes中，您可以將服務配置為跨越兩個副本集（每個版本一個）并手動調整副本計數。但是，由于Kubernetes跨Pod負載均衡的方式，這種方法相當粗糙。例如，如果總共有10個副本，則只能以10％的增量轉移流量。如果使用服務網格，則可以使用服務網格路由規則來實現更復雜的Canary發布策略。