更快的發(fā)布周期是微服務(wù)架構(gòu)的主要優(yōu)勢之一。但是，如果沒有良好的CI/CD流程，您將無法實(shí)現(xiàn)微服務(wù)所承諾的敏捷性。本文介紹了挑戰(zhàn)并提出了解決此問題的一些方法。

什么是CI/CD？

當(dāng)我們談?wù)?/span>CI/CD時(shí)，實(shí)際上是在談?wù)搸讉€(gè)相關(guān)過程：持續(xù)集成、持續(xù)交付和持續(xù)部署。

• 持續(xù)集成。代碼更改經(jīng)常合并到主分支中。自動化的構(gòu)建和測試過程可確保主分支中的代碼始終具有生產(chǎn)質(zhì)量。
• 持續(xù)交付。通過CI流程的所有代碼更改都將自動發(fā)布到生產(chǎn)環(huán)境中。部署到實(shí)時(shí)生產(chǎn)環(huán)境中可能需要手動批準(zhǔn)，但否則會自動進(jìn)行。目標(biāo)是您的代碼應(yīng)始終準(zhǔn)備就緒，可以部署到生產(chǎn)中。
• 持續(xù)部署。通過前兩個(gè)步驟的代碼更改將自動部署到生產(chǎn)中。

以下是微服務(wù)架構(gòu)的健壯CI/CD流程的一些目標(biāo)：

• 每個(gè)團(tuán)隊(duì)都可以獨(dú)立構(gòu)建和部署自己擁有的服務(wù)，而不會影響或破壞其他團(tuán)隊(duì)。
• 在將新版本的服務(wù)部署到生產(chǎn)中之前，會將其部署到開發(fā)/測試/QA環(huán)境中進(jìn)行驗(yàn)證。在每個(gè)階段都要執(zhí)行質(zhì)量關(guān)卡。
• 服務(wù)的新版本可以與先前版本并列部署。
• 有足夠的訪問控制策略。
• 對于容器化的工作負(fù)載，您可以信任部署到生產(chǎn)中的容器映像。

為什么強(qiáng)大的CI/CD管道很重要

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

遵循微服務(wù)理念，永遠(yuǎn)不會有一個(gè)漫長的發(fā)布培訓(xùn)，每個(gè)團(tuán)隊(duì)都必須排隊(duì)。構(gòu)建服務(wù)“A”的團(tuán)隊(duì)可以隨時(shí)發(fā)布更新，而無需等待服務(wù)“B”中的更改被合并，測試和部署。

CI/CD整體圖

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

挑戰(zhàn)性

• 許多小的獨(dú)立代碼庫。每個(gè)團(tuán)隊(duì)都負(fù)責(zé)使用自己的構(gòu)建管道來構(gòu)建自己的服務(wù)。在某些組織中，團(tuán)隊(duì)可能使用單獨(dú)的代碼存儲庫。單獨(dú)的存儲庫可能會導(dǎo)致以下情況：如何構(gòu)建系統(tǒng)的知識分散到各個(gè)團(tuán)隊(duì)中，組織中沒有人知道如何部署整個(gè)應(yīng)用程序。例如，如果您需要快速部署到新集群，在災(zāi)難恢復(fù)方案中會發(fā)生什么？

緩解措施：建立統(tǒng)一的自動化管道來構(gòu)建和部署服務(wù)，以使這些知識不會在每個(gè)團(tuán)隊(duì)中“隱藏”。

• 多種語言和框架。每個(gè)團(tuán)隊(duì)使用自己的技術(shù)組合，很難在整個(gè)組織中創(chuàng)建一個(gè)單一的構(gòu)建過程。構(gòu)建過程必須足夠靈活，以使每個(gè)團(tuán)隊(duì)都可以根據(jù)其選擇的語言或框架對其進(jìn)行調(diào)整。

緩解措施：容器化每個(gè)服務(wù)的構(gòu)建過程。這樣，構(gòu)建系統(tǒng)僅需要能夠運(yùn)行容器。

• 集成和負(fù)載測試。隨著團(tuán)隊(duì)按自己的進(jìn)度發(fā)布更新，設(shè)計(jì)健壯的端到端測試可能是一個(gè)挑戰(zhàn)，特別是當(dāng)服務(wù)依賴于其他服務(wù)時(shí)。而且，運(yùn)行一個(gè)完整的生產(chǎn)集群可能會很昂貴，因此每個(gè)團(tuán)隊(duì)不太可能會在生產(chǎn)規(guī)模上運(yùn)行自己的完整集群，僅用于測試。
• 發(fā)布管理。每個(gè)團(tuán)隊(duì)都應(yīng)該能夠?qū)⒏虏渴鸬缴a(chǎn)中。這并不意味著每個(gè)團(tuán)隊(duì)成員都有權(quán)這樣做。但是具有集中的Release Manager角色可以降低部署速度。

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

• 服務(wù)更新。將服務(wù)更新到新版本時(shí)，它不應(yīng)破壞依賴于該服務(wù)的其他服務(wù)。

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

Monorepo vs.多倉庫

在創(chuàng)建CI/CD工作流之前，您必須了解代碼庫的結(jié)構(gòu)和管理方式。

• 團(tuán)隊(duì)是在單獨(dú)的存儲庫中還是在單個(gè)存儲庫（單個(gè)存儲庫）中工作？
• 您的分支策略是什么？
• 誰可以將代碼推送到生產(chǎn)環(huán)境？有發(fā)布經(jīng)理角色嗎？

monorepo方法一直受到歡迎，但兩者都有優(yōu)點(diǎn)和缺點(diǎn)。

更新服務(wù)

有多種策略可以更新已經(jīng)投入生產(chǎn)的服務(wù)。在這里，我們討論三個(gè)常用選項(xiàng)：滾動更新、藍(lán)綠色部署和canary發(fā)布。

滾動更新

在滾動更新中，您將部署服務(wù)的新實(shí)例，新實(shí)例立即開始接收請求。隨著新實(shí)例的出現(xiàn)，以前的實(shí)例將被刪除。

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

例如，默認(rèn)情況下，Azure Service Fabric使用滾動更新策略。此策略最適合在不更改現(xiàn)有API的情況下部署具有新功能的服務(wù)版本。Service Fabric通過將應(yīng)用程序類型更新為節(jié)點(diǎn)的子集或更新域來啟動升級部署。然后，它將前滾到下一個(gè)更新域，直到所有域都升級。如果升級域更新失敗，則應(yīng)用程序類型將在所有域中回滾到以前的版本。請注意，具有多個(gè)服務(wù)的應(yīng)用程序類型（并且如果所有服務(wù)都作為一個(gè)升級部署的一部分進(jìn)行更新）則很容易發(fā)生故障。如果一項(xiàng)服務(wù)更新失敗，則整個(gè)應(yīng)用程序?qū)⒒貪L到以前的版本，而其他服務(wù)則不會更新。

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

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

藍(lán)綠色部署

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

對于更傳統(tǒng)的單片或N層應(yīng)用程序，藍(lán)綠色部署通常意味著預(yù)配兩個(gè)相同的環(huán)境。您可以將新版本部署到暫存環(huán)境，然后將客戶端流量重定向到暫存環(huán)境，例如，通過交換VIP地址。在微服務(wù)體系結(jié)構(gòu)中，更新發(fā)生在微服務(wù)級別，因此您通常將更新部署到同一環(huán)境中，并使用服務(wù)發(fā)現(xiàn)機(jī)制進(jìn)行交換。

例如，在Kubernetes中，您無需配置單獨(dú)的集群即可進(jìn)行藍(lán)綠色部署。相反，您可以利用選擇器。使用新的pod規(guī)范和一組不同的標(biāo)簽創(chuàng)建新的Deployment資源。創(chuàng)建此部署，而不刪除先前的部署或修改指向它的服務(wù)。新的Pod運(yùn)行之后，您可以更新服務(wù)的選擇器以匹配新的部署。

藍(lán)綠色部署的一個(gè)缺點(diǎn)是，在更新期間，您正在運(yùn)行該服務(wù)的Pod（當(dāng)前和下一個(gè)）兩倍。如果Pod需要大量CPU或內(nèi)存資源，則可能需要臨時(shí)擴(kuò)展群集以處理資源消耗。

Canary發(fā)布

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

Canary版本比藍(lán)綠色更新或滾動更新更復(fù)雜，因?yàn)槟仨殞⒄埱髣討B(tài)路由到服務(wù)的不同版本。

例如，在Kubernetes中，您可以將服務(wù)配置為跨越兩個(gè)副本集（每個(gè)版本一個(gè)）并手動調(diào)整副本計(jì)數(shù)。但是，由于Kubernetes跨Pod負(fù)載均衡的方式，這種方法相當(dāng)粗糙。例如，如果總共有10個(gè)副本，則只能以10％的增量轉(zhuǎn)移流量。如果使用服務(wù)網(wǎng)格，則可以使用服務(wù)網(wǎng)格路由規(guī)則來實(shí)現(xiàn)更復(fù)雜的Canary發(fā)布策略。