微服務(wù)領(lǐng)域的業(yè)務(wù)連續(xù)性和災(zāi)難恢復(fù)方案

沃爾瑪架構(gòu)翻新微服務(wù)領(lǐng)域的業(yè)務(wù)連續(xù)性和災(zāi)難恢復(fù)方案

沃爾瑪為美國幾乎所有州及全球許多國家/地區(qū)提供雜貨店提貨和配送服務(wù)。沃爾瑪?shù)募膳渌拖到y(tǒng)由應(yīng)用程序和后端系統(tǒng)組成，使全球員工可以滿足各地商店的全渠道電商訂單需求。電商環(huán)境下的訂單交付近年來，這套系統(tǒng)的業(yè)務(wù)量取得了巨大的增長：引用來源：/2019/08/13/walmart-tops-u-s-online-grocery-market-with-62-more-customers-than-next-nearest-rival/為了支持如此大的規(guī)模，我們決定對(duì)這套產(chǎn)品進(jìn)行現(xiàn)代化改造和架構(gòu)翻新。同時(shí)，有一項(xiàng)關(guān)鍵要求是保持業(yè)務(wù)的連續(xù)性。系統(tǒng)中的任何生產(chǎn)問題都會(huì)影響全球各地的客戶。這套系統(tǒng)"不能"在"保證的時(shí)間表"之外的時(shí)間下線。災(zāi)難恢復(fù)（DR）

分布式計(jì)算的謬論，是LPeterDeutsch等人在描述人們對(duì)分布式系統(tǒng)所做的錯(cuò)誤假設(shè)時(shí)觀察到的一系列結(jié)果。在云世界中，基礎(chǔ)架構(gòu)棧更加密集，并且包含許多不受我們控制的組件。這意味著其中一些謬論會(huì)更加明顯。當(dāng)一套云部署宕機(jī)時(shí)，我們需要系統(tǒng)從“另一個(gè)位置”繼續(xù)為客戶提供服務(wù)。災(zāi)難恢復(fù)（DR）是一種設(shè)計(jì)結(jié)構(gòu)，允許這套服務(wù)以及相關(guān)的基礎(chǔ)架構(gòu)組件（如消息代理和數(shù)據(jù)庫等）在另一個(gè)數(shù)據(jù)中心繼續(xù)運(yùn)行。高層架構(gòu)

像這樣的系統(tǒng)通常被設(shè)計(jì)為多個(gè)微服務(wù)的形式，這些微服務(wù)使用消息傳遞和API協(xié)作，以實(shí)現(xiàn)所需的行為。每個(gè)服務(wù)都有一個(gè)屬于自己的數(shù)據(jù)庫——從而加強(qiáng)了關(guān)注點(diǎn)隔離和清晰的合約。為了便于討論，下圖描繪了這種高層架構(gòu)的概況：一些“前端”服務(wù)從應(yīng)用接受請(qǐng)求，然后與其他“功能”服務(wù)一起工作以驅(qū)動(dòng)系統(tǒng)的用例。“事件驅(qū)動(dòng)”這一術(shù)語也適用于這些類型的系統(tǒng)，因?yàn)槊糠N服務(wù)之間都是松散耦合的，并且只響應(yīng)事件（消息）。這種微服務(wù)的部署方式稱為“環(huán)（Ring）”。

復(fù)寫

DR解決方案的第一個(gè)模式是遠(yuǎn)程數(shù)據(jù)中心中數(shù)據(jù)（數(shù)據(jù)庫）的可用性。最樸素/簡單的方法是，對(duì)主區(qū)域中DB的寫操作也會(huì)寫入遠(yuǎn)程區(qū)域。具體而言，當(dāng)本地和遠(yuǎn)程DB都保存了寫入的數(shù)據(jù)時(shí)，DB寫操作才算完成。這里的問題是：這些寫操作跨越了WAN鏈接，并且不提供嚴(yán)格的延遲SLA（服務(wù)級(jí)別協(xié)議）。因此DB寫入時(shí)間會(huì)延長且無法保證?，F(xiàn)在，系統(tǒng)可用性的公式中包含了其他一些組件：遠(yuǎn)程DB，本地DB和遠(yuǎn)程DB之間的網(wǎng)絡(luò)鏈接。復(fù)合系統(tǒng)的可靠性永遠(yuǎn)比各個(gè)組件要小，這意味著系統(tǒng)整體的可靠性會(huì)下降。為了避免犧牲性能和可用性，通常使用的模式是“異步復(fù)制”；也就是說，當(dāng)本地DB提交時(shí)DB寫入就完成了，隨后事務(wù)會(huì)被“運(yùn)送”到遠(yuǎn)程DB。在遠(yuǎn)程備用站點(diǎn)上，事務(wù)會(huì)與主DB中發(fā)生的對(duì)應(yīng)事務(wù)異步保存。例如，以下圖表和引用描述了SQLServer使用的分布式可用性組（DAG）技術(shù)：引用來源：/zh-cn/sql/database-engine/availability-groups/windows/distributed-availability-groups你可能會(huì)注意到消息傳遞沒有被復(fù)制——這是因?yàn)槭聞?wù)性分布式系統(tǒng)很難將復(fù)制的消息傳遞狀態(tài)與DB狀態(tài)拼接在一起。如下文所述，使用DB重播消息要容易得多。走進(jìn)微服務(wù)的世界

在微服務(wù)架構(gòu)中，每個(gè)服務(wù)都有自己的DB集。它們的復(fù)制全都是彼此獨(dú)立的：異步復(fù)制這里的問題是，系統(tǒng)整體狀態(tài)自身分散在多個(gè)服務(wù)中，但是多個(gè)微服務(wù)的事務(wù)傳送沒有沿著“清晰一致的路線”進(jìn)行協(xié)調(diào)。因此，遠(yuǎn)程復(fù)制的DB集中某個(gè)特定的“即時(shí)”/快照上的狀態(tài)集合可能是不一致的，或者在災(zāi)難發(fā)生時(shí)不可用！為了說明這個(gè)問題，請(qǐng)考慮以下流程：在這里兩個(gè)DB發(fā)生了變異，當(dāng)它們?cè)谶h(yuǎn)程數(shù)據(jù)中心中復(fù)制時(shí)，兩個(gè)遠(yuǎn)程DB可以處于4種可能的狀態(tài)：++++|#|ServiceX|CapabilityServiceP|++++|1|ObjectAdeleted|ObjectBdeleted||2|ObjectApresent|ObjectBdeleted||3|ObjectAdeleted|ObjectBpreset||4|ObjectApresent|ObjectBpreset|++++第一種和最后一種場景都是沒問題的（是的，即使“丟失數(shù)據(jù)”也可以），因?yàn)檎麄€(gè)系統(tǒng)現(xiàn)在處于“已知的最后一種一致狀態(tài)”上，然后我們就可以建立機(jī)制恢復(fù)一致性了。更糟糕的情況是系統(tǒng)實(shí)際上處于一種不一致的狀態(tài)——也就是場景2和3。在這種跨服務(wù)事務(wù)復(fù)制中可以浮現(xiàn)出3個(gè)問題：損壞的引用：ServiceX中的狀態(tài)指向了CapabilityServiceP中不存在的狀態(tài)。因此，當(dāng)應(yīng)用（客戶端）發(fā)起了一個(gè)流程，迫使ServiceX調(diào)用CapabilityServiceP時(shí)，接下來的交互可能會(huì)中斷——在這里后者并不存在針對(duì)前者所述實(shí)體的引用。腦裂（Split-brain）：很多時(shí)候，諸如CapabilityServiceP之類的服務(wù)提供了整個(gè)系統(tǒng)狀態(tài)的統(tǒng)一視圖，其具體做法是顯示不同應(yīng)用程序的物化視圖。在DR期間，可能發(fā)生的一種情況是物化視圖擁有某些數(shù)據(jù)，但事實(shí)來源卻沒有。這將導(dǎo)致“我在搜索頁面上看到了這個(gè)項(xiàng)目，但是當(dāng)我轉(zhuǎn)到詳細(xì)信息頁面時(shí)卻跳出來了404！”之類的問題。懸空引用（DanglingReference）：這種現(xiàn)象在內(nèi)存管理中通常是這樣描述的：“父”ServiceX沒有對(duì)對(duì)象（“OrderB”）的引用，但是“子”CapabilityServiceP具有有關(guān)“OrderB”的記錄。反規(guī)范化（重復(fù)信息以避免連接并提升性能）會(huì)加劇這種狀況。如果編碼不正確，這些懸空的引用可能會(huì)導(dǎo)致許多難以調(diào)試的問題。例如在上面的示例中，如果CapabilityServiceP用來給出訂單數(shù)量的估算值，那么估算的結(jié)果就會(huì)是錯(cuò)誤的。過去人們?cè)趥浞莸恼Z境中也研究過這個(gè)問題，如標(biāo)題為“微服務(wù)的持續(xù)災(zāi)難恢復(fù)：BAC定理”中的這