本文根據〖2016 全球運維大會•深圳站〗現場演講嘉賓何小鋒老師分享內容整理而成，文字編輯：吳召軍@騰訊，錄音整理：劉玉強@京東。

歡迎關注“高效運維（微信ID：greatops）”公眾號並置頂，以搶先賞閱乾貨滿滿的各種原創文章。

講師介紹：何小鋒

擁有18年的研發經驗，喜歡技術，追求卓越。

2011年加入京東，擔任了京東兩屆架構委員會常委。在京東負責過百億級的分散式訊息系統。2014年下半年開始負責基於Docker的彈性技術平臺，通過諾亞方舟專案，成功的讓京東各個業務系統全面遷移到容器上。

在京東期間支援過多次的618和雙11大促，見證了京東的技術演進過程，在彈性計算、中介軟體、儲存和大併發分散式系統等方面積累了豐富的實踐經驗。

大家好，我是來自京東的何小鋒，今天我跟大家分享一下《京東Docker的實踐經驗》。

1、京東容器之路

1.1 面臨的挑戰

京東為什麼要使用Docker？京東在以前主要是基於物理機進行應用的部署，隨著京東業務的發展，面臨著很多挑戰。

比如說，硬體採購週期比較長，新的應用有可能會等一個月，物理機才會上線。

很多應用部署到物理機上，應用資源的使用情況，大家掌握得不是很清楚，你沒有辦法精細化運營這個應用。

它是用得多了還是用得少了？而且硬體的成本也很高，每年京東物理機採購上萬臺，成本很高。

在雙11或者6·18之前會做一些壓力評估，需要快速擴容，現在擴容的話如果採用物理機的話，京東會花費一個月的時間進行擴容操作，非常慢。京東還有很多資料中心，要把整個部署完需要很長的時間。

1.2 使用者關注

我們採用一些虛擬化或者容器的技術解決我們面臨的問題，在跟使用者溝通的過程中，使用者真的不太關注你是採用物理機還是容器、虛擬化的技術，其實他們更關注的是，你給我換了技術以後，系統是不是穩定的？

例如，一些下單操作、京東首頁效能要求敏感的應用，對效能是非常看重的，如果使用容器，要確保效能沒有損失。

京東有五千多名研發人員，要確保使用者的體驗，如果你換了新的技術，還需要對所有的人再一次的培訓，花費的時間是非常長的。

1.3 容器化之路

在2013年我們最初採用的是虛擬化的KVM的技術，在用的過程中，面臨了效能的問題，有幾個核心的應用效能達不到要求。

在2014年我們看到容器發展比較迅速，在2014年四季度採取容器技術進行試點，最先試點的是京東圖片系統，發現效能非常不錯，而且我們做了彈性伸縮排程，效果也非常明顯。

所以，我們在2015年第一季度就把彈性的平臺做起來了，在6·18的時候就用在了生產環境，在6·18的時候沒有采用物理機來分配，能分配容器的全部使用容器分配，分配了差不多1萬個容器。

在6·18期間非常穩定，並且在下半年新機房的建設全部採用容器建設，目前京東的容器數已經差不多有10萬的規模。

1.4 選擇Docker的原因

我們從KVM切進Docker的時候，做了一個評估，我們覺得Docker還是非常勝任京東應用場景的。

它比較輕量，效能比較好，可以快速部署，穩定性足夠高，在京東的環境下對安全性也要求不高，所以說，我們用Docker非常合適京東私有云的環境。

2、彈性計算架構

其實京東的私有云的彈性的架構還是比較簡單的，我們採用了開源和自研相結合的架構。

基礎的平臺更多的採用社群開源的技術，包括OpenStack、Docker、虛擬化網路、OVS，儲存是採用京東資源的分散式儲存系統。

在上層我們使用的是自己的一個排程系統，是一個CAP的排程，它做了一些應用的治理和部署，包括彈性的排程、監控。

2.1 OpenStack

在Docker的外面我們包了一個OpenStack，社群裡有很多人不使用OpenStack，其實我們是結合京東的一個現狀來採用的OpenStack。

京東做虛擬化是從OpenStack開始做的，所以說下面的團隊對OpenStack還是非常瞭解的，我們沿用OpenStack做叢集的管理，而且OpenStack也相對比較成熟。

我們做Docker的時候，社群這些都不是很完善。所以，我們就是沿用OpenStack，而且OpenStack社群的方案還是非常多的。

還有一個目的，我們現有的京東公有云也是做了OpenStack做了叢集的排程和管理。

2.2 網路

網路方面比較簡單，我們就直接選擇了OVS/VLan的模式進行處理，但是在效能上我們做了優化，特別是一些包的延遲，做了很大的提升。

經過我們的優化以後，本身網路的一些效能會有20%的提升。

為了保持使用者的習慣，京東所有的基礎設施都是以IP來做區分的，所以我們為每一個容器都分配一個獨立的IP。

2.3 儲存

我們是使用了京東的自研的分散式系統來接JFS來做塊儲存，本地儲存是用於滿足日誌的需求。

把日誌打在物理機上，不是打在容器裡面，主要是為了滿足容器丟了，日誌還可以檢視一段時間，通過分散式的日誌系統，近實時地把日誌採集走，如果容器宕機的情況下，它可能會有那麼一丁點時間日誌沒有上傳到分散式日誌系統中，但是可以人工地恢復這一塊的資料。

2.4 映象分層合併

映象分層上，我們採用了OS層、基礎層、應用層的架構，把平時變更比較頻繁的應用層做了映象，相對比較小，這樣可以減小一些儲存的壓力。

2.5 映象中心

在京東有比較嚴格的專案管控機制，我們會對生產環境、線上的環境、預釋出環境、開發、測試環境，我們會對線下的測試環境把映象做好，做好之後再推到生產環境。

映象在開放環境和生產環境是嚴格隔離的，必須要經過一些處理才能上傳到生產的環境上。

映象的儲存還是使用我們京東的JFS這樣一個分散式的物件儲存，它也支援塊儲存。

2.6 配置中心

京東有很多不同的環境，它的配置是不一樣的。所以，構建了自己的配置中心，在容器或應用啟動的時候，可以自動拉取對應的配置，可以滿足一個映象儘量不用改動就可以部署在多個環境裡面。

2.7 排程系統

我們自研的排程系統是一個類似於工作流的引擎，能夠做到動態服務發現，便於擴容。

為什麼要採用這樣呢？

容器排程更多的是一個流程的排程，它要把京東的基礎設施等按照一定的流程串起來。

我們目前實現的一些排程流程，包括線上做一些映象，包括上線、下線、重啟、故障牽引、彈性收縮。

2.8 彈性擴容流程

這一塊的流程，我們首先做了彈性的評估，覺得要進行一個彈性擴容以後，首先會建立整個容器，會做一些相關的授權。

比如說，可能會有一些MySQL的授權，還有一些其他許可權的授權，通過我們的部署系統把這個應用部署上，再去檢測這個應用是否起來了，這個應用起來的時候也有可能出現一些故障。

 在整個起來以後，才為把我們的監控、統一日誌註冊上，最後正式起來以後才會把流量打進來，呼叫一些負載均衡，讓它把流量可以引到這臺容器上，最後再上一個彈性的流程，才是一個完整的結束。

2.9 故障遷移流程

在一些故障遷移方面，如果檢測到某一臺主機或者容器出現故障的情況下，也會觸發它遷移的過程。

牽引首先會把流量摘掉，讓沒有流量打到容器上，建立一個新的容器把應用部署上，然後把它註冊起來。

我們在牽引的過程中會保持整個容器的IP不變，這樣就少了很多其他授權的一些操作了，資料庫授權這些東西就不用再去做了。

2.10 彈性排程演算法

京東也實現了自動的彈性排程，彈性排程的演算法相對還是比較複雜，它會根據我們現有應用的一些元素和資訊，包括應用的重要程度、所屬的業務域、需要的軟硬體來進行評估，還有需要的規格，這個應用需要部署哪些機房，所有的資訊我們都會彈性排程選擇對應的機房機架。

我們還做了一個擴充套件，集成了京東微服的一個框架，會把微服採集到的一些效能資料給彙報上來做一個評估，是否要對這個應用進行擴充套件，進行一個彈性排程。

彈性角度目前是根據應用的分組，在一個機房的負載情況下做一個彈性，而不是根據一個容器實時地進行彈性，最後是應用整體情況負載做一個彈性。

因為有時候出現一些應用程式的Bug，可能某臺負載比較高，但是整體負載比較低。

3、彈性計算應用場景

現在核心的一些應用，除了大資料的應用，其他應用基本上全部牽到這個容器上，我們現在所有的機房都是用容器建設的，主要應用的技術架構都可以牽進來。

比如Nginx等，還有我們京東的微服的架構JSF，包括Oracle的一些應用，還有redis，redis在京東是一個非常大的容器叢集，它也是放在我們這個容器上。

京東也在用容器做MySQL的管理，不是所有的應用都需要微軟很高效能的MySQL獨享物理機，我們有一個雲資料庫是提供一些其他應用來使用的。

4、自動化運維

4.1 系統監控指標

我們採納容器來做推廣以後，對我們一些自動化的運維也做了很大的幫助。首先是監控，我們會把所有容器的基本指標都能採集到，包括系統的負載、網路的流入和流出，在這方面的一些指標採集也做了擴充套件。

把這些資料採集起來之後做一些實時的計算，存在基於Hbase的資料庫下，這個量也非常大，我們現在容器量很大了，每一分鐘都有這樣的資料上傳下來，所以資料量是非常大的。

然後，會做一些監控報警，根據自己的一些指標進行配置，是否需要去做監控報警。另外，根據這個指標其實也可以觸發我們自動彈性的一個伸縮策略。

4.2 監控頁面

可以對一個容器進行監控，也可以對一個應用做一個整體的評估，包括這個應用網路流出、整體CPU佔用量，可以從多個維度進行檢視。

4.3 報警策略

可以讓應用進行個性化的設定，只需要設一套策略以後，每一個容器出現問題都會進行實時的報警，包括一些郵件、簡訊的通知。這也是跟我們京東所有的使用者體系打通的。

4.4 一鍵水平擴容

我們要做擴容，以前擴容要部署物理機，各種情況也是非常麻煩的，現在我們可以快速地擴容，一鍵地進行擴容。

4.5 一鍵垂直擴容

除了這種水平的擴容之外，還支援垂直的擴容，因為應用有可能會對一些規格進行一些調整，比如要把自己的記憶體擴大，這方面也做了一定的垂直擴容。

但是這裡是有一定侷限的，如果本機上不夠的話，我們只能牽引到其他機器上進行擴容。

4.6 宕機探測架構

自動化容器宕機檢測

因為有很多機房，有可能一個點去檢測機器的話，評估出來的報告是不準確的。

所以，我們在每個機房裡都會有很多檢測的程式，每個機房只負責檢查本機房的容器，分佈在不同的機架上、不同的交換機上，同時檢測某一臺容器，如果說全部認為這臺機器可能會宕機，我們認為它的評估是比較準確的，認為這個容器宕機了就觸發故障遷移流程。

4.7 硬體故障探測

對於硬體故障我們進行了一些檢測，這裡主要是通過一些協議，拿物理機硬體報警的一些資訊，京東的物理機數量越來越多，但是採購的機器或多或說的經常會有一些問題，所以說我們需要自動地檢測出來，及時地進行通知，做一些故障牽引。

4.8 故障通知

我們檢測到物理機出新故障以後，會馬上給相關的人做一些通知，進行一些處理。

4.9 應用部署巡檢

在使用容器建設過程中，隨著新機房的建設，逐步的擴容會造成一些應用部署的情況並不是非常健康。

我們會從應用的整體架構會做一個巡檢，報告某個機房部署過多，如果需要跨機房容災的話，必須確保兩個機房的數量一致，還需要確保應用跨交換機部署。

如果應用在一個交換機下部署過多的話，該交換機宕機會影響應用的承載能力。

所以，我們會從多個角度巡檢部署是否是健康的，做一個郵件的報告，讓應用進行一些調整。

5、資料驅動的精細化運營

5.1 資源利用率

在精細化運營上，會以每個小時為單位計算容器資源使用率，然後根據容器的資源使用率計算應用的資源使用率，通過應用和部門關係，計算部門資源使用率。這樣，我們能夠很好地控制目前的應用隨意申請容器。

5.2 容器資源利用率

通過容器資源使用率，通過簡單的資料的分析，可以計算出應用使用情況。

如果一個新的應用來申請容器，可以找到一個類似的應用評估一下容量的數量，包括負載的情況，可以得出一個合理的資料。

5.3 部門資源利用率

部門的資源使用率可以作為部門考核的依據，這樣可以看出部門申請了多少資源，整體的資源使用率是高還是低。

5.4 資源剩餘情況

掌握現有資源情況，還剩餘多少，是否需要儘快補充資源，可以給硬體採購的人提供一些建議。

5.5 配額管理

京東有一個比較特色的東西就是配額的管理，因為京東是一個非常大的集團，大家資源的需求可能各不相同，為了滿足一些重要系統的需求，我們會對一、二級部門進行一個資源的隔離。

界定這個部門最多可以使用多少資源，做一個整體的劃分，下面所有容器的申請、彈性的角度都必須在總體的配額下進行管理。

6、實踐經驗

• 無狀態，同時對磁碟IO要求不高的應用，很適合部署到彈性雲
• 微服務應用由於能自動服務註冊發現，輔助均衡，非常適合部署到彈性雲
• 推薦使用萬兆網路和網絡卡，避免網路共享出現資源競爭
• 選擇穩定的作業系統版本，不同的版本可能會有一些核心的Bug，一旦出現問題，整個系統都會出現問題，對應用來說是災難性的
• 推薦高配置物理機，合理得CPU和記憶體比，便於充分利用資源。如果說不合理的話，會浪費很多CPU和記憶體
• 採購高質量的交換機和物理機。如果物理機有質量問題，可能會影響非常多的應用，對這方面我們的要求把關是非常嚴格的

今天我跟大家分享的內容就到這裡，謝謝大家！

Q&A

提問：現在容器的應用已經差不多到了十萬的規模，看到監控整個容器裡面的情況，光容器這部分的指標就已經達到了近百億了，對監控的資料資訊是怎麼處理和儲存的？

何小鋒：我們是使用的Open TSDB這樣 基於Hbase的，京東有一個大資料部門，它會運營Hbase，它有一個非常大的叢集，我們全部存在裡面，資料一直不會刪除，這樣會之間地根據資料分析應用的資源情況，也可以做資源的未來預測。

提問：接著上一個朋友的問題問一下，MySQL其實也是部署在容器裡面的，但是一般來說MySQL資料庫是不建議這麼做的，您當時是出於什麼樣的考慮？

何小鋒：京東有一些非常核心的應用的MySQL，目前還沒有部署在容器裡面。但是還有很多的應用對IO要求不是很高，如果每個應用獨佔一個MySQL，其實是非常浪費的。

所以，我們會採用一個雲資料庫的方案進行管理，主要是做資源的隔離，為效能要求不是很高的應用，提供MySQL的服務。

提問：一般我們用Docker如果這個出現問題，直接把它停掉直接推一個，但是資料是放在上面，一推全部的資料都丟了。

何小鋒：京東本身的MySQL也要做高可用的方案，它也有自己的主從、資料的複製，當一臺資料丟了，通過DBA主從切換，繼續提供服務。

提問：原生的Open STDB只支援數值型的資料插入，對於字元型資料是怎麼處理的，是直接操作原生Hbase嗎？

何小鋒：我們現在存的全部是數值型的，沒有字元上的。

提問：你裡面有一個註冊日誌服務的功能，我想了解一下注冊日誌服務的應用場景和所應用到的技術，比如有沒有用到流處理？註冊的話，應該有一個日誌的收集，收集包含了什麼樣的應用和系統，Docker支援嗎？這方面希望關注一些。

何小鋒：京東的日誌有專門的一套平臺進行採集和收集，你建了一個容器以後，需要把應用和資訊推給它，它才能把容器產生的日誌、目錄這裡面的資料採集到。它是一個單獨的日誌系統，它會實時地採集資料流，釋出到平臺上供檢索。

提問：我們發現在共享磁碟的情況下，它的高速讀寫會有一些效能損耗，可能沒有那麼高，IO不能達到那麼高。這樣，假如說日誌打得很滿的話，打到資料磁碟這一塊怎麼處理？

何小鋒：有幾個日誌要求效能非常高，我們並不是直接打到物理機的硬碟上，採用了記憶體檔案系統方式，讓它的效能更高一下。

提問：本身做了一個第三方的記憶體檔案系統。

何小鋒：對。

提問：比如說，像你們非常多的容器，整體的服務發現排程能再說一下嗎？

何小鋒：京東很早就有一個微服務的架構，目前京東的應用都是基於該服務架構，它本身原生已經支援了服務發現，我不用在容器上再做很多的服務發現的擴充套件工作，應用起來本身會自動地把一些服務（地址）提供上去，讓消費者就可以連上來進行資料的處理。

提問：請您詳細說一下，您剛才說容器對高IO不是很好，您怎麼得出這個結論的？

何小鋒：本身一臺物理機上會有非常多的容器，有非常多的應用在跑，大家如果都是高IO的話，肯定會有競爭的問題，如果是獨享，IO影響不大，但是如果大家的應用都是同時享IO的話，就會影響。

比如說，一個應用是大資料的，它拉大量的資料，又遇到一個應用是瘋狂地刷日誌的情況，肯定會對IO有影響，現在也經常有這樣的問題需要我們去解決。

提問：您說的CPU和記憶體比指的是物理伺服器，能不能分享一下您這邊推薦什麼樣的CPU和記憶體？

何小鋒：這是根據不同公司而定的，我們京東採集一般都是64G、256G的記憶體，京東為了效能，把很多本地化記憶體為了充分地利用起來，一個應用起來可能希望你給8G、16G的記憶體。

我們根據這個應用它需要多少，如果是普通的應用，需要4C、8C，如果記憶體過低，如果用4C，差不多有60多個核，可能會用15個容器。如果是15個容器，每個應用希望是16G的記憶體，太少了，你根本就生不了那麼多。

所以，可能需要你的記憶體，滿足應用的需求。但是不同的公司是不一樣的，要根據自己公司的情況去計算。

提問：剛才說的十萬個容器，Docker引擎一直在升級，對於我們的容器存續時間這麼長，容器升級是怎麼做的？

何小鋒：我們到現在還沒有升級，現在還使用的是最原始版本。

提問：新建的容器呢？

何小鋒：容器的版本和作業系統一樣，不會隨便去升，雖然新版本容器提供了很多新的功能，但是一旦要升的話，我們所有的架構需要做一些調整，對系統的穩定性影響是比較大的。

提問：終於有這個提問的機會，今天是唯一一個在容器中講到儲存的，我是做儲存的。我說的資料庫是更底層的，我們的容器和儲存之間能不能做一個配合，我們一個系統解決方案中做容災，容器容災有兩種辦法，基於容器的解決辦法本身怎麼做，兩者之間有沒有結合？京東有什麼考慮？

何小鋒：儲存也是可以做容災的，我們現在是分散式的部署，我們目前的應用就是做了一個分散式的儲存系統。一旦應用要上容器，我們要跟他溝通應用的場景，比如說資料恢復以後，宕機以後資料還是有需要的，從另一臺機器恢復，這樣的場景我們都會使用分散式的儲存系統。如果本身資料影響不是很大的話，就可以讓它使用本地儲存，沒有去做嚴格的規定。

提問：我想問一下，京東的監控代理是在每個主機上部署，還有選擇性的部署？

何小鋒：我們每個主機上都會有，其實我們現在監控是系統層面的監控和應用層面的監控，應用層面的監控是在每個容器裡面都有的。

我們現在有很多應用的指標，呼叫到一些效能，這些東西我們是在每個容器裡都有。我們容器裡面監控的指標會佔到5%左右的CPU，本身效能對應用影響不是很。

提問：京東的容器布在物理機上，你們有沒有做業務隔離，兩個應用系統用了容器做安全性的隔離？

何小鋒：我們對應用的業務域或者重要級別是有區別的，根據應用單獨把物理機做一些劃分出來，比如這一臺物理機就是給某一臺重要的業務做的。

提問：物理機各個應用之間不會互用這臺物理機，是吧？

何小鋒：對，如果是應用有這方面的需求，我們是可以這樣做的。

提問：你們當初把它建在物理機之前，有沒有考慮在虛擬機器上搭容器？

何小鋒：虛擬機器的話，它的效能已經滿足不了應用的需求。

提問：是儲存的系統嗎？

何小鋒：虛擬機器的效能是達不到的，它本身要做一些系統的排程，資源的開銷還是比較大的，因為京東6·18的壓力非常大，一旦有10%、20% 效能損耗都不可以。

提問：固態容器裡的應用應該是分散式的，虛擬機器損耗的點通過更多的容器來支撐，應該問題不大？

何小鋒：但是虛擬機器效能比較多，需要的資源會更多。

提問：應用是不共享物理資源的，如果新上來一個開發應用，新上的應用比較多，這個資源池會提前做好嗎？

何小鋒：也不是所有的應用都共享，我們只對核心應用的策略做一些劃分，大的應用可能一臺共享這個資源，如果應用上來我們會根據業務域，我們知道這個業務是否是重要的，這個業務是用於下單的還是生產的，它的業務域不一樣的話，重要性也是不一樣的。

提問：何老師說要用好的網絡卡、好的伺服器，請問你們用的是什麼網絡卡？是英特爾的，戴爾，還是IBM  x86伺服器？

何小鋒：我們用的是x86伺服器，採用大廠商的伺服器，如戴爾。網絡卡的話，目前新採購的都是萬兆網絡卡，英特爾的比較多。

提問：你們的虛擬化用的是什麼樣的軟體？是KVM嗎？

何小鋒：KVM已經被我們放棄了，我們就是基於容器。

提問：是在物理機上，是嗎？

何小鋒：對。

提示1：點選文末“閱讀原文”連結，即可下載本演講的PPT及實況錄音。邊聽邊看，豈不快哉？

提示2：更加精彩的GOPS全球運維大會·上海站即將於9月23-24日舉行，約麼