轉(zhuǎn)：https://my.oschina.net/CraneHe/blog/703169
本系列七篇文章列表如下：
微服務實戰(zhàn)（一）：微服務架構(gòu)的優(yōu)勢與不足
微服務實戰(zhàn)（三）：深入微服務架構(gòu)的進程間通信
微服務實戰(zhàn)（四）：服務發(fā)現(xiàn)的可行方案以及實踐案例
微服務實踐（五）：微服務的事件驅(qū)動數(shù)據(jù)管理
微服務實踐（七）：從單體式架構(gòu)遷移到微服務架構(gòu)
【編者的話】本文是使用微服務創(chuàng)建應用系列的第五篇文章。第一篇文章介紹了微服務架構(gòu)模式，并且討論了使用微服務的優(yōu)缺點；第二和第三篇描述了微服務架構(gòu)模塊間通訊的不同方面；第四篇研究了服務發(fā)現(xiàn)中的問題。本篇中，我們從另外一個角度研究一下微服務架構(gòu)帶來的分布式數(shù)據(jù)管理問題。
1.1 微服務和分布式數(shù)據(jù)管理問題
單體式應用一般都會有一個關(guān)系型數(shù)據(jù)庫，由此帶來的好處是應用可以使用 ACID transactions，可以帶來一些重要的操作特性：
- 原子性 – 任何改變都是原子性的
- 一致性 – 數(shù)據(jù)庫狀態(tài)一直是一致性的
- 隔離性 – 即使交易并發(fā)執(zhí)行，看起來也是串行的
- Durable – 一旦交易提交了就不可回滾
鑒于以上特性，應用可以簡化為：開始一個交易，改變（插入，刪除，更新）很多行，然后提交這些交易。
使用關(guān)系型數(shù)據(jù)庫帶來另外一個優(yōu)勢在于提供SQL（功能強大，可聲明的，表轉(zhuǎn)化的查詢語言）支持。用戶可以非常容易通過查詢將多個表的數(shù)據(jù)組合起來，RDBMS查詢調(diào)度器決定最佳實現(xiàn)方式，用戶不需要擔心例如如何訪問數(shù)據(jù)庫等底層問題。另外，因為所有應用的數(shù)據(jù)都在一個數(shù)據(jù)庫中，很容易去查詢。
然而，對于微服務架構(gòu)來說，數(shù)據(jù)訪問變得非常復雜，這是因為數(shù)據(jù)都是微服務私有的，唯一可訪問的方式就是通過API。這種打包數(shù)據(jù)訪問方式使得微服務之間松耦合，并且彼此之間獨立。如果多個服務訪問同一個數(shù)據(jù)，schema會更新訪問時間，并在所有服務之間進行協(xié)調(diào)。
更甚于，不同的微服務經(jīng)常使用不同的數(shù)據(jù)庫。應用會產(chǎn)生各種不同數(shù)據(jù)，關(guān)系型數(shù)據(jù)庫并不一定是最佳選擇。某些場景，某個NoSQL數(shù)據(jù)庫可能提供更方便的數(shù)據(jù)模型，提供更加的性能和可擴展性。例如，某個產(chǎn)生和查詢字符串的應用采用例如Elasticsearch的字符搜索引擎。同樣的，某個產(chǎn)生社交圖片數(shù)據(jù)的應用可以采用圖片數(shù)據(jù)庫，例如，Neo4j；因此，基于微服務的應用一般都使用SQL和NoSQL結(jié)合的數(shù)據(jù)庫，也就是被稱為polyglot persistence的方法。
分區(qū)的，polyglot-persistent架構(gòu)用于存儲數(shù)據(jù)有許多優(yōu)勢，包括松耦合服務和更佳性能和可擴展性。然而，隨之而來的則是分布式數(shù)據(jù)管理帶來的挑戰(zhàn)。
第一個挑戰(zhàn)在于如何完成一筆交易的同時保持多個服務之間數(shù)據(jù)一致性。之所以會有這個問題，我們以一個在線B2B商店為例，客戶服務維護包括客戶的各種信息，例如credit lines。訂單服務管理訂單，需要驗證某個新訂單與客戶的信用限制沒有沖突。在單一式應用中，訂單服務只需要使用ACID交易就可以檢查可用信用和創(chuàng)建訂單。
相反的，微服務架構(gòu)下，訂單和客戶表分別是相對應服務的私有表，如下圖所示：
訂單服務不能直接訪問客戶表，只能通過客戶服務發(fā)布的API來訪問。訂單服務也可以使用 distributed transactions, 也就是周知的兩階段提交 (2PC)。然而，2PC在現(xiàn)在應用中不是可選性。根據(jù)CAP理論，必須在可用性（availability）和ACID一致性（consistency）之間做出選擇，availability一般是更好的選擇。但是，許多現(xiàn)代科技，例如許多NoSQL數(shù)據(jù)庫，并不支持2PC。在服務和數(shù)據(jù)庫之間維護數(shù)據(jù)一致性是非常根本的需求，因此我們需要找其他的方案。
第二個挑戰(zhàn)是如何完成從多個服務中搜索數(shù)據(jù)。例如，設(shè)想應用需要顯示客戶和他的訂單。如果訂單服務提供API來接受用戶訂單信息，那么用戶可以使用類應用型的join操作接收數(shù)據(jù)。應用從用戶服務接受用戶信息，從訂單服務接受此用戶訂單。假設(shè)，訂單服務只支持通過私有鍵（key）來查詢訂單（也許是在使用只支持基于主鍵接受的NoSQL數(shù)據(jù)庫），此時，沒有合適的方法來接收所需數(shù)據(jù)。
1.2 事件驅(qū)動架構(gòu)
對許多應用來說，這個解決方案就是使用事件驅(qū)動架構(gòu)（event-driven architecture）。在這種架構(gòu)中，當某件重要事情發(fā)生時，微服務會發(fā)布一個事件，例如更新一個業(yè)務實體。當訂閱這些事件的微服務接收此事件時，就可以更新自己的業(yè)務實體，也可能會引發(fā)更多的時間發(fā)布。
可以使用事件來實現(xiàn)跨多服務的業(yè)務交易。交易一般由一系列步驟構(gòu)成，每一步驟都由一個更新業(yè)務實體的微服務和發(fā)布激活下一步驟的事件構(gòu)成。下圖展現(xiàn)如何使用事件驅(qū)動方法，在創(chuàng)建訂單時檢查信用可用度，微服務通過消息代理（Messsage Broker）來交換事件。
-
訂單服務創(chuàng)建一個帶有NEW狀態(tài)的Order （訂單），發(fā)布了一個“Order Created Event（創(chuàng)建訂單）”的事件。
2.png -
客戶服務消費Order Created Event事件，為此訂單預留信用，發(fā)布“Credit Reserved Event（信用預留）”事件
3.png -
訂單服務消費Credit Reserved Event，改變訂單的狀態(tài)為OPEN
4.png更復雜的場景可以引入更多步驟，例如在檢查用戶信用的同時預留庫存等。
考慮到（a）每個服務原子性更新數(shù)據(jù)庫和發(fā)布事件，然后，（b）消息代理確保事件傳遞至少一次，然后可以跨多個服務完成業(yè)務交易（此交易不是ACID交易）。這種模式提供弱確定性，例如最終一致性 eventual consistency。這種交易類型被稱作 BASE model。
亦可以使用事件來維護不同微服務擁有數(shù)據(jù)預連接（pre-join）的實現(xiàn)視圖。維護此視圖的服務訂閱相關(guān)事件并且更新視圖。例如，客戶訂單視圖更新服務（維護客戶訂單視圖）會訂閱由客戶服務和訂單服務發(fā)布的事件。
當客戶訂單視圖更新服務收到客戶或者訂單事件，就會更新 客戶訂單視圖數(shù)據(jù)集。可以使用文檔數(shù)據(jù)庫（例如MongoDB）來實現(xiàn)客戶訂單視圖，為每個用戶存儲一個文檔。客戶訂單視圖查詢服務負責響應對客戶以及最近訂單（通過查詢客戶訂單視圖數(shù)據(jù)集）的查詢。
事件驅(qū)動架構(gòu)也是既有優(yōu)點也有缺點，此架構(gòu)可以使得交易跨多個服務且提供最終一致性，并且可以使應用維護最終視圖；而缺點在于編程模式比ACID交易模式更加復雜：為了從應用層級失效中恢復，還需要完成補償性交易，例如，如果信用檢查不成功則必須取消訂單；另外，應用必須應對不一致的數(shù)據(jù)，這是因為臨時（in-flight）交易造成的改變是可見的，另外當應用讀取未更新的最終視圖時也會遇見數(shù)據(jù)不一致問題。另外一個缺點在于訂閱者必須檢測和忽略冗余事件。
1.3 原子操作Achieving Atomicity
事件驅(qū)動架構(gòu)還會碰到數(shù)據(jù)庫更新和發(fā)布事件原子性問題。例如，訂單服務必須向ORDER表插入一行，然后發(fā)布Order Created event，這兩個操作需要原子性。如果更新數(shù)據(jù)庫后，服務癱了（crashes）造成事件未能發(fā)布，系統(tǒng)變成不一致狀態(tài)。確保原子操作的標準方式是使用一個分布式交易，其中包括數(shù)據(jù)庫和消息代理。然而，基于以上描述的CAP理論，這卻并不是我們想要的。
1.3.1 使用本地交易發(fā)布事件
獲得原子性的一個方法是對發(fā)布事件應用采用multi-step process involving only local transactions，技巧在于一個EVENT表，此表在存儲業(yè)務實體數(shù)據(jù)庫中起到消息列表功能。應用發(fā)起一個（本地）數(shù)據(jù)庫交易，更新業(yè)務實體狀態(tài)，向EVENT表中插入一個事件，然后提交此次交易。另外一個獨立應用進程或者線程查詢此EVENT表，向消息代理發(fā)布事件，然后使用本地交易標志此事件為已發(fā)布，如下圖所示：
訂單服務向ORDER表插入一行，然后向EVENT表中插入Order Created event，事件發(fā)布線程或者進程查詢EVENT表，請求未發(fā)布事件，發(fā)布他們，然后更新EVENT表標志此事件為已發(fā)布。
此方法也是優(yōu)缺點都有。優(yōu)點是可以確保事件發(fā)布不依賴于2PC，應用發(fā)布業(yè)務層級事件而不需要推斷他們發(fā)生了什么；而缺點在于此方法由于開發(fā)人員必須牢記發(fā)布事件，因此有可能出現(xiàn)錯誤。另外此方法對于某些使用NoSQL數(shù)據(jù)庫的應用是個挑戰(zhàn)，因為NoSQL本身交易和查詢能力有限。
此方法因為應用采用了本地交易更新狀態(tài)和發(fā)布事件而不需要2PC，現(xiàn)在再看看另外一種應用簡單更新狀態(tài)獲得原子性的方法。
1.3.2 挖掘數(shù)據(jù)庫交易日志
另外一種不需要2PC而獲得線程或者進程發(fā)布事件原子性的方式就是挖掘數(shù)據(jù)庫交易或者提交日志。應用更新數(shù)據(jù)庫，在數(shù)據(jù)庫交易日志中產(chǎn)生變化，交易日志挖掘進程或者線程讀這些交易日志，將日志發(fā)布給消息代理。如下圖所見：
此方法的例子如LinkedIn Databus 項目，Databus 挖掘Oracle交易日志，根據(jù)變化發(fā)布事件，LinkedIn使用Databus來保證系統(tǒng)內(nèi)各記錄之間的一致性。
另外的例子如：AWS的 streams mechanism in AWS DynamoDB，是一個可管理的NoSQL數(shù)據(jù)庫，一個DynamoDB流是由過去24小時對數(shù)據(jù)庫表基于時序的變化（創(chuàng)建，更新和刪除操作），應用可以從流中讀取這些變化，然后以事件方式發(fā)布這些變化。
交易日志挖掘也是優(yōu)缺點并存。優(yōu)點是確保每次更新發(fā)布事件不依賴于2PC。交易日志挖掘可以通過將發(fā)布事件和應用業(yè)務邏輯分離開得到簡化；而主要缺點在于交易日志對不同數(shù)據(jù)庫有不同格式，甚至不同數(shù)據(jù)庫版本也有不同格式；而且很難從底層交易日志更新記錄轉(zhuǎn)換為高層業(yè)務事件。
交易日志挖掘方法通過應用直接更新數(shù)據(jù)庫而不需要2PC介入。下面我們再看一種完全不同的方法：不需要更新只依賴事件的方法。
1.3.3 使用事件源
Event sourcing （事件源）通過使用根本不同的事件中心方式來獲得不需2PC的原子性，保證業(yè)務實體的一致性。 這種應用保存業(yè)務實體一系列狀態(tài)改變事件，而不是存儲實體現(xiàn)在的狀態(tài)。應用可以通過重放事件來重建實體現(xiàn)在狀態(tài)。只要業(yè)務實體發(fā)生變化，新事件就會添加到時間表中。因為保存事件是單一操作，因此肯定是原子性的。
為了理解事件源工作方式，考慮事件實體作為一個例子。傳統(tǒng)方式中，每個訂單映射為ORDER表中一行，例如在ORDER_LINE_ITEM表中。但是對于事件源方式，訂單服務以事件狀態(tài)改變方式存儲一個訂單：創(chuàng)建的，已批準的，已發(fā)貨的，取消的；每個事件包括足夠數(shù)據(jù)來重建訂單狀態(tài)。
事件是長期保存在事件數(shù)據(jù)庫中，提供API添加和獲取實體事件。事件存儲跟之前描述的消息代理類似，提供API來訂閱事件。事件存儲將事件遞送到所有感興趣的訂閱者，事件存儲是事件驅(qū)動微服務架構(gòu)的基干。
事件源方法有很多優(yōu)點：解決了事件驅(qū)動架構(gòu)關(guān)鍵問題，使得只要有狀態(tài)變化就可以可靠地發(fā)布事件，也就解決了微服務架構(gòu)中數(shù)據(jù)一致性問題。另外，因為是持久化事件而不是對象，也就避免了object relational impedance mismatch problem。
數(shù)據(jù)源方法提供了100%可靠的業(yè)務實體變化監(jiān)控日志，使得獲取任何時點實體狀態(tài)成為可能。另外，事件源方法可以使得業(yè)務邏輯可以由事件交換的松耦合業(yè)務實體構(gòu)成。這些優(yōu)勢使得單體應用移植到微服務架構(gòu)變的相對容易。
事件源方法也有不少缺點，因為采用不同或者不太熟悉的變成模式，使得重新學習不太容易；事件存儲只支持主鍵查詢業(yè)務實體，必須使用 Command Query Responsibility Segregation (CQRS) 來完成查詢業(yè)務，因此，應用必須處理最終一致數(shù)據(jù)。
1.4 總結(jié)
在微服務架構(gòu)中，每個微服務都有自己私有的數(shù)據(jù)集。不同微服務可能使用不同的SQL或者NoSQL數(shù)據(jù)庫。盡管數(shù)據(jù)庫架構(gòu)有很強的優(yōu)勢，但是也面對數(shù)據(jù)分布式管理的挑戰(zhàn)。第一個挑戰(zhàn)就是如何在多服務之間維護業(yè)務交易一致性；第二個挑戰(zhàn)是如何從多服務環(huán)境中獲取一致性數(shù)據(jù)。
最佳解決辦法是采用事件驅(qū)動架構(gòu)。其中碰到的一個挑戰(zhàn)是如何原子性的更新狀態(tài)和發(fā)布事件。有幾種方法可以解決此問題，包括將數(shù)據(jù)庫視為消息隊列、交易日志挖掘和事件源。
在未來的博客中，將會跟深入探討微服務的其他方面。
本系列七篇文章中其它幾篇鏈接如下：
-
Introduction to Microservices:
-
Building Microservices: Using an API Gateway:
-
Building Microservices: Inter-Process Communication in a Microservices Architecture:
-
Service Discovery in a Microservices Architecture:
原文鏈接：https://www.nginx.com/blog/event-driven-data-management-microservices/
