獨家揭祕 | 京東物流Elasticsearch大規模「遷移上雲」實踐

雲妹導讀：
據美國調研機構Gartner公司調研指出，2020年，企業「無雲」就像「無網絡」同樣窘迫。若是企 業對於信息化和數字化視而不見，勢必將被這個時代所淘汰。近日，國常會議指出，要對「互聯網+」、平臺經濟等加大支持力度，發展數字經濟新業態，依託工業互聯網促進傳統產業加快上線上雲。在頂層架構的帶動下，「企業上雲」概念，再次站上風口。

京東物流在上雲過程當中算走在京東集團的最前列，截止目前已經有超過90%的應用在公有云上部署了實例，包括去年的雙11.11大量業務都是運行在公有云上，在業務流量超過了三倍以上的狀況下，總體運營也都很是平穩。

1 京東物流爲何要「上雲」

京東物流之因此須要遷移上雲，除了整個京東集團上雲戰略上的考慮，從物流集團內部自驅來看有三點考慮，即輕資產化、下降成本、架構升級。

物流是很是重資產的行業，要有庫房、大量的員工還有物流系統也是很是龐大的，而這麼大致量的系統卻常年跑在不少物理機上面，隨着時間的推移，這些物理機可能過保或者損壞，帶來了大量的維護成本，而隨着業務的發展，還要採購更多的物理機，這就致使資產會愈來愈重。而從整個互聯網趨勢來看，你們都是但願本身的架構愈來愈輕，資產愈來愈輕。

第二就是下降成本，你們都知道雲計算的特色就是虛擬化和共享化。若是資源在不使用的時候能夠回收掉，使用的時候能夠採用按需申請，包括計費的模式，就能夠按小時按天進行計費。這樣對集團內部資產進行規劃，對於集團制定服務器的預算都有很好的幫助。

第三，若是隻是簡單的把系統搬到雲上去的話是沒有任何意義的，僅僅把系統服務器部署從私有云搬到公有云上意義也不大，真正有意義的是，在這個遷移的過程當中，能夠對自身的系統架構進行梳理，同時也能夠對陳舊的、過期的和如今業務發展不太匹配的系統架構進行必定的升級，包括雲原生的架構，這是一個很是好的機會。

而這三點就是京東物流啓動上雲的驅動力。

2 京東物流遷移上雲方案

依託京東智聯云云搜索Elasticsearch高可用、易擴展、近實時等特性，產品在下降使用門檻，減小資源投入成本的前提下，成功助力京東物流分揀中心自動化系統、冷鏈流程監控系統、開放訂單跟蹤系統等上百個系統遷移上雲。

遷移方案的選擇

根據業務需求，方案包括停機遷移和不停機遷移2種：

一、停機遷移

遷移過程當中，舊集羣能夠暫時中止服務或者暫停寫入，待數據所有遷移到新集羣后，再將業務切換到新集羣進行讀寫。

停機遷移能夠經過elasticsearch-dump、snapshot、reindex、logstash等方式完成數據遷移。

二、不停機遷移

遷移過程當中，舊集羣不能中止寫入，業務不能停服，這也是京東物流上雲主要採用的方案。

若是舊集羣不能中止寫入，此時進行在線數據遷移，須要保證新舊集羣的數據一致性。目前看來，除了官方商業版提供的CCR功能，開源版本並無開源的嚴格保證數據一致性的在線數據遷移工具。所以京東智聯雲Elasticsearch團隊基於京東物流需求提供了業務不停機場景下的遷移工具。

工做原理

在雲端建立新集羣，將雲上集羣和用戶集羣合併成一個大集羣，利用Elasticsearch數據分佈API（cluster.routing.allocation.exclude）將用戶集羣中的索引數據遷移到雲上集羣的數據節點，最後將用戶集羣和雲上集羣構成的大集羣拆分，關閉用戶集羣便可完成遷移。

但採用這種方式必需要同時知足以下兩個條件：

• 用戶集羣版本和雲上集羣版本相同
• 用戶集羣全部節點和雲上集羣全部節點網絡可以互通

操做步驟

整個遷移過程包括新建鏡像集羣、鏡像集羣加入源集羣、移動數據到鏡像集羣、切換客戶端流量、切分集羣5個方面。

#1 建立雲上集羣。在京東智聯云云搜索Elasticsearch控制檯（https://es-console.jdcloud.com/clusters）建立與用戶源集羣版本一致、網絡互通的雲上集羣，做爲鏡像集羣。

#2 合併集羣。設置用戶源端集羣地址和雲上集羣實例ID，建立遷移任務後，將鏡像集羣加入源集羣。

#3 遷移數據。集羣合併成功後，能夠先嚐試遷移一個索引，遷移後切換該索引的應用端流量，觀察應用端讀寫數據正常後，遷移所有索引。

#4 切換流量。索引遷移成功後，應用側須要將配置的集羣地址修改成雲上集羣的地址，切換應用的集羣地址後，建議運行一段時間，觀察應用是否讀寫正常。

#5 切分集羣。集羣切分後沒法恢復，建議運行一段時間，確認集羣運行正常後，再切分集羣，同時關閉源集羣，纔會最終切分完成。

經過上述方法，僅6個月時間京東物流就完成了近百個系統的數百個集羣、數千個節點數據遷移工做。還配套提供了一鍵報警等核心功能，進行全天候、全方位掌握集羣健康等狀況。

3 爲何使用ES？

京東物流做爲全球惟一擁有中小件、大件、冷鏈、B2B、跨境和衆包(達達)六大物流網絡的企業，產生的數據規模極大，須要的組件必然是多元化的，Elasticsearch做爲排名最高的搜索引擎，完美兼容Logstash、Kibana周邊生態，在搜索查詢領域，幾乎完勝全部競爭產品，解決一切搜索查詢問題。所以，這也是Elasticsearch成爲京東物流大件二手倉系統、訂單跟蹤系統等上百個系統搜索查詢場景下的不二選擇的重要緣由。

但在物流上雲以前，使用的Elasticsearch系統均是採用自行搭建方式完成的，使用傳統自建服務器的方式其實存在不少的問題：

• 開源集羣、索引管理工具問題——一是缺乏對公司業務的感知和數據治理能；二是缺少與公司基礎設施的聯動
• 集羣、索引的運維問題——在操做的安全性和標準化的運維手段、流程健全性等方面都有待優化
• 線上問題排查——較多依賴手動操做和人工經驗判斷，解決問題的最佳實踐沒有固化
• 資金成本問題——硬件採購須要大量資金，機房託管、部署機器等工做，須要較長的時間週期和人力成本

雲計算高可用、全託管、易擴展等特性能夠很好的解決用戶服務的痛點。雲搜索Elasticsearch圍繞企業須要和運維中面臨的問題，提供了完善的解決能力：

• 全託管——用戶分鐘級便可成功建立出可用Elasticsearch集羣，無需部署維護軟硬件設施，集成完整的集羣管理、監控與告警系統，專業團隊7*24小時不間斷守護，用戶只需專一於業務開發。
• 高可用——可以方便地爲數據創建索引，擁有節點自動發現和替換失效節點能力,零配置實現分佈。當有新節點加入集羣時，自動發現並從新進行負載均衡，爲新節點分配數據；當某節點失效時，它一樣會自動從新爲可用節點分配數據。
• 易擴展——雲搜索Elasticsearch服務提供實時擴容功能，實現集羣的輕鬆擴展。用戶可根據數據量和查詢量選擇合適的機型，自定義節點的存儲空間，靈活實現按需配置，動態擴容集羣以知足業務增加需求。
• 近實時——自動將海量數據分散到多臺服務器上去存儲和檢索，在秒級別對數據進行搜索和分析，達到海量數據近實時處理。
• 開放兼容——100%兼容開源Elasticsearch，開放大量簡單易用的RestfulAPI，集成了可視化分析工具Kibana和集羣管理工具Head。
• 安全可控——雲搜索Elasticsearch部署在邏輯隔離的專有網絡內，杜絕了外網直連風險。同時只開放雲搜索Elasticsearch服務所需特定端口，加固了數據訪問安全。

以上，Enjoy~

點擊【閱讀】，可瞭解更多Elasticsearch詳請！