http://dockone.io/article/936

微服務(wù)實(shí)踐（五）：微服務(wù)的事件驅(qū)動(dòng)數(shù)據(jù)管理

【編者的話】本文是使用微服務(wù)創(chuàng)建應(yīng)用系列的第五篇文章。第一篇文章介紹了微服務(wù)架構(gòu)模式，并且討論了使用微服務(wù)的優(yōu)缺點(diǎn)；第二和第三篇描述了微服務(wù)架構(gòu)模塊間通訊的不同方面；第四篇研究了服務(wù)發(fā)現(xiàn)中的問(wèn)題。本篇中，我們從另外一個(gè)角度研究一下微服務(wù)架構(gòu)帶來(lái)的分布式數(shù)據(jù)管理問(wèn)題。

1.1 微服務(wù)和分布式數(shù)據(jù)管理問(wèn)題

單體式應(yīng)用一般都會(huì)有一個(gè)關(guān)系型數(shù)據(jù)庫(kù)，由此帶來(lái)的好處是應(yīng)用可以使用 ACID transactions，可以帶來(lái)一些重要的操作特性：

• 原子性 – 任何改變都是原子性的
• 一致性 – 數(shù)據(jù)庫(kù)狀態(tài)一直是一致性的
• 隔離性 – 即使交易并發(fā)執(zhí)行，看起來(lái)也是串行的
• Durable – 一旦交易提交了就不可回滾

鑒于以上特性，應(yīng)用可以簡(jiǎn)化為：開始一個(gè)交易，改變（插入，刪除，更新）很多行，然后提交這些交易。

使用關(guān)系型數(shù)據(jù)庫(kù)帶來(lái)另外一個(gè)優(yōu)勢(shì)在于提供SQL（功能強(qiáng)大，可聲明的，表轉(zhuǎn)化的查詢語(yǔ)言）支持。用戶可以非常容易通過(guò)查詢將多個(gè)表的數(shù)據(jù)組合起來(lái)，RDBMS查詢調(diào)度器決定最佳實(shí)現(xiàn)方式，用戶不需要擔(dān)心例如如何訪問(wèn)數(shù)據(jù)庫(kù)等底層問(wèn)題。另外，因?yàn)樗袘?yīng)用的數(shù)據(jù)都在一個(gè)數(shù)據(jù)庫(kù)中，很容易去查詢。

然而，對(duì)于微服務(wù)架構(gòu)來(lái)說(shuō)，數(shù)據(jù)訪問(wèn)變得非常復(fù)雜，這是因?yàn)閿?shù)據(jù)都是微服務(wù)私有的，唯一可訪問(wèn)的方式就是通過(guò)API。這種打包數(shù)據(jù)訪問(wèn)方式使得微服務(wù)之間松耦合，并且彼此之間獨(dú)立。如果多個(gè)服務(wù)訪問(wèn)同一個(gè)數(shù)據(jù)，schema會(huì)更新訪問(wèn)時(shí)間，并在所有服務(wù)之間進(jìn)行協(xié)調(diào)。

更甚于，不同的微服務(wù)經(jīng)常使用不同的數(shù)據(jù)庫(kù)。應(yīng)用會(huì)產(chǎn)生各種不同數(shù)據(jù)，關(guān)系型數(shù)據(jù)庫(kù)并不一定是最佳選擇。某些場(chǎng)景，某個(gè)NoSQL數(shù)據(jù)庫(kù)可能提供更方便的數(shù)據(jù)模型，提供更加的性能和可擴(kuò)展性。例如，某個(gè)產(chǎn)生和查詢字符串的應(yīng)用采用例如Elasticsearch的字符搜索引擎。同樣的，某個(gè)產(chǎn)生社交圖片數(shù)據(jù)的應(yīng)用可以采用圖片數(shù)據(jù)庫(kù)，例如，Neo4j；因此，基于微服務(wù)的應(yīng)用一般都使用SQL和NoSQL結(jié)合的數(shù)據(jù)庫(kù)，也就是被稱為polyglot persistence的方法。

分區(qū)的，polyglot-persistent架構(gòu)用于存儲(chǔ)數(shù)據(jù)有許多優(yōu)勢(shì)，包括松耦合服務(wù)和更佳性能和可擴(kuò)展性。然而，隨之而來(lái)的則是分布式數(shù)據(jù)管理帶來(lái)的挑戰(zhàn)。

第一個(gè)挑戰(zhàn)在于如何完成一筆交易的同時(shí)保持多個(gè)服務(wù)之間數(shù)據(jù)一致性。之所以會(huì)有這個(gè)問(wèn)題，我們以一個(gè)在線B2B商店為例，客戶服務(wù)維護(hù)包括客戶的各種信息，例如credit lines。訂單服務(wù)管理訂單，需要驗(yàn)證某個(gè)新訂單與客戶的信用限制沒(méi)有沖突。在單一式應(yīng)用中，訂單服務(wù)只需要使用ACID交易就可以檢查可用信用和創(chuàng)建訂單。

相反的，微服務(wù)架構(gòu)下，訂單和客戶表分別是相對(duì)應(yīng)服務(wù)的私有表，如下圖所示：

訂單服務(wù)不能直接訪問(wèn)客戶表，只能通過(guò)客戶服務(wù)發(fā)布的API來(lái)訪問(wèn)。訂單服務(wù)也可以使用 distributed transactions, 也就是周知的兩階段提交 (2PC)。然而，2PC在現(xiàn)在應(yīng)用中不是可選性。根據(jù)CAP理論，必須在可用性（availability）和ACID一致性（consistency）之間做出選擇，availability一般是更好的選擇。但是，許多現(xiàn)代科技，例如許多NoSQL數(shù)據(jù)庫(kù)，并不支持2PC。在服務(wù)和數(shù)據(jù)庫(kù)之間維護(hù)數(shù)據(jù)一致性是非常根本的需求，因此我們需要找其他的方案。

第二個(gè)挑戰(zhàn)是如何完成從多個(gè)服務(wù)中搜索數(shù)據(jù)。例如，設(shè)想應(yīng)用需要顯示客戶和他的訂單。如果訂單服務(wù)提供API來(lái)接受用戶訂單信息，那么用戶可以使用類應(yīng)用型的join操作接收數(shù)據(jù)。應(yīng)用從用戶服務(wù)接受用戶信息，從訂單服務(wù)接受此用戶訂單。假設(shè)，訂單服務(wù)只支持通過(guò)私有鍵（key）來(lái)查詢訂單（也許是在使用只支持基于主鍵接受的NoSQL數(shù)據(jù)庫(kù)），此時(shí)，沒(méi)有合適的方法來(lái)接收所需數(shù)據(jù)。

1.2 事件驅(qū)動(dòng)架構(gòu)

對(duì)許多應(yīng)用來(lái)說(shuō)，這個(gè)解決方案就是使用事件驅(qū)動(dòng)架構(gòu)（event-driven architecture）。在這種架構(gòu)中，當(dāng)某件重要事情發(fā)生時(shí)，微服務(wù)會(huì)發(fā)布一個(gè)事件，例如更新一個(gè)業(yè)務(wù)實(shí)體。當(dāng)訂閱這些事件的微服務(wù)接收此事件時(shí)，就可以更新自己的業(yè)務(wù)實(shí)體，也可能會(huì)引發(fā)更多的時(shí)間發(fā)布。

可以使用事件來(lái)實(shí)現(xiàn)跨多服務(wù)的業(yè)務(wù)交易。交易一般由一系列步驟構(gòu)成，每一步驟都由一個(gè)更新業(yè)務(wù)實(shí)體的微服務(wù)和發(fā)布激活下一步驟的事件構(gòu)成。下圖展現(xiàn)如何使用事件驅(qū)動(dòng)方法，在創(chuàng)建訂單時(shí)檢查信用可用度，微服務(wù)通過(guò)消息代理（Messsage Broker）來(lái)交換事件。

訂單服務(wù)創(chuàng)建一個(gè)帶有NEW狀態(tài)的Order （訂單），發(fā)布了一個(gè)“Order Created Event（創(chuàng)建訂單）”的事件。

客戶服務(wù)消費(fèi)Order Created Event事件，為此訂單預(yù)留信用，發(fā)布“Credit Reserved Event（信用預(yù)留）”事件

訂單服務(wù)消費(fèi)Credit Reserved Event，改變訂單的狀態(tài)為OPEN
更復(fù)雜的場(chǎng)景可以引入更多步驟，例如在檢查用戶信用的同時(shí)預(yù)留庫(kù)存等。

考慮到（a）每個(gè)服務(wù)原子性更新數(shù)據(jù)庫(kù)和發(fā)布事件，然后，（b）消息代理確保事件傳遞至少一次，然后可以跨多個(gè)服務(wù)完成業(yè)務(wù)交易（此交易不是ACID交易）。這種模式提供弱確定性，例如最終一致性 eventual consistency。這種交易類型被稱作 BASE model。

亦可以使用事件來(lái)維護(hù)不同微服務(wù)擁有數(shù)據(jù)預(yù)連接（pre-join）的實(shí)現(xiàn)視圖。維護(hù)此視圖的服務(wù)訂閱相關(guān)事件并且更新視圖。例如，客戶訂單視圖更新服務(wù)（維護(hù)客戶訂單視圖）會(huì)訂閱由客戶服務(wù)和訂單服務(wù)發(fā)布的事件。

當(dāng)客戶訂單視圖更新服務(wù)收到客戶或者訂單事件，就會(huì)更新 客戶訂單視圖數(shù)據(jù)集?？梢允褂梦臋n數(shù)據(jù)庫(kù)（例如MongoDB）來(lái)實(shí)現(xiàn)客戶訂單視圖，為每個(gè)用戶存儲(chǔ)一個(gè)文檔。客戶訂單視圖查詢服務(wù)負(fù)責(zé)響應(yīng)對(duì)客戶以及最近訂單（通過(guò)查詢客戶訂單視圖數(shù)據(jù)集）的查詢。

事件驅(qū)動(dòng)架構(gòu)也是既有優(yōu)點(diǎn)也有缺點(diǎn)，此架構(gòu)可以使得交易跨多個(gè)服務(wù)且提供最終一致性，并且可以使應(yīng)用維護(hù)最終視圖；而缺點(diǎn)在于編程模式比ACID交易模式更加復(fù)雜：為了從應(yīng)用層級(jí)失效中恢復(fù)，還需要完成補(bǔ)償性交易，例如，如果信用檢查不成功則必須取消訂單；另外，應(yīng)用必須應(yīng)對(duì)不一致的數(shù)據(jù)，這是因?yàn)榕R時(shí)（in-flight）交易造成的改變是可見的，另外當(dāng)應(yīng)用讀取未更新的最終視圖時(shí)也會(huì)遇見數(shù)據(jù)不一致問(wèn)題。另外一個(gè)缺點(diǎn)在于訂閱者必須檢測(cè)和忽略冗余事件。

1.3 原子操作Achieving Atomicity

事件驅(qū)動(dòng)架構(gòu)還會(huì)碰到數(shù)據(jù)庫(kù)更新和發(fā)布事件原子性問(wèn)題。例如，訂單服務(wù)必須向ORDER表插入一行，然后發(fā)布Order Created event，這兩個(gè)操作需要原子性。如果更新數(shù)據(jù)庫(kù)后，服務(wù)癱了（crashes）造成事件未能發(fā)布，系統(tǒng)變成不一致狀態(tài)。確保原子操作的標(biāo)準(zhǔn)方式是使用一個(gè)分布式交易，其中包括數(shù)據(jù)庫(kù)和消息代理。然而，基于以上描述的CAP理論，這卻并不是我們想要的。

1.3.1 使用本地交易發(fā)布事件

獲得原子性的一個(gè)方法是對(duì)發(fā)布事件應(yīng)用采用multi-step process involving only local transactions，技巧在于一個(gè)EVENT表，此表在存儲(chǔ)業(yè)務(wù)實(shí)體數(shù)據(jù)庫(kù)中起到消息列表功能。應(yīng)用發(fā)起一個(gè)（本地）數(shù)據(jù)庫(kù)交易，更新業(yè)務(wù)實(shí)體狀態(tài)，向EVENT表中插入一個(gè)事件，然后提交此次交易。另外一個(gè)獨(dú)立應(yīng)用進(jìn)程或者線程查詢此EVENT表，向消息代理發(fā)布事件，然后使用本地交易標(biāo)志此事件為已發(fā)布，如下圖所示：

訂單服務(wù)向ORDER表插入一行，然后向EVENT表中插入Order Created event，事件發(fā)布線程或者進(jìn)程查詢EVENT表，請(qǐng)求未發(fā)布事件，發(fā)布他們，然后更新EVENT表標(biāo)志此事件為已發(fā)布。

此方法也是優(yōu)缺點(diǎn)都有。優(yōu)點(diǎn)是可以確保事件發(fā)布不依賴于2PC，應(yīng)用發(fā)布業(yè)務(wù)層級(jí)事件而不需要推斷他們發(fā)生了什么；而缺點(diǎn)在于此方法由于開發(fā)人員必須牢記發(fā)布事件，因此有可能出現(xiàn)錯(cuò)誤。另外此方法對(duì)于某些使用NoSQL數(shù)據(jù)庫(kù)的應(yīng)用是個(gè)挑戰(zhàn)，因?yàn)镹oSQL本身交易和查詢能力有限。

此方法因?yàn)閼?yīng)用采用了本地交易更新狀態(tài)和發(fā)布事件而不需要2PC，現(xiàn)在再看看另外一種應(yīng)用簡(jiǎn)單更新狀態(tài)獲得原子性的方法。

1.3.2 挖掘數(shù)據(jù)庫(kù)交易日志

另外一種不需要2PC而獲得線程或者進(jìn)程發(fā)布事件原子性的方式就是挖掘數(shù)據(jù)庫(kù)交易或者提交日志。應(yīng)用更新數(shù)據(jù)庫(kù)，在數(shù)據(jù)庫(kù)交易日志中產(chǎn)生變化，交易日志挖掘進(jìn)程或者線程讀這些交易日志，將日志發(fā)布給消息代理。如下圖所見：

此方法的例子如LinkedIn Databus 項(xiàng)目，Databus 挖掘Oracle交易日志，根據(jù)變化發(fā)布事件，LinkedIn使用Databus來(lái)保證系統(tǒng)內(nèi)各記錄之間的一致性。

另外的例子如：AWS的 streams mechanism in AWS DynamoDB，是一個(gè)可管理的NoSQL數(shù)據(jù)庫(kù)，一個(gè)DynamoDB流是由過(guò)去24小時(shí)對(duì)數(shù)據(jù)庫(kù)表基于時(shí)序的變化（創(chuàng)建，更新和刪除操作），應(yīng)用可以從流中讀取這些變化，然后以事件方式發(fā)布這些變化。

交易日志挖掘也是優(yōu)缺點(diǎn)并存。優(yōu)點(diǎn)是確保每次更新發(fā)布事件不依賴于2PC。交易日志挖掘可以通過(guò)將發(fā)布事件和應(yīng)用業(yè)務(wù)邏輯分離開得到簡(jiǎn)化；而主要缺點(diǎn)在于交易日志對(duì)不同數(shù)據(jù)庫(kù)有不同格式，甚至不同數(shù)據(jù)庫(kù)版本也有不同格式；而且很難從底層交易日志更新記錄轉(zhuǎn)換為高層業(yè)務(wù)事件。

交易日志挖掘方法通過(guò)應(yīng)用直接更新數(shù)據(jù)庫(kù)而不需要2PC介入。下面我們?cè)倏匆环N完全不同的方法：不需要更新只依賴事件的方法。

1.3.3 使用事件源

Event sourcing （事件源）通過(guò)使用根本不同的事件中心方式來(lái)獲得不需2PC的原子性，保證業(yè)務(wù)實(shí)體的一致性。 這種應(yīng)用保存業(yè)務(wù)實(shí)體一系列狀態(tài)改變事件，而不是存儲(chǔ)實(shí)體現(xiàn)在的狀態(tài)。應(yīng)用可以通過(guò)重放事件來(lái)重建實(shí)體現(xiàn)在狀態(tài)。只要業(yè)務(wù)實(shí)體發(fā)生變化，新事件就會(huì)添加到時(shí)間表中。因?yàn)楸４媸录菃我徊僮?#xff0c;因此肯定是原子性的。

為了理解事件源工作方式，考慮事件實(shí)體作為一個(gè)例子。傳統(tǒng)方式中，每個(gè)訂單映射為ORDER表中一行，例如在ORDER_LINE_ITEM表中。但是對(duì)于事件源方式，訂單服務(wù)以事件狀態(tài)改變方式存儲(chǔ)一個(gè)訂單：創(chuàng)建的，已批準(zhǔn)的，已發(fā)貨的，取消的；每個(gè)事件包括足夠數(shù)據(jù)來(lái)重建訂單狀態(tài)。

事件是長(zhǎng)期保存在事件數(shù)據(jù)庫(kù)中，提供API添加和獲取實(shí)體事件。事件存儲(chǔ)跟之前描述的消息代理類似，提供API來(lái)訂閱事件。事件存儲(chǔ)將事件遞送到所有感興趣的訂閱者，事件存儲(chǔ)是事件驅(qū)動(dòng)微服務(wù)架構(gòu)的基干。

事件源方法有很多優(yōu)點(diǎn)：解決了事件驅(qū)動(dòng)架構(gòu)關(guān)鍵問(wèn)題，使得只要有狀態(tài)變化就可以可靠地發(fā)布事件，也就解決了微服務(wù)架構(gòu)中數(shù)據(jù)一致性問(wèn)題。另外，因?yàn)槭浅志没录皇菍?duì)象，也就避免了object relational impedance mismatch problem。

數(shù)據(jù)源方法提供了100%可靠的業(yè)務(wù)實(shí)體變化監(jiān)控日志，使得獲取任何時(shí)點(diǎn)實(shí)體狀態(tài)成為可能。另外，事件源方法可以使得業(yè)務(wù)邏輯可以由事件交換的松耦合業(yè)務(wù)實(shí)體構(gòu)成。這些優(yōu)勢(shì)使得單體應(yīng)用移植到微服務(wù)架構(gòu)變的相對(duì)容易。

事件源方法也有不少缺點(diǎn)，因?yàn)椴捎貌煌蛘卟惶煜さ淖兂赡Ｊ?#xff0c;使得重新學(xué)習(xí)不太容易；事件存儲(chǔ)只支持主鍵查詢業(yè)務(wù)實(shí)體，必須使用 Command Query Responsibility Segregation (CQRS) 來(lái)完成查詢業(yè)務(wù)，因此，應(yīng)用必須處理最終一致數(shù)據(jù)。

1.4 總結(jié)

在微服務(wù)架構(gòu)中，每個(gè)微服務(wù)都有自己私有的數(shù)據(jù)集。不同微服務(wù)可能使用不同的SQL或者NoSQL數(shù)據(jù)庫(kù)。盡管數(shù)據(jù)庫(kù)架構(gòu)有很強(qiáng)的優(yōu)勢(shì)，但是也面對(duì)數(shù)據(jù)分布式管理的挑戰(zhàn)。第一個(gè)挑戰(zhàn)就是如何在多服務(wù)之間維護(hù)業(yè)務(wù)交易一致性；第二個(gè)挑戰(zhàn)是如何從多服務(wù)環(huán)境中獲取一致性數(shù)據(jù)。

最佳解決辦法是采用事件驅(qū)動(dòng)架構(gòu)。其中碰到的一個(gè)挑戰(zhàn)是如何原子性的更新狀態(tài)和發(fā)布事件。有幾種方法可以解決此問(wèn)題，包括將數(shù)據(jù)庫(kù)視為消息隊(duì)列、交易日志挖掘和事件源。

在未來(lái)的博客中，將會(huì)跟深入探討微服務(wù)的其他方面。
本系列七篇文章中其它幾篇鏈接如下：

• Introduction to Microservices:?http://dockone.io/article/394
• Building Microservices: Using an API Gateway:?http://dockone.io/article/482
• Building Microservices: Inter-Process Communication in a Microservices Architecture:?http://dockone.io/article/549
• Service Discovery in a Microservices Architecture:?http://dockone.io/article/771

原文鏈接：Event-Driven Data Management for Microservices（翻譯：楊峰）

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/p/8744412.html

總結(jié)

以上是生活随笔為你收集整理的微服务实战（五）：微服务的事件驱动数据管理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。