微服務容器化運維繫列的前兩期，我給你詳細介紹了微服務容器化後如何運維的幾個關鍵問題：鏡像倉庫、資源調度、容器調度、服務編排，這些問題的產生都是因爲微服務部署的節點從一臺臺物理機或者虛擬機變成了一個個容器，運維模式發生了根本性的變化。此時，容器運維平臺也就應運而生。
微博的業務從2013年就開始進行容器化，2015年爲了應對春晚以及突發熱點事件帶來的峯值流量，開始引入阿里雲；同時也爲了適應業務的發展和運維方式的變化，在2015年底開始研發新的容器運維平臺DCP。今天我就和你聊聊微博容器運維平臺DCP，我會講講一個真實的容器運維平臺是如何建設的，在建設過程中面臨了哪些問題，以及對應的解決方案，希望可以讓你對容器運維平臺的架構有所瞭解，並提供一些經驗可供借鑑。
DCP整體架構
首先我們先來看看DCP的架構設計，從下面這張架構圖你可以看到，DCP的架構主要分爲四個部分：基礎設施層、主機層、調度層、編排層，對應的分別解決前面提到的容器運維平臺建設的幾個關鍵問題：基礎設施層用於解決鏡像倉庫的問題，主機層主要解決如何進行資源調度的問題，調度層主要解決容器如何在資源上創建的問題，編排層主要解決容器如何運作以對外提供服務的問題。下面我們來看各層的詳細設計。
基礎設施層
DCP中基礎設施層主要用於提供各種基礎設施，以保證其他層功能的正常運行。通常來講，主要包括以下幾個基礎組件：用於存放容器鏡像的鏡像倉庫、提供監控服務的監控中心、實時監控系統容量以便於自動擴縮容的容量評估系統以及容器創建後，如何加入線上服務的服務發現組件，其中鏡像倉庫是DCP最核心的基礎組件。
正如專欄第26期我講的那樣，DCP以開源鏡像倉庫Harbor爲基礎搭建了私有的鏡像倉庫，不過由於微博業務的特徵，爲了應對隨時可能到來的突發峯值流量的衝擊，需要隨時隨地能夠擴容服務池。但在內網冗餘度不足的時候，也不得不借助公有云來實現，因此服務不僅在內網私有云上有部署，在阿里雲上也有部署，這樣的話從阿里雲申請的主機也需要從鏡像倉庫中拉取鏡像。此時，如果鏡像倉庫只在內網部署的話，就需要跨專線去拉取鏡像，但如果上百臺服務器同時拉取鏡像，帶寬佔用很可能達到上百G，由於專線帶寬是有限的，顯然這樣不可取。爲此，正確的做法就像下圖中那樣，在阿里雲機房也部署一套鏡像倉庫，並且通過Harbor的主從複製機制與內網的鏡像倉庫保持同步。同時，爲了做到負載均衡，每個機房內部都部署了多個Harbor節點，內網節點訪問內網鏡像倉庫會通過LVS進行負載均衡，阿里雲上節點訪問阿里雲鏡像倉庫會通過SLB進行負載均衡，以滿足鏡像倉庫的帶寬需求。
主機層
DCP中主機層的功能主要是爲了完成資源的調度，也就是針對不同的集羣，完成主機的創建、成本的管理以及配置初始化工作，也叫Pluto層。前面提到過微博業務不僅在內網私有云上有部署，而且在阿里雲上也有部署，爲此Pluto需要適配不同底層提供的創建主機的API，進行成本覈算並且進行配置初始化操作。Pluto層的架構你可以參看下圖，我來詳細講一下。
1.主機創建
Pluto在創建主機時，主要有兩個來源，一個是內部物理機組成的共享池，一個是調用阿里雲API創建ECS。其中共享池內的資源主要來源於兩部分：一部分是冗餘度高的服務池縮容部分主機加入到共享池；一部分是在線業務和離線計算互相補充，比如白天在線業務需要的機器多，而離線計算的任務主要運行在凌晨，這時候就可以在白天把離線計算的集羣的部分機器加入到共享池給在線業務使用，而在晚上業務低峯期把在線業務的部分機器加入到共享池給離線計算任務使用。而使用阿里雲創建ECS，主要是在共享池內的資源不足的情況下，比如有突發熱點事件到來，各個服務池都需要緊急擴容，這時候共享池內的資源就不足以應對了。而使用阿里雲API創建ECS會受到阿里雲API的各種限制，下面我列舉幾個微博在使用阿里雲創建機器時所遇到的問題，你就可以理解主機創建的複雜性所在了。
- 由於阿里雲API對單賬戶的調用有併發限制，所以實際業務在創建阿里雲ECS上時，不能上百臺同時創建，一般要控制在幾十臺的規模左右，如果這個時候業務需要創建上百臺機器該怎麼做呢？那就需要採取隊列機制，來控制機器創建的速度。下面這張圖就描述了微博在使用阿里雲創建ECS時的解決方案，在實際創建ECS時，不會立即調用阿里雲API，而是把節點創建任務先放到一個DB隊列中，然後再通過一個線程定時從DB隊列中獲取創建任務，每次只創建幾十臺，這樣的話就不會觸發阿里雲API對單賬號調用的併發限制。
- 除了有單賬戶調用的併發限制，還會有可用區的庫存限制、安全組庫存限制以及vSwitch庫存限制，所以在實際使用阿里雲API創建ECS時，當機器規模較大，如果直接指定使用某個可用區、安全組和vSwitch，就可能因爲庫存原因導致創建失敗。微博一開始就使用了這種方案，但在突發峯值流量來臨時，往往要創建幾百臺甚至上千臺的阿里雲ECS，爲此經常會因爲以上限制導致創建失敗。後來針對可用區、安全組以及vSwitch都做了多可用區、多安全組以及多vSwtich配置，在出現庫存不夠時，就自動切換到別的地方來創建，極大提高了大規模ECS創建的成功率。
2.成本管理
無論是從共享池內創建的機器，還是調用阿里雲API創建的ECS，都是有成本的，爲此必須對機器的數量以及使用時長進行記錄，以便進行成本管理。
以阿里雲的ECS爲例，又分爲按量付費、按月付費以及按年付費，可以按照以下方式來進行管理。
-
按量付費。按照使用時長，以秒爲單位計費，適合突發流量到來臨時需要擴容部分機器時使用，所以需要記錄每臺ECS從調用API創建成功到銷燬所使用的時長。
-
按月付費。這種比較適合短期業務需要使用機器的場景，比如微博曾經在奧運會期間擴容過大量包月付費的機器，以應對奧運會期間帶來的流量上漲。需要注意的是，這種機器到了月底會自動銷燬，所以如果還有使用需要的話，需要及時續費。
-
按年付費。這種比較適合需要長期在阿里雲上部署的業務，比如有一些新的業務因爲業務發展比較快，採用傳統自採機器部署的話，由於採購週期比較長不適合業務發展，所以使用公有云更爲合適。
3.配置初始化
主機創建完成後，還要進行一些基礎軟件的安裝以及配置修改等工作，這就是配置初始化的過程。以阿里雲創建的ECS爲例，如果短時間內創建了上千臺ECS，這個時候配置初始化的工作量會非常大，需要同時給上千臺ECS下發配置文件並安裝基礎軟件，同時還需要記錄每臺ECS的初始化狀態到DB，以便查詢是否初始化成功。下圖描述了初始化的過程，DCP在進行主機配置初始化時，會通過Ansible向所有主機下發配置文件和基礎軟件，並通過自定義callback queue，把每臺主機的初始化狀態異步寫入到DB中，避免上百臺機器同時併發寫入DB造成死鎖。
調度層
DCP中調度層的主要功能是在可用的主機上創建容器。由於微博業務早在2013年就開始進行容器化，基於當時的背景考慮，就選擇了Swarm作爲容器調度的工具，並根據自己的業務特點在Swarm基礎上進行二次封裝，定製了自己的調度層Roam，使其具備支持跨IDC、高可用以及可擴展的特性。下面是Roam的架構，其主要工作原理是：
-
Swarm Manager和Swarm Client節點都向Consul中註冊，並且有一個Active Manager和Standby Manager。任何一個IDC內的Active Manager如果down掉的話，Standby Manager就會註冊到Consul中，成爲新的Active Manager，以保證高可用性。
-
當發起容器調度時，Roam根據IDC參數請求Consul，得到該IDC的Swarm Manager信息。
-
Roam訪問該IDC內的Swarm Manager，Swarm Manager再訪問Consul獲取Swarm Client信息，並根據Roam傳遞的調度策略從Swarm Client中選擇節點創建容器。
編排層
DCP中編排層的主要作用是對服務進行整合以對外提供服務，主要包括服務依賴、服務發現以及自動擴縮容，下面我來詳細介紹每一部分的具體實現。
1.服務依賴
DCP通過模板來管理容器的創建，一個服務如果需要進行擴容、創建容器，就必須按照模板裏定義的參數來執行，以下圖描述的DCP裏的一個擴容任務創建模板爲例，通常來講，模板裏定義的參數主要包括幾個部分：任務的名稱、機器的配置、任務依賴、任務詳細配置（包括調用阿里雲API創建ECS時的可用區、安全組參數等），其中任務依賴的配置項是：
{"Sid":1707061842070000,"Ratio":0.2,"ElasticCount":0}
{"Sid":1703271821000000,"Ratio":0.3,"ElasticCount":0}
它的含義是執行這個擴容任務時，會自動執行ID爲1707061842070000和1703271821000000的擴容任務，並且按照每擴容10臺容器分別擴容2臺和3臺依賴容器的比例來執行。
2.服務發現
微博的業務場景主要包含兩種服務，一種是HTTP服務，一種是Motan RPC服務，他們分別使用了不同的服務發現方式。
-
HTTP服務。考慮到傳統的基於Nginx的配置Reload機制實現的服務發現方式，在高併發訪問的情況下，會導致吞吐量下降10%左右，如果業務頻繁變更的話，就會受到影響。爲此，DCP在實際業務中基於Nginx和Consul研發了一種可行的解決方案nginx-upsync-module，並且已經開源。
-
Motan RPC服務。Motan RPC服務在啓動時，會向註冊中心Config Service註冊服務，並且註冊中心支持多IDC部署。像下圖所描述的那樣，正常情況下服務消費者會訪問同一個IDC內的服務提供者，並且支持在故障的時候，可以切換到其他IDC。
3.自動擴縮容
DCP系統實現自動擴縮容主要依靠的是容量決策支持系統，由容量決策支持系統來實時監控系統的容量。如下圖所示，一旦容量決策支持系統檢測到某個服務需要進行擴容，就會創建擴容任務，Config Watcher會監控到擴容任務，並通知CronTrigger有調度策略變更。CronTrigger接到擴容任務，就會調用Scheduler來具體執行擴容。同時還可以通過API來修改、查詢擴縮容的信息，也可以通過UI來操作。
總結
今天我給你講解了微博容器運維平臺DCP的架構，主要包括基礎設施層、主機層、調度層以及編排層，並詳細介紹了每一層的功能實現，以及各自承擔的不同職能。下面這張圖是一次完整擴容流程，包括了資源評估、配額評估、初始化、容器調度、部署服務、服務依賴、服務發現以及自動擴縮容等，DCP正是通過把這些過程串聯起來，實現容器運維的。
思考題
在講到服務編排時，我提到服務之間會存在依賴關係，比如服務A依賴服務B，假如此時服務A的流量上漲，需要對服務A進行擴容，這時候有兩種方案：一種方案是通過自動擴縮容，服務A和服務B的擴容完全獨立，分別按需自動擴縮容；一種方案是通過服務依賴，擴容服務A之前先擴容服務B，你認爲這兩種方案哪種更好？爲什麼？
實際線上操作時，要考慮自動擴容的時間差問題，比如阿里雲上的A服務擴容了，把流量都引入到阿里雲上，而依賴的阿里雲B服務沒有擴容，就會造成B服務有問題，爲了做大程度不影響線上服務我們使用的是關聯擴容