1. 前言

嚴(yán)選在前期發(fā)展過程中，為了快速交付需求，絕大部分系統(tǒng)采用的都是單體架構(gòu)，主站商城也不例外。

隨著業(yè)務(wù)復(fù)雜度的不斷攀升，才逐步開始進(jìn)行業(yè)務(wù)拆分，由各個(gè)業(yè)務(wù)團(tuán)隊(duì)(商城、渠道以及倉(cāng)配等等)在各自業(yè)務(wù)域內(nèi)推動(dòng)服務(wù)化改造，所在的主站商城業(yè)務(wù)團(tuán)隊(duì)隨之相繼孵化出交易中心、促銷中心以及用戶中心等等業(yè)務(wù)中心。

但是各業(yè)務(wù)中心DB資源共用的局面一直未得到改善，導(dǎo)致各業(yè)務(wù)中心數(shù)據(jù)持續(xù)處于裸奔狀態(tài)，業(yè)務(wù)系統(tǒng)穩(wěn)定性也大打折扣。

交易作為其中的一員，在經(jīng)歷了20-21年平臺(tái)化改造的基礎(chǔ)之后，通過業(yè)務(wù)抽象使得交易中心的平臺(tái)化能力更加的內(nèi)聚和穩(wěn)定，故而我們決定乘勝追擊進(jìn)行交易DB資源獨(dú)立拆解。

本文主要介紹了在當(dāng)下的業(yè)務(wù)背景下存在挑戰(zhàn)以及面對(duì)挑戰(zhàn)的應(yīng)對(duì)之法，最后詳細(xì)介紹了基礎(chǔ)保障工作的落地和核心獨(dú)立流程的組織串聯(lián)。

2. 業(yè)務(wù)背景

嚴(yán)選業(yè)務(wù)發(fā)展初期，為了支撐業(yè)務(wù)的快速發(fā)展，采用集中式架構(gòu)和開發(fā)模式，上圖所示為嚴(yán)選交易的架構(gòu)演進(jìn)路線，在早期，交易不僅僅業(yè)務(wù)耦合在商城中，且商城業(yè)務(wù)之間共享DDB集群。

截止到21年，交易借助業(yè)務(wù)抽象、架構(gòu)分層以及標(biāo)準(zhǔn)化的思想逐步向中臺(tái)化架構(gòu)方向演進(jìn)，但是訂單操作等核心業(yè)務(wù)依然保留在交易前臺(tái)業(yè)務(wù)中，導(dǎo)致需求迭代成本居高不下，代碼嚴(yán)重腐化。同時(shí)商城中各業(yè)務(wù)的DDB資源利用率各不相同，出現(xiàn)能力過剩和瓶頸凸顯兩極分化的局面，亟需各業(yè)務(wù)進(jìn)行邊界治理。

邊界治理的核心難點(diǎn)之一就是如何做好穩(wěn)定性保障，因?yàn)樯婕暗侥芰w移以及內(nèi)外部依賴改造，如何確保改造范圍的完整性、準(zhǔn)確性以及平滑性，這與系統(tǒng)的穩(wěn)定性息息相關(guān)。

以交易能力遷移為例，核心交易能力累計(jì)20+，能力依賴接口1000+，涉及30+表，因此在基于交易核心能力高度頻繁使用的前提下，采取了先完成交易能力收歸，再進(jìn)行交易DB獨(dú)立的執(zhí)行策略， 在22年初完成了全量交易能力的遷移，基于這個(gè)背景條件之下，故而開展交易DB獨(dú)立遷移工作。

3. 面臨的挑戰(zhàn)

在基于交易DB和商城DB共享的背景之下，需要達(dá)成交易DB獨(dú)立于商城DB的核心目標(biāo)，而目標(biāo)的達(dá)成涉及交易DB遷移獨(dú)立問題，結(jié)合交易業(yè)務(wù)場(chǎng)景的特殊性，交易DB作為核心業(yè)務(wù)的強(qiáng)依賴方，任何變動(dòng)行為都有可能觸達(dá)線上用戶感知，故而這對(duì)我們提出了極大的挑戰(zhàn)，確保對(duì)用戶的影響最小，避免由于遷移獨(dú)立引發(fā)一系列連帶負(fù)面影響（諸如: 資損、客訴等問題產(chǎn)生），主要表現(xiàn)為3個(gè)方面，交易前用戶無法進(jìn)行交易行為、交易中用戶交易行為被阻塞中斷、交易后交易數(shù)據(jù)前后不一致。可以簡(jiǎn)單概括總結(jié)為對(duì)數(shù)據(jù)一致性和平滑遷移的保障:

• 數(shù)據(jù)一致性保障

• 數(shù)據(jù)不丟失：無論是切換到目標(biāo)數(shù)據(jù)庫(kù)或者回切回源數(shù)據(jù)庫(kù)，要確保沒有數(shù)據(jù)丟失；
• 不產(chǎn)生臟數(shù)據(jù)：需要保障同一筆訂單數(shù)據(jù)在新數(shù)據(jù)庫(kù)和老數(shù)據(jù)庫(kù)之間保持一致。

• 平滑遷移保障
• 數(shù)據(jù)源切換平滑：在進(jìn)行新老數(shù)據(jù)庫(kù)切換過程中保證盡可能平滑切換；
• 業(yè)務(wù)切換平滑：需要確保在切換到新數(shù)據(jù)庫(kù)的過程中受影響用戶范圍以及業(yè)務(wù)場(chǎng)景最少。

3.1 挑戰(zhàn)：數(shù)據(jù)一致性保障

在數(shù)據(jù)一致性保障方面，主要是從兩個(gè)方面入手，分別是數(shù)據(jù)遷移工具和業(yè)務(wù)切換方案的選擇來確保，通過數(shù)據(jù)遷移工具來達(dá)成源數(shù)據(jù)庫(kù)和目標(biāo)數(shù)據(jù)庫(kù)之間的數(shù)據(jù)同步，確保沒有數(shù)據(jù)丟失現(xiàn)象產(chǎn)生，以及業(yè)務(wù)切換方案的制定，防止遷移過程中臟數(shù)據(jù)的引入。

3.1.1 遷移工具

3.1.1.1 杭研NDC

數(shù)據(jù)同步總體分為離線和實(shí)時(shí)兩類，業(yè)內(nèi)常見的離線數(shù)據(jù)同步方案有三種: Sqoop、DataX以及Kettle，實(shí)時(shí)數(shù)據(jù)同步主要有Canal、Otter以及杭研自研的NDC。而我們的業(yè)務(wù)場(chǎng)景決定了需要采用實(shí)時(shí)同步方案，在最終方案方案選型上采用了NDC（Netease Data Canal）。它是網(wǎng)易自研的一套集數(shù)據(jù)遷移、數(shù)據(jù)訂閱、數(shù)據(jù)實(shí)時(shí)同步、數(shù)據(jù)校驗(yàn)于一體的數(shù)據(jù)傳輸服務(wù)。在支持 0 -> 1 全量數(shù)據(jù)遷移的同時(shí)，也可以很好的支持從1 ->1.1 增量同步，更為重要的是可以更好的支持DDB（目前NDC同步功能的源端可支持MySQL、DDB、Oracle三種類型，同步功能的目標(biāo)端端可支持MySQL、DDB、Oracle， 交易業(yè)務(wù)全量使用DDB作為存儲(chǔ)依賴）。

3.1.1.2 架構(gòu)簡(jiǎn)介

架構(gòu)上NDC大致可以分為源端系統(tǒng)、NDC集群和目標(biāo)端系統(tǒng)三部分。NDC拉取源端系統(tǒng)的全量或增量數(shù)據(jù)，經(jīng)過轉(zhuǎn)化和過濾寫入目標(biāo)系統(tǒng)之中。架構(gòu)圖如下：

3.1.1.3 注意事項(xiàng)

NDC的回放的流程大致可以理解為與源端建立連接，拉取源端binlog，解析binlog，并對(duì)目標(biāo)端進(jìn)行相應(yīng)dml操作，但是需要注意的是整個(gè)回放的過程中是不具備原子性的。所以在進(jìn)行鏡像庫(kù)切換的過程中，會(huì)偶發(fā)出現(xiàn)數(shù)據(jù)不全的現(xiàn)象。

建議：需要使用方結(jié)合業(yè)務(wù)場(chǎng)景對(duì)數(shù)據(jù)的完整性和實(shí)時(shí)性的要求Case by Case分析，如果要求很高，可以在主庫(kù)切換之前再做鏡像庫(kù)切換。

3.1.2 業(yè)務(wù)切換

業(yè)務(wù)平滑切換常見的落地方案主要有三類，分別是停寫、不停寫、雙寫，不同的方案各有優(yōu)劣，雖然雙寫在業(yè)務(wù)上對(duì)用戶層面上的感知是最小的，但是改造成本以及遷移周期也會(huì)隨之增加，在結(jié)合嚴(yán)選商城C端現(xiàn)有業(yè)務(wù)流量特性（夜間流量相對(duì)偏低）以及成本等各項(xiàng)綜合因素考量之下，最終方案選型上采用了數(shù)據(jù)庫(kù)停寫方案。

通過停寫方案，可以確保在同一個(gè)時(shí)刻，只會(huì)有一個(gè)交易數(shù)據(jù)源可以提供寫入，避免了多數(shù)據(jù)源寫入導(dǎo)致的數(shù)據(jù)同步引發(fā)的數(shù)據(jù)覆蓋，從而導(dǎo)致的臟數(shù)據(jù)的產(chǎn)生。

3.2 挑戰(zhàn):平滑遷移保障

平滑遷移保障主要從數(shù)據(jù)源動(dòng)態(tài)切換和賬號(hào)精準(zhǔn)管控兩方面入手：

• 通過數(shù)據(jù)源動(dòng)態(tài)切換確保在切換過程中DB配置可以實(shí)時(shí)生效，不用重啟就可以達(dá)到切換到目標(biāo)數(shù)據(jù)源的效果；
• 針對(duì)賬號(hào)精準(zhǔn)管控，通過在源數(shù)據(jù)庫(kù)中進(jìn)行一系列賬號(hào)重新分配、授權(quán)、回收等措施確保實(shí)際切換到目標(biāo)數(shù)據(jù)庫(kù)過程中不會(huì)產(chǎn)生遺漏。

3.2.1 數(shù)據(jù)源動(dòng)態(tài)切換

3.2.1.1 嚴(yán)選Pandora

在進(jìn)行數(shù)據(jù)源切換過程中，需要顯式支持?jǐn)?shù)據(jù)源的動(dòng)態(tài)切換，業(yè)內(nèi)也有很多比較成熟的動(dòng)態(tài)切換數(shù)據(jù)源的方案總結(jié)（dynamic-datasource-spring-boot-starter、基于Springboot的AbstractRoutingDataSource等等），大致原理是通過配置多數(shù)據(jù)源從而達(dá)到動(dòng)態(tài)切換的效果。最終還是選擇了嚴(yán)選自研的中間件Pandora，相比較于業(yè)內(nèi)的常見的方案，它在支持?jǐn)?shù)據(jù)源的動(dòng)態(tài)切換，無需重啟的基礎(chǔ)能力下，還支持?jǐn)?shù)據(jù)源配置動(dòng)態(tài)下發(fā)生效，前后數(shù)據(jù)源數(shù)據(jù)Diff（和數(shù)據(jù)源切換結(jié)合使用效果更佳）等功能特性。

3.2.2 賬號(hào)精準(zhǔn)管控

在遷移過程需要保障在切換到新交易數(shù)據(jù)源后不會(huì)存在有表遺漏等場(chǎng)景的出現(xiàn)，避免二次回切，因?yàn)楸旧碓谇袚Q的過程中我們采用的方案是需要停寫的，在生產(chǎn)環(huán)境這無疑會(huì)增加對(duì)線上用戶的有損感知（即便是在流量低峰期），因此需要盡可能保障切換過程不會(huì)出現(xiàn)遺漏。

3.2.2.1 業(yè)務(wù)監(jiān)控

如何高質(zhì)量保障沒有遺漏場(chǎng)景的產(chǎn)生，即現(xiàn)有對(duì)交易DB的所有寫操作都已經(jīng)全量收攏完成，不存在有遺漏的寫操作，這是我們需要重點(diǎn)關(guān)注和解決的。

• 階段一：DB層監(jiān)控

• 初期寄希望于DDB自身，希望可以做到指定表的ip進(jìn)行訪問監(jiān)控，但是很遺憾無法支持轉(zhuǎn)而考慮使用消費(fèi)Binlog的方式進(jìn)行解析，但是整個(gè)主站的Binlog過于龐大。

• 階段二：Proxy層監(jiān)控
• 既然DB層監(jiān)控不行，轉(zhuǎn)而考慮代理層，APM中維護(hù)了服務(wù)于表的鏈路關(guān)系，可以顯式的支持部分表集合和服務(wù)是否存在訪問關(guān)系，但是隨之而來的問題則是，這種關(guān)聯(lián)關(guān)系無法詳細(xì)區(qū)分讀寫，需要額外成本支持。但是通過此類方式可以確定交易表存在直連關(guān)系的服務(wù)是明確。
• 階段三：Application層監(jiān)控
• 既然圈定了服務(wù)范圍，具體讀寫請(qǐng)求區(qū)分可以直接代碼DAO攔截解析識(shí)別，輔之監(jiān)控報(bào)警可以有效幫助識(shí)別是否還存在非預(yù)期場(chǎng)景。

總結(jié)解決方案：APM表查詢 + AOP攔截

3.2.2.2 專號(hào)專用

在遷移過程需要保障在切換到新交易數(shù)據(jù)源后不會(huì)存在有表遺漏等場(chǎng)景的出現(xiàn)，避免二次回切，因?yàn)楸旧碓谇袚Q的過程中是停寫的，在生產(chǎn)環(huán)境這無疑會(huì)增加對(duì)線上用戶的有損感知，因此需要盡可能保障切換過程不會(huì)出現(xiàn)遺漏，在實(shí)施策略上，主要通過隔離賬號(hào)與權(quán)限隔離來保障， 確保專號(hào)專用：

• 賬號(hào)隔離

• 通過對(duì)現(xiàn)有賬號(hào)yanxuan進(jìn)行拷貝相同權(quán)限賬號(hào)yanxuan_new

• 權(quán)限隔離
• 針對(duì)yanxuan賬號(hào)Exclude交易表集合
• 針對(duì)yanxuan_new 限定只允許訪問交易表集合

3.2.2.3 質(zhì)量回歸

除此之外可以通過現(xiàn)有沉淀的自動(dòng)化回歸測(cè)試，幫助我們發(fā)現(xiàn)，在賬號(hào)切換環(huán)節(jié) or 權(quán)限回收環(huán)節(jié)驗(yàn)證現(xiàn)有流程的正確性，防止遺漏場(chǎng)景產(chǎn)生， 但是隨之而來的問題則是，現(xiàn)有沉淀的自動(dòng)化測(cè)試用例并沒有100%覆蓋，如果單純依靠人工代碼檢查，則面臨排查周期長(zhǎng)，耗費(fèi)精力，還有可能存在遺漏等問題。

代碼變更分析SDK：目前SDK應(yīng)用于集團(tuán)各部門精準(zhǔn)測(cè)試領(lǐng)域，由集團(tuán)各BU測(cè)試團(tuán)隊(duì)來維護(hù)共建以及開源化，主要支持版本變更分析和指定方法分析：

• 版本變更分析

• 可以針對(duì)工程內(nèi)（包括依賴的工程）兩個(gè)不同分支或版本之間差異化代碼進(jìn)行Diff計(jì)算，得出變更的類和變更的方法。同時(shí)通過靜態(tài)代碼調(diào)用鏈路分析，計(jì)算出這些變更方法所影響的最上層Controller接口（或Service/Compont/RPC方法）。

• 指定方法分析
• 可以針對(duì)工程內(nèi)（包括依賴的工程）指定類的指定方法，通過靜態(tài)代碼調(diào)用鏈路分析，計(jì)算出這些變更方法所影響的最上層Controller接口（或Service/Compont/RPC方法）。

通過借助代碼變更分析SDK-指定方法分析可以完美契合我們的訴求，大致實(shí)現(xiàn)原理如下圖所示：

下圖所示是在天磯平臺(tái)（基于精準(zhǔn)SDK平臺(tái)化產(chǎn)物）進(jìn)行樣例分析的DEMO，通過指定項(xiàng)目、指定類名、指定方法的方式幫助我們有效構(gòu)建了依賴鏈路：

4 必備保障工作

4.1 數(shù)據(jù)源動(dòng)態(tài)切換改造

涉及遷移的業(yè)務(wù)方需要顯式接入Pandora用于數(shù)據(jù)庫(kù)配置的動(dòng)態(tài)下發(fā)。除了Pandora接入之外，由于我們的應(yīng)用中只有交易切換了新交易DB，必然還會(huì)保留有部分業(yè)務(wù)對(duì)主站DB的訪問。因此整體的改造設(shè)計(jì)思路是進(jìn)行數(shù)據(jù)源拷貝 + 數(shù)據(jù)源動(dòng)態(tài)切換識(shí)別來實(shí)現(xiàn)的，具體實(shí)現(xiàn)思路可以參照下圖：

DataSourceA是系統(tǒng)默認(rèn)數(shù)據(jù)源（主站DB），DataSourceB是對(duì)DataSourceA的拷貝，在進(jìn)行主站DB切換之前，DataSourceA和DataSourceB都用于對(duì)主站DB的訪問。當(dāng)通過Pandora切換到交易DB后，DataSourceA的連接從源數(shù)據(jù)庫(kù)（主站DB）切換到了目標(biāo)數(shù)據(jù)庫(kù)（交易DB），但是由于系統(tǒng)默認(rèn)的是數(shù)據(jù)源是DataSourceA，針對(duì)非交易業(yè)務(wù)DB資源的訪問需要通過DataSourceB才可以獲取，因此需要顯式識(shí)別切換。

4.2 事務(wù)中切換數(shù)據(jù)源

由于涉及遷移工程的項(xiàng)目都使用了Spring+MyBatis用于訪問操作數(shù)據(jù)源，基于交易DB獨(dú)立必然性的條件基礎(chǔ)之下，必然涉及到事務(wù)中切換數(shù)據(jù)源的問題。

我們知道如果開啟Spring事務(wù)，則先有Spring的Transaction，然后Mybatis創(chuàng)建SqlSession時(shí)，會(huì)創(chuàng)建SpringManagedTransaction并加入SqlSession中，通過查看源碼可知SpringManagedTransaction中的Connection會(huì)從TheadLocal中獲取（@Transaction會(huì)創(chuàng)建的Connection并放入ThreadLocal，ThreadLocal是以DataSource生成的actualKey為key值和ConnectionHolder作為value值封裝成的Map）。

因此想要支持事務(wù)中切換數(shù)據(jù)源，必須改寫SqlSessionTemplate，復(fù)寫getSqlSession方法，根據(jù)需要切換的key（對(duì)應(yīng)具體數(shù)據(jù)源），重新構(gòu)造SqlSession。如果SqlSession包含的數(shù)據(jù)源是開啟事務(wù)的數(shù)據(jù)源就會(huì)取Spring已經(jīng)創(chuàng)建的，否則就會(huì)重新創(chuàng)建。

4.3 大數(shù)據(jù)平臺(tái)切換

根據(jù)數(shù)據(jù)集成平臺(tái)Datahub現(xiàn)有功能支持，如果主站庫(kù)（源數(shù)據(jù)庫(kù)）表直接切換到訂單庫(kù)（目標(biāo)數(shù)據(jù)庫(kù)）且使用訂單庫(kù)現(xiàn)有數(shù)倉(cāng)表命名規(guī)則，則需要把遷移過的rdb表名全部更改名稱，工作量巨大且存在較大風(fēng)險(xiǎn)。

考慮到目標(biāo)庫(kù)（歷史已經(jīng)存在，但是核心的交易表相關(guān)數(shù)據(jù)依然存留在主站庫(kù)中）現(xiàn)有數(shù)倉(cāng)表僅被1個(gè)下游任務(wù)依賴，采用單獨(dú)配置訂單庫(kù)binlog Kafka topic、rdb表名適配被遷移的主站表命名的方式進(jìn)行切換，基本可以做到被遷移表相關(guān)離線數(shù)倉(cāng)任務(wù)不需要感知影響，最大限度減少下游影響。

5 獨(dú)立流程編排

獨(dú)立流程是通過開發(fā)人為操作指令來實(shí)施的，因此在實(shí)施過程中如何確保不出錯(cuò)，高效完成獨(dú)立需要重點(diǎn)關(guān)注的。需要所有參與人員明確整體的獨(dú)立思路、敲定詳細(xì)的獨(dú)立步驟（約束行為），以及通過反復(fù)的獨(dú)立演練幫助我們發(fā)現(xiàn)問題，以此來不斷優(yōu)化完善我們的獨(dú)立流程。

5.1 獨(dú)立思路

整體遷移思路是針對(duì)交易表寫權(quán)限已經(jīng)回收完成（依賴交易能力全量收攏完成）背景之下開展，整體流程上大致可以分為兩個(gè)階段：鏡像庫(kù)切換階段和主庫(kù)切換階段。

• 鏡像庫(kù)切換

• 流程上可以先行主庫(kù)切換，有助于發(fā)現(xiàn)問題；
• 因?yàn)橐肓薔DC，相比較于常規(guī)的鏡像庫(kù)復(fù)制流程，鏈路被放大，延遲略有提升。

• 主庫(kù)切換
• 在完成主庫(kù)切換之后，需要斷開源數(shù)據(jù)庫(kù)與目標(biāo)數(shù)據(jù)庫(kù)之間的NDC同步任務(wù)，同期創(chuàng)建反向同步任務(wù)，防止回切造成數(shù)據(jù)丟失。

5.2 獨(dú)立流程

大致遷移流程如圖所示，主要包括遷移階段、回滾階段、以及收尾階段。

5.3 驗(yàn)證演練

由于交易DB切換涉及服務(wù)眾多（累計(jì)13個(gè)核心服務(wù)），因此在生產(chǎn)環(huán)境切換之前，需要在測(cè)試環(huán)境進(jìn)行反復(fù)演練，即正向（源數(shù)據(jù)庫(kù)->目標(biāo)數(shù)據(jù)庫(kù)）和逆向（目標(biāo)數(shù)據(jù)庫(kù)-> 源數(shù)據(jù)庫(kù)）流程全量切換演練。通過切換演練有助于完善現(xiàn)有的切換劇本，細(xì)化人員分配安排，以及明確業(yè)務(wù)影響觀察指標(biāo)。

在測(cè)試環(huán)境交易DB的遷移的過程中，依托前置完善后的用例場(chǎng)景全量回歸不僅僅可以幫助發(fā)現(xiàn)遷移過程是否有遺漏，還可以對(duì)原有的交易能力收攏進(jìn)行二次查漏補(bǔ)缺，確保萬(wàn)無一失。

在切換過程中可以借助NDC的數(shù)據(jù)比對(duì)校驗(yàn)?zāi)芰?，幫助我們測(cè)出源端與目標(biāo)端不一致的數(shù)據(jù)，保證數(shù)據(jù)同步功能的正確性。

6 總結(jié)

針對(duì)嚴(yán)選交易DB如何進(jìn)行數(shù)據(jù)源獨(dú)立以及在數(shù)據(jù)源切換整體流程的解決方案以及實(shí)施遷移的過程中遇到的一些問題解決思路作為經(jīng)驗(yàn)分享給大家，希望對(duì)后續(xù)業(yè)務(wù)團(tuán)隊(duì)在進(jìn)行相關(guān)工作開展有所幫助。