新浪公有云Docker編排實踐

TammyBrando 8年前發布 | 45K 次閱讀 Docker 公有云

大家好，本次分享的主題是 微博DCP系統 — 基于Docker容器混合云架構的應用實踐 。

我這次分享的主題更偏向于實踐應用，比如在大峰值流量的情況下，對于私有云解決不了的問題，我們如何利用容器技術跨云端動態調度，比如10分鐘之內創建100到1000個節點解決流量峰值問題。

本次分享主要是分為四個部分:

微博的業務與混合云
業界趨勢與DCP技術架構
彈性調度
混合云三節實戰

下圖展示的微博業務規模：

從圖中可以看出，微博用戶日活躍1億，接口訪問量百億級，設備數量W+，所以每一次的技術升級對于我們都是很大的一個挑戰。

目前微博的用戶訪問特點基本上分兩種：

春節峰值流量會是平時的兩到三倍。如果為春晚花掉上千萬來采購設備，將是一筆很大的開銷。

娛樂事件。突發事件是我們無法來預料，也是我們無法預先準備的。

如上圖右上角所示，10分鐘之內數據流量呈現出3到4倍的增長，假如我們技術平臺內部是2000臺的服務器，對于 web 服務器來說，就需要10分鐘之內擴容4倍，才能承受住流量激增的沖擊。2014年微博已經做了容器化，當時只是一個私有云的建設。但是如果流量增加到3到4倍的時候，之前的技術是解決不了現在這種狀況的，可無可擴。所以我們面臨的一個問題就是，如何在10分鐘之內完成1000個節點的擴增。

上圖下方顯示的是我們公司內部項目評審及設備申請的流程，此流程耗時可能長達兩個月，無法及時應對剛才所提到的峰值問題。

目前主要的痛點基本上就是極端峰值、成本、擴展性以及業務加速迭代，這些給我們提出了更高的技術要求。今年開始我們參考了業界的混合云趨勢，比如安全、可擴展性、成本等方面。此外，國外的 Zynga 、 Airbnb 、 Yelb 以及國內的 阿里云 、 12306 、高德等公司都在用容器技術來解決問題。 Docker 、 Mesos 等容器新技術使大規模調度成為可能。

下面簡單介紹下12306的案例。基于與阿里云的深度合作，我們了解到 12306 主要查詢流量余票查詢業務都放在阿里云上，但是其數據是會經過大約幾分鐘后才會更新，所以大家在12036上看到的余票數量可能是不準確的。火車購票用戶可以容忍這種情況，但是對于微博的用戶，用戶發一條微博出來，不可能幾分鐘后才讓大家才能看到，所以這對實時性提出了更高的要求。

微博混合云涉及到公有云和私有云，2014年微博平臺實現平臺容器化，建立一個共享、安全，資源整合的私有云，2015年利用公有云的高效和低成本，開始混合云方案。我們之所以選用公有云，可以通過算一筆帳來探究一下，如果我們在10分鐘之內需要1000臺機器，阿里云支持按量來付費。假如說一臺機器每小時4塊錢，我們需要1000臺機器，一個小時需花費4000塊錢。如果我們采購1000臺機器，成本可想而知。使用公有云，在一定范圍內可以認為是無限擴容的。基于網絡方面，阿里云內部是VPC網絡，會為每個業務方創建一個內部的私有網絡，微博與阿里云之間實現兩個專線的連通，實現了網絡互通。整個混合云分兩個部分，一個是快速彈性調度，另一個是基礎設施跨云。

上圖是微博 DCP系統 技術架構的演進歷程。第一階段是容器化，2014年我們做了單機容器化、在線Docker集群。第二階段是私有云，我們用的是彈性調度，然后是基于彈性調度的服務發現以及私有云的建設。第三階段是混合云，我們把公司離線資源接入，和公司資源進行整合，多種資源管理調度框架整合，實現了跨云端的調度。

上圖是一個基本的混合云DCP技術架構圖，它來源于Docker的三架馬車，分別是編排、調度以及主機。編排系統 Jpool 發起，比如上線發布、回滾等各種命令。比如現在想要獲取1000個節點的容器信息，向調度層進行申請，調度層向Docker進行下發命令，然后獲取容器信息。基礎環境在底層Pluto系統偏主機層，它的主要作用是和阿里云主機進行打通、計算成本，最重要的是進行初始化，初始化之后首先會安裝Docker環境，包括Swarm、Mesos，之后這些機器進入一個可調度的狀態，底層通過一個專線，保證阿里的機房和我們的機房進行互通。當然除了Docker這三架馬車體系之外，還離不開一些服務發現、鏡像中心、監控中心、容量評估等。

上圖是我們的技術棧，主機或VM主要是私有云裸主機，公有云VM，在上面進行Docker的具體化；OS方面，線上90%的業務已經升級到CentOS 7.0；Docker 版本是1.6.2，之所以還在選用Host模式，微博訪問流量量非常大，選用其他模式導致我們的系統性能有所下降，所以我們選擇Host模式。Iptables我們也是關閉的，因為打開它之后會影響性能。Docker Registry方面，我們構建了自己的倉庫，有V1、V2的版本，實現分布式跨IDC動態同步。Swarm版本是1.0.0。部分小規模的服務用Marathon是進行調度。所有的服務發現基于Consul的，Consul的版本是0.6.0。

上圖顯示的是混合云DCP功能模塊，基本上分為PAAS、IAAS和基礎框架。容器技術雖然解決了我們快速發布問題，但是如果要真正解決峰值流量的問題，還需要建設完整生態體系。

下面簡單介紹一下DCP的核心思想，2014年的時候只有微博平臺內部進行了Docker化，微博的業務是這樣的，用戶用電腦刷微博的時間集中在中午，晚上用戶大都用手機刷微博，而且在凌晨的時候，我們的離線機又開始忙了。每個部門每個時段，它的機器會有空閑的狀態，如何把這些空閑的機器利用起來，設計共享池機制，評估它的容量壓測，比如根據一些系統指標還有一些SLA的情況判斷，如果機器空閑自動進入這個共享池狀態，進入共享池就代表是可供調度的狀態，共享池的機器可供動態調度。DCP整體的模式是基于銀行的運作機制。

上圖是容器的一個生命周期。以私有云為例，當某一部門的機器空閑的時候，它進入共享池，代表這個機器可以用，這個機器進入共享池之后進行初始化，初始化之后按照上圖下方所示，Docker環境或者是機器環境啟動，代表容器可以進行動態調度，直到容器上線。中午不繁忙的時候，容器進行下線再返回共享池。

簡單舉個例子來說，比如此時需要機器，原來共享池里面ABCDE各個業務方空閑都共享給共享池，根據容量評估這時容器可以下線，然后利用資源進行動態擴容。當不需要機器的時候，歸還共享池。

整個流程其實可以模擬成這樣：首先是主機申請，包含內網申請和云端申請。內網申請相當與在共享池里面申請，但是內網會出現一種情況，假如平臺有2000臺機器，當出現5倍或者10倍流量增長的時候，擴無可擴的時候，則進行云端申請。拿到主機之后進行初始化，初始化的時候主要安裝兩個環境，一個是系統環境，一個是Docker環境，Docker環境大家都理解，肯定要把Docker裝上，容器才能運行，成為可動態調度的模式。為什么還要裝系統環境？任何一個公司的產品、任何一條業務線，業務跑到一個真正全新的主機上，肯定有自己的系統環境或者各種各樣的配制、腳本等。我們系統初始化的時候，其實是按照業務方進行選擇，業務方用各自的模板來初始化。基于初始化之后，可以進入動態調度的階段，然后使用算法實現動態調度。比如申請了1000臺機器，容器上線之后，再調度上面的服務發現策略（Nginx、Motan、SLB），然后進行反初始化，歸還Buffer池、結算中心。剛才提到按小時算的成本，按小時每小時4塊錢，還是趕快歸還比較好。

上圖為主機申請的流程。阿里云在北京有三個機房，每個機房據介紹有萬+臺機器，用戶可以選擇可用區域，然后選擇交換機確定IP端，選擇VPC網絡，VPC網絡可認為自己獨立的私有網絡。選擇操作系統VM鏡像，剛才提到初始化的時候，有Docker環境，在整個環境動態擴容的過程中，動態調度的要求幾十秒內完成。比如我有2G的鏡像，還有70M的JDK，千臺節點拉這么大鏡像鏡像倉庫、網絡帶寬都是很大調整，這時候要怎么辦？所有的云產品每隔6小時，把所有的系統VM鏡像進行備份，比如我所有的鏡像拉下來之后，包括Docker都放在云盤上，相當于一個備份，比如說下次創建主機申請的時候，選擇已經做過的鏡像，在這個操作系統上的鏡像創建機器，這樣基礎鏡像就在VM鏡像上面，這樣大大縮短了拉鏡像時間。最后選擇機器配制，選了主機配制之后初始化進行動態調度。初始化是其實基于Ansible，因為阿里云提供的是SSH訪問，Ansible會有性能問題，在Ansible使用過程中我們做了優化，提高其性能。下圖系統環境裝了dnsmasq、ntp、cron等，軟件環境安裝了Docker、Swarm、Consul。

談到調度都離不開Swarm、Mesos、K8S，大家講的比較多的都是Mesos、K8S，先說一下結論，今年年初的時候我們選用了Swarm，我們認為最適合業務的才是最好的。為什么選擇Swarm？，因為它是Docker體系原生的，整個體系比較簡單，也能支持我們的內存隔離，支持我們的分組調度，當然它是以標簽的形式實現的分組隔離。微博備戰元旦峰值時，需要整合離線技術資源及公司其他業務線帶來了新的挑戰。離線Hadoop計算資源服務器大多操作系統為CentOS6. ，CentOS6. 支持Docker1.6.2版本存在bug，而Swarm調度獲取內存、CPU資源信息依賴Docker版本必須大于Docker1.6.2。以此為契機Roam擴展支持Mesos + Marathon、直接Docker Demon下發兩種調度方式。考慮后續整合公司的離線資源，k8s現在在非容器方面還有瓶頸，所以暫沒有考慮。

其實我們的需求是實現內網計算資源的統一調配，公有云上獲得計算資源，快速自動化部署。上圖有一個接口層，我們提供了通用進行調度來滿足以下的功能。任何一個調度框架都不能完全滿足我們的需求，拿到的任何一個框架也不能直接用，因為可能要有一些特性化的需求，比如服務池的動態擴增容，跨服務池、跨租戶來調度，以及單機業務的灰度、多實例的部署、故障自動恢復、容量評估、跨IDC的高可用，所以我們做了二次開發，對外提供統一的Rest API。

Swarm集群規模估計是國內相對比較大規模。重點講一下Swarm，Swarm屬于輕模式。首先我們做了它的高可用，就是雙主策略，多機房的調度，還有對它的調度性能、調度算法做了一個優化，包括一些分組的調度和一個調度策略的設計。Swarm在最開始版本發起調度有全局鎖，這樣整個過程就變為串行，影響調度性能。排查發下調度慢主要集中在拉鏡像慢，改進優化為預拉鏡像，提升性能。Swarm1.0版本后改為分布鎖，同步也大大提升性能，內部測試單機房Swarm支持千節點是沒有問題的。針對以上問題針對Swarm進行二次封裝，研發出調度適配層系統Roam。Roam對外提供Rest API，通過Swarm獲取Docker容器信息，外層自適配調度策略后下發Swarm集群，同時支持Docker Deamon直接下發。

現在簡單說一下我們怎么做的高可用，動態調度的多IDC、高可用、可擴展。Swarm集群按照機房進行拆分，高可用、動態擴展

1. Swarm Manage、Client節點向Consul服務發現注冊，當前Manage在Consul處于加鎖狀態

2. Roam根據IDC參數從Consul獲取需要調度機房 Manage信息

3. Roam彈性調度策略，訪問當前Manage，選擇資源動態擴縮容

4. Swarm Mange從Consul獲取節點信息，30s緩存Node節點信息

當其中一組Master節點Down掉，Standby Master注冊進入Consul成為新主

簡單介紹下Swarm調度算法：調度=主機 or 容器過濾 + 策略選擇

主機/容器過濾通過過濾器（標簽）實現 docker run --label idc="tc"

主機/容器過濾后，根據各個節點的可用的CPU, Mem及正在運行的容器的數量來計算應該運行容器的節點進行打分，剔除掉資源不足的主機。

調度顆粒度

Memory：docker run –m 1g …

CPU：docker run –c 1 …

基本所有的調度框架分組調度都是標簽，Swarm基于Docker Deamon Label標簽（Docker Label標簽修改必須重啟Docker Deamon，在最近官方Docker 1.10.0版本已支持Docker Engine配置熱更新，使容器與Docker Deamon的耦合性大大降低）。在Docker Label標簽基礎上，對標簽進行擴展進行落地存儲，記錄執行不同調度策略，集成Swarm調度算法，支持跨集群/服務池調度、指定IP規劃、定時調度、多實例調度等

Swarm的調度算法并不是太神秘，最核心的調度算法，最簡單來看就是使用的CPU或內存除以物理機的內存，就是物理機所用資源占比。再看一下CPU的分數，如果內存的分數同時滿足的話，總分數為CPU加內存的分數，并非很復雜。如果大家需要定制自己算法策略，可以去修改源碼或者使用其他算法，但是目前這種條件下滿足我們的需求，比如把這些策略選擇出來之后，有一個80分，有一個90分，我們肯定選擇用90分的。因為我們是盡量保證主機資源均攤使用。在調度算法中大家需要注意一點，就是Swarm資源只與容器Create時配置設定資源參數有關，與運行時實際使用資源情況無關。無論容器是否由Swarm創建，無論容器處在何種狀態，只要配置了資源限額，調度時均會計算在內。

我們跨云端調度還面臨其他挑戰。千臺節點服務同時拉取鏡像，還是跨IDC情況，鏡像倉庫是扛不住的，很容易因為拉鏡像時間過長導致調度失敗。在內網的情況下我們的Docker不會遇到這個問題，因為大家機器上都用Docker，基礎鏡像都已在上面，阿里云端為新裝機ECS，沒有基礎鏡像。我們在內網做了自己的私有倉庫，在阿里云上做了自動同步私有倉庫的鏡像緩存集群，后續云端擴展到了多級鏡像緩存。

跨云端服務發現的時候，七層流量的頻繁變更會影響業務性能。微博Nginx Plus的開源版，支持基于Consul的自動服務發現，Docker容器啟動會自動向Consul服務注冊中心進行注冊，Nginx的模塊我們開發了自己的一個Core Module，作用就是去Consul拉剛才注冊的容器節點信息，然后同步更新，實現平滑流量變更。可以看下上圖，這是我們使用Nginx Plus之后，服務變更耗時基本無波動。同時我們設計了動態修改線上云端節點的權重動態適配后端的處理能力，公有云同等配置存在20%的性能損耗，建議權重調低。微博內部用的是Motan RPC的服務發現，它支持跨IDC流量切換，支持按流量權重配制定向路由。DNS服務發現，我們在阿里云上構建DNSServer與內網保持同步。

還有最重要的是監控體系，服務真正跑起來，怎么知道健康狀況？我們的監控分四個級別，系統級監控、業務級監控、資源級監控和專線網絡監控。業務級監控是全網監控到單機容器監控。我們的容量評估系統在線壓測確定服務指標，根據單機的平均系統指標（CPU idie Mem Load）帶寬、業務SLA綜合指標容量評估，來決策服務的擴容或者縮容。

當上面所有的都做完之后，主機創建，初始化完，動態調度完畢之后，然后簡單來看三節保障與阿里云部署。在春晚時主要擴容無狀態Web服務，可以做到10分鐘擴容到千節點容器規模，抵抗峰值流量。在這里大家要了解一個情況，阿里云產品會有PPS的限制，可能在內網的時候PPS達到幾十萬沒問題，云產品上限是10萬+左右，會影響業務單機承載能力。

跨IDC混合云架構離不開基礎網絡，微博本身在北京核心兩個機房。阿里云在北京有三個可用區，最大的是A和C，它是BGP多線接入的，微博電信、聯通兩根專線分別于阿里云A、C機房微博私有VPC網絡互通，專線保證高可用，任何一條專線斷了之后，另外一條路由自動進行切換。中間還搭了一個V*N網絡，這個是走公網的，有一些需要推日志或者一些業務因為數據需要交互就走公網，因為它沒有實時性的要求，我們就走這條線路。

總結一下，其實2014年我們做了容器化，混合云DCP項目是在2015年10月份上線的，所有集群按三個IDC來拆分，峰值2500+的容器，包括業界前一段也有測試，一秒鐘創建3000個容器乃至1萬個容器是沒問題的。雙十一微博內網實現單日10多次擴縮容，單次擴容小于5分鐘。元旦的時候實現的跨云擴容，微博混合云架構小規模試用。春晚動態擴縮容阿里云ECS千臺+規模，承載微博核心Feed流及紅包飛流量。

這次分享偏向項目應用實踐，最大感觸就是從業務需求出發去設計系統架構，沒有最好的架構和技術，目標是業務需求完成。比如我們現在真正實現了10分鐘創建1000個節點的能力，解決了這種峰值流量的問題，Swarm其實滿足業務目標應用場景，所以就選擇了Swarm做容器調度。在用Swarm的過程中，包括一些單機灰度、分組調度問題，我們通過二次開發來解決。Swarm使用遇到的問題在其他資源調度框架都會遇到，沒有任何框架都是拿來即用，最重要就是去實踐，總結共性，設計通用性架構，所以就有了Roam的適配層適配不同調度框架。混合云項目周邊體系比如監控、服務發現、在線容量評估等也是非常重要，這也是任何云平臺不可缺的組件。