雲妹導讀：
據美國調研機構Gartner公司調研指出，2020年，企業“無雲”就像“無網絡”一樣窘迫。如果企業對於信息化和數字化視而不見，勢必將被這個時代所淘汰。近日，國常會議指出，要對“互聯網+”、平台經濟等加大支持力度，發展數字經濟新業態，依托工業互聯網促進傳統產業加快上線上雲。在頂層架構的帶動下，“企業上雲”概念，再次站上風口。
京東物流在上雲過程中算走在京東集團的最前列，截止目前已經有超過90%的應用在公有雲上部署了實例，包括去年的雙11.11大量業務都是運行在公有雲上，在業務流量超過了三倍以上的情況下，整體運營也都非常平穩。
1 京東物流為什么要“上雲”
京東物流之所以需要遷移上雲，除了整個京東集團上雲戰略上的考慮，從物流集團內部自驅來看有三點考慮，即輕資產化、降低成本、架構升級。
物流是非常重資產的行業，要有庫房、大量的員工還有物流系統也是非常龐大的，而這么大體量的系統卻常年跑在很多物理機上面，隨着時間的推移，這些物理機可能過保或者損壞，帶來了大量的維護成本，而隨着業務的發展，還要采購更多的物理機，這就導致資產會越來越重。而從整個互聯網趨勢來看，大家都是希望自己的架構越來越輕，資產越來越輕。
第二就是降低成本，大家都知道雲計算的特點就是虛擬化和共享化。如果資源在不使用的時候可以回收掉，使用的時候可以采用按需申請，包括計費的模式，就可以按小時按天進行計費。這樣對集團內部資產進行規划，對於集團制定服務器的預算都有很好的幫助。
第三，如果只是簡單的把系統搬到雲上去的話是沒有任何意義的，僅僅把系統服務器部署從私有雲搬到公有雲上意義也不大，真正有意義的是，在這個遷移的過程中，可以對自身的系統架構進行梳理，同時也可以對陳舊的、過時的和現在業務發展不太匹配的系統架構進行一定的升級，包括雲原生的架構，這是一個非常好的機會。
而這三點就是京東物流啟動上雲的驅動力。
2 京東物流遷移上雲方案
依托京東智聯雲雲搜索Elasticsearch高可用、易擴展、近實時等特性，產品在降低使用門檻，減少資源投入成本的前提下，成功助力京東物流分揀中心自動化系統、冷鏈流程監控系統、開放訂單跟蹤系統等上百個系統遷移上雲。
遷移方案的選擇
根據業務需求，方案包括停機遷移和不停機遷移2種：
1、停機遷移
遷移過程中，舊集群可以暫時停止服務或者暫停寫入，待數據全部遷移到新集群后，再將業務切換到新集群進行讀寫。
停機遷移可以通過elasticsearch-dump、snapshot、reindex、logstash等方式完成數據遷移。
2、不停機遷移
遷移過程中，舊集群不能停止寫入，業務不能停服，這也是京東物流上雲主要采用的方案。
如果舊集群不能停止寫入，此時進行在線數據遷移，需要保證新舊集群的數據一致性。目前看來，除了官方商業版提供的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詳請！
