[[381481]]

本文轉載自微信公眾號「全棧碼農畫像」，作者小碼甲。轉載本文請聯系全棧碼農畫像公眾號。  

Backing services

云原生系統依賴于許多不同的輔助資源，例如數據存儲、消息隊列、監視和身份服務，這些服務統稱為支撐性服務。

下圖顯示了云原生系統使用的常見支撐性服務

支撐性服務幫助實現了“十二要素應用”中的Statelessness原則

要素6提到：“每個微服務應在獨立隔離的進程中執行，將所需狀態信息作為外部支撐性服務，例如分布式緩存或數據存儲”

最佳實踐是將支撐性服務視為附加資源，并使用外部掛載的方式將配置(URL和憑據)動態綁定到微服務。

要素4指出：“支撐性服務“應通過可尋址的URL公開，這樣做解耦了將資源與應用”

要素3指出：“將配置信息從微服務中移出并外掛”

Stateless和支撐性服務，這樣松散的設計使你可以將一項支撐性服務換成另一項支撐性服務，或將代碼移至其他公有云，而無需更改主線服務代碼。

支撐性服務將在第5章“云原生數據模式”和第4章“云原生通信模式”中詳細討論。

自動化

如你所見，云原生依賴(微服務、容器和現代設計理念)來實現速度和敏捷性。

但是，你如何配置運行這些系統的云環境?你如何快速部署應用程序功能和更新?

被廣泛認可的作法是基礎設施即代碼(IaC)

借助IaC，你可以將平臺配置和應用程序部署自動化，將諸如測試和版本控制之類的軟件工程實踐應用于你的DevOps實踐。你的基礎架構和部署是自動化，一致且可重復的。

Automating infrastructure

在底層，IaC是冪等的，這意味著你可以一遍又一遍地運行相同的腳本，而不會產生副作用。

如果團隊需要進行更改，可以編輯并重新運行腳本，(僅)需要更新的資源受到影響。

在《基礎架構即代碼》一書中，作者Sam Guckenheimer指出：“實施IaC的團隊可以大規模、快速、穩定地交付。團隊不用手動配置環境，通過代碼表示 需要的環境狀態，來增強交付預期。使用IaC進行基礎架構部署是可重復的，可防止由于配置差異或缺少依賴關系而導致運行時問題”。

Automating deployments

"十二要素應用"指出了從代碼開發到交付落地的原則

要素5指出：“嚴格區分構建、發行和運行階段。每個發行階段都應標有唯一的ID，并支持回滾功能。”

現代CI/CD實現了這一原則。它們提供的獨立部署步驟，確保將一致的、高質量的代碼交付給用戶。

下圖演示了獨立的部署過程：

在上圖中，要注意任務分離。

開發人員在其開發環境中創建feature分支，反復迭代“inner loop”(運行和調試)。完成后，該代碼將被推送到代碼存儲庫中，例如GitHub、Azure DevOps或BitBucket。

推送觸發自動構建，構建階段將代碼轉換為二進制產物。這項工作是通過持續集成(CI)管道實現的，它會自動生成，測試和打包應用程序。

發布階段拾取前面的二進制產物，加上外部應用程序和環境配置信息，產生不可變更的發行版。該版本將會部署到指定的環境。這項工作是通過持續交付(CD)管道實現的。每個版本都應該是可識別、可追溯的。你可以說：“這次部署的是應用程序的Release 2.1.1版本”。

最后，發布的版本放在目標執行環境中運行。版本不可變，這意味著任何更改都必須創建一個新版本。

應用這些實踐，從根本上發展了軟件發布方式。許多人已經從季度發布轉為按需更新。通過集成過程的一致性，團隊可以更頻繁地提交代碼更改，從而改善協作和軟件質量。

Ref

https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/definition