1. 程式人生 > >京東618:Docker扛大旗,彈性伸縮成重點 (2015-06-23)

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

目前 ati 提升 2015年 如何 vlan 才會 擴容 消息隊列

不知不覺中,年中的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

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