關於微服務CD的5點思考
持續交付是任何軟體交付實踐的重要組成部分。無論目標部署環境如何，我們都應該設計CD工作流，以便將軟體的任何更改投入生產。
對於微服務架構來說同樣如此。本文將分享作者Sheroy Marker在架構設計和應用開發中的一些關於CD工作流的思考和經驗。
微服務和CD
按照Martin Fowler的說法，微服務架構是“將軟體設計一組為可獨立部署的服務的方式“。這種方式目前已經成為構建分散式系統/應用的主流；按照Jez Humble的說法，CD（持續交付）是“能夠以可持續的方式安全快速地將所有型別的變更 - 包括新功能、配置、錯誤修復和實驗 - 投入生產”。
無論是一體化架構還是微服務架構，無論目標部署環境或我們的架構選擇如何，設計好CD工作流程以使我們對應用的任何更改投入生產都很重要。CD工作流程是DevOps流程的核心，能夠很好的串聯組織中的各種功能，包括開發、QA以及IT運維等等。
微服務架構CD的4項挑戰
-
維護複雜分散式系統的完整性：由於我們將大型一體化系統分解成為了更小、更易於管理的微服務，因此係統本身的整體複雜性會增加，我們開始需要處理分散式系統相關的問題；
-
安全快速地釋出功能：當我們的功能可能涉及一個或多個微服務的更改時，需要特別考慮一下如何管理頻繁的功能釋出；
-
管理不同技術堆疊的部署：微服務環境通常包括用於服務的不同技術堆疊，跨技術對戰的管理和部署過程很有挑戰性；
-
獨立部署服務的過程和工具：有許多工具可用於構建CD工作流程，但選擇工具、制定CD工作流並不是一件容易的事。
微服務架構CD的5點思考
- 準備好測試策略
跟傳統一體化架構應用相比，微服務架構的測試和驗證更加細緻，也更加複雜。一個有效的測試策略必須同時考慮到測試單個服務和驗證整個系統行為的需要。
對於服務的pre-production測試，特別是以隔離的方式測試，傳統方法仍然適用。測試金字塔仍然可以幫助我們在不同型別的測試之間保持平衡。但是，在測試服務聚合時，這種測試方式的效果有限。我們會遇到一些在測試環境中無法模擬的錯誤類別，例如由分散式系統中的最終一致性引起的問題，導致系統部分失敗的硬體和網路故障等。
我們最好利用一些技術來作為傳統測試的補充，例如synthetic user testing、lightweight user acceptance testing以及fault injection testing等等。
- 檢查好CI實踐
CI是CD的關鍵實踐。除了構建伺服器、構建定義相關的考慮，基於主幹的開發和功能切換是實現簡單而強大的CI過程的兩個關鍵實踐。
在基於主幹的開發中，開發人員在一個名為“trunk”的分支中協作。這樣做的好處是，避免開發分支的drift和由此產生的merge hell。這與維護長期特徵和釋放分支的做法相反。在分支模型中，雖然我們可能會在各個分支上執行構建，但事實上，我們沒有進行持續整合。
要進行基於主幹的開發，需要有稱為feature toggles的控制元件。功能切換支援WIP和已完成功能的組合的多次提交。通過這些切換，我們可以在生產環境中關閉不完整特性的顯示，直到這些特性在生產環境中得到充分的開發和測試。特性切換通常儲存在靠近程式碼基的規範或配置檔案中，並由CD管道中的自動化程式在特定環境中開啟切換。
一旦我們有了維護feature toggles的機制，我們可以使用相同的機制來引入其他類別的toggles，如release toggles（控制對未完成的程式碼的訪問）、Ops toggles（控制生產程式碼的行為）、permissions toggles（到開啟特權使用者的特定行為）和experimental toggles（對於多變數測試 - 在使其成為永久性之前接收到的功能的程度）。
- 計劃好環境
環境計劃包括我們的環境集、它們的預期用途、通過這些環境促進工件的策略以及在這些環境中的toggle狀態。
首先，考慮需要什麼環境以及它們的預期用例。組織中不同的部門有不同的競爭需求。在建立環境時，我們應該滿足所有這些相互競爭的需求。
其次，如果可能的話，考慮使用雲基礎設施動態建立環境。例如使用Kubernetes的標籤功能，可以在飛行測試環境中建立自動化測試，而不是在長期存在的環境。
第三，CD管道會生成許多artifacts，我們應該考慮要儲存多少artifacts？我們需要多少repositories等等。
- 管理好配置
應用的配置包括那些每次部署時不盡相同的東西，應該與程式碼分開儲存。那麼當我們擁有一組微服務時，應該如何處理配置呢？
一種辦法是在Consul或Vault等儲存庫中集中管理部署配置，在Chef和CD管道中擴充套件部署配置只會徒增理解難度。
另一種技術是採用標準化分發配置的流程，不管服務的技術對戰如何，讓服務根據堆疊處理配置。例如，我們通常參考12-factors，避免分發配置檔案。
最後，像證書這樣的關鍵部分需要一個治理過程來確保它們得到適當的管理。通常會是手動的過程，但我們需要早點考慮並安排妥當。
- 準備好應對可能的錯誤
在微服務系統中，多個服務頻繁更新，當服務的部署引入不穩定性或bug時，我們怎麼辦？
回滾，找到故障的根源並儘快修復，在大多數情況下是最好的反應。能夠實現回滾的一個先決條件是確保我們能夠從熱修復分支直接釋出到生產。
回滾操作在生產環境中往往非常棘手。在大多數情況下，如果更改不大，並且明白問題其中的緣由，回滾會相對容易些。但如果部署包含了一些不容易理解的更改，例如DB更改，特別是那些涉及到模式的更改，則需要在連續部署中將DB更改與程式碼更改分開部署，以確保DB更改與早期版本的程式碼向後相容。
關於Rainbond
Rainbond（雲幫）是"以應用為中心”的開源PaaS， 深度整合基於Kubernetes的容器管理、ServiceMesh微服務架構最佳實踐、多型別CI/CD應用構建與交付、多資料中心資源管理等技術， 為使用者提供雲原生應用全生命週期解決方案，構建應用與基礎設施、應用與應用、基礎設施與基礎設施之間互聯互通的生態體系， 滿足支撐業務高速發展所需的敏捷開發、高效運維和精益管理需求。