經(jīng)國?

螞蟻金服數(shù)字金融線擔(dān)任技術(shù)風(fēng)險架構(gòu)師

讀完需要

15

分鐘

速讀僅需 5 分鐘

經(jīng)國，螞蟻金服資深技術(shù)專家，畢業(yè)于浙江大學(xué)。

2014 年加入螞蟻金服，先后負(fù)責(zé)過支付寶的單元化、彈性、去 ORACLE 等架構(gòu)升級，擔(dān)任多年支付寶雙十一、雙十二、新春紅包大型活動等技術(shù)保障負(fù)責(zé)人，現(xiàn)為螞蟻金服數(shù)字金融線擔(dān)任技術(shù)風(fēng)險架構(gòu)師，負(fù)責(zé)高可用架構(gòu)、技術(shù)風(fēng)險平臺、應(yīng)急快反等技術(shù)底盤的建設(shè)。

本次直播視頻精彩回顧，請點(diǎn)擊“閱讀原文”！

以下內(nèi)容根據(jù)演講視頻以及 PPT 整理而成。

本次分享主要圍繞以下五個方面：

應(yīng)用架構(gòu)演進(jìn)路徑

云原生時代的技術(shù)福利

高可用架構(gòu)的設(shè)計(jì)原則

經(jīng)典案例的設(shè)計(jì)

未來思考

微服務(wù)是當(dāng)下非常熱門的一種架構(gòu)，阿里目前正在從 SOA 架構(gòu)體系向微服務(wù)架構(gòu)遷移。同時整個軟件應(yīng)用研發(fā)開始進(jìn)入云原生時代。在這些技術(shù)演進(jìn)背景下討論如何更好地實(shí)現(xiàn)穩(wěn)定且高可用的架構(gòu)方案，保證應(yīng)用持續(xù)可用非常有必要。

1

? ?

應(yīng)用架構(gòu)演進(jìn)路徑

支付寶最開始是一個單體應(yīng)用。隨著業(yè)務(wù)不斷發(fā)展，支付寶拆分成了多個服務(wù)，衍生出了若干代架構(gòu)。微服務(wù)是服務(wù)化后的進(jìn)一步演進(jìn)，服務(wù)的粒度比服務(wù)化更細(xì)，具有很好的流量管控機(jī)制，中間件和編程模型。

云原生的發(fā)展使 Serverless 也得到了發(fā)展，FAAS 是 Serverless 的一種典型實(shí)現(xiàn)，能夠以非常小的成本搭建小程序。另外，低代碼和無代碼現(xiàn)在也非常流行。

基礎(chǔ)設(shè)施同樣也得到了很好的發(fā)展。最開始，單體架構(gòu)是托管式的，通常將應(yīng)用程序托管給電信運(yùn)營商的某個機(jī)房，在物理機(jī)上運(yùn)行單體應(yīng)用。后來，基礎(chǔ)設(shè)施開始向虛擬化演進(jìn)，比如 VMware 等公司在物理機(jī)上構(gòu)建虛擬化層和虛擬機(jī)，在虛擬機(jī)上運(yùn)行操作系統(tǒng)。再后來，云化結(jié)合虛擬化技術(shù)和基礎(chǔ)設(shè)施，在虛擬機(jī)上運(yùn)行 Docker 進(jìn)程，在 Docker 進(jìn)程中運(yùn)行應(yīng)用程序。現(xiàn)在，根據(jù)云通未來的理念，包括螞蟻在內(nèi)的很多公司都在實(shí)現(xiàn)上云。螞蟻的基礎(chǔ)設(shè)施已經(jīng)完全實(shí)現(xiàn)了云化，包括公有云和私有云。從架構(gòu)角度來看，螞蟻的基礎(chǔ)設(shè)施就是在云底座上運(yùn)行一層 K8S，在 Pod 里運(yùn)行 APP，其上層對應(yīng)著 FAAS、網(wǎng)格化、Service mesh、微服務(wù)等應(yīng)用程序。

作為一個復(fù)雜的業(yè)務(wù)應(yīng)用，如何實(shí)現(xiàn)技術(shù)支撐對螞蟻非常關(guān)鍵。螞蟻目前正在嘗試許多 FAAS 相關(guān)的技術(shù)選型，但從更大的范圍來看，微服務(wù)仍然是主流的選擇。螞蟻所使用的微服務(wù)架構(gòu)本身也在不斷演進(jìn)，比如把和業(yè)務(wù)無關(guān)的功能下沉到 Sidecar，將數(shù)據(jù)庫的一些中間件 mesh 化等。盡管從應(yīng)用研發(fā)的角度看，螞蟻所使用的架構(gòu)風(fēng)格相比于原來發(fā)生了很大的變化，但從整體趨勢來看，最主要的變化仍在于將和業(yè)務(wù)能力無關(guān)并且和基礎(chǔ)設(shè)施相關(guān)的能力下沉。

2

? ?

云原生時代的技術(shù)紅利

云原生已經(jīng)演化成了一個非常龐大的生態(tài)。這張圖囊括了云原生里非常多的內(nèi)容。從設(shè)計(jì)高可用且穩(wěn)定性高的應(yīng)用的角度來看，相關(guān)的內(nèi)容包括數(shù)據(jù)庫技術(shù)、云原生存儲、Service mesh、可觀測性、Serverless 等。

2.1

? ?

數(shù)據(jù)庫技術(shù)

應(yīng)用開發(fā)不僅需要關(guān)注業(yè)務(wù)邏輯，還需要關(guān)注數(shù)據(jù)，將領(lǐng)域模型、業(yè)務(wù)流程、配置等數(shù)據(jù)以 Online 形式存儲。近幾年，數(shù)據(jù)庫技術(shù)發(fā)生了很大的變化，HBase 等分布式數(shù)據(jù)庫提供的強(qiáng)一致保證給云原生應(yīng)用的設(shè)計(jì)和開發(fā)帶來了許多好處。此前，應(yīng)用設(shè)計(jì)需要考慮讀寫分離，需要連接不同的數(shù)據(jù)源處理讀寫分離的結(jié)果，并且這些功能都需要寫入應(yīng)用程序代碼。而現(xiàn)在，這些功能可以直接利用數(shù)據(jù)庫的水平擴(kuò)展能力來實(shí)現(xiàn)，數(shù)據(jù)庫技術(shù)的發(fā)展極大地避免了我們直接和數(shù)據(jù)層交互。

2.2

? ?

云原生存儲

螞蟻的大部分業(yè)務(wù)已經(jīng)實(shí)現(xiàn)云盤存儲，也就是將日志存儲到遠(yuǎn)方磁盤。此前，單體應(yīng)用通常將數(shù)據(jù)存儲于本機(jī)磁盤，并且不提供其它冗余備份；而云盤則默認(rèn)提供數(shù)據(jù)冗余，這在基于日志不可靠假設(shè)進(jìn)行應(yīng)用設(shè)計(jì)時帶來了很多變化。

2.3

? ?

可觀測性

應(yīng)用程序存在著許多監(jiān)控操作。隨著 Sidecar 將很多能力下沉，包括訪問 RPC 和 DB，此前以中間件形式實(shí)現(xiàn)的監(jiān)控操作，現(xiàn)在則以切面形式來實(shí)現(xiàn)，二者有很大的區(qū)別。

2.4

? ?

云原生時代的技術(shù)紅利

云原生時代帶來的最大變化在于基礎(chǔ)設(shè)施和業(yè)務(wù)邏輯的真正解耦。此前，中間件邏輯存在于應(yīng)用程序的進(jìn)程中，而現(xiàn)在壓測、限流等都可以在 Sidecar 中實(shí)現(xiàn)，從而解耦了基礎(chǔ)設(shè)施和業(yè)務(wù)邏輯。然而，這種解耦是不斷進(jìn)行著的，即使在未來也很難做到業(yè)務(wù)完全不需要關(guān)注基礎(chǔ)設(shè)施。

比如，業(yè)務(wù)流量應(yīng)該多大，DB 節(jié)點(diǎn)應(yīng)該設(shè)置多少個，業(yè)務(wù)流量和 DB 的設(shè)計(jì)是否符合要求。比如，同步的關(guān)鍵業(yè)務(wù)對應(yīng)的流量鏈路和異步化任務(wù)可能運(yùn)行在同一個節(jié)點(diǎn)中，那么如何實(shí)現(xiàn)二者流量隔離就是一個難題。

再比如，如何結(jié)合基礎(chǔ)設(shè)施和業(yè)務(wù)要求進(jìn)行部署，保證內(nèi)存和 CPU 合理分配。在基礎(chǔ)設(shè)施對這些內(nèi)容無感知的前提下，如何自動化地進(jìn)行混布和限流。從應(yīng)用研發(fā)的視角來看，此前需要寫很多代碼來實(shí)現(xiàn)業(yè)務(wù)邏輯和基礎(chǔ)設(shè)施交互；而現(xiàn)在相應(yīng)的代碼量會減少很多。

3

? ?

高可用架構(gòu)設(shè)計(jì)的設(shè)計(jì)原則

3.1

? ?

三個架構(gòu)設(shè)計(jì)原則：可觀測、可灰度、可回滾

高可用設(shè)計(jì)主要有三個原則，包括可觀測、可灰度、可回滾。大部分云研發(fā)場景并不需要關(guān)注可演變，但在一些特殊場景下可演變?nèi)匀皇且粋€問題。比如，螞蟻的金融業(yè)務(wù)需要和一些機(jī)構(gòu)進(jìn)行信息交換，由于金融領(lǐng)域的 RPC 交互常常使用標(biāo)準(zhǔn)化文件，在文件場景下如何保證可演變也是高可用設(shè)計(jì)需要關(guān)注的內(nèi)容。典型的用于提高架構(gòu)可用性的設(shè)計(jì)原則包括四種：解耦、冗余、異構(gòu)和異步。

3.2

? ?

解耦

在數(shù)據(jù)庫方面，如何解耦核心和非核心業(yè)務(wù)的 DB。在業(yè)務(wù)鏈路方面，由于微服務(wù)具有復(fù)雜的業(yè)務(wù)場景和節(jié)點(diǎn)，這些業(yè)務(wù)場景和節(jié)點(diǎn)間如何混合，業(yè)務(wù)節(jié)點(diǎn)如何支撐業(yè)務(wù)鏈路，容量不足時哪些業(yè)務(wù)場景應(yīng)優(yōu)先通過，限流時應(yīng)優(yōu)先限流哪些業(yè)務(wù)等也是解耦需要關(guān)注的內(nèi)容。總體而言，解耦原則要求將最核心的業(yè)務(wù)鏈路隔離出來，使其與其它業(yè)務(wù)間的耦合盡可能小。

3.3

? ?

冗余

應(yīng)用程序可能有多個機(jī)房，如果多個機(jī)房間存在數(shù)據(jù)冗余，那么一個位置的錯誤就能夠由另一個位置的數(shù)據(jù)來彌補(bǔ)，從而保證系統(tǒng)的持續(xù)可用。讀寫分離也是一種冗余設(shè)計(jì)，緩存和 DB 間存在數(shù)據(jù)冗余，當(dāng)緩存宕機(jī)時，可以從 DB 回源到緩存。

3.4

? ?

異構(gòu)

如果多個 DB 間是同構(gòu)的，那么可能存在一些情況使得中心化的內(nèi)容同時掛掉；但如果 DB 是異構(gòu)的，比如使用的數(shù)據(jù)庫版本不同，那么這些數(shù)據(jù)庫同時掛掉的情況則非常少。

3.5

? ?

異步

異步要求將業(yè)務(wù)流程的核心部分抽象出來，使其不與非核心的內(nèi)容耦合。從理論上看，核心部分越精煉，系統(tǒng)出錯誤的概率越小。比如，支付寶的支付業(yè)務(wù)背后有一百多個業(yè)務(wù)處理節(jié)點(diǎn)，在微服務(wù)時代，其背后可能有幾百個甚至上千個業(yè)務(wù)節(jié)點(diǎn)，假設(shè)每個節(jié)點(diǎn)的可用率都是 5 個 9，把幾百個甚至幾千個節(jié)點(diǎn)的可用率乘起來就會使得整體的可用率非常小。但通過移除和核心業(yè)務(wù)無關(guān)的內(nèi)容，從而減小節(jié)點(diǎn)數(shù)量后，系統(tǒng)的可用率就會大幅增高。上圖的左右兩邊從不同角度對微服務(wù)的高可用設(shè)計(jì)進(jìn)行了分析。左邊是微服務(wù)設(shè)計(jì)應(yīng)具有的能力，右邊是設(shè)計(jì)高可用微服務(wù)架構(gòu)時應(yīng)遵循的原則。另外，有三塊內(nèi)容實(shí)際支撐著一個微服務(wù)系統(tǒng)：代碼、配置和數(shù)據(jù)。其中，代碼和配置是相輔相成的，代碼執(zhí)行的間歇可能需要修改系統(tǒng)配置；業(yè)務(wù)數(shù)據(jù)也非常重要。對這三塊內(nèi)容進(jìn)行分析是微服務(wù)架構(gòu)高可用設(shè)計(jì)的重要方面。比如，配置文件的可回滾和可灰度能力。與代碼相比，配置文件的可灰度能力不夠標(biāo)準(zhǔn)化，尤其是和業(yè)務(wù)或者運(yùn)營相關(guān)的配置文件；數(shù)據(jù)也是如此，由于一些數(shù)據(jù)有多種來源，這些數(shù)據(jù)的可觀測和可演練能力比代碼差。從整體而言，代碼的相關(guān)體系比配置文件和數(shù)據(jù)更完備。

3.6

? ?

不過度設(shè)計(jì)

架構(gòu)設(shè)計(jì)的另一個重要原則是不過度設(shè)計(jì)，高可用架構(gòu)設(shè)計(jì)應(yīng)基于業(yè)務(wù)需求進(jìn)行。這是因?yàn)楦呖捎迷O(shè)計(jì)通常極為復(fù)雜。比如，將鏈路中的一些重要業(yè)務(wù)解耦出來單獨(dú)部署，無論其業(yè)務(wù)流量多大，都為這些業(yè)務(wù)分配一百個節(jié)點(diǎn)，從而降低單節(jié)點(diǎn)宕機(jī)帶來的影響。從本質(zhì)上來看，這些差異化配置通過付出成本和效率來換取高可用，這就存在著權(quán)衡難題。從目前來看，很少有軟件系統(tǒng)的高可用能力能夠?qū)崿F(xiàn) 5 個 9，大部分都還停留在理論上達(dá)到 5 個 9 的狀態(tài)。

4

? ?

經(jīng)典案例的設(shè)計(jì)

接下來，以具體的業(yè)務(wù)場景為例分析典型業(yè)務(wù)的高可用設(shè)計(jì)。

4.1

? ?

手機(jī)掃碼場景

手機(jī)掃碼場景要求在手機(jī)斷網(wǎng)時正常顯示其二維碼。在這個場景里，真正的業(yè)務(wù)鏈路從 POS 鏈路開始，有的 POS 鏈路需要經(jīng)過商戶的處理系統(tǒng)，有的則直接進(jìn)入支付寶自身的業(yè)務(wù)系統(tǒng)。在支付寶端，該鏈路將從一個統(tǒng)一的網(wǎng)關(guān)接入，攜帶著訂單相關(guān)信息，比如商戶 ID 等。此后，鏈路進(jìn)入一個收單系統(tǒng)，由該系統(tǒng)處理這些相關(guān)信息。再往后，鏈路開始進(jìn)入交易系統(tǒng)，通過調(diào)用交易系統(tǒng)的核心模塊完成該業(yè)務(wù)支付。此外，為了實(shí)現(xiàn)掃碼，POS 系統(tǒng)還需要和支付寶簽約以建立授權(quán)關(guān)系，并且同步商戶信息。這個微服務(wù)系統(tǒng)所涵蓋的高可用需求包括：

其一，該系統(tǒng)主要面向線下場景，商家在未獲取現(xiàn)金時不會將商品交給用戶。因此，不可用問題對商家的影響很大，比如用戶不能正常支付。

其二，該系統(tǒng)的一些節(jié)點(diǎn)還需要支撐整個支付寶的業(yè)務(wù)體系，比如會員信息節(jié)點(diǎn)，它需要支持成百上千個與螞蟻森林相同體量的業(yè)務(wù)功能，對可用性的要求非常高。

這意味著，在這個微服務(wù)系統(tǒng)中，不同業(yè)務(wù)對可用性的要求不同，因此需要不同的手段實(shí)現(xiàn)該系統(tǒng)的可用性需求。

4.2

? ?

灰度設(shè)計(jì)

首先，簽約業(yè)務(wù)是異步的，在設(shè)計(jì)時不應(yīng)被納入系統(tǒng)的核心鏈路。另外，簽約服務(wù)需要與網(wǎng)關(guān)和商戶服務(wù)進(jìn)行信息同步，仍可能導(dǎo)致網(wǎng)關(guān)和商戶服務(wù)宕機(jī)，比如修改商戶的鑒權(quán)信息可能使簽約不成功。因此，簽約服務(wù)需要實(shí)現(xiàn)灰度設(shè)計(jì)。

4.3

? ?

異構(gòu)設(shè)計(jì)

其次，如果將一個非常重要的業(yè)務(wù)從鏈路中隔離出來，那么為了處理隔離后的節(jié)點(diǎn)的宕機(jī)事件，就需要一個異構(gòu)設(shè)計(jì)使得當(dāng)其宕機(jī)時整個系統(tǒng)還能繼續(xù)運(yùn)轉(zhuǎn)，包括數(shù)據(jù)存儲方面和計(jì)算能力方面的異構(gòu)。值得一提的是，現(xiàn)在的分布式數(shù)據(jù)庫能夠?qū)崿F(xiàn) RPO 等于 0，使得當(dāng)數(shù)據(jù)出問題時不發(fā)生數(shù)據(jù)丟失，其基本原理就是存儲多個數(shù)據(jù)副本，并且當(dāng)數(shù)據(jù)出現(xiàn)故障時，可以在多個副本間切換，數(shù)據(jù)恢復(fù)速度非常快。

然而，這并不意味著高可用設(shè)計(jì)只需依賴數(shù)據(jù)庫，而不需要額外的容災(zāi)能力。事實(shí)上，這與系統(tǒng)所要求的高可用級別相關(guān)。比如，假設(shè)系統(tǒng)所要求的高可用能力級別為 5 個 9，那么即使數(shù)據(jù)庫僅發(fā)生一次宕機(jī)并且數(shù)據(jù)恢復(fù)失敗，那么就無法實(shí)現(xiàn)所要求的 5 個 9 的高可用能力。高可用設(shè)計(jì)的一個原則是，核心業(yè)務(wù)的設(shè)計(jì)不應(yīng)信任其所依賴的基礎(chǔ)設(shè)施。這樣，為了提高系統(tǒng)高可用能力，就需要實(shí)現(xiàn)應(yīng)用層容災(zāi)。應(yīng)用層的容災(zāi)可能會 FO 到一個數(shù)據(jù)庫中，數(shù)據(jù)庫版本不同，數(shù)據(jù)存儲類型不同，那么二者同時出現(xiàn)故障的概率就會變得更低。因此，應(yīng)用層的容災(zāi)非常重要。

4.4

? ?

防熱點(diǎn)、讀寫分離

在 service mesh 場景下，應(yīng)用層不再需要關(guān)注防熱點(diǎn)、讀寫分離等。幾年前，應(yīng)用層還需要對緩存熱點(diǎn)做特殊處理以建設(shè)高可用能力，比如在一個緩存節(jié)點(diǎn)掛掉時對其進(jìn)行預(yù)熱操作。而現(xiàn)在，大多數(shù)分布式架構(gòu)本身就提供了緩存熱點(diǎn)能力。此外，大多數(shù)分布式數(shù)據(jù)庫本身就使用了讀寫分離架構(gòu)，只需稍加配置就可以將數(shù)據(jù)路由到只讀節(jié)點(diǎn)。這些都是云原生時代帶來的紅利之一。

4.5

? ?

近端

近端在不同場合下可能有不同的名稱。比如，如果將會員信息的全部請求都發(fā)給應(yīng)用層，那么其所需要的集群數(shù)量將會非常龐大。由于會員信息的查詢遵循了較為固定的范式，因此可以將會員信息的查詢功能前置到收單服務(wù)，從而使收單服務(wù)不需要訪問會員信息，而可以直接訪問會員信息所依賴的服務(wù)。這本質(zhì)上也是通過應(yīng)用層設(shè)計(jì)來減小高可用的成本。

總的來說，對于一個給定的業(yè)務(wù)場景，高可用設(shè)計(jì)需要分析它的業(yè)務(wù)特點(diǎn)，可用性的要求，從而設(shè)計(jì)對應(yīng)高可用設(shè)計(jì)的節(jié)點(diǎn)。比如，如何設(shè)計(jì)以查詢功能為主的節(jié)點(diǎn)，特別是當(dāng)其所依賴的數(shù)據(jù)庫不被信任時。在微服務(wù)架構(gòu)中進(jìn)行高可用設(shè)計(jì)時，應(yīng)該針對每個節(jié)點(diǎn)的特征進(jìn)行有針對的設(shè)計(jì)。另外，即使在云原生場景下，也需要通過應(yīng)用層設(shè)計(jì)實(shí)現(xiàn)防抖、業(yè)務(wù)隔離、配置灰度設(shè)計(jì)和應(yīng)用層容災(zāi)。比如，使用 FASS 能夠很容易地實(shí)現(xiàn)系統(tǒng)功能，但當(dāng)系統(tǒng)的可用性要求、業(yè)務(wù)體量增大時，任何一個抖動都可能影響到整個軟件系統(tǒng)的可用能力。高可用設(shè)計(jì)并不存在標(biāo)準(zhǔn)配置。實(shí)際上，高可用設(shè)計(jì)需要根據(jù)業(yè)務(wù)重要性、能力和效率的分層等進(jìn)行分層次的設(shè)計(jì)，最核心業(yè)務(wù)需要通過一些高復(fù)雜度的設(shè)計(jì)來提高它們的可用性。

4.6

? ?

業(yè)務(wù)隔離

線下業(yè)務(wù)和淘寶業(yè)務(wù)實(shí)際上使用同一個版本進(jìn)行應(yīng)用開發(fā)和發(fā)布，它們的隔離僅僅體現(xiàn)在流量和部署層面。比如，它們所使用的交易服務(wù)在開發(fā)層面就是完全相同的，僅僅在部署層面將它們的流量分離到不同的服務(wù)中。這樣，在以業(yè)務(wù)維度做跨節(jié)點(diǎn)的流量綁定時，就需要將幾個服務(wù)及其節(jié)點(diǎn)圈出來進(jìn)行分流。

首先，需要識別某流量是否與該業(yè)務(wù)相關(guān)；其次，需要將該流量接入到某個特定區(qū)域中；然后，該區(qū)域還需要將所有與完成該業(yè)務(wù)相關(guān)的節(jié)點(diǎn)都包含進(jìn)來。這種設(shè)計(jì)需要一定的先驗(yàn)知識，因此需要定義一些元信息，比如流量入口。在確定流量入口后所有和其相關(guān)的后續(xù)處理節(jié)點(diǎn)都應(yīng)被打標(biāo)或者以其它方式圈定起來。門面系統(tǒng)后對應(yīng)著內(nèi)部系統(tǒng)，包括一系列 Http 組。在定義好這些后，某個組件會在流量接入后識別門面系統(tǒng)，進(jìn)而找到該門面系統(tǒng)對應(yīng)的圈定區(qū)域，也就是內(nèi)部系統(tǒng)，從而完成一個整體上的流量綁定過程。

值得一提的是，這并不是微服務(wù)體系下流量綁定的標(biāo)準(zhǔn)配置，而是阿里的應(yīng)用開發(fā)人員和中間件人員提出的業(yè)務(wù)隔離設(shè)計(jì)。隨著上云等措施，這種設(shè)計(jì)逐漸內(nèi)置到基礎(chǔ)設(shè)施中，成為一個典型的業(yè)務(wù)隔離設(shè)計(jì)。

4.7

? ?

防抖設(shè)計(jì)

圖中的業(yè)務(wù)場景對應(yīng)著買家向賣家支付。由于實(shí)際支付時，支付操作后置一段時間并不會引發(fā)大問題，因此大部分系統(tǒng)在實(shí)際運(yùn)行時，買家向賣家支付的錢都不會即時到賬，而需要經(jīng)過一段時間的累積后再批量到賬。本質(zhì)上，這是一種信息流和業(yè)務(wù)流的解耦。從業(yè)務(wù)角度看，錢需要即時從買家流動到賣家，中間還可能有聚合支付等操作。而在實(shí)際運(yùn)行時，系統(tǒng)無需關(guān)注具體的支付細(xì)節(jié)，而只需要通知買家支付成功，通知賣家錢已到賬。在不同處理模式下，資金流和信息流的處理流程可能有很大的不同。

4.8

? ?

防抖設(shè)計(jì)架構(gòu)抽象

在具體設(shè)計(jì)時，一個邏輯支付處理單元實(shí)際上被拆分成信息處理單元和資金處理單元。中間的 T+x 表示，信息處理單元和資金處理單元間可以存在一個較大的時間差。在信息受理時，即使不需要進(jìn)行實(shí)際的資金流處理，也需要明確買家和賣家信息，而這些信息來自會員系統(tǒng)和商家系統(tǒng)。

那么，當(dāng)會員系統(tǒng)宕機(jī)時，為了使防抖設(shè)計(jì)機(jī)制可用，就需要異構(gòu)的設(shè)計(jì)。實(shí)際資金流處理所依賴的數(shù)據(jù)需要異構(gòu)出一份以供信息流處理，而不是直接用原來的數(shù)據(jù)。異構(gòu)設(shè)計(jì)使得一份數(shù)據(jù)宕機(jī)不影響整個系統(tǒng)功能的正常運(yùn)行。除了數(shù)據(jù)需要進(jìn)行異構(gòu)處理外，一些計(jì)算規(guī)則也需要遷移到信息流處理中，比如商家的店鋪信息處理等。數(shù)據(jù)和計(jì)算規(guī)則的異構(gòu)使我們能夠?qū)崿F(xiàn)解耦，這種設(shè)計(jì)對應(yīng)著一個標(biāo)準(zhǔn)化的范式。幾乎在所有的業(yè)務(wù)場景都能看到這種設(shè)計(jì)。

總的來說，將業(yè)務(wù)最頂端跟信息流相關(guān)的邏輯抽象出來，并且將這部分邏輯所依賴的數(shù)據(jù)異構(gòu)一部分出來，這就能夠使所有的業(yè)務(wù)實(shí)現(xiàn)不依賴于實(shí)際的處理邏輯，從而保證底層的任意一個節(jié)點(diǎn)發(fā)生宕機(jī)時整個系統(tǒng)的可用性。

4.9

? ?

防抖設(shè)計(jì)架構(gòu)延展

理論上，這種架構(gòu)設(shè)計(jì)是可以擴(kuò)展的。信息流處理和業(yè)務(wù)流處理被解耦后就可以被部署在不同的節(jié)點(diǎn)中。比如，在國際支付時可以將信息流處理邏輯部署在支付方所在的區(qū)域中，這就使得支付操作不需要依賴原來的處理邏輯所部署的機(jī)房。需要注意的是，在將數(shù)據(jù)部署在其它機(jī)房時，通常需要一些額外的處理，比如信息安全等內(nèi)容。

4.10

? ?

配置灰度設(shè)計(jì)

某節(jié)點(diǎn)的配置數(shù)據(jù)發(fā)生變更可能影響其它與之相關(guān)的節(jié)點(diǎn)，因此這就需要對這些節(jié)點(diǎn)做灰度設(shè)計(jì)，帶來了一個鏈路級的配置灰度設(shè)計(jì)問題。

分布式事務(wù)中通常有一個發(fā)起者和多個參與者。發(fā)起者發(fā)起一個預(yù)提交，在所有參與者確認(rèn)后，該任務(wù)才被執(zhí)行。這對應(yīng)著一個二階段確認(rèn)過程，即先發(fā)起、再確認(rèn)、后執(zhí)行。配置灰度設(shè)計(jì)和分布式事務(wù)處理非常類似。首先，簽約節(jié)點(diǎn)發(fā)起一個灰度設(shè)計(jì)，此后和簽約節(jié)點(diǎn)相關(guān)的節(jié)點(diǎn)需要參與進(jìn)來，一同完成灰度。假設(shè)灰度的內(nèi)容是某倉庫信息，此時所有參與節(jié)點(diǎn)都需要對本節(jié)點(diǎn)下的相關(guān)數(shù)據(jù)進(jìn)行灰度。在實(shí)際進(jìn)行灰度時，每個節(jié)點(diǎn)實(shí)現(xiàn)灰度的方式可能不同。比如，商家需要修改 DB 數(shù)據(jù)，而會員節(jié)點(diǎn)除了需要修改 DB 數(shù)據(jù)外，還需要修改對應(yīng)節(jié)點(diǎn)中的緩存。需要注意的是，無論每個節(jié)點(diǎn)如何進(jìn)行具體的灰度操作，各個節(jié)點(diǎn)間需要實(shí)現(xiàn)灰度的同進(jìn)同退。

值得注意的是，這是一個最復(fù)雜的配置灰度設(shè)計(jì)，實(shí)際上的灰度設(shè)計(jì)比這個場景要簡單地多。

4.11

? ?

容災(zāi)設(shè)計(jì)

4.12

? ?

狀態(tài)型數(shù)據(jù)和流水型數(shù)據(jù)

螞蟻通常按照特性將數(shù)據(jù)分為狀態(tài)型數(shù)據(jù)和流水型數(shù)據(jù)。所謂流水型數(shù)據(jù)，即每出現(xiàn)一條數(shù)據(jù)都將其存入數(shù)據(jù)庫中。比如，訂單數(shù)據(jù)就是一種流水型數(shù)據(jù)，每出現(xiàn)一條新訂單都被存入數(shù)據(jù)庫。流水型數(shù)據(jù)的大部分業(yè)務(wù)類型是將數(shù)據(jù)插入到數(shù)據(jù)庫。另一種數(shù)據(jù)是狀態(tài)型數(shù)據(jù)，通常可以被修改，并且具有生命周期特征，比如會員信息。

4.13

? ?

狀態(tài)型數(shù)據(jù)的容災(zāi)設(shè)計(jì)

這兩種數(shù)據(jù)在進(jìn)行應(yīng)用層容災(zāi)設(shè)計(jì)時需要不同的處理方式，狀態(tài)型數(shù)據(jù)的容災(zāi)設(shè)計(jì)通常比較困難。比如，會員信息在出現(xiàn)錯誤時通常不能再寫該數(shù)據(jù)，也不能讓該用戶重新注冊一次支付寶。狀態(tài)型數(shù)據(jù)的容災(zāi)設(shè)計(jì)需要以數(shù)據(jù)庫不可靠為前提。數(shù)據(jù)庫通常存在主備庫，這兩個庫通常使用異步復(fù)制的方式來保證兩個庫之間的同步。然而，這種同步通常具有時延特征。當(dāng)主庫宕機(jī)時，如果 FO 庫的版本比較舊，就不能直接將 FO 庫作為主庫，因?yàn)樵瓉淼闹鲙焐弦呀?jīng)有用戶修改的內(nèi)容。如果此時將 FO 庫作為主庫繼續(xù)進(jìn)行修改，那么最終得到的數(shù)據(jù)必然不是用戶所預(yù)期的。一個處理方式是將持續(xù)往黑名單庫里寫差異。

當(dāng)主庫宕機(jī)時，首先將 FO 庫拉起來，此時，這些差異可能使得 FO 庫中某一部分?jǐn)?shù)據(jù)是禁寫的。對用戶信息這樣的業(yè)務(wù)而言，每天只有很少的數(shù)據(jù)會發(fā)生更改，并且用戶信息發(fā)生宕機(jī)的概率很低，因此這種處理帶來的禁寫對業(yè)務(wù)的影響非常小。通過這種方式強(qiáng)一致地寫黑名單庫，能夠近似地實(shí)現(xiàn)無損的容災(zāi)設(shè)計(jì)。回切數(shù)據(jù)庫時也是如此。由于 FO 庫已經(jīng)有很多新的數(shù)據(jù)內(nèi)容，因此在回切數(shù)據(jù)庫時需要將這部分?jǐn)?shù)據(jù) merge 回主庫中。

即使在云原生時代，一個業(yè)務(wù)場景的高可用架構(gòu)設(shè)計(jì)也仍然需要許多操作來共同實(shí)現(xiàn)。未來，這些與業(yè)務(wù)無關(guān)的設(shè)計(jì)可能被組件化地沉淀下來，成為基礎(chǔ)設(shè)施。

5

? ?

未來思考

5.1

? ?

根據(jù)業(yè)務(wù)場景實(shí)現(xiàn)個性化高可用設(shè)計(jì)

高可用設(shè)計(jì)通常是靜態(tài)的，它能夠被內(nèi)嵌到架構(gòu)設(shè)計(jì)中，被內(nèi)嵌到基礎(chǔ)設(shè)施或者中間件中。高可用設(shè)計(jì)應(yīng)根據(jù)業(yè)務(wù)場景實(shí)現(xiàn)個性化設(shè)計(jì)。這要求我們不僅需要關(guān)注系統(tǒng)當(dāng)下的業(yè)務(wù)特點(diǎn)，還需要預(yù)測其未來的業(yè)務(wù)特點(diǎn)，通過各種特性來刻畫該業(yè)務(wù)對用戶的可用性影響。這就需要結(jié)合各種原子手段以實(shí)現(xiàn)業(yè)務(wù)在當(dāng)前階段所需要的高可用能力。未來，可能存在非常智能的系統(tǒng)，能夠使用最低成本刻畫業(yè)務(wù)的當(dāng)前特征，然后自動化地組合一些原子高可用能力最大化系統(tǒng)高可用能力。

5.2

? ?

5 個 9 的高可用設(shè)計(jì)

未來還可能實(shí)現(xiàn) 5 個 9 的高可用。首先，假設(shè)存在一個和螞蟻非常類似但又異構(gòu)的環(huán)境，它們之間完全是去中心化的；其次，這兩個環(huán)境下的數(shù)據(jù)規(guī)則同步應(yīng)該是可舍棄的，能夠?qū)崿F(xiàn) FO 以及全自動的切換；另外，還需要實(shí)現(xiàn)監(jiān)控，監(jiān)控也應(yīng)該是異構(gòu)的，需要有一個外部系統(tǒng)來觀測本系統(tǒng)的行為。

- EOF -

想要加入中生代架構(gòu)群的小伙伴，請?zhí)砑尤汉匣锶?strong>大白的微信

申請備注（姓名+公司+技術(shù)方向）才能通過哦！

阿里技術(shù)精彩文章推薦

往期推薦

深度：揭秘阿里巴巴的客群畫像

多隆：從工程師到阿里巴巴合伙人

阿里技術(shù)專家楚衡：架構(gòu)制圖的工具與方法論

螞蟻集團(tuán)技術(shù)專家山丘：性能優(yōu)化常見壓測模型及優(yōu)缺點(diǎn)

阿里文娛技術(shù)專家戰(zhàn)獒: 領(lǐng)域驅(qū)動設(shè)計(jì)詳解之What, Why, How?

阿里專家馬飛翔：一文讀懂架構(gòu)整潔之道

阿里專家常昊：新人如何上手項(xiàng)目管理？

螞蟻集團(tuán)沈凋墨：Kubernetes-微內(nèi)核的分布式操作系統(tǒng)

阿里合伙人范禹：常掛在阿里技術(shù)人嘴邊的四句土話

阿里技術(shù)專家都鐸：一文搞懂技術(shù)債

支付寶研究員兼OceanBase總架構(gòu)師楊傳輝：我在數(shù)據(jù)庫夢之隊(duì)的十年成長路

阿里技術(shù)專家麒燁：修煉測試基本功

阿里計(jì)算平臺掌門人賈揚(yáng)清：我對人工智能方向的一點(diǎn)淺見

螞蟻資深算法專家周俊：從原理到落地，支付寶如何打造保護(hù)隱私的共享智能？

阿里高級技術(shù)專家簫逸：如何畫好一張架構(gòu)圖？

阿里高級技術(shù)專家張建飛：應(yīng)用架構(gòu)分離業(yè)務(wù)邏輯和技術(shù)細(xì)節(jié)之道

螞蟻科技 Service Mesh 落地實(shí)踐與挑戰(zhàn) | GIAC 實(shí)錄

阿里6年，我的技術(shù)蛻變之路！

螞蟻集團(tuán)涵暢：再啟程，Service Mesh 前路雖長，尤可期許

阿里P9專家右軍：大話軟件質(zhì)量穩(wěn)定性

阿里合伙人程立：阿里15年，我撕掉了身上兩個標(biāo)簽

阿里高工流生 | 云原生時代的 DevOps 之道

阿里高級技術(shù)專家邱小俠：微服務(wù)架構(gòu)的理論基礎(chǔ) - 康威定律

阿里P9專家右軍：以終為始的架構(gòu)設(shè)計(jì)

阿里P8架構(gòu)師：淘寶技術(shù)架構(gòu)從1.0到4.0的架構(gòu)變遷！12頁P(yáng)PT詳解

阿里技術(shù)：如何畫出一張合格的技術(shù)架構(gòu)圖？

螞蟻資深技術(shù)專家王旭：開源項(xiàng)目是如何讓這個世界更安全的？

阿里資深技術(shù)專家崮德：8 個影響我職業(yè)生涯的重要技能

儒梟：我看技術(shù)人的成長路徑

阿里高級技術(shù)專家宋意：平凡人在阿里十年的成長之旅

阿里技術(shù)專家甘盤：淺談雙十一背后的支付寶LDC架構(gòu)和其CAP分析

阿里技術(shù)專家光錐：億級長連網(wǎng)關(guān)的云原生演進(jìn)之路

阿里云原生張羽辰：服務(wù)發(fā)現(xiàn)技術(shù)選型那點(diǎn)事兒

螞蟻研究員玉伯：做一個簡單自由有愛的技術(shù)人

阿里高級技術(shù)專家至簡: Service Mesh 在超大規(guī)模場景下的落地挑戰(zhàn)

阿里巴巴山獵：手把手教你玩轉(zhuǎn)全鏈路監(jiān)控

? ?END ? ?? #架構(gòu)師必備#點(diǎn)分享點(diǎn)點(diǎn)贊點(diǎn)在看

總結(jié)

以上是生活随笔為你收集整理的蚂蚁金服资深技术专家经国：云原生时代微服务的高可用架构设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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