134
設計事件驅動的微服務
事件驅動的微服務是一個未受到應有探討的領域，在近日舉行的μCon倫敦2017微服務大會上，Greg Young表達了這樣的觀點。同時，他還特別強調，不應該對所有的微服務都使用事件驅動模式。相反，他建議逐個服務進行考察，並將事件驅動模式運用到真正能從中受益的服務上。
Greg Young是一名事件驅動專家，同時也是Event Store的首席架構師。他認為，在創建微服務係統時需要考慮的一個重要的設計問題是，應該每個微服務使用一個數據庫，還是所有的微服務都訪問同一個數據庫。在存儲狀態時，比如使用一個關係型數據庫，使用一個或多個數據庫並沒有很大的不同，但是，他指出，在使用“事件庫（event source）”時，多個服務使用一個事件庫比一個服務一個事件庫要簡單許多。原因是事件排序，他還提及了Leslie Lamport及他的論文“分布式係統中的時間、時鍾和事件順序”。
在每個服務一個事件庫的情況下，當服務從兩個或兩個以上的事件庫中讀取事件時，既不能保證所有的事件被以和創建順序相同的順序讀取，也不能保證順序和事件重放時相同。在多個服務使用一個事件庫的情況下，順序就有保證了，因為順序是確定的。這就是“線性化（linearizing）”。該技術不能讓係統更具擴展性，但卻可以讓係統更容易推斷，Young認為，在大多數情況下，這都比將來可能出現的可擴展性問題更重要。
Young指出，對於大多數係統而言，線性化都是有效的，即使是在每秒處理超過10K事件的時候。對於真正的高吞吐量，也許高達每秒250K事件，尋求另外一種設計也許就是好主意了。
由於操作會跨多個微服務，所以相關性和因果關係標識可以帶來極大的好處。當一個服務引發了一個其他服務監聽的事件，它們就會引發自己的事件，這會使係統產生一個難以追蹤的級聯事件流。但是，通過向事件添加三個標識（uuid）——消息標識、相關性標識和因果關係標識，就可以克服這個問題。
事件創建時會獲得唯一的消息標識。把事件的相關性標識設置為引發該事件的事件的相關性標識，事件流中相關性標識相同的所有事件都是有著相同的根源，把因果關係標識設置為引發該事件的事件的消息標識，就可以找出事件發生的順序。
在理解和查找錯誤出現的原因時，按照正確的順序查看整體消息流的能力非常有用。這項技術也可以用於非事件驅動的係統中。通過增加一個審計服務，監聽所有服務引發的所有事件並存儲它們，可以獲得同樣的可能性。
在演講中，Young還討論了其他主題，包括內存服務、複製模型及地域分布。
按照計劃，明年的大會將於2018年11月5號到6號舉行。
本文轉自d1net（轉載）
最後更新：2017-11-16 15:35:28