線上資料遷移，數字化時代的必修課 —— 京東雲資料遷移實踐

混合多雲新趨勢

雲原生時代的到來，企業上雲需求日益細緻化，從而推進了企業IT架構進化，混合多雲已經成為企業上雲新趨勢。據混合雲產業聯盟最新發布的《中國混合雲使用者調查報告（2021年）》顯示，調查中72.1%的企業應用了雲端計算，其中超半數採用混合雲，且其平均用雲數量達4.3個，同時在應用雲端計算的企業中選擇多雲的企業也高達86.7%。

混合多雲變革中，核心系統應該放在哪種雲中，如何遷移，之前簡單的雲原生應用和留在傳統資料中心中的其他應用應該如何連線和互動，資源調配能力及效率和異構虛擬實現方面等眾多問題均困擾著企業使用者。

混合多雲時代，使用者資料遷移需求與場景激增

今天我們來重點聊聊混合雲時代中資料遷移，先來看看常見的幾種企業資料遷移的需求與場景：

1. 傳統雲化型：裝置老舊，需要升級，硬體成本升級價效比不高，雲上更經濟；

2. 價格敏感型：綜合對比多家廠商價格，靈活選型採用成本最優方案；

3. 災備驅動型：需要多雲、異構雲來架構自己的災備體系，保證資料的安全

4. 遊戲客戶：異地開服，服務不同地域的使用者，因各地網路質量不一致需要多雲模式用於構建服務本地使用者的遊戲伺服器。

5. 泛金融客戶：要符合金融安全政策的要求，需要資料的遷移

這些客戶都因系統和技術升級、業務的發展、以及安全合規等因素採用混合多雲的方案，同時對其資料的遷移有著很高的訴求，在不同的業務模式和需求下也會面臨多種問題。

混合多雲時代下，資料遷移的困境

資料庫的發展多樣性提升遷移門檻

混合多雲時代，遷移是面臨的一大難題，其中資料安全遷移往往又是企業最關注的。提到資料遷移的困難，究其原因先粗略回顧下關係型資料庫到非關係型資料庫的發展。

關係型資料庫，是指採用了關係模型來組織資料的資料庫。關係模型是在1970年由IBM的研究員E.F.Codd博士首先提出的，在之後的幾十年中，關係模型的概念得到了充分的發展並逐漸成為主流。關係型資料庫具備事務一致性、讀寫實時性、結構化與規範化等特性，因而容易理解、使用方便、易於維護，在虛機時代，網際網路還未普及時它是最主流的資料庫，典型的代表有Oracle、Microsoft SQL Server、DB2、MySQL等。

但隨著網際網路的飛速發展，網站使用者併發高，海量資料的產生，傳統關係型資料庫已經不能滿足企業的資料儲存需求了，非關係型資料庫應勢而生，它高併發,讀寫能力強、弱化資料結構一致性,使用更加靈活有良好的可擴充套件性等優勢逐漸成為了企業的首選。

NoSQL一詞首先是Carlo Strozzi在1998年提出來的。典型代表Redis， Amazon DynamoDB， Memcached，Microsoft Azure Cosmos DB等

在面對這兩種資料庫之間的遷移，關係型資料庫SQL RDBMS發展久，遷移生態工具齊全，且大部分資料庫產品都自帶遷移工具；而非關係NoSQL，資料定義更寬鬆，產品體積輕量，放棄了一致性校驗，導致某些資料結構濫用，提升了遷移難度。而遷移工具大部分開放給生態來做，由於發展時間較短，工具完善度不如RDBMS高。

廠商試圖“資料綁架”，使遷移雪上加霜

分析完關係型資料庫到非關聯式資料庫的發展，可以看到資料儲存結構本身已發生了巨大的變化，這從根因上已大幅提升了遷移的難度，而一些雲廠商對資料庫的再次改造，且對關係型資料庫底層改造不透明，導致資料庫的複雜性大大加大，試圖用資料遷移成本高來長期繫結客戶，更是令資料的遷移雪上加霜。

“個體差異”導致通用型解決方案缺失

不同的企業由於自身需求不同與使用場景的多樣性，每一個客戶，對我們來說都是一個新的案例，我們必須“量身定製”化服務，但在過程中我們也總結出幾類常見難點：

• 難點一：多節點資料庫遷移，節點數量不一致

• 難點二：原生產品跨版本問題，版本不一致且上下版本相容性不夠好

• 難點三：快取類資料易失性更高 

面臨挑戰，京東雲破局遷移困境

下面透過實際案例和大家分享我們是如何破局遷移困境，幫助使用者解脫資料枷鎖的。

重大挑戰，臨危不亂/從容不迫

2019年京東物流為了實現其輕資產化、降低成本、升級架構的三大目的，將其ES開始由本地機房遷移到雲上。依託京東云云搜尋ES高可用、易擴充套件、近實時等特性，京東物流成功地將分揀中心自動化系統、冷鏈流程監控系統、開放訂單跟蹤系統等上百個系統遷移上雲。

在遷移過程中京東雲不僅提供了常規的停機遷移方案，還提供了特殊的不停機遷移方案，保證了物流業務不停服。不停機遷移方案如下：在雲端建立新叢集，將雲上叢集和使用者叢集合併成一個大叢集，利用Elasticsearch資料分佈API（cluster.routing.allocation.exclude）將使用者叢集中的索引資料遷移到雲上叢集的資料節點，最後將使用者叢集和雲上叢集構成的大叢集拆分，關閉使用者叢集即可完成遷移。（採用這種方式須注意同時滿足以下兩個條件：使用者叢集版本和雲上叢集版本相同；使用者叢集所有節點和雲上叢集所有節點網路能夠互通。）

透過上述方法，很快就就完成了京東物流近百個系統的數百個叢集、數千個節點資料上雲工作。在此之上京東雲還配套提供了一鍵報警等核心功能，對上雲工作進行全天候、全方位的保障。

截止目前，京東物流已有超過90%的應用在公有云上部署了例項，去年11.11期間業務量超過日常三倍以上的情況下，整體運營平穩。

遷移利器，上雲必備

關係型資料庫依然是各行業的主流應用之一，怎樣更快的將傳統關係型資料中的資料遷移上雲也是很多行業使用者關心的。為此京東雲特意打造了一款針對關係型資料庫的遷移工具——資料傳輸DTS。

資料傳輸DTS 提供實時資料流服務，支援資料遷移、資料訂閱和資料同步服務，可簡單方便的滿足資料上雲、業務非同步解耦、資料異地災備、業務系統資料流轉等業務場景。目前資料傳輸DTS支援MySQL、MariaDB、Percona、SQL Server、PostgreSQL等多種資料庫遷移，可以簡單快速地將本地自建資料庫遷移至京東雲，源資料庫在遷移過程中可繼續正常執行，從而最大程度地減少應用程式的停機時間。

不斷突破，技術創新

某家線上廣告公司需要將Redis從自有機房遷移到雲上。由於客戶系統承載著大量結算快取和業務快取所以要求在遷移過程中不能有業務中斷。當時有一些開源工具，但是不滿足要求。主要是由於版本問題，客戶用的Redis版本是4.0而當時開源的工具只支援3.28及以下版本。本著京東客戶業務為先的原則，和鼓勵創新的技術精神，我們思考，能不能為客戶自研一套工具，能夠Cover住Redis資料流轉大部分場景的通用工具，於是2019年7月redissyncer 1.0版本誕生，完成了資料來源及目標校驗、原生叢集同步、 大KV的拆解等基本功能。

1.0完後很快迎來了幾個客戶：

• 其一是網際網路行業使用者，Redis單例項，資料體量不大20Gb左右。我們透過啟動引數修復、調整每批次Value值等細節最佳化順利完成了遷移任務；

• 第二個使用者是遊戲行業的使用者，使用者需要將自有IDC中的Redis遷移到京東雲。在使用我們的產品之前，使用者自己找過若干開源產品但都不符合要求。由於使用者的例項數量較多，在瞭解過Redissyncer產品特性後，使用者決定使用我們的工具自行遷移。

貼近一線，無微不至

經過一個下午的培訓遠端培訓，使用者很快上手第一個例項遷移很順利。在接下來的幾天使用者透過我們的工具陸續完成遷移工作，並反饋中給予產品很高評價，並特意發來感謝信。

來自客戶的認可，是我們不斷向前的最大動力！

不斷打磨，精益求精

在剖析過更多客戶痛點與需求後， 2019年11月底，我們完成了2.0版本的升級，補充了同步模式拆分、斷點續傳、離線檔案載入、跨版本遷移、流式載入等功能。

很快2019年12月我們又迎來了一個金融使用者。使用者需要將原生Redis叢集遷移到自研的Redis叢集。目標叢集節點數多大16*2即16對主從構成的叢集，遷移過程很順利，經過準備15分鐘完成應用割接。

（遷移部署圖）

經過實際場景的打磨，我們陸續修復了一些測試中很難遇到的bug，新增了一些新特性。使得產品不僅支援升級遷移同時支援降級遷移；為了提高使用者體驗，我們參考Redis、MySQL等優秀開源產品的方式做了一個命令列客戶端命名為redissyncer-cli。至此，完成了RedisSyncer3.X的升級，這個專案的體系建設基本上可以滿足Redis遷移同步場景中的大部分需求了。

不止於此，突破創新

起初，我們把RedisSyncer定位為一個Redis的同步工具。隨著開發和使用者側的實踐，我們下一步想把RedisSyncer打造成為具備企業級災備能力的Redis資料同步中介軟體。從工具到具備企業級災備能力還是有一定門檻的。所以下一步我們的工作重點是對軟體進行分散式改造，最終目標是在任意節點發生故障時任務可自動化持續，實現企業級災備能力的Redis資料同步中介軟體。

擁抱開源，包容開放

目前京東雲已經積累了覆蓋網際網路、遊戲、金融、物流、零售等多場景領域的遷移經驗。隨著混合多雲趨勢到來，我們深知使用者遷移之苦，也願意以相容開放的心態為客戶提供技術服務，真正做到把選擇權交給使用者，同時為了讓更多人享受技術帶來的便利，我們在今年決定將自研RedisSyncer完全開源（開源地址：https://github.com/TraceNature/redissyncer-server），將技術迴歸社群，給更多使用者和開發者帶來便利！