建站
咨詢
售后
建站咨詢
新聞中心
1. 前言
嚴(yán)選在前期發(fā)展過(guò)程中，為了快速交付需求，絕大部分系統(tǒng)采用的都是單體架構(gòu)，主站商城也不例外。
網(wǎng)站的建設(shè)成都創(chuàng)新互聯(lián)專注網(wǎng)站定制,經(jīng)驗(yàn)豐富,不做模板,主營(yíng)網(wǎng)站定制開(kāi)發(fā).小程序定制開(kāi)發(fā),H5頁(yè)面制作!給你煥然一新的設(shè)計(jì)體驗(yàn)!已為成都柔性防護(hù)網(wǎng)等企業(yè)提供專業(yè)服務(wù)。
隨著業(yè)務(wù)復(fù)雜度的不斷攀升，才逐步開(kāi)始進(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ǔ)之后，通過(guò)業(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)和開(kāi)發(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)能力過(guò)剩和瓶頸凸顯兩極分化的局面，亟需各業(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è)背景條件之下，故而開(kāi)展交易DB獨(dú)立遷移工作。
3. 面臨的挑戰(zhàn)
在基于交易DB和商城DB共享的背景之下，需要達(dá)成交易DB獨(dú)立于商城DB的核心目標(biāo)，而目標(biāo)的達(dá)成涉及交易DB遷移獨(dú)立問(wèn)題，結(jié)合交易業(yè)務(wù)場(chǎng)景的特殊性，交易DB作為核心業(yè)務(wù)的強(qiáng)依賴方，任何變動(dòng)行為都有可能觸達(dá)線上用戶感知，故而這對(duì)我們提出了極大的挑戰(zhàn)，確保對(duì)用戶的影響最小，避免由于遷移獨(dú)立引發(fā)一系列連帶負(fù)面影響（諸如: 資損、客訴等問(wèn)題產(chǎn)生），主要表現(xiàn)為3個(gè)方面，交易前用戶無(wú)法進(jìn)行交易行為、交易中用戶交易行為被阻塞中斷、交易后交易數(shù)據(jù)前后不一致?？梢院?jiǎn)單概括總結(jié)為對(duì)數(shù)據(jù)一致性和平滑遷移的保障:
- 數(shù)據(jù)一致性保障
- 數(shù)據(jù)不丟失：無(wú)論是切換到目標(biāo)數(shù)據(jù)庫(kù)或者回切回源數(shù)據(jù)庫(kù)，要確保沒(méi)有數(shù)據(jù)丟失；
- 不產(chǎn)生臟數(shù)據(jù)：需要保障同一筆訂單數(shù)據(jù)在新數(shù)據(jù)庫(kù)和老數(shù)據(jù)庫(kù)之間保持一致。
- 平滑遷移保障
- 數(shù)據(jù)源切換平滑：在進(jìn)行新老數(shù)據(jù)庫(kù)切換過(guò)程中保證盡可能平滑切換；
- 業(yè)務(wù)切換平滑：需要確保在切換到新數(shù)據(jù)庫(kù)的過(guò)程中受影響用戶范圍以及業(yè)務(wù)場(chǎng)景最少。
3.1 挑戰(zhàn)：數(shù)據(jù)一致性保障
在數(shù)據(jù)一致性保障方面，主要是從兩個(gè)方面入手，分別是數(shù)據(jù)遷移工具和業(yè)務(wù)切換方案的選擇來(lái)確保，通過(guò)數(shù)據(jù)遷移工具來(lái)達(dá)成源數(shù)據(jù)庫(kù)和目標(biāo)數(shù)據(jù)庫(kù)之間的數(shù)據(jù)同步，確保沒(méi)有數(shù)據(jù)丟失現(xiàn)象產(chǎn)生，以及業(yè)務(wù)切換方案的制定，防止遷移過(guò)程中臟數(shù)據(jù)的引入。
3.1.1 遷移工具
3.1.1.1 杭研NDC
數(shù)據(jù)同步總體分為離線和實(shí)時(shí)兩類，業(yè)內(nèi)常見(jiàn)的離線數(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)過(guò)轉(zhuǎn)化和過(guò)濾寫(xiě)入目標(biāo)系統(tǒng)之中。架構(gòu)圖如下：
3.1.1.3 注意事項(xiàng)
NDC的回放的流程大致可以理解為與源端建立連接，拉取源端binlog，解析binlog，并對(duì)目標(biāo)端進(jìn)行相應(yīng)dml操作，但是需要注意的是整個(gè)回放的過(guò)程中是不具備原子性的。所以在進(jìn)行鏡像庫(kù)切換的過(guò)程中，會(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ù)平滑切換常見(jiàn)的落地方案主要有三類，分別是停寫(xiě)、不停寫(xiě)、雙寫(xiě)，不同的方案各有優(yōu)劣，雖然雙寫(xiě)在業(yè)務(wù)上對(duì)用戶層面上的感知是最小的，但是改造成本以及遷移周期也會(huì)隨之增加，在結(jié)合嚴(yán)選商城C端現(xiàn)有業(yè)務(wù)流量特性（夜間流量相對(duì)偏低）以及成本等各項(xiàng)綜合因素考量之下，最終方案選型上采用了數(shù)據(jù)庫(kù)停寫(xiě)方案。
|
方案 |
優(yōu)點(diǎn) |
缺點(diǎn) |
|
停寫(xiě) |
低成本，簡(jiǎn)單 |
遷移過(guò)程中影響業(yè)務(wù)的正常運(yùn)轉(zhuǎn) |
|
不停寫(xiě) |
低成本，簡(jiǎn)單 |
遷移過(guò)程中可能有臟數(shù)據(jù)產(chǎn)生，人工修復(fù) |
|
雙寫(xiě) |
真正意義上的平滑切換, 用戶無(wú)感知 |
整體改造工作量大，時(shí)間跨度長(zhǎng)，需要解決數(shù)據(jù)一致性問(wèn)題 |
通過(guò)停寫(xiě)方案，可以確保在同一個(gè)時(shí)刻，只會(huì)有一個(gè)交易數(shù)據(jù)源可以提供寫(xiě)入，避免了多數(shù)據(jù)源寫(xiě)入導(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)管控兩方面入手：
- 通過(guò)數(shù)據(jù)源動(dòng)態(tài)切換確保在切換過(guò)程中DB配置可以實(shí)時(shí)生效，不用重啟就可以達(dá)到切換到目標(biāo)數(shù)據(jù)源的效果；
- 針對(duì)賬號(hào)精準(zhǔn)管控，通過(guò)在源數(shù)據(jù)庫(kù)中進(jìn)行一系列賬號(hào)重新分配、授權(quán)、回收等措施確保實(shí)際切換到目標(biāo)數(shù)據(jù)庫(kù)過(guò)程中不會(huì)產(chǎn)生遺漏。
3.2.1 數(shù)據(jù)源動(dòng)態(tài)切換
3.2.1.1 嚴(yán)選Pandora
在進(jìn)行數(shù)據(jù)源切換過(guò)程中，需要顯式支持?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等等），大致原理是通過(guò)配置多數(shù)據(jù)源從而達(dá)到動(dòng)態(tài)切換的效果。最終還是選擇了嚴(yán)選自研的中間件Pandora，相比較于業(yè)內(nèi)的常見(jiàn)的方案，它在支持?jǐn)?shù)據(jù)源的動(dòng)態(tài)切換，無(wú)需重啟的基礎(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)管控
在遷移過(guò)程需要保障在切換到新交易數(shù)據(jù)源后不會(huì)存在有表遺漏等場(chǎng)景的出現(xiàn)，避免二次回切，因?yàn)楸旧碓谇袚Q的過(guò)程中我們采用的方案是需要停寫(xiě)的，在生產(chǎn)環(huán)境這無(wú)疑會(huì)增加對(duì)線上用戶的有損感知（即便是在流量低峰期），因此需要盡可能保障切換過(guò)程不會(huì)出現(xiàn)遺漏。
3.2.2.1 業(yè)務(wù)監(jiān)控
如何高質(zhì)量保障沒(méi)有遺漏場(chǎng)景的產(chǎn)生，即現(xiàn)有對(duì)交易DB的所有寫(xiě)操作都已經(jīng)全量收攏完成，不存在有遺漏的寫(xiě)操作，這是我們需要重點(diǎn)關(guān)注和解決的。
- 階段一：DB層監(jiān)控
- 初期寄希望于DDB自身，希望可以做到指定表的ip進(jìn)行訪問(wèn)監(jiān)控，但是很遺憾無(wú)法支持轉(zhuǎn)而考慮使用消費(fèi)Binlog的方式進(jìn)行解析，但是整個(gè)主站的Binlog過(guò)于龐大。
- 階段二：Proxy層監(jiān)控
- 既然DB層監(jiān)控不行，轉(zhuǎn)而考慮代理層，APM中維護(hù)了服務(wù)于表的鏈路關(guān)系，可以顯式的支持部分表集合和服務(wù)是否存在訪問(wèn)關(guān)系，但是隨之而來(lái)的問(wèn)題則是，這種關(guān)聯(lián)關(guān)系無(wú)法詳細(xì)區(qū)分讀寫(xiě)，需要額外成本支持。但是通過(guò)此類方式可以確定交易表存在直連關(guān)系的服務(wù)是明確。
- 階段三：Application層監(jiān)控
- 既然圈定了服務(wù)范圍，具體讀寫(xiě)請(qǐng)求區(qū)分可以直接代碼DAO攔截解析識(shí)別，輔之監(jiān)控報(bào)警可以有效幫助識(shí)別是否還存在非預(yù)期場(chǎng)景。
總結(jié)解決方案：APM表查詢 + AOP攔截
3.2.2.2 專號(hào)專用
在遷移過(guò)程需要保障在切換到新交易數(shù)據(jù)源后不會(huì)存在有表遺漏等場(chǎng)景的出現(xiàn)，避免二次回切，因?yàn)楸旧碓谇袚Q的過(guò)程中是停寫(xiě)的，在生產(chǎn)環(huán)境這無(wú)疑會(huì)增加對(duì)線上用戶的有損感知，因此需要盡可能保障切換過(guò)程不會(huì)出現(xiàn)遺漏，在實(shí)施策略上，主要通過(guò)隔離賬號(hào)與權(quán)限隔離來(lái)保障， 確保專號(hào)專用：
- 賬號(hào)隔離
- 通過(guò)對(duì)現(xiàn)有賬號(hào)yanxuan進(jìn)行拷貝相同權(quán)限賬號(hào)yanxuan_new
- 權(quán)限隔離
- 針對(duì)yanxuan賬號(hào)Exclude交易表集合
- 針對(duì)yanxuan_new 限定只允許訪問(wèn)交易表集合
3.2.2.3 質(zhì)量回歸
除此之外可以通過(guò)現(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)生， 但是隨之而來(lái)的問(wèn)題則是，現(xiàn)有沉淀的自動(dòng)化測(cè)試用例并沒(méi)有100%覆蓋，如果單純依靠人工代碼檢查，則面臨排查周期長(zhǎng)，耗費(fèi)精力，還有可能存在遺漏等問(wèn)題。
代碼變更分析SDK：目前SDK應(yīng)用于集團(tuán)各部門(mén)精準(zhǔn)測(cè)試領(lǐng)域，由集團(tuán)各BU測(cè)試團(tuán)隊(duì)來(lái)維護(hù)共建以及開(kāi)源化，主要支持版本變更分析和指定方法分析：
- 版本變更分析
- 可以針對(duì)工程內(nèi)（包括依賴的工程）兩個(gè)不同分支或版本之間差異化代碼進(jìn)行Diff計(jì)算，得出變更的類和變更的方法。同時(shí)通過(guò)靜態(tài)代碼調(diào)用鏈路分析，計(jì)算出這些變更方法所影響的最上層Controller接口（或Service/Compont/RPC方法）。
- 指定方法分析
- 可以針對(duì)工程內(nèi)（包括依賴的工程）指定類的指定方法，通過(guò)靜態(tài)代碼調(diào)用鏈路分析，計(jì)算出這些變更方法所影響的最上層Controller接口（或Service/Compont/RPC方法）。
通過(guò)借助代碼變更分析SDK-指定方法分析可以完美契合我們的訴求，大致實(shí)現(xiàn)原理如下圖所示：
下圖所示是在天磯平臺(tái)（基于精準(zhǔn)SDK平臺(tái)化產(chǎn)物）進(jìn)行樣例分析的DEMO，通過(guò)指定項(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的訪問(wèn)。因此整體的改造設(shè)計(jì)思路是進(jìn)行數(shù)據(jù)源拷貝 + 數(shù)據(jù)源動(dòng)態(tài)切換識(shí)別來(lái)實(shí)現(xiàn)的，具體實(shí)現(xiàn)思路可以參照下圖：
DataSourceA是系統(tǒng)默認(rèn)數(shù)據(jù)源（主站DB），DataSourceB是對(duì)DataSourceA的拷貝，在進(jìn)行主站DB切換之前，DataSourceA和DataSourceB都用于對(duì)主站DB的訪問(wèn)。當(dāng)通過(guò)Pandora切換到交易DB后，DataSourceA的連接從源數(shù)據(jù)庫(kù)（主站DB）切換到了目標(biāo)數(shù)據(jù)庫(kù)（交易DB），但是由于系統(tǒng)默認(rèn)的是數(shù)據(jù)源是DataSourceA，針對(duì)非交易業(yè)務(wù)DB資源的訪問(wèn)需要通過(guò)DataSourceB才可以獲取，因此需要顯式識(shí)別切換。
4.2 事務(wù)中切換數(shù)據(jù)源
由于涉及遷移工程的項(xiàng)目都使用了Spring+MyBatis用于訪問(wèn)操作數(shù)據(jù)源，基于交易DB獨(dú)立必然性的條件基礎(chǔ)之下，必然涉及到事務(wù)中切換數(shù)據(jù)源的問(wèn)題。
我們知道如果開(kāi)啟Spring事務(wù)，則先有Spring的Transaction，然后Mybatis創(chuàng)建SqlSession時(shí)，會(huì)創(chuàng)建SpringManagedTransaction并加入SqlSession中，通過(guò)查看源碼可知SpringManagedTransaction中的Connection會(huì)從TheadLocal中獲?。ˊTransaction會(huì)創(chuàng)建的Connection并放入ThreadLocal，ThreadLocal是以DataSource生成的actualKey為key值和ConnectionHolder作為value值封裝成的Map）。
因此想要支持事務(wù)中切換數(shù)據(jù)源，必須改寫(xiě)SqlSessionTemplate，復(fù)寫(xiě)getSqlSession方法，根據(jù)需要切換的key（對(duì)應(yīng)具體數(shù)據(jù)源），重新構(gòu)造SqlSession。如果SqlSession包含的數(shù)據(jù)源是開(kāi)啟事務(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ī)則，則需要把遷移過(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ú)立流程是通過(guò)開(kāi)發(fā)人為操作指令來(lái)實(shí)施的，因此在實(shí)施過(guò)程中如何確保不出錯(cuò)，高效完成獨(dú)立需要重點(diǎn)關(guān)注的。需要所有參與人員明確整體的獨(dú)立思路、敲定詳細(xì)的獨(dú)立步驟（約束行為），以及通過(guò)反復(fù)的獨(dú)立演練幫助我們發(fā)現(xiàn)問(wèn)題，以此來(lái)不斷優(yōu)化完善我們的獨(dú)立流程。
5.1 獨(dú)立思路
整體遷移思路是針對(duì)交易表寫(xiě)權(quán)限已經(jīng)回收完成（依賴交易能力全量收攏完成）背景之下開(kāi)展，整體流程上大致可以分為兩個(gè)階段：鏡像庫(kù)切換階段和主庫(kù)切換階段。
- 鏡像庫(kù)切換
- 流程上可以先行主庫(kù)切換，有助于發(fā)現(xiàn)問(wèn)題；
- 因?yàn)橐肓薔DC，相比較于常規(guī)的鏡像庫(kù)復(fù)制流程，鏈路被放大，延遲略有提升。
- 主庫(kù)切換
- 在完成主庫(kù)切換之后，需要斷開(kāi)源數(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ù)）流程全量切換演練。通過(guò)切換演練有助于完善現(xiàn)有的切換劇本，細(xì)化人員分配安排，以及明確業(yè)務(wù)影響觀察指標(biāo)。
在測(cè)試環(huán)境交易DB的遷移的過(guò)程中，依托前置完善后的用例場(chǎng)景全量回歸不僅僅可以幫助發(fā)現(xiàn)遷移過(guò)程是否有遺漏，還可以對(duì)原有的交易能力收攏進(jìn)行二次查漏補(bǔ)缺，確保萬(wàn)無(wú)一失。
在切換過(guò)程中可以借助NDC的數(shù)據(jù)比對(duì)校驗(yàn)?zāi)芰Γ瑤椭覀儨y(cè)出源端與目標(biāo)端不一致的數(shù)據(jù)，保證數(shù)據(jù)同步功能的正確性。
6 總結(jié)
針對(duì)嚴(yán)選交易DB如何進(jìn)行數(shù)據(jù)源獨(dú)立以及在數(shù)據(jù)源切換整體流程的解決方案以及實(shí)施遷移的過(guò)程中遇到的一些問(wèn)題解決思路作為經(jīng)驗(yàn)分享給大家，希望對(duì)后續(xù)業(yè)務(wù)團(tuán)隊(duì)在進(jìn)行相關(guān)工作開(kāi)展有所幫助。
當(dāng)前標(biāo)題：嚴(yán)選交易數(shù)據(jù)源獨(dú)立切換實(shí)踐
URL標(biāo)題：http://www.5511xx.com/article/cdijpdh.html
