京東618：Docker扛大旗，彈性伸縮成重點 (2015-06-23)

不知不覺中，年中的618和年終的11.11已經成爲中國電商的兩大促銷日，固然，這兩天也是一年中系統訪問壓力最大的兩天。對於京東而言，618更是這一年中最大的一次考試，考點是系統的擴展性、穩定性、容災能力、運維能力、緊急故障處理能力。彈性計算雲是京東2015年研發部戰略項目，它基於Docker簡化了應用的部署和擴容，提升了系統的伸縮能力。目前京東的圖片系統、單品頁、頻道頁、風控系統、緩存、登陸、團購、O2O、無線、拍拍等業務都已經運行在彈性計算雲系統中。

 

過去的一段時間裏，彈性計算雲項目在京東內部得到了普遍應用，而且日趨穩定成熟。一方面，這個項目能夠更有效地管理機器資源，提升資源利用率；另外還能大幅提升生產效率，讓原來的申請機器上線擴容逐漸過渡到全自動維護。京東彈性計算雲項目將深入影響京東將來幾年的基礎架構。

 

受訪嘉賓介紹

劉海鋒，京東雲平臺首席架構師、系統技術部負責人。系統技術部專一於基礎服務的自主研發與持續建設，包括分佈式存儲、之內存爲中心的NoSQL服務、圖片源站、內容分發網絡、消息隊列、內部SOA化、彈性計算雲等核心系統，均大規模部署以支撐京東集團的衆多業務。

InfoQ：可否介紹下京東彈性計算雲項目的狀況，大家何時開始使用Docker的？目前有多大的規模？

 

劉海鋒：彈性計算雲項目在去年第四季度開始研發，今年春節後正式啓動推廣應用。通過半年多的發展，逐漸作到了必定規模。截至6月17日，咱們線上運行了9853個Docker實例（注：無任何誇大）以及幾百個KVM虛擬機。京東主要的一些核心應用好比商品詳情頁、圖片展示、秒殺、配送員訂單詳情等等都部署在彈性雲中。彈性計算雲項目也做爲今年618的擴容與災備資源池，這估計是國內甚至世界上最大規模的Docker應用之一。隨着業務的發展以及IDC的增長，預計今年年末規模會翻兩番，京東大部分應用程序都會經過容器技術來發布和管理。

系統架構能夠這樣簡潔定義：彈性計算雲 = 軟件定義數據中心 容器集羣調度。整個項目分紅兩層架構，底層爲基礎平臺，系統名JDOS，經過『OpenStack married with Docker』來實現基礎設施資源的軟件管理，Docker取代VM成爲一等公民，但這個系統目標是統一輩子產物理機、虛擬機與輕量容器；上層爲應用平臺，系統名CAP，集成部署監控日誌等工具鏈，實現『無需申請服務器，直接上線』，並進行業務特定的、數據驅動的容器集羣調度與彈性伸縮。

Q：可否談談大家的Docker使用場景？在618這樣的大促中，Docker這樣的容器有什麼優點？618中有哪些業務跑到Docker中？

 

劉海鋒：目前主要有兩類場景：無狀態的應用程序，和緩存實例。這兩類場景規模最大也最有收益。不一樣的場景具體需求不一樣，所以技術方案也不相同。內部咱們稱呼爲「胖容器」與「瘦容器」技術。從資源抽象角度，前者帶獨立IP以及基礎工具鏈如同一臺主機，後者能夠理解爲物理機上面直接啓動cgroup作資源控制加上鏡像機制。

618這樣的大促備戰，彈性計算雲具有不少優點：很是便捷的上線部署、半自動或全自動的擴容。Docker這樣的操做系統級虛擬化技術，啓動速度快，資源消耗低，很是適合私有云建設。

今年618，是京東彈性計算雲第一次大促亮相，支持了有不少業務的流量。好比圖片展示80%流量、單品頁50%流量、秒殺風控85%流量、虛擬風控50%流量，還有三級列表頁、頻道頁、團購頁、手機訂單詳情、配送員主頁等等，還有全球購、O2O等新業務。特別是，今年618做戰指揮室大屏監控系統都是部署在彈性雲上的。

Q：大家是如何結合Docker和OpenStack的？網絡問題是如何解決的？

 

劉海鋒：咱們深度定製OpenStack，持續維護本身的分支，稱之爲JDOS（the Jingdong Datacenter Operating System）。JDOS目標很明確：統一管理和分配Docker、VM、Bare Metal，保證穩定高性能。網絡方面不玩複雜的，線上生產環境劃分VLANs Open vSwitch。SDN目前沒有顯著需求因此暫不投入應用。咱們以『研以至用』爲原則來指導技術選擇和開發投入。

Q：可否談談大家目前基於Docker的workflow？

 

劉海鋒：彈性計算平臺集成了京東研發的統一工做平臺（編譯測試打包上線審批等）、自動部署、統一監控、統一日誌、負載均衡、數據庫受權，實現了應用一鍵部署，而且全流程處理應用接入，擴容、縮容、下線等操做。支持半自動與全自動。

Q：這麼多的容器，大家是如何調度的？

 

劉海鋒：容器的調度由自主研發的CAP（Cloud Application Platform）來控制，並會根據應用配置的策略來進行調度；在建立容器的時候，會根據規格、鏡像、機房和交換機等策略來進行建立；建立完容器後，又會根據數據庫策略、負載策略、監控策略等來進行註冊；在彈性調度中，除了根據容器的資源狀況，如CPU和鏈接數，還會接合應用的TPS性能等等來綜合考慮，進行彈性伸縮。

目前已經針對兩大類在線應用實現自動彈性調度，一是Web類應用，二是接入內部SOA框架的服務程序。大規模容器的自動化智能調度，咱們仍在進一步作研究與開發。

 

Q：目前主要有哪些業務使用了Docker？業務的選擇方面有什麼建議？

 

劉海鋒：目前有1000個應用已經接入彈性雲，涵蓋京東各個業務線，包括不少核心應用。目前咱們主要支持計算類業務，存儲類應用主要應用到了緩存。數據庫雲服務也將經過Docker進行部署和管理。

特別強調的是，業務場景不一樣，技術方案就有差異。另外，有些對隔離和安全比較敏感的業務就分配VM。技術無所謂優劣和新舊，技術以解決問題和創造業務價值爲目的。

Q：大家的緩存組件也跑在Docker中，這樣作有什麼好處？IO什麼的沒有問題嗎？有什麼好的經驗能夠分享？

 

劉海鋒：咱們團隊負責一個系統叫JIMDB，京東統一的緩存與高速NoSQL服務，兼容Redis協議，後臺保證高可用與橫向擴展。系統規模增加到如今的三千多臺大內存機器，平常的部署操做、版本管理成爲最大痛點。經過引入Docker，一鍵完成容器環境的緩存集羣的全自動化搭建，大幅提高了系統運維效率。

技術上，緩存容器化的平臺並不基於OpenStack，而是基於JIMDB自身邏輯來開發。具體說來，系統會根據需求所描述的容量、副本數、機房、機架、權限等約束建立緩存容器集羣，並同時在配置中心註冊集羣相關元數據描述信息，經過郵件形式向運維人員發出構建流水詳單，並通知用戶集羣環境構建完成。調度方面，不只會考慮容器內進程，容器所在機器以及容器自己當前的實時情況，還會對它們的歷史情況進行考察。一旦緩存實例觸發內存過大流量太高等擴容條件，系統會當即執行擴容任務建立新的容器分攤容量和流量，爲保證服務質量，緩存實例只有在過去一段時間指標要求持續保持低位的狀況下才會縮容。在彈性伸縮的過程當中，會採用Linux TC相關技術保證緩存數據遷移速度。

Q：使用過程當中有哪些坑？大家有作哪些重點改進？

 

劉海鋒：坑太多了，包括軟件、硬件、操做系統內核、業務使用方式等等。底層關鍵改進印象中有兩個方面：第一，Docker本地存儲結構，拋棄Device Mapper、AUTFS等選項，自行定製；第二，優化Open vSwitch性能。好比，優化Docker鏡像結構，加入多層合併、壓縮、分層tag等技術，並採用鏡像預分發技術，能夠作到秒級建立容器實例；優化Open vSwitch轉發層，顯著提高網絡小包延遲。

 

參考文章：http://blog.sina.com.cn/s/blog_88d451810102vkxr.html