創建良好的分布式應用程序并非易事：這樣的系統通常會遵循 12 要素應用程序和微服務原則。它們必須是無狀態的、可擴展的、可配置的、獨立發布的、容器化的、可自動化的，有時甚至是事件驅動的和 serverless。創建之后，它們應該很容易進行升級，并且可以承受長期的維護。用今天的技術在這些互相競爭需求中找到一個良好的平衡點仍然需要付出艱苦的努力。

在本文中，我將探討分布式平臺該如何演化以實現這種平衡，更重要的是，在分布式系統的發展中還需要做些什么才能簡化可維護的分布式架構的創建。

1. 分布式應用程序的需求

為了討論方便起見，我把現代分布式應用程序的需求分為 4 類，分別是生命周期（lifecycle）、網絡（networking）、狀態（state）和綁定（binding），并簡要地分析一下最近幾年中它們的發展情況。

生命周期

讓我們從基礎開始。當我們編寫功能時，編程語言會指定生態系統中的可用庫、打包格式和運行時。例如，Java 使用.jar 格式，所有的 Maven 依賴項作為一個生態系統，而將 JVM 作為運行時。如今，隨著發布周期變得更短，生命周期中更為重要的是以自動化的方式部署的能力、從錯誤中恢復的能力和擴展服務的能力。這組能力廣泛地代表了應用程序生命周期的需求。

網絡

如今，從某種意義上說，幾乎所有的應用程序都是分布式應用程序，因此，它們都需要網絡。但是，現代分布式系統需要從更廣泛的角度去掌握網絡。從服務發現和錯誤恢復，到實現現代軟件發布技術和各種跟蹤及遙測。為了滿足我們的需要，我們甚至會在這個類別中包含不同的消息交換模式、點對點和發布 / 訂閱方式，以及智能路由機制。

狀態

當我們在討論狀態時，通常是在討論服務的狀態以及為什么無狀態是更好的方案。但是，管理我們服務的平臺本身需要狀態。進行可靠的服務編排和工作流、分布式單例、臨時調度（即 cron jobs）、冪等性（idempotency）、狀態化的錯誤恢復、緩存等等都需要它。這里所列出的功能都依賴于底層的狀態。盡管實際狀態管理不屬于本文討論的范圍，但是，我們感興趣的是分布式原語及其依賴于狀態的抽象。

綁定

分布式系統的組件不僅要相互通信，而且要和現代的或遺留的外部系統集成。這需要連接器（connector）能夠轉換各種協議、支持不同的消息交換模式，如輪詢、事件驅動、請求 / 答復、轉換消息格式，甚至能夠執行自定義的錯誤恢復程序和安全機制。

排除一次性用例的情況，上面提到的內容代表了創建良好分布式系統通用原語的一個很好的集合。如今，很多平臺都提供這類功能，但是，我們在本文中要講的是，在過去的 10 年中，我們使用這些功能的方式發生了什么變化，以及它在未來 10 年里會怎樣變化。為了進行對比，我們來看看過去 10 年中基于 Java 的中間件是如何滿足這些需求的。

2. 傳統中間件的局限性

在知名的傳統解決方案中，有一個方案滿足了上述需求的老一代版本，那就是企業服務總線（ESB）及其變體，如面向消息的中間件、輕量級的集成框架等等。ESB 是一個中間件，它支持利用面向服務的架構（即經典的 SOA）實現異構環境之間的互操作性。

盡管 ESB 可以提供良好的功能集，但是，ESB 的主要挑戰是單體架構以及業務邏輯和平臺之間緊密的技術耦合，這導致了技術和組織的集中化。在這類系統中開發和部署服務時，它和分布性系統框架會緊密耦合，從而限制了服務的演化。在軟件生命的后期這才會變成一個明顯的問題。

ESB 面對每類需求都有一些問題和局限性，這使得 ESB 在現代已經不再是可行的方案了，詳述如下。

生命周期

傳統的中間件通常只支持的一個語言運行時，（比如 Java），這就限定了軟件該如何打包、哪些庫可用、它們打補丁的頻率等等。業務服務必須使用這些庫，這些庫與平臺緊密耦合并使用相同的語言編寫。在實踐中，這會導致服務和平臺的同步升級，從而妨礙服務和平臺之間實現獨立和定期的版本發布。

網絡

盡管傳統的中間件擁有高級的功能集，這些功能注重與其他內部及外部服務的交互，但是，它有一些重大的缺陷。網絡功能集中于一種主要的編程語言及其相關的技術。對于 Java 語言，即 JMS、JDBC、JTA 等等。更重要的是，網絡問題和語義也深深地刻入了業務服務中。一些庫具有解決網絡問題的抽象（如曾經流行一時的 Hystrix 項目），但是，該庫的抽象將自身的編程模型、交換模式和錯誤處理語義及庫本身“泄漏”到了服務之中。盡管可以方便地在一個位置編寫和讀取混合了網絡功能的完整業務邏輯，但是，這樣會把兩個問題緊密地耦合到一個實現中，最終會形成綁定在一起的演化路徑。

狀態

為了進行可靠的服務編排、業務流程管理和實現模式（如 Saga 模式以及其他運行緩慢的流程），平臺需要在后臺保持持久狀態。類似的，臨時操作（如觸發定時器和 cron job）都是基于狀態構建的，并需要在分布式環境中對數據庫進行集群和彈性處理。這里主要的約束是，與狀態交互的庫和接口沒有完全抽象出來，也沒有與服務運行時完全解耦。通常，這些庫必須配置數據庫細節，并且它們位于服務中，從而把語義和依賴項問題泄露到了應用程序域中。

綁定

使用集成中間件的主要驅動因素之一是能夠使用不同協議、數據格式和消息交換模式連接各種其他系統。然而，這些連接器必須與應用程序共存的事實意味著，依賴項必須與業務邏輯一起更新和打補丁。這樣的話，數據類型和數據格式必須在服務內進行來回地轉換。這意味著，必須根據消息交換模式構造代碼和設計流程。上述的這幾個樣例場景說明了在傳統中間件中，即使是抽象的端點也會如何影響服務的實現。

3. 云原生的趨勢

傳統的中間件功能非常強大。它擁有所有必要的技術特性，但是，它缺乏快速改變和擴展的能力，而這是現代數字業務需求所要求的。這是微服務架構及其設計現代分布式應用程序的指導原則正在解決的問題。

微服務背后的思想以及其技術需要推動了容器和 Kubernetes 的普及和廣泛使用。這開啟了一種新的創新方式，會影響未來幾年分布式應用程序開發的方式。我們來看看 Kubernetes 及其相關的技術是如何影響每組需求的。

生命周期

容器和 Kubernetes 把我們打包、分發和部署應用程序的方法演化成與編程語言無關的格式。關于 Kubernetes 模式和 Kubernetes 對程序開發人員的影響，有很多文章，這里我簡單說一下。請注意，對 Kubernetes 來說，需要管理的最小原語是容器，并且，它專注于在容器級別和流程模型上交付分布式原語。這意味著，在管理應用程序的生命周期方面、健康檢查、恢復、部署和擴展都做得很好，但是，在改進分布式應用程序的其他方面（如靈活的網絡、狀態管理和綁定）做得并不好，這些分布式應用程序生存于容器內部。

我們可能會指出，Kubernetes 擁有有狀態的工作負載、服務發現、cron job 及其他功能。這是事實，但是，所有這些原語都在容器級別，并且在容器內部，開發人員仍然必須使用特定于編程語言的庫來獲取更細粒度的功能，這些功能我們已經在本文的開頭部分列出。這就是驅動 Envoy、Linkerd、Consul、Knative、Dapr、Camel-K 等等項目的原因。

網絡

事實證明，由 Kubernetes 提供的圍繞服務發現的基本網絡功能是一個良好的基礎，但是，對于現代應用程序來說還不夠。隨著微服務數量的增加和部署的加快，無需接觸服務就能實現更先進的發布策略、管理安全、指標、追蹤、從錯誤中恢復、模擬錯誤等功能變得越來越有吸引力，并產生了一種新的軟件類別，稱為服務網格。

這里有一個更令人興奮的趨勢，那就是將網絡相關的關注點從包含業務邏輯的服務轉移出來，放到一個單獨的運行時中，這可能是邊車，也可能是節點級別的代理。今天，服務網格可以進行更高級的路由，有助于測試、處理安全的某些問題，甚至可以使用特定于應用程序的協議（例如，Envoy 支持 Kafka、MongoDB、Redis、MySQL 等）。盡管，服務網格作為一種解決方案，還沒有得到廣泛的采用，但是，它觸及了分布式系統真正的痛點，我相信，它將找到適合自己生存的形式。

除了典型的服務網格外，還有其它項目，如 Skupper，它證實了把網絡能力放入外部運行時代理的趨勢。Skupper 通過第 7 層虛擬網絡解決了多集群通信的難題，并提供了高級路由及連接功能。但是，它在每個 Kubernetes 命名空間運行一個實例，而不是把 Skupper 嵌入業務服務運行時。

總之，容器和 Kubernetes 在應用程序的生命周期管理中向前邁出了重要的一步。服務網格及相關技術觸及了真正的痛點，并為把應用程序更多的責任向外轉移到代理打下了基礎。我們來看看接下來的事。

狀態

我們在前面列出了依賴于狀態的主要集成原語。狀態的管理比較困難，應該把它委派給專門的存儲軟件和托管服務。這不是本文的主題，但是，使用狀態，以語言無關的抽象方式來幫助集成用例才是主題。如今，大家做了很多努力，試圖在語言中立的抽象背后面提供狀態化的原語。對于基于云的服務來講，狀態化工作流的管理是必備功能，例如 AWS 的 Step 函數、Azure Durable 函數等。在基于容器的部署中，CloudState 和 Dapr 都依賴邊車模型以提供分布式應用程序中狀態化抽象更好的解耦。

我希望，把前面列出的狀態化功能也都抽象到一個獨立的運行時。這意味著，工作流管理、單例、冪等、事務管理、cron job 觸發器和狀態化錯誤處理都在邊車（或主機級別的代理）中可靠地發生，而不是存在于服務中。業務邏輯不需要在應用程序中包括這類依賴項和語義，它可以從綁定環境中聲明式地請求這類行為。例如，邊車可以充當 cron job 觸發器、冪等消費者和工作流管理器，并且自定義業務邏輯可以作為回調調用或在工作流、錯誤處理、臨時調用或唯一冪等請求等的某些階段插入。

另一個狀態化的用例是緩存。無論是服務網格層執行的請求緩存，還是用 Infinispan、Redis、Hazelcast 等進行的數據緩存，有一些把緩存功能推到應用程序運行時之外的示例。

綁定

盡管我們一直在討論從應用程序運行時解耦所有分布式需求這個主題，但是這種趨勢也伴隨著綁定。連接器、協議轉換、消息轉換、錯誤處理和安全中介都可以移出服務運行時。我們還沒到那個階段，但是，有幾個項目在朝這個方向進行嘗試，如：Knative 和 Dapr。把所有這些職責移出應用程序運行時將導致更小型的專注于業務邏輯的代碼。這類代碼將生存于獨立于分布式系統需求的運行時中，可以作為預打包的功能使用。

Apache Camel-K 項目采用了另一種有趣的方法。該項目依賴于一個智能 Kubernetes 操作符（Kubernetes Operator，該操作符利用來自 Kubernetes 和 Knative 附加的平臺能力構建應用程序運行時），而不是將運行時代理和主應用程序放到一起。在這里，該代理是負責應用程序要求的操作符，其中包括分布式系統原語。區別在于，有些分布式原語被添加到應用程序運行時中，而有些是在平臺（也可能包括邊車）中實現的。

4. 未來架構的趨勢

從廣義上看，我們可以總結為，通過把功能移到平臺級別，分布式應用程序的商業化達到了新領域。除了生命周期之外，現在我們可以將網絡觀察、狀態抽象、聲明性事件以及端點綁定也視為有現成解決方案的領域，而 EIP 則是該列表上的下一個。有趣的是，商業化正在使用進程外模型（邊車）進行功能擴展，而不是運行時庫或單純的平臺功能（如新 Kubernetes 功能）。

通過把所有傳統中間件功能（也即 ESB）移到其他運行時，我們正在接近實現整個循環，不久之后，我們在服務中唯一要做的就是編寫業務邏輯。

與傳統 ESB 時代相比，這個架構更好地解耦了業務邏輯和平臺，但還沒完全解耦。很多分布式原語，如經典的企業集成模式（Enterprise Integration Pattern，簡稱 EIP）: 拆分器、聚合器、過濾器、基于內容的路由器；以及流處理模式（映射、過濾、折疊、聯接、合并、滑動窗口）仍然需要包含在業務邏輯運行時中，很多其他應用程序依賴于多個不同的及重疊的平臺附加組件中。

如果我們把在不同領域中進行創新的不同云原生項目疊加起來，那么，我們最終會看到這張圖，如下所示：

這里的圖只是用于說明，它故意選擇了有代表性的項目，并把它們映射為分布式原語的一種。實際上，我們不會同時使用所有這些項目，因為它們中的一些是重疊的，并且工作負載模型也是不兼容的。如何來講解這張圖？

• Kubernetes 和容器在多語言應用程序的生命周期管理中取得了巨大的飛躍，并為未來的創新奠定了基礎。
• 服務網格技術在 Kubernetes 之上利用高級的網絡功能進一步進行了改善，并開始涉足應用程序方面。
• 盡管 Knative 憑借其快速擴展主要專注于 serverless 類型的工作負載，但是，它也滿足了服務編排和事件驅動的綁定需求。
• Dapr 建立在 Kubernetes、Knative 和服務網格的思想之上，并深入應用程序運行時以解決狀態化工作負載、綁定和集成的需求，充當現代分布式中間件。

這張圖能夠幫助我們看到，很可能在將來，我們最終會使用多運行時來實現分布式系統。多運行時，不是因為有多個微服務，而是因為每個微服務將由多個運行時構成，很可能會有兩個，即自定義業務邏輯運行時和分布式原語運行時。

5. 引入多運行時微服務

以下是正在形成的多運行時微服務架構的概述。

你是否記得在電影《阿凡達》中，科學家開發的增強機動平臺（Amplified Mobility Platform，簡稱 AMP）“機甲戰衣（mech suits）”以進入荒野去探索潘多拉星球（Pandora）？這個多運行時架構和 Mecha- 戰衣類似，都能為人類驅動者提供超能力。在電影中，我們把人類放入戰衣以獲得力量及毀滅性武器。在這個軟件架構中，我們讓業務邏輯（指的是微邏輯）形成應用程序的核心，而邊車 mecha 組件提供強大的開箱即用的分布式原語。這個微邏輯和 mecha 功能組合起來形成一個多運行時微服務，該微服務使用進程外功能以滿足其分布式系統的需求 。最棒的是，Avatar 2 即將出手來幫助推廣這個架構。這樣我們終于可以在所有的軟件大會上用非凡的機甲照片來替換老式的挎斗摩托車照片了；）。下面，我們來看看這個軟件架構的細節。

這是一個有兩個組件的模型，類似于客戶端 - 服務器架構，其中每個組件都是獨立的運行時。它和純粹客戶端 - 服務器架構的區別在于，這兩個組件都位于同一個主機中，并且在它們之間有可靠的網絡，這一點無需擔心。兩個組件同等重要，它們可以在任何一個方向上初始化操作并充當客戶端或服務器。組件之一稱為微邏輯（Micrologic），它包含了幾乎所有從分布式系統關注點中剝離出來的最小業務邏輯。在一起的另一個部件叫 Mecha，它提供了我們一直在本文中討論的所有分布式系統功能（生命周期除外，它是平臺的功能）。

微邏輯和 Mecha（即邊車模型）可能是一對一的部署，也可以多個微邏輯運行時共享 Mecha。第一種模型最適合 Kubernetes 等環境，而后者適用于邊緣部署。

微邏輯運行時特征

我們簡要地探討一下微邏輯運行時的一些特征：

• 微邏輯組件本身不是微服務。它包含微服務會有的業務邏輯，但是，該邏輯只能和 Mecha 組件結合使用。另一方面，微服務是自包含的，整體功能的片段或部分處理流沒有分散到其他的運行時。微邏輯及其對應的 Mecha 組合形成了微服務。
• 這也不是函數或 serverless 架構。serverless 主要以其托管的快速擴展和歸零能力而聞名。在 serverless 架構中，函數只實現單個操作，因為這是擴展的單位。在這一方面，函數與微邏輯不同，微邏輯實現多個操作，但是，實現不是端到端的。更重要的是，操作的實現分散于 Mecha 和微服務運行時。
• 這是客戶端 - 服務器架構的特殊形式，針對無需編碼就使用眾所周知的分布式原語進行了優化。另外，如果我們假設 Mecha 扮演服務器的角色，那么，每個實例必須專門配置如何與每個的客戶端一起工作。它不是一個旨在支持多個客戶端的同時又是一個典型的客戶端 - 服務器架構的通用服務器實例。
• 微邏輯中的用戶代碼沒有直接和其他系統交互，也沒有實現任何分布式系統原語。它通過事實標準（如 HTTP/gRPC、CloudEvents 規范）和 Mecha 交互，并且，在配置好的步驟和機制的指導下，Mecha 利用豐富的功能與其他系統通信。
• 盡管微邏輯只負責實現從分布式系統問題中剝離出來的業務邏輯，但是，它仍然必須至少實現一些 API。它必須允許 Mecha 和平臺通過預定義的 API 和協議（例如，遵循 Kubernetes 部署的云原生設計原則）與之交互。

Mecha 運行時特征

以下是一些 Mecha 運行時的特征：

• Mecha 是一個通用的、高度可配置的、可重用的組件，提供分布式原語作為現成的功能。
• Mecha 的每個實例必須配置成與一個微邏輯組件（邊車模型）一起工作，或者配置成與一些組件共享。
• Mecha 不對微邏輯運行時做任何假設。它與利用開放協議和格式（如 HTTP/gRPC、JSON、Protobuf、CloudEvents）的多語言微服務或甚至單體系統一起工作。
• Mecha 用簡單文本格式（如 YAML、JSON）進行聲明式配置，這些格式規定了要啟用什么功能以及如何把它們綁定到微邏輯端點上。對于特定的 API 交互操作，可以為 Mecha 附加規范，如 OpenAPI、AsyncAPI、ANSI-SQL 等。對于由多個步驟構成的狀態化工作流，可以使用如 亞馬遜狀態編程語言（Amazon State Language）的規范。對無狀態集成，可以用類似 Camel-K YAML DSL 的方法使用企業集成模式（Enterprise Integration Patterns，簡稱 EIPs）。這里的關鍵之處是，所有這些都是簡單的、基于文本的、聲明式的、多語言定義的，Mecha 可以不需要編碼就能實現。請注意，這些是未來派的預測，目前，沒有用于狀態化編排或 EIP 的 Mecha，但是，我期望現有的 Mecha（Envoy、Dapr、Cloudstate 等）很快開始添加這類功能。Mecha 是應用程序級別的分布式原語抽象層。
• 與其依賴于用于不同目的（如網絡代理、緩存代理、綁定代理）的多個代理，不如有一個提供所有這些功能的 Mecha。某些能力的實現（如存儲、消息持久性、緩存等）將會有其他的云或自建的服務插入并支持。
• 關于生命周期管理的一些分布式系統問題由管理平臺（比如，Kubernetes 或其他云服務）而不是由使用 Open App Model 等通用開放規范的 Mecha 運行時來提供是合理的。

這個架構的主要好處是什么？

它的好處是業務邏輯和不斷增長的分布式系統問題之間的松耦合。軟件系統的這兩個元素有完全不同的動態。業務邏輯總是唯一的，代碼是自定義的和內部編寫的。它經常更改，具體取決于組織的優先級和執行能力。另一方面，分布式原語是用來解決本文所列的那些問題的，并且大家都知道。它們由軟件供應商開發并作為庫、容器或服務使用。代碼隨著供應商的優先級、發布周期、安全補丁、開源管理規則等進行更改。這兩者相互之間沒有什么可見性，也無法相互控制。

微服務原則有助于通過限界上下文解耦不同的業務領域，其中每個微服務可以獨立地發展。但是，微服務架構沒有解決業務邏輯與中間件問題耦合帶來的難題。對于某些缺少集成場景的微服務來說，這可能不是一個大問題。但是，如果我們的領域涉及復雜的集成（每個人的情況都越來越復雜），遵循微服務原則將無助于我們避免與中間件耦合。即使中間件被表示為包含在我們的微服務中的庫，在我們開始遷移和改變這些庫的時候，耦合也將變得明顯。我們需要的分布式原語越多，就越容易耦合到集成平臺中。通過預定義的 API 而不是庫，把中間件作為獨立的運行時 / 進程使用，有助于松耦合并實現每個組件的獨立發展。

這也是一種為供應商分發和維護復雜中間件軟件的更好的方法。只要與中間件是通過開放 API 和標準的進程間通信進行交互的，那么，軟件供應商就可以按其節奏自由地發布補丁和更新。用戶可以自由地使用其喜歡的編程語言、庫、運行時、部署方式和流程。

這個架構的主要缺點是什么？

進程間通信。事實上，分布式系統的業務邏輯和中間件機制（Mecha 就來自 mechanics 這個詞）處于不同的運行時，這需要采用 HTTP 或 gRPC 調用而不是進程內的方式調用。但是，請注意，這不是一個轉到另一臺主機或數據中心的網絡調用。微邏輯運行時和 Mecha 應該在同一個主機中共存，因此延遲很低，并且出現網絡問題的可能性最小。

復雜性。接下來的問題是，是否值得進行如此復雜的開發并維護這樣的系統以獲得收益。我認為，答案越來越傾向于“是”。分布式系統的需求在增加，發布周期變得越來越短。該架構針對該領域進行了優化。前段時間，我曾經寫道，未來的開發人員必須具備混合開發技能。該架構進一步證實并加強了這個趨勢。應用程序的一部分將用更高級的編程語言編寫，而部分功能將由必須進行聲明式配置的現成組件提供。這兩個部分的連接沒有發生在編譯期，也沒有在啟動時通過進程內依賴項注入而實現，而是在部署的時候通過進程間通信發生的。該模型可實現更高的軟件重用率和更快的變更速度。

微服務之后并不是函數

微服務架構有個明確的目標。它對變更進行優化。通過把應用程序切分到業務域，該架構借助服務為軟件演化和可維護性提供了最優的服務邊界，這些服務是解耦的，由獨立的團隊管理，并以獨立的節奏發布。

如果我們來看看 serverless 架構的編程模型，會發現它主要是基于函數的。函數針對可擴展性進行了優化。借助函數，我們把每個操作分解為一個獨立的組件，從而可以根據需要，快速且獨立地擴展。在這個模型中，部署粒度是一個函數。選擇函數的原因是，它的代碼結構的輸入的速度與擴展行為直接相關。這個架構針對極端的可擴展性而不是復雜系統的長期維護性進行了優化。

我們從 AWS Lambda 的流行程度及其完全托管的運維來看，serverless 的其他方面又是什么呢？“AWS Serverless”針對供應速度進行了優化，以彌補缺乏控制和鎖定的代價。但是，完全托管不是應用程序架構，而是軟件消費模型。它在功能上是正交的，與使用基于 SaaS 的平臺類似，在理想情況下適用于任何架構，無論是單體、微服務、Mecha 還是函數。在很多方面，AWS Lambda 類似于完全托管的 Mecha 架構，但有一個很大的不同：Mecha 沒有強制使用函數模型，相反，它允許圍繞業務域使用更具凝聚力的代碼構造，而與所有中間件無關。

另一方面，Mecha 架構針對中間件的獨立性優化了微服務。盡管微服務彼此獨立，但是，它們嚴重依賴嵌入式分布式原語。Mecha 架構把這兩個問題分成獨立的運行時，允許它們通過獨立的團隊進行獨立的發布。這種解耦改善了日常的運維（如補丁和更新）并提高了業務邏輯內聚單位的長期維護性。Mecha 架構是微服務架構的自然發展，根據引發最大摩擦的邊界來分割軟件。與函數模型相比，該優化以軟件重用和演化的方式提供了更多的好處，函數模型通過以代碼的過度分布為代價為優化提供了極大的可擴展性。

6. 結論

分布式應用程序有很多要求。創建有效的分布式系統需要多種技術和好的集成方法。盡管傳統的單體中間件提供了分布式系統要求的所有必需的技術功能，但是，它缺乏快速變化、適應和擴展的能力，而這些是業務所需要的。這就是為什么基于微服務架構促成容器和 Kubernetes 的快速普及背后的原因，借助云原生領域最新的發展，現在，我們回到了原點，把所有傳統中間件功能遷移到平臺和現成的輔助運行時。應用程序功能的商品化主要使用進程外模型而不是運行時庫或純平臺功能進行功能擴展。這意味著，將來我們很可能使用多運行時來實現分布式系統。多運行時，不是因為有多個微服務，而是因為每個微服務將有多運行時構成，有用于自定義微業務邏輯的運行時以及用于分布式原語的現成的可配置的運行時。

作者簡介

Bilgin Ibryam 是紅帽（Red Hat）的首席架構師、Apache 軟件基金會（Apache Software Foundation）的提交者和成員。他熱衷于推廣開源、寫博客，偶爾還參與技術演講。他是《Kubernetes 模式（Kubernetes Patterns）》和《Camel 設計模式（Camel Design Patterns）》的作者。在日常工作中，Bilgin 樂于指導、編碼并領導開發人員成功地構建開源解決方案。目前，他專注于區塊鏈、分布式系統、微服務、開發運維和云原生應用程序開發。