微服務原理可以通過有界上下文使不同的業務領域脫鉤解耦，每個微服務都可以獨立開發，但是微服務架構無法解決將業務邏輯與中介軟體問題耦合在一起帶來的困難。如果您的領域涉及複雜的整合，那麼遵循微服務原則無法避免與中介軟體耦合。即使中介軟體作為包含在微服務中的庫，當您開始遷移和更改這些庫時，這種耦合也會變得顯而易見。還有您需要的更多分散式技術，這些讓微服務與整合平臺的耦合就越多。

儘管傳統的單體中介軟體（SOA/ESB）提供了分散式系統所需的所有必要技術功能，但它缺乏業務所需的快速更改，適應和擴充套件的能力。這就是為什麼基於微服務的架構背後的思想為容器和Kubernetes的快速普及做出了貢獻的原因。隨著雲原生領域的最新發展，我們現在通過將所有傳統中介軟體功能轉移到平臺和現成的輔助執行時中來全面發展。

• Kubernetes和容器在多語言應用程式的生命週期管理中取得了巨大飛躍，併為未來的創新奠定了基礎。
• 服務網格技術通過高階網路功能在Kubernetes上進行了改進，並開始涉足應用程式方面。
• 儘管Knative主要通過快速擴充套件專注於無伺服器工作負載，但它也滿足了服務編排和事件驅動的繫結需求。
• Dapr以Kubernetes，Knative和Service Mesh的思想為基礎，並深入應用程式執行時以解決有狀態的工作負載，繫結和整合需求，充當現代的分散式中介軟體。

該圖可幫助您直觀地看到，很可能在將來，我們最終將使用多個執行時來實現分散式系統。多個執行時，不是因為有多個微服務，而是因為每個微服務都將由多個執行時組成，最有可能是兩個執行時環境：自定義業務邏輯執行環境和分散式原語執行環境。

擁有兩個執行環境的微服務

在這種軟體體系結構中，您將擁有構成應用程式核心的業務邏輯（稱為微邏輯）和提供強大的現成分散式原語的sidecar mecha元件。

這是一個類似於客戶端-伺服器體系結構的兩元件模型，其中每個元件都是獨立的執行時。它與純客戶端-伺服器體系結構的不同之處在於，這兩個元件都位於同一主機上，並且它們之間沒有可靠的網路連線。這兩個元件的重要性相同，它們可以在任一方向上啟動操作並充當客戶端或伺服器。其中的一個元件稱為Micrologic，它擁有從幾乎所有分散式系統問題中剝離出來的非常少的業務邏輯。另一個隨附的元件是Mecha，它提供了本文中我們一直在討論的所有分散式系統功能（生命週期除外，它是一個平臺功能）。

Micrologic和Mecha可能是一對一的部署（稱為sidecar模型），也可以是帶有幾個Micrologic執行時的共享Mecha。第一種模型最適用於Kubernetes等環境，而第二種模型則適用於邊緣部署。

1. 讓我們簡要地探討Micrologic執行時環境的一些特徵：

• Micrologic元件本身不是微服務。它包含微服務將具有的業務邏輯，但是該邏輯只能與Mecha元件結合使用。另一方面，微服務是自包含的，沒有整體功能的一部分，也沒有一部分處理流程擴充套件到其他執行時中。Micrologic和其Mecha對應產品的組合形成了微服務。
• 這也不是功能或無伺服器架構。無伺服器最著名的是其託管的快速擴充套件和從零擴充套件到零的功能。在無伺服器體系結構中，函式實現單個操作，因為這是可伸縮性的單位。在這方面，功能不同於實現多種操作的Micrologic，但實現方式不是端到端的。最重要的是，操作的實現分佈在Mecha和Micrologic執行時上。
• 這是客戶端-伺服器體系結構的一種特殊形式，針對無需編碼即可使用眾所周知的分散式基元進行了優化。另外，如果我們假設Mecha扮演伺服器角色，那麼每個例項都必須經過專門配置以與單個客戶端一起工作。它不是旨在與典型的客戶端-伺服器體系結構同時支援多個客戶端的通用伺服器例項。
• Micrologic中的使用者程式碼不會直接與其他系統互動，也不會實現任何分散式系統原語。它通過事實上的標準（例如HTTP / gRPC，CloudEvents規範）與Mecha進行互動，並且Mecha使用豐富的功能並在配置的步驟和機制的指導下與其他系統進行通訊。
• 儘管Micrologic僅負責實施從分散式系統問題中剝離出來的業務邏輯，但仍必須至少實現一些API。它必須允許Mecha和平臺通過預定義的API和協議與其進行互動（例如，通過遵循Kubernetes部署的雲原生設計原則）。

2. 以下是一些Mecha執行時環境特徵：

• Mecha是一個通用的，高度可配置的，可重用的元件，提供分散式原語作為現成的功能。
• Mecha的每個例項都必須配置為與一個Micrologic元件（邊車模型）一起使用，或者配置為與幾個元件共享。
• Mecha不對Micrologic執行時做任何假設。它與使用開放協議和格式（例如HTTP / gRPC，JSON，Protobuf，CloudEvents）的多語言微服務甚至單片系統一起使用。
• Mecha以簡單的文字格式（如YAML，JSON）宣告性地配置，該格式指示要啟用的功能以及如何將其繫結到Micrologic端點。對於專業的API互動，可以為Mechan附加規範，例如OpenAPI，AsyncAPI，ANSI-SQL等。對於由多個處理步驟組成的有狀態工作流，可以使用諸如Amazon State Language的規範。對於無狀態整合，可以使用與Camel-K YAML DSL類似的方法使用企業整合模式（EIP）。。這裡的關鍵點是，所有這些都是Mecha無需編碼即可實現的簡單的，基於文字的，宣告性的，多種語言的定義。請注意，這些都是未來派的預測，目前，尚無用於狀態編排或EIP的Mechas，但我希望現有的Mechas（Envoy，Dapr，Cloudstate等）很快就會開始新增此類功能。Mecha是應用程式級別的分散式原語抽象層。
• 與其依靠多個代理來實現不同的目的（例如網路代理，快取代理，繫結代理），不如使用一個Mecha提供所有這些功能。一些功能（例如儲存，訊息永續性，快取等）的實現將被其他雲或本地服務插入並支援。
• 管理平臺（例如Kubernetes或其他雲服務）可以提供一些與生命週期管理有關的分散式系統問題，而不是使用諸如Open App Model這樣的通用開放規範的Mecha執行時。

兩個執行環境的架構好處

好處是業務邏輯和越來越多的分散式系統問題之間的鬆耦合。軟體系統的這兩個要素具有完全不同的動力學。業務邏輯始終是內部編寫的唯一的自定義程式碼。它經常更改，具體取決於您的組織優先順序和執行能力。另一方面，分散式原語是解決這篇文章中列出的問題的人，它們是眾所周知的。這些由軟體供應商開發，並作為庫，容器或服務使用。該程式碼根據供應商的優先順序，釋出週期，安全補丁，開放原始碼管理規則等而更改。這兩個組之間幾乎沒有可見性並且無法相互控制。

這也是為技術平臺供應商分發和維護複雜的中介軟體軟體提供了更好方法。只要與中介軟體的互動是通過涉及開放API和標準的程式間通訊進行的，軟體供應商就可以按照自己的節奏自由釋出補丁和升級。消費者可以自由使用他們喜歡的語言，庫，執行時，部署方法和流程。

兩種執行環境的主要缺點

1. 程式間通訊。分散式系統的業務邏輯和中介軟體機制（您知道名稱的來源）在不同的執行時中，並且需要HTTP或gRPC呼叫而不是程式內方法呼叫。Micrologic執行時和Mecha應該以較低的延遲和最小的網路問題並置在同一主機上。
2.  複雜。應用程式的一部分將用高階程式語言編寫，部分功能將由必須進行宣告性配置的現成元件提供。這兩個部分的互連不是在編譯時或在啟動時通過程式內依賴注入，而是在部署時通過程式間通訊互連。該模型可實現更高的軟體重用率和更快的變更速度。

更詳細分析點選標題見原文。