為什麼微服務應該是事件驅動？

banq發表於2016-06-02
微服務事件
建立微服務的真正道路是事件驅動，這是一個有著DDD, CQRS, Event-sourcing, event streaming, complex-event processing(CEP) 等背景以及豐富JavaEE技術經驗的架構師的認識，他經歷了從傳統整體型monolith到微服務架構之轉變，細節技術涉及從容器技術 (Docker, Kubernetes) 到JVM層 (Spring Boot 和 WildFly Swarm)到應用架構(事件, 命令, 流streaming, 原始事件, 聚合, 聚合根, 事務, CQRS, 等等)，他會在六月的Red Hat Summit演講上詳細陳述。

這裡他從自主性與權威性的比較角度來談論微服務為什麼應該是事件驅動，原文見：Why Microservices Should Be Event Driven: Autonomy

首先，我們使用微服務是為了構建一個業務敏捷的IT系統，也就是能跟隨業務快速變化的IT系統，這樣才能保證我們的業務能力始終保持競爭力。而自治系統是能夠相互互動提供業務敏捷，包括如果系統發生問題怎麼辦？系統如何克服問題？提供業務敏捷和失敗容錯的系統就是自治autonomy。

自治系統能夠獨立於彼此演進，因為他們本質上是彼此沒有依賴的，改變一個服務A不會強迫系統B改變，包括引起任何其他漣漪影響，如果服務A是服務B依賴的，服務A死了，那麼服務B也會死期不遠。

那麼自治性除了微服務以外，其他方面還需要什麼？如果你閱讀過http://blog.christianposta.com/microservices/the-real-success-story-of-microservices-architectures/，你會知道不是技術讓Netflix和亞馬遜的微服務獲得成功，而是組織系統結構。

與敏捷系統的相同型別的一些例子包括：開源社群、城市、股票市場、螞蟻群、成群的鳥類和其他的。它們可以進化，響應react環境，甚至持續在面對巨大的失敗，事實上，它們都是屬於複雜自適應系統的理論研究領域。這些系統之間的共同點是什麼？目標，自治性和對環境的反應。自治意味著 對“事件”的“反應react” 。

當有什麼事情發生時，自治者（螞蟻 人或服務）會做某些事或不做某些事，但是總體來說，是這些發生事情的事件驅動了它們的行為，想想你（作為一個獨立自主與自治的人）在一天中做的事情：你醒過來，基於溫度穿衣服（事件或事實），你開車和去工作（在停車燈停下來（事件），避免駕駛人發生不正常事件等）。這些都是對事件的回應。你會收到收件箱裡的電子郵件，你會回應。你會從你妻子提供的文字中挑選一篇關於家庭的晚餐，等等，我們生活在對事件的反應中。建立在事件的IT系統也可以是同樣擁有自主性，可擴充套件性和彈性應對失敗。

從許可權到自治自主並擁抱最終一致性
在大多數分散式系統實現中，我們傾向於在一個單一地理空間建立跨不可靠網路的系統，這在很多方面都是壞主意，我們傾向於呼叫遠端物件，驅動它們做某些事情，或者我們呼叫一個遠端服務進行資料查詢，如果是購物車服務，我們需要計算購物車中所有商品的最終價格以便支付，這樣購物車服務會呼叫計價服務，計價服務也許會呼叫計稅服務以基於價格根據不同洲稅調整最終價格，計稅服務也許會呼叫產品目錄服務，貨運服務也許會呼叫庫存服務等等，最後也許需要經過一長段呼叫才會結束，我們正在遵循“authority許可權”模式進行資料訪問，我們呼叫那些對資料擁有許可權的服務，這有點像共享全域性狀態，它們也有另外一個理由，因為事務性或ACID需要這樣整合在一起呼叫。

這可能會導致瓶頸。如果服務鏈中的某些服務不可用，它也會導致其他服務掛起以及級聯崩潰性故障。它也可能導致一些奇怪的依賴關係，比如庫存服務暴露給稅務服務的出資料和航運服務使用的資料會不同。或者它公開了一個單一格式的資料，但其中有很多額外的細節是這兩個服務都不真正關心的。

如果我們以不同方式來看這個模型？如果我們顛倒這個模型，我們不再依賴和呼叫那些對資料擁有許可權的服務，而是依賴時間和事件（如同我們現實世界一樣）重新理解上下文場景和環境。
我們剛剛從周圍環境發現從美國到古巴的航運剛剛推出了一個較低的稅收，這是一個發生的事實，我們可以觀察和反應，或者忽視不做任何事。

如果我們能瞭解到對運送到古巴的稅收現在已經降低了，那麼在我們展示購物車頁面時，我們就可以捕捉這樣的資料以便未來可能的查詢，然後我們可以有更多的自主權，我們可以在我們自己的資料庫中儲存該資訊息或該資訊的衍生物，這將為我們提供的服務型別進行最佳化。如果我們必須對我們的服務進行版本的修改，我們就可以把重點放在我們自己的架構和資料上，而不必擔心更改時其他相關服務會發生什麼。

什麼是最終一致性？
響應事件而不是“及時”查詢許可權系統會讓我們更具有自主性，更有容錯能力和彈性，但也有一點其他影響，會影響自治事件驅動系統的是“延遲”。

如果你立即注意到某一事件，你可以立即做出反應。例如，如果一輛車轉彎進入你的車道，你看到這個，你可以很快剎車或者調整駕駛避免不發生碰撞。但是，如果有一些延遲，在觀察到這個事件後，你的反應可能是緩慢的（也許有駕駛障礙？或者你在玩手機？或是在你的孩子們做某事，等等）。

這也可能發生在IT系統。比如在亞馬遜訂購商品。這會對其他自主服務（如訂單處理，帳單，庫存等）釋出一個事件或事實。這些系統可以觀察到這一事件，但如果此時庫存系統從網路斷開幾分鐘/小時？當他們重新恢復正常執行後，他們最終會看到這個事件並繼續檢查庫存，釋出任何它認為必要的事件（即反應）像“inventoryreserved事件”或“inadequateinventory”事件。這是一組自主系統“最終”變得一致的一個簡單例子。

最後一件事是關於事件，延遲和自主權。如果我們能夠捕捉到它們並觀察它們的順序，事件就是有用的。也就是說，在我們的系統中必須保留一組事件的總排序，這樣我們才能如何對它們做出反應有信心。

現在你已經明白：事件的順序在分散式系統中構建事務是如何的重要，如果事件變得無序，那麼我們就無從獲得最終一致性，除非再次需要人工介入。

【結束】

什麼是無為？就是除了React to event以外什麼都不做。

參考：使用事件流擴充套件微服務

[該貼被banq於2016-06-02 16:40修改過]

相關文章