Service Mesh被用作微服務的基礎設施層，使通訊變得更加靈活，可靠和快速。 它得到了谷歌、微軟、IBM、紅帽和 Pivotal 等行業巨頭的推動，並且正在推出 Kubernetes、OpenShift 和 Pivotal Container Service（PKS）等平臺和服務。

雖然 Service Mesh （服務網格）可以很好地支援同步 RESTful 和一般的<請求-回覆>互動，但它不支援非同步、事件驅動的互動，不適合將雲原生微服務與遺留應用程式連線，也不適用於 IoT。

現代企業正在將事件驅動架構作為其數字化轉型的一部分，每個事件驅動型的企業都需要一箇中樞神經系統來快速、可靠和安全地將事件從它們發生的地方傳送到它們需要去的地方。

這個中樞神經系統可以被視為 Event Mesh（事件網格） - 您架構中的一個新層。

事件網格作為服務網格的補充，可以做為應用程式的連線層，以提供企業實現其數字化轉型目標所需的全套應用程式間通訊模式。

什麼是 Event Mesh？

事件網格對於事件驅動的應用程式，就好比是服務網格對於 RESTful 應用程式：一個架構層，無論在哪裡部署這些應用程式（非雲、公有云或者私有云），都可以動態路由某個應用程式的事件並使其被其他應用程式所接收。 事件網格由內部連通的 Event broker(事件代理)網路來建立和啟用。

Event Mesh vs. Service Mesh

事件網格可以做為服務網格的補充。 事件網格和服務網格類似，它們可以在應用程式之間實現更好的通訊，並允許應用程式透過將某些功能放在網路層和應用程式層之間，這樣我們可以更多地關注業務邏輯。 但是，相比之下，也有一些重要的區別：

服務網格連線雲環境中的微服務，例如 Kubernetes，Amazon ECS、Google Kubernetes Engine、IBM Cloud 和 Alibaba；事件網格不僅連線微服務（容器化或其他），還連線遺留的應用程式、雲原生服務以及可在雲和非雲環境中執行的各種裝置和資料來源/接收端。 事件網格可以將任何事件源連線到任何事件處理程式，無論它們在何處部署。Event Mesh 的特點

事件網格的定義有三個顯著特徵。 事件網格是：

由內部連通的 Event Broker 形成的組合與環境無關動態的

事件網格由 Event Broker（1）網路建立和啟用的事實意味著其本質上是事件驅動的。

“我相信事件將成為現代企業的生命線。”

與環境無關（2），我的意思是事件網格可以部署在任何公共雲、私有云、PaaS 或非雲環境中，並且它將在所有環境中以統一的方式執行。

事件網格的動態特性（3）可能是其最重要的屬性。 所謂動態，我指的是它能夠動態地瞭解哪些事件將被路由到哪些消費者應用程式，然後在事件發生時實時路由這些事件，無論生產者和消費者在哪裡被附加到網格， 而且無需配置事件路由。 我們應該讓事件網格負責這些，而不是開發人員。

為什麼企業需要 Event Mesh?

簡而言之，事件網格支援以下使用場景：

連線和編排微服務將事件從內部部署推送到雲應用程式或服務（混合雲）跨 LOB(line-of-business) 啟用“資料即服務”實現與後端系統的物聯網連線

這是更長的答案：

事件網格使企業能夠支援事件驅動的體系結構，從最小的微服務部署，到以易管理、健壯、安全和架構良好的方式將應用程式擴充套件到混合雲。 它提供了動態和全部實時地整合遺留應用程式、資料儲存、現代微服務、SaaS、物聯網和移動裝置的能力。 事件網格為應用程式開發人員和架構師提供了構建和部署分散式事件驅動應用程式的基礎，無論他們需要在何處構建和部署。

結論

事件網格概念旨在實現和支援企業數字化轉型。 在 2018 年，那些不完全採用事件驅動架構的企業正在向全面擁抱事件驅動架構轉型。 但根據我的經驗，許多人正在針對特定用例進行此操作，並且通常採用零碎的方法，而不是採用企業範圍內事件分發的明確願景。

我相信事件將成為現代企業的生命線。 為此，他們需要讓事件在數字企業越來越分散的環境和元件中自由輕鬆地流動。

事件網格就是實現此功能的架構層。