《京東：10萬規模容器的實踐及運營之道》要點：
本文介紹了京東：10萬規模容器的實踐及運營之道，希望對您有用。如果有疑問，可以聯系我們。

本文根據〖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日舉行,約么??

get運維新技能,怎么總是搶先一步?

“置頂”高效運維公眾號,第一時間看到相關好文章就可以啦!那怎么“置頂呢“?

請打開高效運維公眾號,點擊右上角小人,將“置頂公眾號”滑到右邊即可.

文/何小鋒

文章來自高效運維微信公眾號

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4526.html