還在複製Jar或War包？還在用Maven拉庫包或框架？基於Kubernetes的運維者與邊車模型將是軟體交付的新模式 〜Bilgin Ibryam

banq發表於2020-07-05
JARMaven框架運維模型模式

邊車和運維者模型可能會成為主流的軟體分發和消費模型，在某些情況下甚至會取代軟體庫包和框架。
如果您是一個軟體供應商，可能您已經考慮過將您的軟體作為API或基於SaaS的解決方案提供給潛在使用者，這是最快的軟體消費模型，並且儘可能地提供了便利；根據軟體的性質，您可能還會將軟體作為庫或執行時框架進行分發(如Spring框架等)；也許現在是時候考慮是否也可以將它作為容器提供給運維者了，這種分發軟體的機制和最終的體系結構具有一些庫機制無法提供的非常獨特的好處。
Kubernetes上的軟體應用程式架構的發展將朝著由運營者管理的sidecar邊車模型發展。邊車和運營商兩個模型可能會成為主流的軟體分發和消費模型，在某些情況下甚至會像我們過去那樣取代軟體庫和框架。
邊車模型允許以不同語言編寫的應用程式組合可以更快地交付聯合價值，而無需執行時耦合。讓我們看一些邊車和操作員的具體示例，然後我們將探索這種新的軟體組合範例如何影響我們。

什麼是Kubernetes的運維者與邊車模型？
在Kubernetes中，邊車是透過在單個Pod中組織多個容器輕鬆實現的。Pod構造可確保將容器始終放置在同一節點上，並可以透過網路，檔案系統或其他IPC方法進行互動來進行協作。Kubernetes運維者 可以將邊車與平臺的其餘部分進行自動化、管理和整合。

邊車代表了與語言無關的可擴充套件資料平面，為定製應用程式提供了分散式原語。運維者代表集中管理和控制平面。

邊車模型的實現

  • Istio，Consul等服務網格使用Envoy等透明服務代理 為分散式系統提供增強的聯網功能。。Envoy可以提高安全性，支援高階流量管理，提高彈性，新增深度監視和跟蹤功能。不僅如此，它還了解越來越多的第7層協議，例如Redis，MongoDB，MySQL和最新的Kafka。它還增加了響應快取功能，甚至還提供了WebAssembly支援，可啟用各種自定義外掛。Envoy是透明服務代理如何將高階網路功能新增到分散式系統而不將其包括在分散式應用程式元件的執行時中的一個示例。
  • 除了上面典型的服務網格外，還有一些專案，例如Skupper，這些專案透過外部代理傳遞應用程式網路功能。
  • Cloudstate 是Sidecar模型的另一個示例，但這一次是為無伺服器開發模型提供有狀態抽象。它透過GRPC提供有狀態原語，用於EventSourcing，CQRS，Pub / Sub，鍵/值儲存和其他用例。同樣，它是邊車和操作員在行動的例子，但是這次是無伺服器程式設計模型。
  • Dapr是一個由Microsoft發起的相對較年輕的專案，它還使用sidecar模型來提供針對開發人員的分散式系統原語。Dapr為狀態管理，服務呼叫和故障處理，資源繫結，釋出/訂閱，分散式跟蹤等提供抽象。Dapr和Service Mesh區別：帶有Istio的Envoy被注入並從服務中透明地執行，並且代表一種運維工具；Dapr必須透過HTTP或gRPC顯式呼叫，面向開發人員的顯式工具。
  • Apache Camel是一個成熟的整合庫，可以在Kubernetes上重新發現自己。其子專案Camel K 大量使用運營商模型來改善開發人員體驗並與Kubernetes平臺進行深度整合。儘管Camel K不依賴於sidecar，但透過其CLI和操作員，它能夠在不到一秒鐘的時間內重用同一應用程式容器並在遠端Kubernetes叢集中執行任何原生程式碼修改。這是透過運營商模型開發人員為目標的軟體使用量的另一個示例。

有一些基於GraalVM實現的新Java專案，例如Quarkus。 從而減少了資源消耗和應用程式啟動時間，從而使更多的工作負載吸引了邊車(現在的JavaEE和Spring都無法做到)。所有這些創新將使邊車模型更具吸引力，並使建立更多此類專案成為可能。
更具體用例的專案：例如對長期執行的有狀態編排（例如，邊車中的業務流程模型和註釋（BPMN）引擎）進行的處理，我並不感到驚訝。邊車上的作業排程程式。無狀態整合引擎，即Sidecar中的Enterprise Integration Patterns實現。

運維者模型
(banq注：將軟體直接交付給運維者，軟體研發和軟體實施的兩個階段實現分離，研發團隊交付帶有yaml配置的Docker容器映象，實施團隊直接一鍵部署運維監控，兩者之間不再扯皮。)
基於容器的運維者交付模型好處是：

  • 支援多語種消費者，透過提供可透過開放協議和標準使用的庫，可以開放為所有程式語言。
  • 應用架構不可知，顯式的sidecar體系結構（與透明的sidecar體系結構相反）是一種軟體功能消耗的方法，它作為以開發人員為中心的API後面的單獨執行時。它是一個正交功能，可以新增到任何應用程式中，無論是單塊，微服務，基於函式，基於參與者還是介於兩者之間的任何東西。它可以在不太動態的環境中緊挨著一個整體，或者在動態的基於雲的環境中緊挨著每個微服務。在Kubernetes上建立輔助工具很簡單，並且在許多其他軟體編排平臺上也可行。
  • 容忍釋放阻抗不匹配：您的團隊與消費使用的第三方庫供應商之間的阻抗不匹配變得更易於管理。

當某個功能作為庫包或框架使用時，它會包含在您的應用程式執行時中，您有責任瞭解它的工作原理，配置，監視，調整和升級。這是因為語言執行時（例如JVM）和執行時框架（例如Spring Boot或應用程式伺服器）決定了如何包括，配置，監視和升級第三方庫。
而當軟體功能被用作單獨的Runtime執行時環境（例如，邊車或獨立容器）時，它會以Kubernetes運算子的形式附帶其自己的控制平面。
由於控制平面瞭解其管理的軟體（運算元）並具有所有必要的管理智慧，否則它將作為文件和最佳實踐分發了，因此，這將帶來很多好處。此外，運營商還與Kubernetes進行了深度整合，並提供了平臺整合和運算元管理智慧的獨特組合。運算子由建立應用的同一開發人員建立，他們瞭解容器化功能的內部結構，並且知道如何最佳地操作。

未來的軟體發行和消費使用
未來是作為帶有控制平面的邊車分發的軟體，
假設您是Java框架的軟體提供商。您可以將其作為存檔或Maven工件進行分發。也許您走得更遠，然後分發了容器映像。無論哪種情況，在當今的雲原生世界中，這還不夠好。
使用者仍然必須知道如何在零停機時間內修補和升級正在執行的應用程式。他們必須知道要備份和還原其狀態的內容。他們必須知道如何配置其監視和警報閾值。他們必須知道如何檢測複雜故障並從中恢復。他們必須知道如何根據當前的負載配置檔案調整應用程式。
在所有這些以及類似的場景中，Kubernetes運算子形式的智慧控制平面就是解決答案。運營商將應用程式的平臺和領域知識封裝在以宣告方式配置的元件中，以管理工作負載。
假設您提供的軟體庫作為依賴項包含在使用者應用程式中。也許它是上述後端框架的客戶端庫。例如，如果它使用Java，則可能已認證它可以在JEE伺服器上執行，必須提供Spring Boot Starters，Builders，Factory和其他實現都隱藏在乾淨的Java介面後面。您甚至可能也將其反向移植到.Net。
使用Kubernetes運維者和小邊車，所有這些對消費者都是隱藏的。工廠類被運維者模型替換，唯一的配置介面是自定義資源的YAML檔案。然後，運營者模型負責配置軟體和平臺，以便使用者可以將其作為顯式的輔助工具或透明的代理使用。在所有情況下，您的應用程式還是都可以透過遠端API使用，並且與平臺功能甚至其他從屬操作員完全整合。

透過遠端API而不是Maven等嵌入式庫使用的軟體
未來標準API除了Java資料庫連線（JDBC）API，Java快取API（JCache），Java永續性API（JPA）之外，我們還將使用CloudEvents之類的基於HTTP的多語言API。用於訊息傳遞，快取，可靠的網路，cron作業和計時器排程，資源繫結（其他API，協議的聯結器），冪等性，SAGA等的Sidecar中心API。
所有這些功能都將隨表格中包含的管理層一起提供運營商，甚至包裹著自助式使用者介面。運營商是此處的關鍵推動力，因為它們將使這種更加分散的架構易於在Kubernetes上進行管理和自我操作。

總結
在交付速度和可操作性的驅動下，這是一種思想上的巨大轉變，轉向了一種不同的分發和使用軟體的方式。這是從單一執行時架構到多執行時應用程式架構的轉變。這與摩爾定律結束時硬體行業從單核平臺向多核平臺的轉變相似。透過構建難題的所有要素，這種變化正在慢慢發生：我們已經統一採用並標準化了容器，我們已經透過Kubernetes制定了事實上的編排標準，CloudEvents廣泛有了適當的標準，就可以使用Quarkus等輕量級執行時。有了這樣的基礎，應用程式，生產力工具，實踐，標準化的API和生態系統也會隨之出現。(banq注：怪不得Spring公司戰略轉移到K8s，雖然遲了一步，但是有希望。)

相關文章