現如今的開發人員希望可以開發出具備彈性和可擴展的分布式系統。該系統受益于軟件復用和開源模型創新，針對安全性問題能夠輕易完成補丁更新并進行低風險的升級。該系統不可能通過帶有各種嵌入式語言庫的應用程序框架來實現。最近，一篇關于“多運行時微服務體系結構”的文章，其中探討了分布式系統的需求，例如生命周期管理，高級網絡，資源綁定，狀態抽象以及這些抽象概念多年來的變化。

在以Kubernetes為中心的分布式系統的發展過程中，形成了以Kubernetes Operators和sidecar作為分布式系統交付的主要創新機制。

基于Kubernetes構建的軟件應用，其架構的發展正朝著Kubernetes Operators和sidecar模型發展。Kubernetes Operators和sidecar可能會成為主流的軟件分發和消費方式，在極端情況下甚至會像我們過去那樣取代軟件庫和框架。Sidecar模型允許以不同語言編寫的應用程序組合完成交付，而無需與運行時捆綁。

接下來讓我們看一下Kubernetes Operators和sidecar的一些具體示例，然后我們將探索這種新的模型如何影響我們后續的開發模式。

一、智能化進程外延

在Kubernetes中，sidecar是通過在單個Pod中組織多個容器而實現的核心設計模式之一。Pod功能可確保將容器與指定節點綁定，并通過網絡，文件系統或其他IPC來進行協作。并且Operator可以將sidecar與平臺的其余部分進行自動化管理和集成。sidecar代表了語言無關性，可擴展的數據平面，為定制應用程序提供了分布式原語。Operator代表了集中化管理和控制平面。

讓我們看一下基于Sidecar模型的一些流行的開源項目。

Envoy

Istio，Consul等服務網格使用諸如Envoy之類的透明服務代理為分布式系統提供增強型聯網功能。Envoy具備高安全性、高級流量管理、彈性、深度監控和跟蹤特性。
不僅如此，它支持越來越多的七層協議產品，例如Redis，MongoDB，MySQL和Kafka。它增加了響應緩存功能，甚至還支持WebAssembly，這些功能將支持各種自定義插件。Envoy是透明服務代理如何將高級網絡功能添加到分布式系統而不將其涵蓋在分布式應用程序組件的運行時的一個典型示例。

Skupper

除了典型的服務網格外，還有一些項目（如Skupper）可通過外部代理透傳應用程序網絡流量。Skupper通過7層虛擬網絡解決了多集群Kubernetes的通信難題，并提供了高級路由和連接功能。但是，它沒有將Skupper嵌入到業務服務運行時中，而是在每個Kubernetes名稱空間運行一個實例。

Cloudstate

Cloudstate是Sidecar模型的另一個示例，但這一次是為serverless開發模型提供有狀態抽象。它通過GRPC提供有狀態原語，用于EventSourcing，CQRS，Pub / Sub，鍵值存儲和其他用例。這次是serverless編程模型涵蓋Operators和sidecar的例子。

Dapr

Dapr是由Microsoft發起的一個相對較年輕的項目，它還是使用sidecar模型來提供以開發人員為中心的分布式系統原語。Dapr為狀態管理，服務調用和故障處理，資源綁定，發布/訂閱，分布式跟蹤等提供抽象。盡管Dapr和Service Mesh提供的功能有些重疊，但兩者在本質上卻大有不同。帶有Istio的Envoy被注入并在
服務中透明運行，其代表一種操作工具。另一方面，必須從應用程序運行時通過HTTP或gRPC顯式調用Dapr，它是面向開發人員的顯式工具。其是一個用于分布
式原語的庫，可作為sidecar進行分發和使用，該模型對于使用分布式功能的開發人員變得非常有吸引力。

Camel K

Apache Camel是一個成熟的集成庫。其子項目Camel K大量使用Operators模型來改善開發人員體驗并與Kubernetes平臺進行深度集成。雖然Camel K不依賴于sidecar，但通過其CLI和Operators，它能夠在不到一秒鐘的時間內重用同一應用程序容器并在遠程Kubernetes集群中執行任何本地修改代碼。

這些只是通過Operators和sidecar探索各種可能的一些探索項目。為了減少基于容器的分布式體系結構（如數據平面開發工具包（DPDK））引入的網絡開銷，需要做更多的工作，該工具包是一種用戶空間應用程序，它繞過Linux內核網絡堆棧直接訪問網絡硬件。Kubernetes項目正在進行一些工作，以創建具有更精細的生命周期保證的sidecar容器。有一些基于GraalVM實現的Java項目，例如Quarkus，它們減少了資源消耗和應用程序啟動時間，這些創新的嘗試使得sidecar更具有吸引力。并為更多此類項目的誕生提供了可能。

看到圍繞更具體用例的項目，例如sidecar上的作業調度程序對長期運行的有狀態編排（例如，BPMN引擎）進行的處理。無狀態集成引擎，如Sidecar中的Enterprise Integration Patterns實現；sidecar中的數據抽象和數據聯合引擎；sidecar中的OAuth2 / OpenID代理；可擴展的數據庫連接池；可用于無人駕駛汽車中的serverless工作負載；應用程序網絡，如輔助工具等。但是，為什么軟件供應商和開發人員會切換到這種模式？

接下來介紹這種模式帶來的優越性。

二、模式的優勢

控制平面的運行時

作為軟件供應商，可能已經考慮過將軟件以API或基于SaaS的解決方案的方式提供給客戶，這是最快的軟件消費模型。根據軟件的性質，您可能還會將軟件作為工具庫或運行時框架進行產品分發，也許現在是時候考慮是否將其以operator方式提供。這種軟件的分發機制和體系結構具有一些可執行文件無法提供的特有的好處。

支持多語言

通過協議標準或者標準庫，為多數編程語言提供開發方案。使用sidecar方式運行并通過HTTP協議對外暴露接口的方式，而無需任何特定的運行時庫。即使采用gRPC和Protobuf協議用于處理低延遲和高性能的交互，生成此類客戶端也比在應用程序運行時中包含第三方自定義庫和實現某些接口來的容易得多。兼容性 顯式的sidecar體系結構（與透明的sidecar體系結構相反）是一種軟件消費方式，其作為一個獨立運行時，支持面向開發人員為中心的API。它作為一種通用特性，可以添加到任何應用程序中，無論是單體，微服務，還是基于函數的架構。在Kubernetes上創建輔助工具很簡單，并且在其他軟件編排平臺上也可行。容錯性

業務邏輯始終是內部定制和開發的。分布式系統原語是眾所周知的產品功能，并且已作為平臺功能或產品庫使用。您可能正在使用來自第三方的開源項目或商業軟件來實現消息傳遞，網絡彈性和監視。這些第三方軟件的發布周期、關鍵代碼的修復和CVE補丁同樣會影響您的軟件發布周期。當第三方庫作為單獨的運行時（sidecar）使用時，升級過程會更簡單，因為它位于API服務的后面，并且不與應用程序運行時解藕。軟件開發團隊與第三方軟件之間的解藕變得更易于管理。

控制平面

當某個功能作為庫使用時，它就包含在應用程序的運行時中，您有責任了解它的工作方式，其中包括配置、監控、性能和升級。語言的運行時（例如JVM）和運行時框架（例如Spring Boot或應用程序服務器）決定了如何處理配置、監視和升級方案。當軟件功能作為單獨的運行時使用（例如，sidecar或獨立容器）時，它將以Kubernetes operator的形式提供其控制平面。由于控制平面了解其管理的軟件并具備必要的智能化管理特性，否則它將作為文檔和最佳實踐進行分發。此外，運營商還與Kubernetes進行了深度集成，提供了平臺集成和operator開箱即用的奇妙組合。operator由同一開發人員創建，他們了解容器化功能的內部結構，并且知道如何最佳地操作。operator是容器中的SRE，隨著更多operator及其應用市場的興起，operator的數量及其功能正在穩步增長。

三、未來軟件發行

以sidecar方式分發軟件并附帶管理平面

假設您是Java框架的軟件提供商，我們可以以Maven配置方式進行分發。當然更進一步，我們可以直接以容器鏡像方式分發。無論采用何種方式，在當今的云原生世界中，都未達到盡善盡美的地步。用戶仍然需要知道如何在零停機狀態下對應用程序程序進行熱更新，同時需要知道應該備份的內容以及如何配置其監控并設置告警閾值。他們必須知道如何檢測復雜故障并解決。他們必須知道如何根據當前的負載配置文件來調整應用程序。

在處理上述類似的場景時，Kubernetes以operator方式提供管理平面的方案將是最優解。operator包含應用程序和以關聯業務特性的配置方式來以管理工作負載的組件。

Sidecars和operators正在成為主流的軟件分發和消費方式，在某些情況下甚至會像我們過去那樣取代軟件庫和框架。

假設您提供的軟件庫作為依賴項包含在使用者應用程序中。可能是上面描述的后端框架的客戶端庫。例如，如果它是在Java中，那么您可能已經在J2EE服務器上運行，前提是Spring啟動程序、構建程序、工廠和其他實現都隱藏在Java接口后面，這樣你甚至可以把它移植到golang。

有了Kubernetes的operator和sidecars之后，所有這些都對消費者透明。工廠類被operator取代，唯一的配置接口是自定義資源的YAML文件。然后，operator負責配置軟件，以便用戶可以將其作為一個顯式的sidecar來使用。在所有情況下，您的應用程序都可以通過遠程API調用，并與平臺功能甚至其他依賴的operator完全集成。

通過遠程API而不是嵌入式庫使用的軟件

換種角度來看，sidecar的作用類似于OOP中繼承原則的組合，但是在多語言環境中。通過組合來自不同進程的功能，而不是將它們作為依賴項包含在單個應用程序中，這是一種組織應用程序功能的不同方式。當您將軟件用作庫時，可以實例化一個類，并通過傳遞一些值來調用其方法。當您將其用作進程外功能時，您將訪問本地進程。在此模型中，方法被API取代，進程內方法被HTTP或gRPC調用所取代，并使用CloudEvents之類的通信標準。這是從應用程序服務器到Kubernetes的分布式運行時的轉變。這是從特定語言的界面到遠程API的轉變。從內存調用到HTTP，從值對象到CloudEvents，等等。

這要求軟件提供商分發容器和控制器以對其進行管理。創建能夠在本地構建和調試多個運行時服務的IDE。用于代碼更新并配置控制平面以快速部署到Kubernetes的CLI。可以決定在自定義應用程序運行時中進行編譯的內容，可以從Sidecar輸出哪些能力以及從業務流程平臺獲得哪些功能。

從長遠來看，這將導致標準API的合并，這些標準API用于消耗sidecar中的通用能力。除了特定語言的標準和API，我們將使用多語種API。例如，除了Java數據庫連接（JDBC）API，Java緩存API（JCache），Java持久性API（JPA）之外，我們還將使用CloudEvents之類的基于HTTP的多語言API。以Sidecar為中心API，如用于消息傳遞，緩存，可靠的網絡，cron作業和計時器調度，資源綁定（其他API，協議的連接器），冪等性，SAGA等。所有這些功能都將隨表格中包含的管理層一起提供，甚至包含自助式用戶管理界面。operator是上述特性的關鍵推動力，因為它們將使分散的架構易于在Kubernetes上進行管控。operator的管理接口由CustomResourceDefinition定義，代表第三方資源面向公眾管理的API。

在交付速度和可操作性的驅動下，這是一種思想上的巨大轉變，其轉向了一種革命性的軟件分發和使用的方式。這是從單一運行時架構到多運行時應用程序架構的轉變。這與摩爾定律結束后硬件行業從單核平臺向多核平臺的轉變歷史。這一變化正在慢慢發生：我們已經統一采用標準化容器，我們已經基于Kubernetes確定了事實上的編排標準，隨著推出的sidecar，以及operator的廣泛應用，以及CloudEvents標準的深入人心，標準化的API和生態系統也會隨之出現。

參考資料

Operators及Sidecars成為軟件交付新模式

End

樂于輸出干貨的CloudNative相關技術公眾號：DCOS。