1. 前言

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

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

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

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

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

2. 業(yè)務背景

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

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

邊界治理的核心難點之一就是如何做好穩(wěn)定性保障，因為涉及到能力遷移以及內外部依賴改造，如何確保改造范圍的完整性、準確性以及平滑性，這與系統(tǒng)的穩(wěn)定性息息相關。

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

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

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

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

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

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

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

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

3.1.1 遷移工具

3.1.1.1 杭研NDC

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

3.1.1.2 架構簡介

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

3.1.1.3 注意事項

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

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

3.1.2 業(yè)務切換

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

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

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

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

• 通過數(shù)據(jù)源動態(tài)切換確保在切換過程中DB配置可以實時生效，不用重啟就可以達到切換到目標數(shù)據(jù)源的效果；
• 針對賬號精準管控，通過在源數(shù)據(jù)庫中進行一系列賬號重新分配、授權、回收等措施確保實際切換到目標數(shù)據(jù)庫過程中不會產生遺漏。

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

3.2.1.1 嚴選Pandora

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

3.2.2 賬號精準管控

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

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

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

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

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

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

總結解決方案：APM表查詢 + AOP攔截

3.2.2.2 專號專用

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

• 賬號隔離

• 通過對現(xiàn)有賬號yanxuan進行拷貝相同權限賬號yanxuan_new

• 權限隔離
• 針對yanxuan賬號Exclude交易表集合
• 針對yanxuan_new 限定只允許訪問交易表集合

3.2.2.3 質量回歸

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

代碼變更分析SDK：目前SDK應用于集團各部門精準測試領域，由集團各BU測試團隊來維護共建以及開源化，主要支持版本變更分析和指定方法分析：

• 版本變更分析

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

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

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

下圖所示是在天磯平臺（基于精準SDK平臺化產物）進行樣例分析的DEMO，通過指定項目、指定類名、指定方法的方式幫助我們有效構建了依賴鏈路：

4 必備保障工作

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

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

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

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

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

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

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

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

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

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

5 獨立流程編排

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

5.1 獨立思路

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

• 鏡像庫切換

• 流程上可以先行主庫切換，有助于發(fā)現(xiàn)問題；
• 因為引入了NDC，相比較于常規(guī)的鏡像庫復制流程，鏈路被放大，延遲略有提升。

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

5.2 獨立流程

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

5.3 驗證演練

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

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

在切換過程中可以借助NDC的數(shù)據(jù)比對校驗能力，幫助我們測出源端與目標端不一致的數(shù)據(jù)，保證數(shù)據(jù)同步功能的正確性。

6 總結

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