2019獨角獸企業(yè)重金招聘Python工程師標準>>>

ServiceComb數(shù)據(jù)一致性解決方案Saga演進介紹

?

本文轉(zhuǎn)自 微服務 開源項目 Apache ServiceComb (incubating) 的官方博客：

http://servicecomb.incubator.apache.org/cn/docs/saga_pack_design/

?

傳統(tǒng)的單體應用的微服務化改造過程中大多會面臨數(shù)據(jù)庫拆分，故而原來由數(shù)據(jù)庫保證的數(shù)據(jù)一致性也一定面臨重新設計和實現(xiàn)，此時需要引入分布式數(shù)據(jù)一致性方案來解決。常見的解決方案主要有2PC，TCC，事件驅(qū)動等，而在微服務開源項目 ServiceComb中提出并實現(xiàn)了使用Saga[1]來解決微服務的數(shù)據(jù)一致性難題，不同方案的對比可參考《ServiceComb中的數(shù)據(jù)最終一致性方案》[2]一文。Saga是一個數(shù)據(jù)最終一致性的解決方案，它允許我們成功地執(zhí)行所有事務，或在任何事務失敗的情況下，補償已成功的事務，并提供了ACID[3]中ACD的保證（由于事務是交錯執(zhí)行的，可能會看到其他事務的部分結(jié)果，因此不能滿足隔離性要求）。因此，Saga適用于以下跨服務的事務場景：

• 嵌套調(diào)用。如網(wǎng)上購物時，會依次經(jīng)過下單、支付服務和第三方支付這幾個子事務，其中，下單依賴于支付服務的返回狀態(tài)，而支付服務也包含了多種可選的支付方式，并依賴于具體支付方式返回的結(jié)果。通過Saga，可以清晰地看到一個完整事務中各個服務之間的關(guān)系，在異常時也能快速定位出現(xiàn)問題的子事務。
• 高并發(fā)。如秒殺場景下，在成功扣除庫存和完成支付后方可認為秒殺成功，若成功扣除庫存但支付失敗則自動進行補償（即恢復庫存）。鑒于Saga只有提交和補償兩種狀態(tài)，成功場景下只需對每個子事務進行一次調(diào)用即可，因此可以在高并發(fā)下保持高性能。
• 調(diào)用時間長。如線上購買電影票，選好座位后一般會有15分鐘的支付時間。Saga僅在子事務的提交階段對資源進行短暫的鎖定，且通過超時機制確保事務超時后能自動補償，即在規(guī)定時間內(nèi)沒有支付成功的話就自動釋放鎖定的座位，極大地簡化了業(yè)務出現(xiàn)異常時的處理邏輯。

Saga新版本演進

新年新氣象，Apache ServiceComb(incubating) Saga[4]（以下簡稱Saga）進行了演進。相對于上一版[2]，新演進的設計主要有以下優(yōu)勢：

• 極大提升易用性。開發(fā)者只需使用2-3個注解（即啟用事務服務：EnableOmega、全局事務標記：SagaStart和子事務標記：Compensable）。
• 更方便擴展。對微服務框架的支持更友好。
• 數(shù)據(jù)一致性與業(yè)務邏輯解耦。在演進后的設計中，通過服務側(cè)omega的引入，saga協(xié)調(diào)器的職責更為單一（只需負責協(xié)調(diào)事務的完整性），與具體業(yè)務無關(guān)，因此，開發(fā)人員可以聚焦在具體業(yè)務的開發(fā)。

Saga演進后的架構(gòu)，如下圖所示，主要包含兩個組件，即alpha和omega，其中：

• alpha充當協(xié)調(diào)者的角色，主要負責對事務的事件進行持久化存儲以及協(xié)調(diào)子事務的狀態(tài)，使其最終得以與全局事務的狀態(tài)保持一致，即保證事務中的子事務要么全執(zhí)行，要么全不執(zhí)行。
• omega是微服務中內(nèi)嵌的一個agent，負責對網(wǎng)絡請求進行攔截并向alpha上報事務事件，并在異常情況下根據(jù)alpha下發(fā)的指令執(zhí)行相應的補償或重試操作。

omega內(nèi)部運行機制

omega是微服務中內(nèi)嵌的一個agent，負責向alpha上報事務狀態(tài)并與其它omega直接傳遞事務上下文信息。其中，每個服務的事務上下文包括：

• 全局事務id(Global Tx Id)：用于唯一標識全局事務，一般在全局事務入口生成，并在整個事務過程中傳遞。
• 本地事務id(Local Tx Id)：用于唯一標識本地事務，一般由本地事務生成。
• 父事務id(Parent Tx Id)：用于構(gòu)建子事務間的關(guān)系，可由請求上下文中構(gòu)建。

如下圖所示，分布式事務與用于分布式調(diào)用鏈追蹤的zipkin[5]的處理流程很類似，在服務提供方，omega會將請求攔截并從中提取請求信息中的全局事務id作為其自身的全局事務id（即Saga事件id），并將請求中的本地事務id作為其父事務id，且使用新生成的id作為本地事務id；在服務消費方，omega會將請求攔截并往其中添加當前的全局事務id和本地事務id。通過服務提供方和服務消費方的這種協(xié)作處理，子事務能連接起來形成一個完整的全局事務。

omega在預處理階段會先向alpha發(fā)送事務開始的事件，在后處理階段會再向alpha發(fā)送事務結(jié)束的事件。alpha在收到事件后會進行持久化的存儲。因此，每個成功的子事務都有一一對應的開始及結(jié)束事件。

在omega啟動時會向alpha注冊，使得異常或者超時場景下，alpha能通過回調(diào)向omega發(fā)送重試或補償?shù)拿詈拖鄳恼{(diào)用參數(shù)，從而確保全局事務的一致性。

具體處理流程

成功場景

全局事務開始前omega會先向alpha發(fā)送全局事務開始的事件，并在所有子事務完成時向alpha發(fā)送全局事務結(jié)束的事件。而每個子事務在執(zhí)行前也會向alpha發(fā)送事務開始的事件，在成功執(zhí)行后，會向alpha發(fā)送事務結(jié)束的事件。子事務間通過全局事務id連接在一起，但也因本地事務id而有所區(qū)分。因此，在成功場景下，每個開始的事件都會有對應的結(jié)束事件。

異常場景

在子事務執(zhí)行期間拋出異常時，omega會向alpha上報aborted事件，然后alpha會向該全局事務的其它已完成的子事務發(fā)送補償指令，確保最終同一全局事務下的所有子事務要么都成功，要么都回滾。由于事務中沒有明確指定全局事務中的參與者，因此，alpha的掃描器會定期查詢事件表并找出已完成所有補償子事務的全局事務，然后對這些全局事務添加全局事務結(jié)束事件以保證事務的完整性。

超時場景

alpha的掃描器會定期掃描正在處理的事件狀態(tài)，若發(fā)現(xiàn)事件超時，則會記錄相應的aborted事件，然后alpha會向該全局事務的其它已完成的子事務發(fā)送補償指令來恢復至事務開始前的狀態(tài)。

如何使用？

Saga的使用主要涵蓋兩方面，alpha的啟動及omega的使用。

alpha的啟動

alpha啟動前需要先運行數(shù)據(jù)庫PostgreSQL：

docker run -d -e "POSTGRES_DB=saga" -e "POSTGRES_USER=saga" -e "POSTGRES_PASSWORD=password" -p 5432:5432 postgres

?

在確保數(shù)據(jù)庫正常啟動后，即可運行alpha：

docker run -d -p 8090:8090 \-e "JAVA_OPTS=-Dspring.profiles.active=prd" \-e "spring.datasource.url=jdbc:postgresql://{docker.host.address}:5432/saga?useSSL=false" \alpha-server:0.1.0

?

omega的使用

omega的使用很簡單，以一個簡化的轉(zhuǎn)賬業(yè)務為例，同一筆轉(zhuǎn)賬要么轉(zhuǎn)入和轉(zhuǎn)出都成功，要么都失敗。在這樣一個業(yè)務中引入Saga，只需簡單幾步即可：

引入依賴 <dependency><groupId>org.apache.servicecomb.saga</groupId><artifactId>omega-spring-starter</artifactId><version>0.1.0</version> </dependency> <dependency><groupId>org.apache.servicecomb.saga</groupId><artifactId>omega-transport-resttemplate</artifactId><version>0.1.0</version> </dependency>

?

添加Saga的注解及相應的補償方法 2.1 在應用入口添加?@EnableOmega?的注解來初始化omega的配置并與alpha建立連接。 @SpringBootApplication@EnableOmegapublic class Application {public static void main(String[] args) {SpringApplication.run(Application.class, args);}}

Copy

2.2 在全局事務的起點添加?@SagaStart?的注解。

@SagaStart(timeout=10)public boolean transferMoney(String from, String to, int amount) {transferOut(from, amount);transferIn(to, amount);}

?

2.3 在子事務處添加?@Compensable?的注解并指明其對應的補償方法。其中，補償方法的形參列表需與子事務方法的形參列表保持一致。

@Compensable(timeout=5, compensationMethod="cancel")public boolean transferOut(String from, int amount) {repo.reduceBalanceByUsername(from, amount);}public boolean cancel(String from, int amount) {repo.addBalanceByUsername(from, amount);}

?

2.4 對轉(zhuǎn)入服務重復第2.3步即可。

2.5 在每個服務的application.yaml中添加配置項，指明服務信息和alpha的地址信息：

spring:application:name: {application.name}alpha:cluster:address: {alpha.cluster.addresses}

?

目前Saga的實現(xiàn)還存在著很多有意思且有挑戰(zhàn)性的課題，如alpha的協(xié)調(diào)調(diào)度實現(xiàn)、冪等的實現(xiàn)及自動補償?shù)膶崿F(xiàn)等，歡迎有志之士與我們攜手一起解決數(shù)據(jù)一致性的難題，共同為完善微服務生態(tài)貢獻自己的力量。

如何加入Apache ServiceComb 社區(qū)：

http://servicecomb.incubator.apache.org/cn/docs/join_the_community/

?

參考文獻

[1] Apache ServiceComb 官網(wǎng),

http://servicecomb.incubator.apache.org/cn/

[2] 代碼參考項目地址? Apache ServiceComb(incubating) Saga,

https://github.com/apache/incubator-servicecomb-saga

[3] ServiceComb中的數(shù)據(jù)最終一致性方案，

http://servicecomb.incubator.apache.org/cn/docs/distributed_saga_1/

http://servicecomb.incubator.apache.org/cn/docs/distributed_saga_2/

http://servicecomb.incubator.apache.org/cn/docs/distributed_saga_3/

[4] Sagas, Hector Garcia-Molina & Kenneth Salem,?

https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf

[5] ACID, Wikipedia,?

https://en.wikipedia.org/wiki/ACID

[6] zipkin, zipkin,?

https://github.com/openzipkin/zipkin

[7] 碼云地址,

https://gitee.com/servicecomb

https://www.oschina.net/p/servicecomb

轉(zhuǎn)載于:https://my.oschina.net/u/3823482/blog/1798723

總結(jié)

以上是生活随笔為你收集整理的微服务Apache ServiceComb 数据一致性Saga演进介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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