將業務邏輯和雲架構分離的多執行時Muilti-Runtime的微服務架構 〜Bilgin Ibryam

• 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部署的雲原生設計原則）。

• 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.  複雜。應用程式的一部分將用高階程式語言編寫，部分功能將由必須進行宣告性配置的現成元件提供。這兩個部分的互連不是在編譯時或在啟動時透過程式內依賴注入，而是在部署時透過程式間通訊互連。該模型可實現更高的軟體重用率和更快的變更速度。