微服務架構
微服務原理可以通過有界上下文使不同的業務領域脫鉤解耦，每個微服務都可以獨立開發，但是微服務架構無法解決將業務邏輯與中間件問題耦合在一起帶來的困難。如果您的領域涉及複雜的集成，那麼遵循微服務原則無法避免與中間件耦合。即使中間件作爲包含在微服務中的庫，當您開始遷移和更改這些庫時，這種耦合也會變得顯而易見。還有您需要的更多分佈式技術，這些讓微服務與集成平臺的耦合就越多。
儘管傳統的單體中間件（SOA/ESB）提供了分佈式系統所需的所有必要技術功能，但它缺乏業務所需的快速更改，適應和擴展的能力。這就是爲什麼基於微服務的架構背後的思想爲容器和Kubernetes的快速普及做出了貢獻的原因。隨着雲原生領域的最新發展，我們現在通過將所有傳統中間件功能轉移到平臺和現成的輔助運行時中來全面發展。
Kubernetes和容器在多語言應用程序的生命週期管理中取得了巨大飛躍，併爲未來的創新奠定了基礎。
服務網格技術通過高級網絡功能在Kubernetes上進行了改進，並開始涉足應用程序方面。
儘管Knative主要通過快速擴展專注於無服務器工作負載，但它也滿足了服務編排和事件驅動的綁定需求。
Dapr以Kubernetes，Knative和Service Mesh的思想爲基礎，並深入應用程序運行時以解決有狀態的工作負載，綁定和集成需求，充當現代的分佈式中間件。
該圖可幫助您直觀地看到，很可能在將來，我們最終將使用多個運行時來實現分佈式系統。多個運行時，不是因爲有多個微服務，而是因爲每個微服務都將由多個運行時組成，最有可能是兩個運行時環境：自定義業務邏輯運行環境和分佈式原語運行環境。
擁有兩個運行環境的微服務
在這種軟件體系結構中，您將擁有構成應用程序核心的業務邏輯（稱爲微邏輯）和提供強大的現成分佈式原語的sidecar mecha組件。
這是一個類似於客戶端-服務器體系結構的兩組件模型，其中每個組件都是獨立的運行時。它與純客戶端-服務器體系結構的不同之處在於，這兩個組件都位於同一主機上，並且它們之間沒有可靠的網絡連接。這兩個組件的重要性相同，它們可以在任一方向上啓動操作並充當客戶端或服務器。其中的一個組件稱爲Micrologic，它擁有從幾乎所有分佈式系統問題中剝離出來的非常少的業務邏輯。另一個隨附的組件是Mecha，它提供了本文中我們一直在討論的所有分佈式系統功能（生命週期除外，它是一個平臺功能）。
Micrologic和Mecha可能是一對一的部署（稱爲sidecar模型），也可以是帶有幾個Micrologic運行時的共享Mecha。第一種模型最適用於Kubernetes等環境，而第二種模型則適用於邊緣部署。
- 讓我們簡要地探討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和標準的進程間通信進行的，軟件供應商就可以按照自己的節奏自由發佈補丁和升級。消費者可以自由使用他們喜歡的語言，庫，運行時，部署方法和流程。
兩種運行環境的主要缺點
進程間通信。分佈式系統的業務邏輯和中間件機制（您知道名稱的來源）在不同的運行時中，並且需要HTTP或gRPC調用而不是進程內方法調用。Micrologic運行時和Mecha應該以較低的延遲和最小的網絡問題並置在同一主機上。
複雜。應用程序的一部分將用高級編程語言編寫，部分功能將由必須進行聲明性配置的現成組件提供。這兩個部分的互連不是在編譯時或在啓動時通過進程內依賴注入，而是在部署時通過進程間通信互連。該模型可實現更高的軟件重用率和更快的變更速度。