轉載自賀卓凡

上集我們闡述了使用微服務體系架構的關鍵障礙是領域模型，事務和查詢，這三個障礙似乎和功能拆分具有天然的對抗。只要功能拆分了，就涉及這三個難題。

然後我們向你展示了一種解決方案就是將每個服務的業務邏輯實現為一組DDD聚合。然後每個事務只能更新或建立一個單獨的聚合。然後通過事件來維護聚合（和服務）之間的資料一致性。

在本集中，我們將會向你介紹使用事件的時候遇到了一個新的問題，就是怎麼樣通過原子方式更新聚合和釋出事件。然後會展示如何使用事件源來解決這個問題，事件源是一種以事件為中心的業務邏輯設計和持久化的方法。之後，我們會闡述微服務架構下的查詢困難的問題。然後向你介紹一種稱為命令查詢責任分離（CQRS）的方法來實現可擴充套件和高效能的查詢。

可靠地更新狀態和釋出事件

從表面上看，使用事件來保持聚合之間的一致性似乎很簡單。

當一個服務建立或更新資料庫的一個聚合時，它只是簡單地釋出一個事件。
但是，這只是表象，其實還有一個核心問題就是：更新資料庫和釋出事件必須是原子的。否則，就會出現類似這樣的情況：如果服務在更新資料庫之後但在釋出事件之前崩潰，則系統就出現了不一致的問題。

傳統的解決方案是一般都是使用分散式事務來搞，一個涉及資料庫和訊息broker的分散式事務。但是，由於上一集所述的原因，2PC不是一個可行的選擇。
其實除了2PC ，還有幾種解決這個問題的方法。

一種解決方案就是，應用程式可以通過向類似Kafka這樣的訊息中介軟體的broker釋出一個事件來執行更新。然後一個訊息consumer訂閱這個事件，通過消費該事件然後最終更新資料庫。這種方法可以確保資料庫被更新並且事件被髮布。
但是缺點就是這種一致性模型過於複雜，至少有點複雜。而且應用程式不能夠立即讀取到自己剛剛的寫入。

圖1 - 通過釋出事件到訊息broker來更新資料庫

另一種做法就是，如圖2所示，就是應用程式追加事務日誌到資料庫（a.k.a.commit log），將每個記錄的更改轉換為事件，然後把事件釋出到訊息broker。這種做法的一個重要好處就是應用程式本身不需要任何的改變。

然而，一個缺點是，這種做法是一種底層（low-level）的事件，而不是上層業務事件。可能難以將上層業務事件（由於資料庫更新的原因）從底層更改逆轉到表中的行。

原文：it can be difficult toreverse engineer the high-level business event - the reason for the databaseupdate - from the low-level changes to the rows in the tables.

圖2 - 追加資料庫事務日誌

第三種解決方案就是，圖3所示的這種，使用資料庫表來作為一種臨時性的message queue。當一個服務更新一個聚合，它會insert一個事件到EVENTS表，作為本地ACID事務的一部分。然後一個單獨的程序輪詢EVENTS表並將事件釋出到訊息broker。

這種做法的好處就是service能夠釋出high-level的業務事件。

缺點是這種做法容易出錯，有這種潛在的可能，因為事件釋出程式碼必須與業務邏輯同步。

圖3 - 使用資料庫表作為message queue

上面三種做法都有比較典型的缺點。

釋出一個事件到message broker並稍後更新的做法總是不能提供一種read-your-writes的一致性，也就是隻能保證最終一致。

追加事務日誌提供了一致的讀取，但卻不能釋出高階業務事件。

使用資料庫表作為message queue提供了一致的讀取並且可以釋出high-level業務事件，但
卻對開發人員有依賴，就是開發人員得記得在狀態發生改變的時候加上釋出事件的邏輯。

幸運的是，我們還有另外一種解決方案，那就是event sourcing，事件源。它是一種針對持久化和業務邏輯的一種以事件為中心方法，稱為事件源。這裡解釋的不夠清楚，稍後慢慢展開。

使用事件源來開發微服務

事件源（Event sourcing）是一種以事件為中心的持久化方法。這不是一個新的概念。

我第一次瞭解到這個概念是在大概五年多以前，之後對這個新生事物一直充滿了好奇，直到我開始開發微服務。接下來，你將會看到通過事件源來實現事件驅動的微服務架構是多麼不錯的一種方法。

一個service通過event sourcing使用一系列的事件來持久化每個聚合。
當建立或更新一個聚合的時候，這個service會在資料庫裡儲存一個或多個事件，這種資料庫裡儲存event的方式可以叫做是event store，以下我們就叫“事件資料庫”。

它通過載入這些事件並replay這些事件，從而實現更新聚合的當前狀態。
在函數語言程式設計裡，一個service通過執行一個函式式的fold或reduce來重構聚合，而不是事件。

由於事件就是狀態，所以你就不會再有原子地更新狀態和釋出事件的問題了。

例如，比如訂單服務（Order Service）。不是將每個訂單作為一行儲存在ORDERS表中，而是將每個訂單聚合作為一系列的事件，比如訂單已建立，訂單已批准，訂單已發貨等持久化到EVENTS表中。圖4顯示了這些事件如何儲存在基於SQL的事件資料庫（event store）中。

圖4 - 使用事件源來持久化一個訂單

每列的意思：

• entity_type 和entity_id –唯一標識一個聚合
• event_id – 事件ID，唯一標識
• event_type – 事件型別
• event_data -事件屬性的序列化JSON表示

一些事件包含大量資料。例如，訂單建立（Order Created）事件包含完整訂單，包括其訂單項，付款資訊和交貨資訊。其他事件，如訂單出貨（Order Shipped）事件，包含很少或沒有資料，只是表示狀態轉換。

事件源（Event Sourcing）和釋出事件

嚴格的講，事件源只是簡單的將聚合們作為事件進行了持久化。更直接的說，就是使用事件源來作為一種可靠的事件釋出機制。儲存一個事件是一個固有的原子操作，它可以確保事件資料庫（event store）把事件傳遞給感興趣的服務。

例如，如果事件被儲存在上面所示的EVENTS表中，訂閱者可以簡單地輪詢表以查詢新事件。更復雜的事件資料庫（event store）將使用另一種做法，這種做法具有更高效能和可擴充套件性。例如，Eventuate Local使用追加事務日誌的方式。它從MySQL replication流中讀取插入到EVENTS表中的事件，並將它們釋出到Apache Kafka。

至於Eventuate Local是個什麼鬼？你可以去github 搜搜。下面放一張圖：

使用Snapshot改善效能

訂單（Order）聚合具有相對較少的狀態轉換，因此它只有少量的事件。
所以，針對這些事件查詢事件資料庫（event store）並重構Order聚合，效率是不錯的。然而，一些聚合有很多的事件。例如，客戶（Customer）聚合可能有大量的預留信用（Credit Reserved）事件。隨著時間的推移，載入和消費（fold）這些事件的效率會越來越低。

一個常見的解決方案是定期儲存聚合狀態的快照（snapshot）。應用程式通過載入最近的快照然後從快照建立之後發生的那些事件開始來恢復聚合的狀態。
在函式式下，快照就是摺疊（fold）的初始值。（原文：In functional terms, the snapshot is the initial value of thefold. ）如果聚合是一個簡單，容易序列化的結構，則快照可以簡單地是JSON序列化格式。更復雜的聚合可以使用Memento模式（Mementopattern）進行快照。至於這種設計模式具體是什麼鬼，你可以自己查閱。

線上商店示例中的客戶（Customer）聚合具有非常簡單的結構：客戶的資訊，他們的信用額度（credit limit）和他們的信用預留（credit reservations）。
客戶（Customer）的快照只是其狀態的JSON序列化。圖5展現瞭如何從與事件＃103的客戶（Customer）的狀態相對應的快照中重新建立一個客戶（Customer）。客戶服務（Customer Service）只需要載入快照和載入事件＃103後發生的事件。

圖5 – 使用快照來優化效能

客戶服務（Customer Service）通過反序列化快照的JSON後加載並消費＃104到＃106的事件來重新建立那個客戶（Customer）。

事件源實現

事件資料庫（event store）是資料庫和訊息borker的混合體。它是一個數據庫，因為它有一個API，用於通過主鍵插入和檢索聚合的事件。事件資料庫（event store）也是訊息broker，因為它具有用於訂閱事件的API。

有一些不同的方法來實現事件資料庫（event store）。

一個做法是編寫自己的事件源框架。例如，您可以在RDBMS中持久化事件。一種簡單的，但效能略低的方式來發布事件，然後訂閱者輪詢事件的EVENTS表。

另一個做法是使用專用的事件資料庫（event store），它通常能夠提供更豐富的功能以及更好的效能和可擴充套件性。“事件源”的開發者之一Greg Young有一個基於.NET的開源事件資料庫，稱為Event Store。 Lightbend，這個公司以前叫Typesafe，有一個叫Lagom的微服務框架，是基於事件源的。這裡推薦一個我自己的創業專案，Eventuate，一個用於微服務的事件源框架，你可以把它作為一個雲服務，你也可以把它認為是一個基於Kafka 或RDBMS的開源專案。

事件源的好處與缺點

事件源有好處也有缺點。

事件源的一個主要優點是它可以在聚合的狀態發生變化時可靠地釋出事件。它為事件驅動的微服務架構打下了良好的基礎。而且，由於每個事件都可以記錄進行更改的使用者的身份，因此事件源還提供了一個準確的稽核日誌。事件流可用於各種其他目的，包括向用戶傳送通知以及應用整合等等。

事件源的另一個好處是它儲存每個聚合的整個歷史。你可以輕鬆實現檢索聚合的過去狀態的時態查詢。要確定在給定時間點的聚合的狀態，您只需消費（fold）直到該點為止發生的事件。例如，可以直接計算過去某個時間點客戶的可用信用額。

事件源也避免了O / R阻抗失衡的問題。這是因為它持久化了事件而不是聚合。事件通常具有簡單，容易序列化的結構。服務（service）可以通過序列化其狀態的記錄來對複雜聚合進行快照。 Memento模式在聚合和它的序列化表示之間增加了一箇中間層。

有關O/R impedance mismatch：
物件關係阻抗失衡（object-relational impedance mismatch ）是當關係數據庫管理系統（RDBMS）由以面向物件的程式語言或風格編寫的應用程式（或多個應用程式）服務時經常遇到的一組概念和技術困難，特別是因為物件或類定義必須對映到關係模式定義的資料庫表。

事件源當然不是完美的，它也有一些缺點。它是一個完全不一樣的和而且你可能並不熟悉的程式設計模型，所以要花一些時間去學習。為了使現有應用程式使用事件源，你必須要重寫業務邏輯。幸運的是，這是一個相當機械的轉換，你可以在將應用程式遷移到微服務的時候做這件事情。

事件源的另一個缺點是訊息broker通常保證至少一次（at-least once）傳遞。非冪等的事件處理handler必須檢測並丟棄那些重複的事件。事件源框架可以通過為每個事件分配單調遞增的id來解決這個問題。事件處理handler然後可以通過對最大事件ID跟蹤來檢測重複事件。

事件源的另一個侷限就是事件（和快照！）的schema將隨時間發展。 由於事件永久儲存，當服務重建聚合時，服務可能需要摺疊與多個schema版本對應的事件。 簡化服務的一種方法是，當事件源框架從事件資料庫（event store）載入它們時，將所有事件轉換為最新版本的模式。因此，服務只需消費（fold）最新版本的事件。

事件源的另一個缺點是查詢事件資料庫（event store）可能比較困難。讓我們想象一下，例如，您需要找到信用額度較低的客戶。你不能簡單地寫SELECT * FROM CUSTOMERWHERE CREDIT_LIMIT <？ AND c.CREATION_DATE>？。因為根本就沒有信用額度（CREDIT_LIMIT）這樣的列。相反，你不得不使用巢狀SELECT的更復雜而且還可能無效的查詢，通過處理和消費（fold）事件來計算信用額度。更糟糕的是，基於NoSQL的事件資料庫（event store）通常只支援基於主鍵的查詢。因此，必須使用“命令查詢責任分離“（CQRS）的方法實施查詢。CQRS 的全稱：Command Query Responsibility Segregation。

我們接下來的內容就是介紹CQRS。

使用CQRS實現查詢

事件源是在微服務體系結構中實現高效查詢的主要障礙。這還不是唯一的問題，還有比如你使用SQL去查詢一些高價值訂單的新客戶。

SELECT *
FROM CUSTOMER c, ORDER o
WHERE
   c.id = o.ID
     AND o.ORDER_TOTAL > 100000
     AND o.STATE = 'SHIPPED'
     AND c.CREATION_DATE > ?

在微服務架構中，你不能join CUSTOMER和ORDER這兩張表。每個表由不同的服務所擁有，並且只能通過該服務的API訪問。你不能編寫連線多個服務所擁有的表的傳統查詢。事件源使事情變得更糟，阻礙你編寫簡單，直接的查詢。讓我們來看看在微服務架構中是如何實現類似查詢的。

如何使用CQRS

實現查詢的好方法是使用稱為命令查詢責任分離（CQRS）的體系結構模式： Command Query Responsibility Segregation。如名稱所示，CQRS將應用程式分為兩部分。第一部分是命令側（command-side），其處理命令（例如，HTTP POST，PUT和DELETE）以建立，更新和刪除聚合。前提是這些聚合是使用事件源實現的。應用程式的第二部分是查詢側（query-side），其通過查詢聚合的一個或多個物化檢視（materialized views）來處理查詢（例如HTTP GET）。查詢側通過訂閱由命令側釋出的事件來保持檢視（view）與聚合（aggregate）同步。

查詢側（query-side）檢視可以使用任何型別的能滿足需求的資料庫來實現。根據需求，應用程式的查詢端可能使用一個或多個以下資料庫：

表1. 查詢側檢視資料庫選擇

在很多場合，CQRS是一個以事件為基礎（event-based）的綜合體，比如使用RDBMS作為記錄系統再使用比如Elasticsearch來處理文字查詢。CQRS的查詢側可以使用其它型別的資料庫，支援多種型別的資料庫，不僅僅是文字搜尋引擎。而且，它通過訂閱事件準實時地去更新查詢側的檢視。

圖6顯示了應用於線上商店示例的CQRS模式。客戶服務（Customer Service）和訂單服務（Order Service）是命令端服務。它們提供用於建立和更新客戶和訂單的API。客戶檢視服務（Customer View Service）是查詢側服務。它提供了一個用於查詢客戶的API。

圖6 – 線上商店中使用 CQRS

客戶檢視服務（Customer View Service）訂閱命令端服務釋出的客戶（Customer）和訂單（Order）事件。它更新那個用MongoDB實現的檢視儲存（view store）。該服務維護一個MongoDB文件集合，每個客戶一個。每個文件都具有客戶詳細資訊的屬性。它還具有儲存客戶最近訂單的屬性。此集合支援各種查詢，包括上面說到的那些查詢。

CQRS的好處和缺點

CQRS既有優點也有缺點。 CQRS的一個主要優點是它可以在微服務架構中實現查詢，特別是使用事件源的架構。它使應用程式有效地支援一組不同的查詢。另一個好處就是把命令側和查詢側分離，達到了解耦的作用。

CQRS也有一些缺點。一個缺點就是需要額外的工作來開發和維護這套系統。你需要開發和部署更新和查詢檢視的查詢端服務。還有就是你需要部署檢視資料庫（view store）。

CQRS的另一個缺點是處理命令側和查詢側檢視之間的“滯後”。查詢層相比命令側存在一定的時延。更新聚合，然後立即查詢檢視的客戶端應用程式可能會看到聚合的以前版本。所以必須通過一些手法來避免暴露這些潛在的不一致性給使用者。

總結

使用事件來維護服務之間的資料一致性時的主要挑戰是原子級地更新資料庫和釋出事件。傳統的解決方案是使用跨資料庫和訊息broker的分散式事務。然而，2PC不是現代應用的可行技術。更好的方法是使用事件源，這是一種以事件為中心的方法來處理業務邏輯設計和持久化。

微服務架構中的另一個挑戰是查詢。查詢通常需要join由多個服務擁有的資料。但是，join不能再使用了，因為資料對每個服務都是私有的。使用事件源還使得更加難以有效地實現查詢，因為當前狀態沒有被顯式地儲存。解決方案是使用命令查詢責任分離（CQRS）並維護可以容易查詢的聚合的一個或多個物化檢視。

關於作者：Chris Richardson是一位開發人員和架構師。 他是Java Champion和POJO in Action的作者，他描述瞭如何使用Spring和Hibernate等框架構建企業Java應用程式。 Chris也是早期CloudFoundry.com的創始人。 他與組織協商，改進他們如何開發和部署應用程式，並在他的第三個創業公司工作。 你可以在Twitter @crichardson和Eventuate上找到Chris。

本文作者：賀卓凡
原文連結：https://mp.weixin.qq.com/s/GPngf6I-zrcOVmimtvwEOA
版權歸作者所有，轉載請註明出處