記者：魏偉（[email protected]）
編輯：周建丁（[email protected]）

從1萬Docker到15萬，從試水部分應用到承擔全部流量，京東彈性雲團隊用了1年的時間，為2016年618大考交上了新的答卷。Docker化的技術細節，京東技術團隊是如何實現的呢？日前，京東雲中間件首席架構師何小鋒接受CSDN記者專訪，介紹了基於Docker的京東彈性雲構建、優化和規模化推廣始末、備戰618的相關舉措，以及Docker部署和遷移心得。

何小鋒介紹，基於Docker 的彈性雲能夠簡化應用部署和擴容，提升系統伸縮能力，保障618高併發流量下的系統穩定性，同時及時採集容器的指標，對應用的負載進行評估預測，有助於自動化運維和精細化管理。在Docker化的嘗試過程中，京東先進行區域性嘗試、驗證，再進行大規模推廣，優先遷移計算類應用、無狀態應用，在不影響業務的情況下平滑遷移。何小鋒認為，可以使用成熟的方案替換Docker裡面的新特性以保證系統穩定性，並整合公司的基礎設施和應用治理、監控報警等功能，才能完整實施企業解決方案。

嘉賓簡介

何小鋒，京東雲中間件首席架構師，擁有18年的研發經驗，2011年加入京東，擔任了京東兩屆架構委員會常委。目前負責京東雲中間件部，包括快取平臺、訊息平臺、微服務框架、彈性雲等產品。

CSDN：能否介紹下京東的彈性雲平臺？

何小鋒：京東彈性雲是京東標誌性的戰略研發專案，它基於Docker（容器）簡化了應用的部署和擴容，提高了系統的伸縮能力；京東目前擁有容器數量超過15萬，已經成為全球最大規模Docker叢集之一，有力地保障了整個運維繫統的平穩執行；而京東的資料中心現在佈局華北、華東、華南三大地區，多中心模式有力支撐了京東的所有業務，將為整個系統提供更加強大的承載力。

經受住了2015年618和雙11大流量的考驗後，2016年雙活的資料中心已經全部採用彈性雲進行建設，同時今年618流量全部落到彈性雲上。京東彈性雲通過雲端計算將使用者的流量均勻分散到彈性雲的高效能節點，優化微服務來驅動訂單的生產。京東彈性雲會根據歷史資料的計算進行資源預估和儲備，實現自動化運維和精細化管理。而像618大促這樣的流量高峰期，彈性雲會自動補充資源，做到彈性擴充套件，在流量低谷期，又可以進行資源回收，從而將資源靈活地排程起來，在提升資源利用率的同時確保了運維繫統的穩定性。

CSDN：618流量高峰是平時的多少倍？面對比平時高很多的流量高峰，彈性雲平臺做了哪些準備？

何小鋒：對於618流量高峰，我們做了如下準備：

1. 按照平時的10倍進行的預估，並提前做了資源擴容，準備了足夠的資源池，配合業務方進行壓測演練。
2. 為了確保系統的穩定性，我們啟動了彈性雲雙機房容災專案，如果其中一個機房出現問題，系統將自動把流量切換到另一個機房，實現跨機房的容災，保證無論在何種情況下，都能讓資料迅速恢復，讓應用系統的容災能力得到極大的保障。
3. 我們每天都對物理機、網路、容器和應用部署進行巡檢，確保應用部署跨機架部署均勻，每個機房都能抗住100%的流量。
4. 我們建立了一個非常成熟的監控體系，可以面向容器級別進行監控，能夠準確瞭解每個容器的問題，並及時收到報警，為京東應用系統應對突發情況增加了一層有效的防護。

CSDN：京東彈性雲平臺整體是基於Docker來打造的，你們選擇Docker之前做了哪些評估和測試？

何小鋒：京東彈性雲首先應用於京東私有云上，在選擇Docker之前，我們嘗試了KVM虛擬化方案，各方反饋效能不夠好，無法滿足大促的需求。在2014年底，我們決定採用Docker容器化方案，基於Docker映象的方式進行釋出，其快速的彈性伸縮能力適合京東大規模生產需求，並且其具備輕量、高效能和便捷性的優勢。我們首先使用京東圖片系統來驗證其效能和彈性伸縮能力，之後再逐步推廣到如單品頁這樣的核心繫統，並進行網路的優化，以滿足京東應用的效能。應用中我們採用和物理機混合部署的模式，經過2015年618和雙11大流量的考驗，驗證了Docker的穩定性。所以到2016年的618大促，我們才有信心使用Docker來抗100%流量。

CSDN：從落地到大規模推廣Docker的過程中遇到哪些阻力，如何解決的？

何小鋒：在部署中，我們首先要確保彈性雲足夠的穩定之後，才能將核心應用遷移上來。通過彈性雲的培訓，讓使用者對Docker容器有了足夠的瞭解，我們也採用了物理機和彈性雲混合部署，通過長時間的執行指標，並且經歷了618和雙11大流量考驗之後，更給使用者樹立了信心。

另外最重要的是要滿足效能的需求，確保大促不受影響。我們對使用者反饋的效能問題逐步優化，通過優化網路，簡化模型，提升網路效能，解決應用刷日誌問題的方式作出了改善。
最後還要滿足使用者習慣，便於推廣。每個容器都有獨立的IP，使用者可以SSH登陸上去操作；同時使用者也可以整合現有的基礎設施系統，通過自動部署、統一日誌、統一監控、HA等等；在應用中還可以採集豐富的監控指標，讓使用者感覺和物理機操作是一樣的。此外，日誌保留到本地物理機磁碟上，更確保了使用者檢索日誌的需求。

CSDN：能否詳細介紹京東彈性雲的架構？據瞭解你們是基於開源和自研相結合的架構，這是基於哪些考慮？

何小鋒：京東雲的基礎平臺（JDOS）能夠實現基礎設施，包括網路，物理機和儲存的資源管理、容器的生命週期管理以及監控指標採集。

京東雲的應用平臺（CAP）則負責應用治理、部署、監控報警、資源利用率統計以及手動和自動的彈性伸縮。

我們採用開源主要是為了提高效率，因為目前業界已經有相應的成熟方案，可以直接使用，以加快交付效率。另外一點，也是為了滿足京東的應用場景，整合京東的基礎設施，實現在開源的基礎上進行了改造或者自主研發。

CSDN：大規模/跨資料中心叢集的儲存、網路問題是如何解決的？

何小鋒：我們的方案包括：

• 京東研發的京東檔案系統（JFS），提供物件儲存和塊儲存，實現跨資料中心的複製。
• 京東研發的MySQL雲資料庫，支援跨資料中心的複製。
• 京東研發的JIMDB，相容Redis協議，實現跨資料中心的複製。
• 京東研發的HBase叢集，支援跨資料中心的複製。
• 網路採用OVS/VLAN模式，為私有云簡化了模型，跨網段訪問通過物理交換機實現。

CSDN：服務之間的排程是如何實現的？針對618的規模挑戰與效率挑戰的矛盾如何取捨？

何小鋒：彈性雲集成了京東很多基礎設施，例如部署、資料庫授權、負載均衡等等。並且我們已經通過自主研發的CAP來實現面向應用的排程，同時容器的建立、銷燬過程，也都是基於任務和狀態機來實現。

我們的任務排程框架基於Zookeeper和狀態機來實現，這樣便於動態擴容。通過各個節點向Zookeeper註冊，並由選舉出的Leader負責在資料庫中掃描出待執行的任務，根據當前存活的任務節點和負載均衡演算法，派發到各個節點執行。任務執行完畢後，更改狀態為最終狀態。如果任務失敗，可以設定下次重試時間進行重試。同時為了避免衝突，相同資源之間的排程也做了支援互斥的處理。

CAP會實時計算應用的資源利用率，預測是否要進行擴容，如果需要，就會生成擴容申請，並分解成各個任務，由內部的編排進行任務的排程。

正如之前提到的，為了應對618大流量的考驗，我們提前進行了大規模的擴容，做好了充分的準備。

CSDN：你們對Docker做了哪些優化？你認為Docker在生產環境下，還需要哪些改進？

何小鋒：為了在京東生產環境下使用，我們做了如下改進：

• 優化了Docker dameon，便於升級；
• 另外在映象儲存上還使用了京東自研的JFS；
• 放棄了Docker的網路模型，改用更成熟穩定的OVS；
• 日誌主要通過卷輸出到物理機上；
• 完善了監控資料的採集；
• Docker本身不帶排程和彈性伸縮的功能，需要根據應用場景研發彈性排程功能。

CSDN：採用容器技術對自動化運維和精細化運營有哪些幫助？

何小鋒：在採用容器後，使用者能夠實現快速的應用部署，提升交付效率。以前應用採用物理機方式部署，部署較慢，需要各處申請許可權、配置HA。現在這些都可以交給彈性雲來做到一鍵部署。

在部署之前，我們不能準確掌握系統的整體壓力，也無法及時響應應用的擴容。但在採用彈性雲之後，我們能夠及時採集容器的指標，對應用的負載進行評估預測，並進行自動的彈性的伸縮；另外，我們也可以提前手動一鍵擴容來滿足秒殺等特殊場景的需求。

彈性雲能夠及時採集物理機、容器的指標，根據報警策略進行報警，同時也能對出現故障的例項快速進行遷移。

通過採集的指標，可以實時計算出容器的資源利用率，同時也可以計算出應用和部門的加權平均資源利用率，這樣便於資源的統一調配。

CSDN：通過你們的實踐，能否給正在考察Docker的團隊一些建議？

何小鋒： Docker是比較新的技術，經過京東的大規模生產實踐，證明以Docker為核心的系統可以做到非常穩定、高效。為了確保系統的穩定性，我們建議使用成熟的方案替換Docker裡面的新特性。此外，我們還建議必須整合公司的基礎設施和應用治理、監控報警等功能，才能完整實施企業解決方案。

CSDN：在進行雲遷移的雲考量因素有應用、資料庫、檔案等，能否詳細介紹其中的注意事項？

何小鋒：京東把應用遷移到彈性雲，考慮瞭如下幾點：

1. 計算類應用、無狀態應用優先，例如微服務特別容易遷移到彈性雲。
2. 應用遷移到彈性雲，最好選擇統一的規格，避免各個例項的負載不均衡。
3. 應用從物理機遷移到彈性雲後，例項數量會增加，相應對後端服務的連線數會增加，特別是資料庫連線，所以需要防止連線過載。
4. 在彈性雲上共享磁碟IO，要避免應用刷日誌，減少本地讀寫檔案，採用JFS或JIMDB來滿足檔案儲存或共享資料需求。
5. 容器的CPU核數原低於原有物理機的核數，應用需要根據CPU核數來合理地配置執行緒數和網路引數。
6. 修改底層，讓應用在執行時能準確地拿到自身容器的核數。

CSDN：未來實現全域性流量排程的挑戰有哪些規劃？

何小鋒：在全域性流量的排程中，實現快速地進行流量切換和故障遷移有三要素：要把流量排程到最近的機房；要讓每個機房的流量和應用的部署實現均衡；要讓每個容器的流量和自身的規格均衡。

在應用中，我們的策略包括：

• 根據入口流量和應用歷史指標，設計資料模型，準確的評估大促各個應用需要準備的資源，並進行自動化的擴容，以減少備戰工作量。
• 結合Kubernetes進行更精細化的排程，以映象方式釋出推廣，更加快速排程流程。
• 最大程度地降低日誌對磁碟IO的影響，日誌直接通過網路採集，只有網路故障的時候才落到本地。
• 把各個Agent從應用映象裡面移除，採用統一的容器來管理系統的Agent，便於升級，降低對系統負載的影響。
  總而言之，就是提高資源利用率，在空閒時段，能把計算資源提供給大資料計算。

CSDN：未來把彈性雲、快取雲輸出到公有云平臺，還需要解決什麼問題？

何小鋒：彈性雲和快取雲輸出到公有云平臺，首先需要解決租戶隔離、網路安全等問題。這些在私有云場景是不需要解決的。另外依賴的京東私有云的基礎設施系統，如中介軟體和監控報警等，在公有云上也需要相應的解決方案。

京東618/雙11技術演進路線：

OpenStack Days China將於7月14-15日在北京國家會議中心舉辦，屆時包括OpenStack基金會的Jonathan Bryce、Mark Collier、Alan Clark等大牛都將來到大會現場和2000名參會者一起坐而論道，共話OpenStack大勢，現在報名票價優惠，欲報從速（http://openstackdaychina.csdn.net/）。