建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
最強(qiáng)大的事務(wù)類(lèi)型之一稱(chēng)為兩階段提交，當(dāng)?shù)谝粋€(gè)事務(wù)的提交取決于第二個(gè)事務(wù)的完成時(shí)，它是摘要。特別是當(dāng)您必須同時(shí)更新多個(gè)實(shí)體時(shí)，例如確認(rèn)訂單和立即更新庫(kù)存時(shí)，它非常有用。
創(chuàng)新互聯(lián)建站一直通過(guò)網(wǎng)站建設(shè)和網(wǎng)站營(yíng)銷(xiāo)幫助企業(yè)獲得更多客戶(hù)資源。 以"深度挖掘，量身打造，注重實(shí)效"的一站式服務(wù)，以網(wǎng)站建設(shè)、成都網(wǎng)站制作、移動(dòng)互聯(lián)產(chǎn)品、全網(wǎng)整合營(yíng)銷(xiāo)推廣服務(wù)為核心業(yè)務(wù)。10余年網(wǎng)站制作的經(jīng)驗(yàn)，使用新網(wǎng)站建設(shè)技術(shù)，全新開(kāi)發(fā)出的標(biāo)準(zhǔn)網(wǎng)站，不但價(jià)格便宜而且實(shí)用、靈活，特別適合中小公司網(wǎng)站制作。網(wǎng)站管理系統(tǒng)簡(jiǎn)單易用，維護(hù)方便，您可以完全操作網(wǎng)站資料，是中小公司快速網(wǎng)站建設(shè)的選擇。
但是，例如，當(dāng)您使用微服務(wù)時(shí)，事情變得更加復(fù)雜。每個(gè)服務(wù)都是一個(gè)獨(dú)立的系統(tǒng)，擁有自己的數(shù)據(jù)庫(kù)，您不再可以利用本地兩階段提交的簡(jiǎn)單性來(lái)維護(hù)整個(gè)系統(tǒng)的一致性。
當(dāng)你失去這種能力時(shí)，RDBMS成為一個(gè)非常糟糕的存儲(chǔ)選擇，因?yàn)槟憧梢酝瓿上嗤摹皢螌?shí)體原子事務(wù)”，但只需使用像Couchbase這樣的NoSQL數(shù)據(jù)庫(kù)就可以快幾十倍。這就是為什么大多數(shù)使用微服務(wù)的公司也在使用NoSQL。
要舉例說(shuō)明此問(wèn)題，請(qǐng)考慮以下電子商務(wù)系統(tǒng)的高級(jí)微服務(wù)架構(gòu)：
圖片
在上面的示例中，人們不能只在一個(gè)ACID交易中下訂單，向客戶(hù)收費(fèi)，更新庫(kù)存，并將其發(fā)送到交貨。要始終如一地執(zhí)行此整個(gè)流程，您將需要?jiǎng)?chuàng)建分布式事務(wù)。
我們都知道實(shí)現(xiàn)分布式任務(wù)是多么困難，不幸的是，交易也不例外。處理瞬態(tài)狀態(tài)，服務(wù)，隔離和回滾之間的最終一致性是在設(shè)計(jì)階段應(yīng)該考慮的場(chǎng)景。
幸運(yùn)的是，我們已經(jīng)為它提出了一些好的模式，因?yàn)槲覀円呀?jīng)實(shí)施分布式事務(wù)已有二十多年了。我今天要談的那個(gè)叫做Saga模式。
傳奇(Saga)模式
分布式事務(wù)最著名的模式之一稱(chēng)為Saga。關(guān)于它的第一篇論文發(fā)表于1987年，從那時(shí)起它就成了一種流行的解決方案。
Saga是一系列本地事務(wù)，其中每個(gè)事務(wù)在單個(gè)服務(wù)中更新數(shù)據(jù)。第一個(gè)事務(wù)由對(duì)應(yīng)于系統(tǒng)操作的外部請(qǐng)求啟動(dòng)，然后每個(gè)后續(xù)步驟由前一個(gè)完成觸發(fā)。
使用我們之前的電子商務(wù)示例，在一個(gè)非常高級(jí)的設(shè)計(jì)中，Saga實(shí)現(xiàn)如下所示：
圖片
有幾種不同的方法來(lái)實(shí)現(xiàn)傳奇交易，但最受歡迎的兩種方式是：
- 事件/Choreography(編舞)：當(dāng)沒(méi)有中央?yún)f(xié)調(diào)時(shí)，每個(gè)服務(wù)產(chǎn)生并監(jiān)聽(tīng)其他服務(wù)的事件，并決定是否應(yīng)該采取行動(dòng)。
- 命令 / Orchestration(編曲)：協(xié)調(diào)器服務(wù)負(fù)責(zé)集中saga的決策和排序業(yè)務(wù)邏輯。
讓我們更深入地了解每個(gè)實(shí)現(xiàn)，以了解它們的工作原理。
事件/編舞
在事件/Choreography(編舞)方法中，第一個(gè)服務(wù)執(zhí)行事務(wù)然后發(fā)布事件。該事件由一個(gè)或多個(gè)服務(wù)監(jiān)聽(tīng)，這些服務(wù)執(zhí)行本地事務(wù)并發(fā)布（或不發(fā)布）新事件。
當(dāng)最后一個(gè)服務(wù)執(zhí)行其本地事務(wù)并且不發(fā)布任何事件時(shí)，分布式事務(wù)結(jié)束，或者任何傳奇(Saga)參與者都不會(huì)聽(tīng)到發(fā)布的事件。
讓我們看看它在我們的電子商務(wù)示例中的樣子：
圖片
- 訂單服務(wù)保存新訂單，將狀態(tài)設(shè)置為掛起并發(fā)布名為ORDER_CREATED_EVENT的事件。
- 付款服務(wù)偵聽(tīng)ORDER_CREATED_EVENT，向客戶(hù)收費(fèi)并發(fā)布事件BILLED_ORDER_EVENT。
- Stock Service監(jiān)聽(tīng)BILLED_ORDER_EVENT，更新庫(kù)存，準(zhǔn)備訂單中購(gòu)買(mǎi)的產(chǎn)品并發(fā)布ORDER_PREPARED_EVENT。
- Delivery Service偵聽(tīng)ORDER_PREPARED_EVENT，然后選擇并交付產(chǎn)品。最后，它發(fā)布了ORDER_DELIVERED_EVENT
- 最后，Order Service偵聽(tīng)ORDER_DELIVERED_EVENT并將訂單狀態(tài)設(shè)置為已結(jié)束。
在上面的情況中，如果需要跟蹤訂單的狀態(tài)，訂單服務(wù)可以簡(jiǎn)單地監(jiān)聽(tīng)所有事件并更新其狀態(tài)。
分布式事務(wù)中的回滾
回滾分布式事務(wù)并非免費(fèi)。通常，您必須實(shí)施另一個(gè)操作/事務(wù)來(lái)補(bǔ)償之前已完成的操作。
假設(shè)Stock Service在交易期間失敗了。讓我們看看回滾會(huì)是什么樣子：
圖片
- 庫(kù)存服務(wù)生產(chǎn)PRODUCT_OUT_OF_STOCK_EVENT;
- 訂單服務(wù)和付款服務(wù)都會(huì)收聽(tīng)上一條消息：
- 付款服務(wù)退還客戶(hù)。
- 訂單服務(wù)將訂單狀態(tài)設(shè)置為失敗。
請(qǐng)注意，為每個(gè)事務(wù)定義一個(gè)公共共享ID至關(guān)重要，因此每當(dāng)您拋出一個(gè)事件時(shí)，所有偵聽(tīng)器都可以立即知道它所引用的事務(wù)。
Saga 事件/Choreography(編舞)設(shè)計(jì)的好處和缺點(diǎn)
事件/編排是實(shí)現(xiàn)Saga模式的自然方式;它簡(jiǎn)單，易于理解，不需要太多的努力來(lái)構(gòu)建，并且所有參與者都是松散耦合的，因?yàn)樗麄儧](méi)有彼此的直接知識(shí)。如果您的交易涉及2到4個(gè)步驟，那么它可能非常合適。
但是，如果您不斷在事務(wù)中添加額外的步驟，這種方法很快就會(huì)變得混亂，因?yàn)楹茈y跟蹤哪些服務(wù)監(jiān)聽(tīng)哪些事件。此外，它還可能在服務(wù)之間添加循環(huán)依賴(lài)，因?yàn)樗鼈儽仨氂嗛啽舜说氖录?/p>
最后，使用這種設(shè)計(jì)實(shí)現(xiàn)測(cè)試會(huì)很棘手。為了模擬事務(wù)行為，您應(yīng)該運(yùn)行所有服務(wù)。
分享標(biāo)題：Saga模式|如何使用微服務(wù)實(shí)現(xiàn)業(yè)務(wù)事務(wù)
文章出自：http://www.dlmjj.cn/article/dpsegjh.html
