作者簡介：

韓建飛
京東商城 基礎平臺部 資深架構師

京東彈性計算部門，負責 Docker 容器和 Linux 核心。2014年加入京東，重點在京東基礎平臺 Docker 容器二次定製開發和 Linux 核心 JD 版本優化維護，運營多箇中大規模 IaaS 叢集，包括（京東彈性雲、公有云、混合雲等產品）。

在 Linux 核心優化、Docker 二次開發，自動化部署、KVM、分散式系統等方面有豐富的實踐。

服務過中興通訊等IT公司，負責和參與中興 IPTV，CDN，軟體平臺，中興自研分散式儲存系統等開發維護。

前言

為什麼用多快好省這四個字？體現在哪些方面呢？

• 多 – 京東商城目前所有的業務均執行在彈性雲1.0平臺上，目前容器規模是15萬+。
• 快 – 我們的運維團隊人數並不多，大概兩、三個人左右，京東現在有五六千個業務，這麼多業務分佈在這麼多的容器上，維護的壓力其實是很大的。但是我們有完善的運營維護機制，如果出現問題，及時響應速度非常快，出了問題我們馬上處理馬上進行分析和回溯。
• 好 – 我們的容器在2014年的時候開始上線，到目前為止經歷了三年時間，目前為止沒有出現過大的影響業務的故障，也沒有一個 COE，目前執行相當的穩定。
• 省 – 其實是從運維的角度來講的，因為原來傳統的物理機運維要上線的話得找運維工程師操作，有了彈性雲v1.0這個之後，我們現在的運維上線流程變得非常簡單，提交一個申請，後臺處理就上線了，節省大家的時間也節省了人力物力。相對來說，傳統的運維就是要上線的話得運維工程師幫著上線，如果說某個業務上線的時候出現了問題，所有後面的上線任務都得排隊，拿著小板凳在後面等，處理好了前面的問題，後面的業務才可以繼續上線，這樣就很耽誤事兒。

本文主要寫這幾個方面：目前京東彈性運維的版本彈性雲1.0線上運營情況、彈性雲1.0遇到的挑戰分享、彈性雲1.0的主要架構、彈性雲1.0的一些經驗分享、容器的穩定性和效能的提升和現在正在進行的彈性雲2.0的啟航工作。

1. 彈性雲V1.0線上運營情況

這個是京東彈性雲推行的一個主要時間戳：

大概在2014年雙十一前面開始構思京東自己的私有計算平臺，其實當時的選擇也有很多，可以用容器、虛擬機器以及現在也比較多的 Caas 平臺，但最終我們確定了用容器來做業務。

經歷過2014年、2015年每次大促業務都翻番的狀況後，從去年底我們開始規劃彈性雲2.0，增加了很多新的特性，主要的架構也進行了變動，這是我們大概時間戳的情況。

2. 我們的挑戰

挑戰1：選擇

為什麼當時考慮使用容器？

大部分人都知道，想上一個新的系統，若非從上到下的政策強推，業務方一定會各種質疑：

• 新的系統是否穩定？
• 效能和原來的物理機相比究竟怎樣？
• 是否用得習慣？
• 是否有很大的改變？
• ……

所以我們主要考慮這三個方面：

• 第一，相容性，新的系統需要相容老的執行環境。京東老的執行環境是在物理機上，所以我們當時考慮彈性雲時，需要適應業務對於物理機比較熟悉的情況。
• 第二，物理效能，採用虛擬機器相關技術，相對於物理機總有一定效能的損失，比如說直接使用虛擬機器或者在虛擬機器基礎上搭建的 Caas 平臺。但在當時正好容器的概念剛剛興起，我們就想嘗試一下用容器。
• 第三，安全性，我們知道容器的隔離安全性並不像虛擬機器這麼好，他還是使用的 cgroup 相關的隔離的屬性。作業系統的很多的特性還是公用的，比如說核心，一些引數的設定等等。但是這些屬性其實在私有云環境下都是可以避免的，私有叢集主要為內部客戶提供服務，相對穩定，效能損失較少。安全性其實相對比較好實現，因為私有云在內部，外面看不到，網路隔離、租戶都可以不用，在當時的情況可以不用很好的考慮這個事情；而作業系統相關的隔離，可以通過業務約束來實現目的。所以我們當時選擇了用容器。

 挑戰2：向前相容

我們不可能把所有的業務一下子都部署到容器上，現在做的系統考慮了向前相容和物理機的情況。雖然當時業務對於容器這個東西還是持比較懷疑的態度，但我們自己還是比較有信心的。

 挑戰3：第一個核心系統用哪個？（單品頁）

一開始，在京東開始推廣容器的時候配合我們的業務是京東的單品頁業務。

單品頁，就是京東商城每件物品銷售時的詳情頁，是一個非常重要的業務方。

新系統上線一般是找一個不是重要的系統先上一段時間觀察一下是否穩定，然後再過渡到核心業務甚至是全部業務。

但我們當時想上一個比較核心的品類，因為核心系統比其他系統承受的流量和壓力都要大許多，如果核心繫統部署在彈性雲中都穩定了，那在業務推廣的時候，其他的業務方更加能接受，推廣的效果也會更明顯。

現在我們在核心的系統上表現非常穩定，推到其它的系統上就比較好推。

現在看來當時推彈性雲落地是一個比較明智的策略，先在核心繫統上跑起來，再推其它的系統，逐步覆蓋全部業務系統。

挑戰4：容器的效能和穩定性

容器的效能和穩定性相當重要，與虛擬機器不同的是，虛擬機器是強隔離的。但是容器不一樣，容器的許多東西都是整個宿主機共享的，這樣有可能出現一些問題會導致這臺機器所有的東西都會受到影響，這是我們當時比較著重考慮的一個非常主要的方面，就是容器的效能和穩定性。這方面，後來我們通過規範業務使用方法來規避。

挑戰5：大規模

到目前為止京東所有的業務都跑在容器上，15萬個容器，這是比較大的規模。

 挑戰6：運維成本

我們的彈性雲運維只有三人，三個人維護了現在所有的容器。運維的人力雖然不是很多，但是我們能把目前整個彈性雲集群維護的很完善。

3. 彈性雲1.0架構

1.0架構做的時候是2014年，目前這套系統執行比較穩定，從去年年底開始規劃彈性雲2.0的時候已經重新架構和規劃了。

這套架構是我們京東現在所有的容器的架構方式。從這個版本開始，我們在現有線上環境中基本上沒有做過大版本的升級。只是合入和修改了一些bug。所以這個版本相對來說在京東上跑的非常穩定，到目前為止沒有出現重大的故障。

3.1 架構展示

圖中，JFS 主要是儲存檔案的，OVS 主要是網路，OVS 所有的轉發都在核心交換機上，還有 DPDK，不是說所有的容器都有 DPDK，在網路流量消耗比較大的一些業務上，尤其是小包轉發和處理上用了 DPDK，使用DPDK帶來的效能提升還是相當可觀的。這個就是我們整個的基本架構圖。

彈性雲1.0的架構網路模型如上圖，我們的網路做的是基於 VLAN 模型的，主要是因為在京東內部其實業務之間目前都是互相打通的，因為很多業務需要有依賴，比如說我這個服務依賴於這個節點，如果你強隔離之後反而會導致出現很多問題。

還有就是考慮簡化為主的思想，所以京東的網路都是用 VLAN 模型，兩個網絡卡，eth0 主要是作為控制節點以及一些控制的資料比如說網路傳輸。

容器之間的網路交換用了另外一個網口 eth1，在 OVS 做了一個很簡單的事情，起一個 VETH 的虛擬網口將一端連在物理機的 OVS 網橋上，另外一端連在容器的口上，這樣達到網路互通的目的。網路模型相對也比較直觀，不那麼複雜。

3.2 使用例項

這個是一個線上的我們為業務同事開發的平臺，圖片中字不是很清楚，大致介紹一下，是一個業務上線、遷移、銷燬的平臺。

上線主要是業務申請名稱立項以及規格，對一個容器也就那麼多專案，規格比如說 4C 8G或者是100G的硬碟，映象選擇，還有業務名稱，然後放在資源池裡面。下次有其他人過來申請，如果這臺容器異常需要遷移過去，保證業務 ip 不變。

這樣新的系統就上線了，因為京東許多業務都是無狀態的，所以這樣對於業務使用來說就不會受到影響。對於物理機和容器都是使用這一套流程對接原有上線系統，業務方操作的時候無縫切換，提高使用者的親和性。

這是一個給運維使用的系統，主要是物理資源的管理，可以看到很多指標：叢集現在有多少臺容器、多少個資源、使用了多少、還有多少個空閒的資源，在這個平臺上都可以一目瞭然的看到。

另外還有異常訊息追蹤功能，比如說我建立一個主機失敗了，我能追朔到失敗的原因。

還有日常巡檢功能，每天把所有的物理機以及容器相關的資源使用異常的（比如說負載很高，某些系統引數的配置不正確等）通過巡檢系統發出來，用郵件發出去，可以看到故障地方有什麼問題，可以提前有針對性的改進，巡檢的選項也支援自己定義，簡單方便。

4. 全力大戰6.18

講到彈性雲2.0，很多人都會有一個疑問：會不會自動彈？

京東做的時候這塊目前都還不是完全自動彈，我們當時認為完全自動彈的成本比較高，這種彈性目前還是人為不可控的。

618備戰之前，大致一個月前就開始分資源，商城需要多少個資源池，無線需要多少個資源，這些都是提前規劃的，根據壓測的情況，需要多少資源，我們進行資源規劃。

這是每年618之前都會做的一件事情，為了保證穩定渡過618，壓測時對618和雙十一都是正常業務量的二十倍，保證二十倍流量穩定通過。

關於縱向擴充套件和橫向拓展的問題：京東目前彈性雲1.0在目前更多的是使用縱向擴充套件不是橫向擴充套件，因為我們所有的資源都是規劃好的，那麼在彈性的時候，業務壓力非常大怎麼辦？

因為容器許多的配置都是可調並且實時生效的，所以在大促期間，如果核心繫統業務量非常大的情況下，我們就進行縱向擴充套件，將部分的 CPU 或者記憶體等資源向核心系統中更多的調整和分配一些。

比如，臺物理機上跑了十個容器，發現某個核心的系統資源使用率非常高，這個時候怎麼辦？

我們可以快速的將這臺物理機上的比較空閒的容器資源彈到資源使用率比較繁忙的核心繫統或者相對重要的一些系統的資源上去。

比如說原來是4C的，換成6C、8C的，這是一個非常迅速的過程，不過這個過程目前是人工完成的。

我們彈性伸縮的過程是非常快的，由監控系統發出告警，或者反饋，如果需要彈，整個時間控制在三十秒之內，就能完成彈性工作。

在物理機上資源的分配和回收，我們目前沒有全自動化的方式來完成，依靠通過人工干預加上完備的操縱維護工具來實現。

京東現在的線上業務有五六千個，每種特點都不一樣，我們會針對一個業務在雙十一之前進行業務壓測，調整系統的引數，改一些相關的指標做一些優化以及容器分配排程策略的優化。

另外我們發現，容器的使用上儲存的效能是一個瓶頸，一臺宿主機上部署多至幾十個容器，但是磁碟的效能就這麼大。比如針對業務進行分類，或者說計算密集型的，記憶體密集型的，io密集型的，業務部署的時候要進行綜合考慮。

因為現在的伺服器記憶體資源都很充足，那麼在這種情況下，我們也可以針對特定業務，需要高磁碟io，但檔案不是非常重要的情況下，可以把記憶體當儲存用，提升應用的效能。

5. 容器效能提升

在穩定性方面，從2014年用到現在，小問題肯定有，但是目前相對來說還是比較穩定。

很多人原來是用物理機的，在使用上多少還是有一些差別的，這種情況下只能我們和業務方去解釋差別的原因，同時來帶動業務的雲化升級。

5.1 硬體環境

講一個伺服器的坑：當時某品牌的伺服器，我們買了配置一模一樣的一臺伺服器，執行起來後，發現一個 CPU 佔用25%，一個是50%，很奇怪，因為所有的容器的環境，作業系統的環境，應用業務的環境都是一樣的。

後來排查到這個是硬體伺服器 bios 的一個 BUG，調到節能模式都是 max performance，功率不一樣，就碰到這樣的一個問題。

還有就是容器例項密度對 local 機械磁碟的挑戰，另外就是不同品牌網絡卡的困擾，因為不同品牌的網絡卡，處理能力其實還是有區別的，比如說處理的中斷的個數不一樣。

還有包括 CPU 和 Memory 的比例、計量效能的規則和手段等，不同的 CPU 硬體給業務方帶來了很大困擾。一個叢集那麼多機械硬體不可能都一樣，但這是業務方看不到的，但你的 CPU 效能稍微差點，那個 CPU 效能稍微好點，一下子就看出來了，所以也會有很多困擾。

5.2 萬兆NIC

網絡卡中斷，多 CPU 分攤網絡卡軟中斷。最終調整在網路效能的小包的吞吐量與大包的吞吐量基本上和物理網絡卡的吞吐量是相當的。

5.3 Cgroup：CPU

在容器的情況下，容器下的程序的排程方式都是 cfs 的模式，我們嘗試修改成 FIFO 或者 RR 模式，但都沒有成功。

另外業務的流量與 cpu 也不完全是呈現線性關係的，關鍵要看短板或者瓶頸在什麼地方。

單純 cpu 計算資源的 load  在目前我們僅使用 cpuset 的模型下，不會對其他的容器產生干擾。

cpu set 模式和 cpu share 逃逸，它帶來的業務之間的干擾相對比較大，考慮到很多業務希望像原來的物理機的思維來執行這個容器，我們僅僅使用了 cpu set。

5.4 Cgroup：Memory

Memory 也有不少的問題，我們在計算記憶體的時候，Cache 是可以被回收的，實際計算記憶體使用率時，沒有加上 Cache  使用的量，雖然可以統計出來這個容器用了多少個 Cache，但是 Cache 的回收策略等等是整個物理機共用的。

當時發現一個問題，小檔案的吞吐量，以及每秒鐘寫和釋放的頻率非常非常快，導致了物理機的 Slab 佔用的非常多，到了作業系統的極限回收門限開始回收的時候，由於要遍歷大量 Slab 節點，回收非常慢，導致物理機上和容器上程序申請記憶體的操作都受到了影響。

當你記憶體申請由於 Slab 的回收而卡住的時候，整個物理機的內容會全部卡住，會影響其他容器。所以我們當時通過配置適當的回收閾值來規避解決這個問題。

5.5 Cgroup：資源及隔離

做使用者隔離時，我們遇到過一個問題：因為很多業務方的應用程序的執行緒數起的非常多，甚至達到幾萬個執行緒。導致程序使用的堆疊開銷非常大，這樣的話虛擬記憶體就會佔的非常高。當時的目的是為了控制執行緒數，希望目標是對每個容器的使用者的執行緒數控制住。

後來測試發現 cgroup 在我們使用的 centos6.6 版本中並不隔離使用者，好坑呀。不過新的版本好像已經解決了使用者隔離的問題。

還有比如說 /proc 下的 file-max 等等。

5.6 監控

我們會監控很多東西，包括硬體和作業系統，容器和平臺等等各種資源的使用。現在監控 CPU的負載、記憶體、SWAP，磁碟使用率，讀寫流量、讀寫iops繁忙程度等等。這些都是常用的監控。

5.7 大叢集

6. 未來

彈性雲2.0未來會把服務化更加往上提一下，我們已經規劃了一部分線上機器在使用彈性雲2.0。

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