近期讀到騰訊發(fā)布的《商業(yè)銀行核心系統(tǒng)分布式轉(zhuǎn)型白皮書》，書中介紹了銀行核心分布式改造的架構(gòu)路線、關(guān)鍵技術(shù)及最佳實踐等內(nèi)容。結(jié)合自己之前在金融業(yè)的一些體驗，感覺總結(jié)整理的不錯，特分享出來。文中的部分內(nèi)容摘自此白皮書。

1. 背景：分布式選擇成為必然

無論從業(yè)務還是技術(shù)角度，銀行業(yè)都正在完成從“集中式”到“分布式”的轉(zhuǎn)型。其背后是有必然性的，可概括為以下幾個方面：

? 業(yè)務發(fā)展需求

隨著互聯(lián)網(wǎng)技術(shù)和移動支付的快速發(fā)展，銀行的業(yè)務形態(tài)和模式發(fā)生了巨大變化。傳統(tǒng)的集中化核心系統(tǒng)往往難以滿足快速應對市場變化、實時處理大量交易的要求，因此需要進行分布式核心改造。

? 系統(tǒng)性能瓶頸

傳統(tǒng)的集中化核心系統(tǒng)往往存在系統(tǒng)性能瓶頸，無法滿足大規(guī)模用戶同時在線交易、高頻交易的需求。通過分布式核心改造，可以將系統(tǒng)對各項業(yè)務進行分拆和擴展，提高系統(tǒng)的并發(fā)處理能力和吞吐量。

? 系統(tǒng)可擴展性不足

傳統(tǒng)的集中化核心系統(tǒng)往往難以實現(xiàn)快速靈活的業(yè)務拓展和系統(tǒng)擴展。通過分布式核心改造，可以將不同的業(yè)務模塊分布在不同的服務器上，實現(xiàn)業(yè)務功能的獨立擴展，提高系統(tǒng)的可擴展性和靈活性。

? 系統(tǒng)穩(wěn)定性和安全性

傳統(tǒng)的集中化核心系統(tǒng)往往存在單點故障風險，一旦發(fā)生故障或被攻擊，將對銀行的正常運營造成嚴重影響。通過分布式核心改造，可以將系統(tǒng)分布在多個服務器上，實現(xiàn)故障隔離和負載均衡，提高系統(tǒng)的穩(wěn)定性和安全性。

? 技術(shù)創(chuàng)新驅(qū)動

現(xiàn)代分布式技術(shù)和云計算技術(shù)的快速發(fā)展為銀行分布式核心改造提供了技術(shù)支持。通過采用分布式數(shù)據(jù)庫、分布式計算等技術(shù)手段，可以實現(xiàn)銀行業(yè)務的高效處理和大規(guī)模擴展，進而提升銀行的競爭力和用戶體驗。

2. 方法：建設模式與整體架構(gòu)

1).建設模式

銀行核心分布式改造，可分為兩種模式：一是技術(shù)平移，二是規(guī)劃重建。

• 技術(shù)平移

這是科技部門內(nèi)部能夠閉環(huán)的模式，在保持功能基本不變的情況下，將應用遷移到分布式平臺或?qū)眠m配到國產(chǎn)數(shù)據(jù)庫或云平臺上。技術(shù)平移首先要確定平移目標，如平移到國產(chǎn)化的云、操作系統(tǒng)、數(shù)據(jù)庫、中間件等等。其次是要確定平移的路徑，比如優(yōu)先使用產(chǎn)品、定價等模塊做試點，再平移核算，形成完善的平移經(jīng)驗和工序后，最后是進行存貸模塊的平移。

• 規(guī)劃重建

這是比較徹底的一種模式，需要聯(lián)合業(yè)務部門，結(jié)合全行業(yè)務發(fā)展戰(zhàn)略，整合業(yè)務需求，重新設計建設新一代核心系統(tǒng)。規(guī)劃重建整體上比技術(shù)平移更具挑戰(zhàn)，不同銀行也都根據(jù)自身特點走出一條適合自己道路。

業(yè)務建模

業(yè)務建模是最早由建行聯(lián)合眾多業(yè)內(nèi)專家實踐產(chǎn)生的需求分析與統(tǒng)一建模的方法論，隨后在幾家國有大行的新核心建設中逐步豐富延展。IT工藝是與之配套的新核心建設方法論，其能承接業(yè)務建模的產(chǎn)出，用業(yè)務模型指導微服務模型落地，用識別、定義、分解等標準工序拆解復雜架構(gòu)，最終基于構(gòu)件實現(xiàn)松耦合的組裝和編排，在復雜項目設計與建設中發(fā)揮了重要作用。

2).整體架構(gòu)

圖片

從核心系統(tǒng)整體架構(gòu)上，可分為七大部分內(nèi)容。

• 底層是IaaS云平臺，中間是PaaS云原生平臺，上層是SaaS核心應用領(lǐng)域，左側(cè)為研發(fā)效能體系和混沌測試體系，右側(cè)為智能運維體系和安全體系。上圖七塊內(nèi)容形成新核心所需的整體能力框架。
• SaaS層包括了銀行核心系統(tǒng)的應用域，如：存貸、支付結(jié)算、銀行卡、核算及公共服務等。所需的能力中心和7*24等公共機制。分布式技術(shù)組件用于封裝分布式底層技術(shù)，負責對上層應用模塊屏蔽產(chǎn)品差異與技術(shù)復雜度，同時連接著下層PaaS平臺的各項能力。其中，一部分與云廠商的產(chǎn)品存在一定重疊，如：單元化能力組件、分布式事務、聚合查詢組件、服務調(diào)用代理等。在實際落地過程中需要明確雙方邊界，進行有效的整合與聯(lián)動形成一體化的、穩(wěn)定的技術(shù)平臺底座。
• PaaS層以云原生容器平臺、分布式數(shù)據(jù)庫、分布式消息隊列、分布式緩存、微服務平臺等中間件為主。
• IaaS層主要包括了云平臺的計算、存儲、網(wǎng)絡、資源編排、多云管理和安全能力。
• 研發(fā)效能體系中包括了傳統(tǒng)的Devops體系，同時還集成了項目管理和質(zhì)量管控體系。以需求為抓手，貫穿設計、開發(fā)、測試、安全、發(fā)布、生產(chǎn)全生命周期管理，每個環(huán)節(jié)形成有效的反饋機制，確保在每一輪迭代都能有效量化生產(chǎn)數(shù)據(jù)，實現(xiàn)精益管理。

3. 路線：微服務與單元化

對于核心提供的分布式改造，有兩種技術(shù)路線選擇：一是微服務、二是單元化。微服務和單元化之間并不是一個包含關(guān)系，而是一種加強關(guān)系：單元化是微服務架構(gòu)在宏觀架構(gòu)層面的增強，而微服務是單元化架構(gòu)在微觀機制層面的支撐。我們可以從多方面對比兩者的差異。

圖片

在若干核心的設計要點上，兩者均存在一些差異，可以從下面六個方面進行對比。

• 數(shù)據(jù)切分策略上，需考慮幾個問題：一是按什么維度進行何種拆分，二是采用什么存儲方式，三是如何進行擴容，四是需處理那些數(shù)據(jù)。
• 技術(shù)架構(gòu)標準上，需考慮幾個問題：一是交易調(diào)用處理策略，二是分布式事務策略，三是聚合查詢策略，四是灰度發(fā)布策略。
• 服務實現(xiàn)策略上，需考慮幾個問題：一是服務顆粒度的選擇，二是落地實施工藝，三是技術(shù)組件。
• 業(yè)務連續(xù)性上，需考慮高可用架構(gòu)及容災切換策略。
• 研發(fā)效能上，將研發(fā)、測試、發(fā)布環(huán)節(jié)打通，形成一體化的持續(xù)跟蹤、反饋、提升體系。
• 分布式運維上，一改傳統(tǒng)運維方式，突出發(fā)現(xiàn)隔離能力，并可引入大數(shù)據(jù)與AI提高分布式下的分析預測能力。

圖片

4. 路線：微服務架構(gòu)

1).基本概念

微服務架構(gòu)是一種軟件架構(gòu)風格，其中應用程序被拆分為一組小型、松耦合的、自治的服務。每個服務都可以獨立地進行開發(fā)、部署和擴展，并通過輕量級的通信機制（如HTTP、消息隊列等）進行互相通信。微服務架構(gòu)的核心原則是將復雜的單體應用程序拆分成更小、更可管理的部件，每個部件專注于完成一個特定的業(yè)務功能。這些服務旨在可以獨立開發(fā)、測試、部署和擴展，以滿足不同的需求和快速變化的業(yè)務要求。

? 架構(gòu)特點

• 松耦合：每個服務都是獨立的，可以獨立部署和擴展，沒有共享的數(shù)據(jù)庫或技術(shù)限制。
• 獨立自治：每個服務具有自己的代碼庫、數(shù)據(jù)庫和團隊，可以獨立地進行開發(fā)和管理。
• 服務邊界明確：每個服務都定義了明確的業(yè)務邊界，可以專注于解決特定的業(yè)務問題。
• 分布式：不同的服務可以運行在不同的服務器或容器中，并通過網(wǎng)絡進行通信。
• 彈性和可伸縮性：由于每個服務都是獨立的，可以根據(jù)需求進行單獨的擴展，提高系統(tǒng)整體的彈性和可伸縮性。
• 高可用性：通過服務復制和負載均衡等機制，提高系統(tǒng)的可用性，一個服務的故障不會影響整個系統(tǒng)的正常運行。

? 銀行微服務特點

微服務架構(gòu)可以帶來像應用解耦、獨立自治等諸多優(yōu)勢，但微服務并沒有解決所有問題，如服務拆分后的服務編排問題、分布式事務問題，或者數(shù)據(jù)拆分后的聚合查詢問題等。在銀行核心如此嚴謹?shù)念I(lǐng)域，微服務的使用一定要綜合考慮各種場景，充分聽取多方意見，從中找到平衡點。如果一味從理論角度推進，往往得不償失?？紤]到微服務顆粒過細所帶來的整體復雜度，通常在設計時會按照標準的業(yè)務領(lǐng)域進行組件的設計和開發(fā)，但在發(fā)布時會將多個相關(guān)的組件進行合并發(fā)布。以此來減少組件間的調(diào)用鏈路，提供系統(tǒng)穩(wěn)定性和性能，簡化運維復雜度，包括減少分布式事務的產(chǎn)生。

2).設計要點

? 數(shù)據(jù)切分策略

• 維度字段：數(shù)據(jù)切分維度主要以客戶號Hash和List兩種方式為主，可分別從分布式事務出現(xiàn)概率、數(shù)據(jù)分布均勻程度、訪問壓力的均勻程度、擴容的難易度等幾個維度結(jié)合核心業(yè)務特征來確定?？蛻籼柌⑽次ㄒ贿x擇，只是在核心業(yè)務場景中單客戶的交易場景居多，為避免產(chǎn)生分布式事務所以大多以客戶號作為數(shù)據(jù)分片的維度。當然也有按地域和機構(gòu)的維度來切分數(shù)據(jù)的，這種切分方式一定程度上解決了核心場景中非客戶維度的查詢問題，但會導致潛在的數(shù)據(jù)分布不均以及訪問不均的風險。
• 聚合查詢：針對數(shù)據(jù)分散之后帶來的聚合查詢問題，業(yè)界有不同的技術(shù)手段來處理，比如把相關(guān)數(shù)據(jù)同步到聚合庫或搜索引擎，或者采用分布式數(shù)據(jù)庫產(chǎn)品自帶的AP引擎進行處理。
• 擴容問題：設計切分策略時需要同步考慮未來的擴容策略，針對微服務架構(gòu)路線，可直接采用分布式數(shù)據(jù)庫自身的擴容能力實現(xiàn)數(shù)據(jù)層的擴容。無論用哪種方案原則都是在擴容時要盡可能的減少數(shù)據(jù)遷移的規(guī)模。在銀行核心場景中，我們建議充分評估未來業(yè)務增長量，結(jié)合單個物理分片能承載的業(yè)務量基線，評估能滿足未來5年的規(guī)模容量，盡可能避免數(shù)據(jù)遷移場景的產(chǎn)生。

? 服務交互方式

技術(shù)標準主要以SpringCloud微服務體系的標準為主，服務注冊和發(fā)現(xiàn)模型是目前分布式系統(tǒng)最主流的模塊交互模式。應用實例在啟動時均會向注冊中心提交自身信息，而注冊中心會維護一個全量的服務目錄，并下推到所有消費方。服務消費方通過微服務提供的負載均衡組件和服務調(diào)用組件實現(xiàn)對目標服務的尋址與點對點的調(diào)用能力。這個過程中，注冊中心作為非關(guān)鍵交易路徑提供服務，提升了該模型的整體穩(wěn)定性。負載均衡算法需要支持主流的幾種策略，包括：隨機、輪詢、最小連接數(shù)等。

? 分布式事務

分布式事務是集中式系統(tǒng)微服務化之后不可避免的問題，在金融領(lǐng)域顯得格外重要。然而目前為止在微服務體系中尚未統(tǒng)一分布式事務的處理標準。其產(chǎn)生的原因不同，對應也有不同解法。

圖片

分布式事務最好的處理方式是“恰好不用解決”。即通過合理的應用規(guī)劃和數(shù)據(jù)切分來有效地避免分布式事務的產(chǎn)生。所有的分布式事務處理機制都會帶來不同程度的損耗，無論是在應用側(cè)實現(xiàn)還是數(shù)據(jù)庫側(cè)實現(xiàn)。在數(shù)據(jù)庫性能和容量允許的情況下，也會考慮將相關(guān)微服務組件對應的數(shù)據(jù)庫進行合并，來減少因為數(shù)據(jù)拆分而產(chǎn)生的分布式事務，應用層也會考慮將關(guān)聯(lián)的服務組件合并成一個微服務組件進行發(fā)布，以減少因為應用拆分而產(chǎn)生的分布式事務。

? 擴容策略

擴容可分為應用擴容與數(shù)據(jù)庫擴容。在微服務架構(gòu)下，因為有注冊中心的存在，新的應用實例在啟動時會自動注冊到注冊中心，注冊中心會更新服務目錄并推送到服務消費方，隨后消費方在新的服務目錄中負載時就會將一部分流量隨機到新的實例上，以此來實現(xiàn)應用集群的擴容。對于數(shù)據(jù)庫擴容，則基本依托分布式數(shù)據(jù)庫能力實現(xiàn)。

? 高可用策略

在同城兩個數(shù)據(jù)中心中，標準架構(gòu)中數(shù)據(jù)庫采用分布式實例，對上層應用屏蔽底層數(shù)據(jù)庫結(jié)構(gòu)，應用只需連接本單元的數(shù)據(jù)庫代理進行訪問。數(shù)據(jù)主副本都在主中心部署，應用在兩個中心中分別部署。

圖片

流量通過頂層接入，經(jīng)過 DNS 到中心內(nèi)負載均衡服務再到微服務網(wǎng)關(guān)，經(jīng)過鑒權(quán)、限流等一些列檢測后進到微服務業(yè)務集群，處理時兩個中心的應用都連接本機房的數(shù)據(jù)庫代理進行訪問數(shù)據(jù)，但在數(shù)據(jù)庫代理這一層會根據(jù)路由算法計算客戶所在的數(shù)據(jù)主備位置，并發(fā)起轉(zhuǎn)發(fā)，這個過程中同城機房的請求將出現(xiàn)橫向流量訪問主中心的數(shù)據(jù)主本，這個過程應用是不可見的，因為分布式數(shù)據(jù)庫對上屏蔽了底層的數(shù)據(jù)庫架構(gòu)和數(shù)據(jù)路由。以此實現(xiàn)同城兩個數(shù)據(jù)中心同時處理業(yè)務請求的雙活架構(gòu)。當下基礎(chǔ)設施在同城之間的數(shù)據(jù)傳輸和穩(wěn)定性已經(jīng)非常成熟，對于大多數(shù)系統(tǒng)組建這樣的分布式架構(gòu)是完全沒有問題的。只有在兩個機房間超過一定距離，或延時過高時才需要考慮橫向流量的治理問題，那時單元化架構(gòu)是一種好的解決方案。

異地容災上，由于在分布式應用系統(tǒng)中，應用的無狀態(tài)屬性使得擴容和遷移都變得方便許多，我們只需要考慮有狀態(tài)服務，站在核心系統(tǒng)視角主要是數(shù)據(jù)庫。數(shù)據(jù)庫的 RTO 和 RPO 是整個核心做異地切換的主要關(guān)鍵指標。在大型復雜的銀行核心系統(tǒng)中，會涉及到多個業(yè)務數(shù)據(jù)庫，且每個數(shù)據(jù)庫下又會有多個數(shù)據(jù)分片，由于異地間的數(shù)據(jù)傳輸是異步模式，其切換過程比同城切換要復雜許多，會涉及網(wǎng)絡狀況的判斷，數(shù)據(jù)補償與校驗等。

圖片

當數(shù)據(jù)庫切換完成后，容災中心的應用集群連到切換后的數(shù)據(jù)庫，隨后啟動內(nèi)部校驗，確認無誤后，在全局負載均衡服務（GSLB）中將流量指向異地的容災中心，實現(xiàn)地域級故障的業(yè)務連續(xù)性保障能力。整體異地容災切換的流程極為復雜，且與客戶的實際運維環(huán)境有關(guān)。

5. 路線：單元化架構(gòu)

1).基本概念

單元化，通過把一部分計算資源和一部分數(shù)據(jù)資源進行邏輯上的綁定，形成一個標準化的處理單元。我們將一個大型系統(tǒng)拆解成多個標準的處理單元，每個處理單元具備完整的業(yè)務能力，但只處理全量數(shù)據(jù)中的一部分，簡單理解一個單元就相當于一個小分行。單元化架構(gòu)因其學習成本和實施成本較高，比較適合體量相對較大或有異地多活規(guī)劃的銀行，需要結(jié)合具體銀行客戶在賬戶數(shù)、預算、自主研發(fā)能力、業(yè)務連續(xù)性要求、異地多活規(guī)劃等方面來綜合考慮。單元化架構(gòu)是銀行核心分布式轉(zhuǎn)型的一種重要方向，但不是唯一的技術(shù)方向。

單元化與微服務區(qū)別

標準微服務架構(gòu)默認不對跨中心流量進行治理，其對雙活兩個機房之間的距離和延時有一定要求。假設兩個異地機房，沒有單元化的微服務架構(gòu)中，應用在訪問數(shù)據(jù)庫時會存在異地間的數(shù)據(jù)訪問，因為計算層的負載是無狀態(tài)的，而數(shù)據(jù)的主本是固定在某一機房的，應用跨異地訪問數(shù)據(jù)時，其穩(wěn)定性和時延是無法保證核心系統(tǒng)正常運行的，也就是微服務架構(gòu)在不做改進的情況下較難適應未來異地多活的場景。這是標準微服務架構(gòu)和單元化架構(gòu)之間較大的區(qū)別之一。

2).設計要點

? 數(shù)據(jù)切分策略

單元化架構(gòu)下，數(shù)據(jù)分片的維度、分布規(guī)則都與微服務架構(gòu)相似，主要以客戶號 Hash 和 List 兩種方式為主。同樣需要考慮分布式事務出現(xiàn)概率、數(shù)據(jù)分布均勻程度、訪問壓力的均勻程度、擴容的難易度等幾個方面。不同的是單元化架構(gòu)多以應用側(cè)主導數(shù)據(jù)分片策略及路由策略。這種方式能擺脫對分布式數(shù)據(jù)庫或中間件產(chǎn)品的依賴，靈活可控是單元化架構(gòu)的重要優(yōu)勢。

? 服務交互方式

單元化架構(gòu)下交易處理策略以注冊發(fā)現(xiàn)體系為基礎(chǔ)，但在調(diào)用與負載時需要遵循以單元維度和就近調(diào)用原則，即：所有路由均需要判斷單元維度，識別單元內(nèi)調(diào)用還是跨單元調(diào)用，對于相同服務的調(diào)用順序為：優(yōu)先單元內(nèi)調(diào)用，其次本中心調(diào)用，最后同城中心調(diào)用。

單元化架構(gòu)會要求所有應用在往注冊中心注冊時需要帶上自身所在單元的標記信息，同時微服務之間在調(diào)用時需要先根據(jù)單元標記過濾目標服務的實例，確保在指定單元的服務實例之間進行負載均衡算法。這種根據(jù)單元標記進行路由和目標尋址的邏輯在標準微服務架構(gòu)中是不存在的。

? 分布式事務

同“微服務”的處理機制一致

? 擴容策略

在分布式系統(tǒng)中，應用的無狀態(tài)化讓計算資源的擴容變得容易，但在銀行核心場景中就顯得不規(guī)范和不受控，而單元化架構(gòu)則提供了一種分布式系統(tǒng)下計算和數(shù)據(jù)資源擴容的標準規(guī)范。針對數(shù)據(jù)層的擴容，在單元化架構(gòu)中會將全量數(shù)據(jù)分為若干份，每一份稱為一個邏輯分片，然后建立邏輯分片到物理分片和單元的映射關(guān)系。擴容時，首先加入新的物理分片，再將指定邏輯分片遷移到新的物理分片中，最后更新邏輯分片到物理分片的映射關(guān)系。這個擴容的邏輯通常是由應用側(cè)結(jié)合數(shù)據(jù)遷移工具來做定制化開發(fā)，也可以通過分布式數(shù)據(jù)庫的擴容功能實現(xiàn)。在核心場景中，原則上要盡可能減少數(shù)據(jù)層的擴容，其次是擴容時要盡可能減少數(shù)據(jù)遷移的規(guī)模。

圖片

舉例：假設以客戶維度切分全量數(shù)據(jù)，每個邏輯分片中存放著1萬客戶數(shù)據(jù)?，F(xiàn)在有兩個單元，每個單元中各一個物理分片，每個物理分片中有32個邏輯分片，也就是一個單元中有32萬客戶數(shù)據(jù)。其中1號邏輯分片原本是在1單元的1號物理分片中，由于識別到其為熱點分片，現(xiàn)要將其遷移至一個新的3號單元的3號物理分片。那么首先要將1號邏輯分片中的所有數(shù)據(jù)遷移至3號物理分片，再修改1號邏輯分片到3號物理分片的映射關(guān)系以及1號邏輯分片到3號單元的映射關(guān)系。當更新生效后，1號邏輯分片中的客戶再發(fā)起交易時，網(wǎng)關(guān)就會將其路由到3號單元，其中的應用會從3號物理分片中獲取數(shù)據(jù)進行處理。通過這種方式解決擴容問題。

? 高可用策略

在單元化下的業(yè)務連續(xù)性，通過設計“互備單元表”來建立兩個單元間的互備關(guān)系。當其中一方出現(xiàn)故障時，通過更新狀態(tài)，來指向其互備單元ID從而進行路由調(diào)整。實現(xiàn)單元間互備要求單元的數(shù)據(jù)庫副本需要放置在對方單元中，當發(fā)生切換時，數(shù)據(jù)庫會將對方單元下的副本調(diào)整為主本。

圖片

如圖，請求通過全局負載服務進入到兩個機房，機房內(nèi)部通過負載均衡服務轉(zhuǎn)發(fā)到本中心的微服務網(wǎng)關(guān)集群，在網(wǎng)關(guān)這一層識別請求對應的單元和路由信息，轉(zhuǎn)發(fā)到指定單元處理。當單元1發(fā)生故障時，停用單元1的流量，并獲取單元1對應的互備單元信息（單元5），等待數(shù)據(jù)庫主備切換完成，更新全局路由將流量轉(zhuǎn)發(fā)至單元5。此時單元5除了承載自身業(yè)務流量還會承載單元1的業(yè)務流量。單元切換的指標絕大部分情況下取決于數(shù)據(jù)庫的RPO和RTO。回切過程類似，先關(guān)停單元1的流量，執(zhí)行主備切換，讓主庫回到原單元1下，調(diào)整網(wǎng)關(guān)層路由回到單元1。

與微服務的區(qū)別

單元化架構(gòu)在同城高可用設計上與標準微服務架構(gòu)有所不同，微服務架構(gòu)因為沒有單元概念，在故障發(fā)生時是直接將整個數(shù)據(jù)庫切到同城，再切換GSLB的流量。而單元化架構(gòu)則是以單元維度進行切換，雖然最終效果是一樣的，但是內(nèi)部運作機制不同，切換控制的顆粒度也不同。

3).示例：騰訊銀行單元化架構(gòu)

騰訊單元化架構(gòu)是一種針對銀行分布式核心系統(tǒng)技術(shù)架構(gòu)的體系化、分層次、分領(lǐng)域的架構(gòu)思想。接入層負責接收流量、識別流量、轉(zhuǎn)發(fā)流量。識別后的流量被轉(zhuǎn)發(fā)至應用層對應單元處理，單元默認按照客戶維度拆分，單客戶交易實現(xiàn)單元內(nèi)閉環(huán)處理?？缈蛻艚灰状嬖谝欢ū壤目鐔卧獏f(xié)同處理。數(shù)據(jù)默認被分為64份，被均勻放置在若干個單元內(nèi)?？赏ㄟ^灰度機制將指定標簽的客戶放置在灰度單元實現(xiàn)生產(chǎn)灰度運行或驗證。其中：接入單元(ADU)負責接入接出能力、標準處理單元(SDU)負責業(yè)務處理能力、本地單元(LDU)和同城單元(RDU)分別用于提供單AZ共享服務能力和同城共享服務能力、以及在異地多活架構(gòu)中會涉及的全局類型服務則由全局單元(GDU)提供。