事件驅動的微服務是一個未受到應有探討的領域，在近日舉行的μCon倫敦2017微服務大會上，Greg Young表達了這樣的觀點。同時，他還特別強調，不應該對所有的微服務都使用事件驅動模式。相反，他建議逐個服務進行考察，并將事件驅動模式運用到真正能從中受益的服務上。

Greg Young是一名事件驅動專家，同時也是Event Store的首席架構師。他認為，在創建微服務系統時需要考慮的一個重要的設計問題是，應該每個微服務使用一個數據庫，還是所有的微服務都訪問同一個數據庫。在存儲狀態時，比如使用一個關系型數據庫，使用一個或多個數據庫并沒有很大的不同，但是，他指出，在使用“事件庫（event source）”時，多個服務使用一個事件庫比一個服務一個事件庫要簡單許多。原因是事件排序，他還提及了Leslie Lamport及他的論文“分布式系統中的時間、時鐘和事件順序”。

在每個服務一個事件庫的情況下，當服務從兩個或兩個以上的事件庫中讀取事件時，既不能保證所有的事件被以和創建順序相同的順序讀取，也不能保證順序和事件重放時相同。在多個服務使用一個事件庫的情況下，順序就有保證了，因為順序是確定的。這就是“線性化（linearizing）”。該技術不能讓系統更具擴展性，但卻可以讓系統更容易推斷，Young認為，在大多數情況下，這都比將來可能出現的可擴展性問題更重要。

Young指出，對于大多數系統而言，線性化都是有效的，即使是在每秒處理超過10K事件的時候。對于真正的高吞吐量，也許高達每秒250K事件，尋求另外一種設計也許就是好主意了。

由于操作會跨多個微服務，所以相關性和因果關系標識可以帶來極大的好處。當一個服務引發了一個其他服務監聽的事件，它們就會引發自己的事件，這會使系統產生一個難以追蹤的級聯事件流。但是，通過向事件添加三個標識（uuid）——消息標識、相關性標識和因果關系標識，就可以克服這個問題。

事件創建時會獲得唯一的消息標識。把事件的相關性標識設置為引發該事件的事件的相關性標識，事件流中相關性標識相同的所有事件都是有著相同的根源，把因果關系標識設置為引發該事件的事件的消息標識，就可以找出事件發生的順序。

在理解和查找錯誤出現的原因時，按照正確的順序查看整體消息流的能力非常有用。這項技術也可以用于非事件驅動的系統中。通過增加一個審計服務，監聽所有服務引發的所有事件并存儲它們，可以獲得同樣的可能性。

在演講中，Young還討論了其他主題，包括內存服務、復制模型及地域分布。

原文地址：http://www.infoq.com/cn/news/2017/11/event-sourcing-microservices

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的设计事件驱动的微服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。