事件驅動架構和微服務架構的區別與聯系
我們生活在一個軟件開發的新時代,一個云原生應用時代。為云交付而構建的應用程序必須具有高度可傳輸性、非常松散耦合、高度彈性和極快的響應能力。這要求很多。將今天的開發環境與之前的環境進行比較有助于解釋所有這些是如何實現的。
1、事件驅動和微服務的區別
微服務架構旨在將單個大型“單體”設計/系統分解為多個獨立的組件/流程,從而使代碼庫更加細化和易于管理。甲微服務基本上是小的,松散耦合的分布式服務。它是更廣泛的微服務架構的一部分,由一組松散耦合的微服務組成,這些微服務一起運行以解決一個共同的目標。
事件驅動架構(EDA)是一種解決耦合的方法,否則會在較大系統中的組件進行通信時發生(這就是微服務中發生的情況)。當微服務同步通信時,通過API調用,它們會變得相互依賴,導致系統難以維護。EDA通過使用事件代理作為中介,允許組件通過引發和響應事件進行通信來解決這個問題。
2、單體巨石程序與服務獨立性
大多數給定應用程序都是作為單個代碼塊編寫的。每個函數、每個布爾選項、每個重復或迭代過程以及應用程序調用的每個服務都包含在該代碼中。每個服務、進程、函數、子例程和庫之間的通信是代碼處理中固有的。
在這樣一個完整的單體應用程序中,如果代碼中的任何地方出現任何問題,整個應用程序都會完全崩潰。程序錯誤……嚴重錯誤……致命錯誤……它們都不是令人愉快的,而且通常不容易解決。
如果任何服務中出現的缺陷會導致整個應用程序癱瘓,那么合乎邏輯的解決方案是通過單獨和獨立運行來隔離每個服務。任何服務中的故障只會導致該進程停止運行,而不是整個應用程序停止運行,整個應用程序將繼續運行,直到重新實例化失敗的服務并變為可用為止。
為了提高每個服務的隔離度,微服務在容器內的自己的進程中運行,該容器包括服務的代碼、其配置、所有依賴項、庫以及運行代碼所需的其他資源。容器化服務可以單獨測試并作為容器化鏡像實例部署到主機操作系統。
將應用程序創建為獨立容器化微服務的集合有幾個顯著的優勢:
由于它們各自獨立執行,因此每個微服務可以包含不同的代碼——在不同的平臺上創建不同的依賴項。
- 微服務無需修改即可部署在不同的環境中。
- 容器直接在操作系統上運行,比VM映像占用的空間小得多。
- 通過為各種任務創建新容器,可以輕松實現橫向擴展。
- 新映像的實例化(創建容器的過程)與實例化服務或Web應用程序沒有什么不同。
- 容器提供獨立性、隔離性、可移植性、可擴展性和控制性。
3、新的關聯關系
微服務、容器、DevOps、持續改進、持續開發和部署(CI/CD)、事件驅動架構(EDA)等都圍繞實現更高的敏捷性而結合在一起。
容器中的每個微服務都獨立于所有其他微服務,從而通過啟用分段部署來提高應用程序的彈性。如果需要對任何特定微服務進行更改,則不需要重建甚至停止整個應用程序。這也允許簡化維護。
開發者還可以享受分工協作,組成小團隊來構建和維護特定的服務。他們甚至可以用任何語言構建這些服務,因為每個服務都與所有其他服務分開運行。
將所有這些結合在一起,容器化微服務符合敏捷性的核心概念。它們是非常松散耦合的,因此更改一個微服務不需要更改另一個。而且由于微服務易于復制,因此它們的可擴展性也很高。如果需要更改,只需修改需要更改的服務。容器實際上是應用服務粒度的定義。
4、事件驅動的微服務架構

傳感事件驅動示意
一個簡單的事件通常需要復雜的響應。所上圖所求,房屋傳感器檢測到昂貴的戒指被盜的事件。諸如此類的事件處理器通過發出警報同時通知戒指的所有者和警察以便他們能夠做出反應來提供必要的指導以提供威懾。這些通知中沒有一個需要知道其他通知,也不需要在執行之前等待它們發生。此序列提供的即時操作展示了松散耦合的價值。
5、云原生應用
互連的容器化微服務可創建云原生應用程序,這些應用程序可輕松傳輸到網絡上需要的任何位置。為了可靠和一致地運行,他們必須擁有一個能夠自動執行所有潛在響應的通信平臺(如:Istio)。
經典的單體應用很難實現這一點,因為它們既不能很好地擴展,也不能提供所需的彈性。然而,云原生應用程序利用EDA使它們能夠促進定義DevOps目標的敏捷性——在高度促進持續開發和部署的動態環境中實現持續改進。
總之,微服務和EDA是互補的,但也可以獨立存在。微服務不必使用EDA構建。同樣,EDA可以獨立存在于不使用微服務的系統中,但隨著云原生的推廣應用,兩者之間的關系越來越“親密無間”。