微服務CD怎么實現

這篇文章主要講解了“微服務CD怎么實現”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“微服務CD怎么實現”吧！

微服務和CD

按照Martin Fowler的說法，微服務架構是“將軟件設計一組為可獨立部署的服務的方式“。這種方式目前已經成為構建分布式系統/應用的主流；按照Jez Humble的說法，CD（持續交付）是“能夠以可持續的方式安全快速地將所有類型的變更 - 包括新功能、配置、錯誤修復和實驗 - 投入生產”。

無論是一體化架構還是微服務架構，無論目標部署環境或我們的架構選擇如何，設計好CD工作流程以使我們對應用的任何更改投入生產都很重要。CD工作流程是DevOps流程的核心，能夠很好的串聯組織中的各種功能，包括開發、QA以及IT運維等等。

微服務架構CD的4項挑戰

1. 維護復雜分布式系統的完整性：由于我們將大型一體化系統分解成為了更小、更易于管理的微服務，因此系統本身的整體復雜性會增加，我們開始需要處理分布式系統相關的問題；

2. 安全快速地發布功能：當我們的功能可能涉及一個或多個微服務的更改時，需要特別考慮一下如何管理頻繁的功能發布；

3. 管理不同技術堆棧的部署：微服務環境通常包括用于服務的不同技術堆棧，跨技術對戰的管理和部署過程很有挑戰性；

4. 獨立部署服務的過程和工具：有許多工具可用于構建CD工作流程，但選擇工具、制定CD工作流并不是一件容易的事。

微服務架構CD的5點思考

1. 準備好測試策略

跟傳統一體化架構應用相比，微服務架構的測試和驗證更加細致，也更加復雜。一個有效的測試策略必須同時考慮到測試單個服務和驗證整個系統行為的需要。

對于服務的pre-production測試，特別是以隔離的方式測試，傳統方法仍然適用。測試金字塔仍然可以幫助我們在不同類型的測試之間保持平衡。但是，在測試服務聚合時，這種測試方式的效果有限。我們會遇到一些在測試環境中無法模擬的錯誤類別，例如由分布式系統中的最終一致性引起的問題，導致系統部分失敗的硬件和網絡故障等。

我們最好利用一些技術來作為傳統測試的補充，例如synthetic user testing、lightweight user acceptance testing以及fault injection testing等等。

2. 檢查好CI實踐

CI是CD的關鍵實踐。除了構建服務器、構建定義相關的考慮，基于主干的開發和功能切換是實現簡單而強大的CI過程的兩個關鍵實踐。

在基于主干的開發中，開發人員在一個名為“trunk”的分支中協作。這樣做的好處是，避免開發分支的drift和由此產生的merge hell。這與維護長期特征和釋放分支的做法相反。在分支模型中，雖然我們可能會在各個分支上運行構建，但事實上，我們沒有進行持續集成。

要進行基于主干的開發，需要有稱為feature toggles的控件。功能切換支持WIP和已完成功能的組合的多次提交。通過這些切換，我們可以在生產環境中關閉不完整特性的顯示，直到這些特性在生產環境中得到充分的開發和測試。特性切換通常存儲在靠近代碼基的規范或配置文件中，并由CD管道中的自動化程序在特定環境中打開切換。

一旦我們有了維護feature toggles的機制，我們可以使用相同的機制來引入其他類別的toggles，如release toggles（控制對未完成的代碼的訪問）、Ops toggles（控制生產代碼的行為）、permissions toggles（到打開特權用戶的特定行為）和experimental toggles（對于多變量測試 - 在使其成為永久性之前接收到的功能的程度）。

3. 計劃好環境

環境計劃包括我們的環境集、它們的預期用途、通過這些環境促進工件的策略以及在這些環境中的toggle狀態。

首先，考慮需要什么環境以及它們的預期用例。組織中不同的部門有不同的競爭需求。在創建環境時，我們應該滿足所有這些相互競爭的需求。

其次，如果可能的話，考慮使用云基礎設施動態創建環境。例如使用Kubernetes的標簽功能，可以在飛行測試環境中創建自動化測試，而不是在長期存在的環境。

第三，CD管道會生成許多artifacts，我們應該考慮要存儲多少artifacts？我們需要多少repositories等等。

4. 管理好配置

應用的配置包括那些每次部署時不盡相同的東西，應該與代碼分開存儲。那么當我們擁有一組微服務時，應該如何處理配置呢？

一種辦法是在Consul或Vault等存儲庫中集中管理部署配置，在Chef和CD管道中擴展部署配置只會徒增理解難度。

另一種技術是采用標準化分發配置的流程，不管服務的技術對戰如何，讓服務根據堆棧處理配置。例如，我們通常參考12-factors，避免分發配置文件。

最后，像證書這樣的關鍵部分需要一個治理過程來確保它們得到適當的管理。通常會是手動的過程，但我們需要早點考慮并安排妥當。

5. 準備好應對可能的錯誤

在微服務系統中，多個服務頻繁更新，當服務的部署引入不穩定性或bug時，我們怎么辦？

回滾，找到故障的根源并盡快修復，在大多數情況下是最好的反應。能夠實現回滾的一個先決條件是確保我們能夠從熱修復分支直接發布到生產。

回滾操作在生產環境中往往非常棘手。在大多數情況下，如果更改不大，并且明白問題其中的緣由，回滾會相對容易些。但如果部署包含了一些不容易理解的更改，例如DB更改，特別是那些涉及到模式的更改，則需要在連續部署中將DB更改與代碼更改分開部署，以確保DB更改與早期版本的代碼向后兼容。

感謝各位的閱讀，以上就是“微服務CD怎么實現”的內容了，經過本文的學習后，相信大家對微服務CD怎么實現這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！