本文是鄭坤根據(jù)第14期美團(tuán)點(diǎn)評(píng)技術(shù)沙龍“你不知道的美團(tuán)云”演講內(nèi)容整理而成，已發(fā)表在《程序員》雜志2017年1月刊。

美團(tuán)點(diǎn)評(píng)容器平臺(tái)簡介

本文介紹美團(tuán)點(diǎn)評(píng)的Docker容器集群管理平臺(tái)（以下簡稱“容器平臺(tái)”）。該平臺(tái)始于2015年，是基于美團(tuán)云的基礎(chǔ)架構(gòu)和組件而開發(fā)的Docker容器集群管理平臺(tái)。目前該平臺(tái)為美團(tuán)點(diǎn)評(píng)的外賣、酒店、到店、貓眼等十幾個(gè)事業(yè)部提供容器計(jì)算服務(wù)，承載線上業(yè)務(wù)數(shù)百個(gè)，日均線上請(qǐng)求超過45億次，業(yè)務(wù)類型涵蓋Web、數(shù)據(jù)庫、緩存、消息隊(duì)列等。

為什么要開發(fā)容器管理平臺(tái)

作為國內(nèi)大型的O2O互聯(lián)網(wǎng)公司，美團(tuán)點(diǎn)評(píng)業(yè)務(wù)發(fā)展極為迅速，每天線上發(fā)生海量的搜索、推廣和在線交易。在容器平臺(tái)實(shí)施之前，美團(tuán)點(diǎn)評(píng)的所有業(yè)務(wù)都是運(yùn)行在美團(tuán)私有云提供的虛擬機(jī)之上。隨著業(yè)務(wù)的擴(kuò)張，除了對(duì)線上業(yè)務(wù)提供極高的穩(wěn)定性之外，私有云還需要有很高的彈性能力，能夠在某個(gè)業(yè)務(wù)高峰時(shí)快速創(chuàng)建大量的虛擬機(jī)，在業(yè)務(wù)低峰期將資源回收，分配給其他的業(yè)務(wù)使用。美團(tuán)點(diǎn)評(píng)大部分的線上業(yè)務(wù)都是面向消費(fèi)者和商家的，業(yè)務(wù)類型多樣，彈性的時(shí)間、頻度也不盡相同，這些都對(duì)彈性服務(wù)提出了很高的要求。在這一點(diǎn)上，虛擬機(jī)已經(jīng)難以滿足需求，主要體現(xiàn)以下兩點(diǎn)。

第一，虛擬機(jī)彈性能力較弱。使用虛擬機(jī)部署業(yè)務(wù)，在彈性擴(kuò)容時(shí)，需要經(jīng)過申請(qǐng)?zhí)摂M機(jī)、創(chuàng)建和部署虛擬機(jī)、配置業(yè)務(wù)環(huán)境、啟動(dòng)業(yè)務(wù)實(shí)例這幾個(gè)步驟。前面的幾個(gè)步驟屬于私有云平臺(tái)，后面的步驟屬于業(yè)務(wù)工程師。一次擴(kuò)容需要多部門配合完成，擴(kuò)容時(shí)間以小時(shí)計(jì)，過程難以實(shí)現(xiàn)自動(dòng)化。如果可以實(shí)現(xiàn)自動(dòng)化“一鍵快速擴(kuò)容”，將極大地提高業(yè)務(wù)彈性效率，釋放更多的人力，同時(shí)也消除了人工操作導(dǎo)致事故的隱患。

第二，IT成本高。由于虛擬機(jī)彈性能力較弱，業(yè)務(wù)部門為了應(yīng)對(duì)流量高峰和突發(fā)流量，普遍采用預(yù)留大量機(jī)器和服務(wù)實(shí)例的做法。即先部署好大量的虛擬機(jī)或物理機(jī)，按照業(yè)務(wù)高峰時(shí)所需資源做預(yù)留，一般是非高峰時(shí)段資源需求的兩倍。資源預(yù)留的辦法帶來非常高的IT成本，在非高峰時(shí)段，這些機(jī)器資源處于空閑狀態(tài)，也是巨大的浪費(fèi)。

由于上述原因，美團(tuán)點(diǎn)評(píng)從2015年開始引入Docker，構(gòu)建容器集群管理平臺(tái)，為業(yè)務(wù)提供高性能的彈性伸縮能力。業(yè)界很多公司的做法是采用Docker生態(tài)圈的開源組件，例如Kubernetes、Docker Swarm等。我們結(jié)合自身的業(yè)務(wù)需求，基于美團(tuán)云現(xiàn)有架構(gòu)和組件，實(shí)踐出一條自研Docker容器管理平臺(tái)之路。我們之所以選擇自研容器平臺(tái)，主要出于以下考慮。

快速滿足美團(tuán)點(diǎn)評(píng)的多種業(yè)務(wù)需求

美團(tuán)點(diǎn)評(píng)的業(yè)務(wù)類型非常廣泛，幾乎涵蓋了互聯(lián)網(wǎng)公司所有業(yè)務(wù)類型。每種業(yè)務(wù)的需求和痛點(diǎn)也不盡相同。例如一些無狀態(tài)業(yè)務(wù)（例如Web），對(duì)彈性擴(kuò)容的延遲要求很高；數(shù)據(jù)庫，業(yè)務(wù)的master節(jié)點(diǎn)，需要極高的可用性，而且還有在線調(diào)整CPU，內(nèi)存和磁盤等配置的需求。很多業(yè)務(wù)需要SSH登陸訪問容器以便調(diào)優(yōu)或者快速定位故障原因，這需要容器管理平臺(tái)提供便捷的調(diào)試功能。為了滿足不同業(yè)務(wù)部門的多種需求，容器平臺(tái)需要大量的迭代開發(fā)工作。基于我們所熟悉的現(xiàn)有平臺(tái)和工具，可以做到“多快好省”地實(shí)現(xiàn)開發(fā)目標(biāo)，滿足業(yè)務(wù)的多種需求。

從容器平臺(tái)穩(wěn)定性出發(fā)，需要對(duì)平臺(tái)和Docker底層技術(shù)有更高的把控能力

容器平臺(tái)承載美團(tuán)點(diǎn)評(píng)大量的線上業(yè)務(wù)，線上業(yè)務(wù)對(duì)SLA可用性要求非常高，一般要達(dá)到99.99%，因此容器平臺(tái)的穩(wěn)定性和可靠性是最重要的指標(biāo)。如果直接引入外界開源組件，我們將面臨3個(gè)難題：1. 我們需要摸熟開源組件，掌握其接口、評(píng)估其性能，至少要達(dá)到源碼級(jí)的理解；2. 構(gòu)建容器平臺(tái)，需要對(duì)這些開源組件做拼接，從系統(tǒng)層面不斷地調(diào)優(yōu)性能瓶頸，消除單點(diǎn)隱患等；3. 在監(jiān)控、服務(wù)治理等方面要和美團(tuán)點(diǎn)評(píng)現(xiàn)有的基礎(chǔ)設(shè)施整合。這些工作都需要極大的工作量，更重要的是，這樣搭建的平臺(tái)，在短時(shí)間內(nèi)其穩(wěn)定性和可用性都難以保障。

避免重復(fù)建設(shè)私有云

美團(tuán)私有云承載著美團(tuán)點(diǎn)評(píng)所有的在線業(yè)務(wù)，是國內(nèi)規(guī)模最大的私有云平臺(tái)之一。經(jīng)過幾年的經(jīng)營，可靠性經(jīng)過了公司海量業(yè)務(wù)的考驗(yàn)。我們不能因?yàn)橐С秩萜?#xff0c;就將成熟穩(wěn)定的私有云擱置一旁，另起爐灶再重新開發(fā)一個(gè)新的容器平臺(tái)。因此從穩(wěn)定性、成本考慮，基于現(xiàn)有的私有云來建設(shè)容器管理平臺(tái)，對(duì)我們來說是最經(jīng)濟(jì)的方案。

美團(tuán)點(diǎn)評(píng)容器管理平臺(tái)架構(gòu)設(shè)計(jì)

我們將容器管理平臺(tái)視作一種云計(jì)算模式，云計(jì)算的架構(gòu)同樣適用于容器。如前所述，容器平臺(tái)的架構(gòu)依托于美團(tuán)私有云現(xiàn)有架構(gòu)，其中私有云的大部分組件可以直接復(fù)用或者經(jīng)過少量擴(kuò)展開發(fā)。容器平臺(tái)架構(gòu)如下圖所示。

美團(tuán)點(diǎn)評(píng)容器管理平臺(tái)架構(gòu)

可以看出，容器平臺(tái)整體架構(gòu)自上而下分為業(yè)務(wù)層、PaaS層、IaaS控制層及宿主機(jī)資源層，這與美團(tuán)云架構(gòu)基本一致。

業(yè)務(wù)層：代表美團(tuán)點(diǎn)評(píng)使用容器的業(yè)務(wù)線，他們是容器平臺(tái)的最終用戶。 PaaS層：使用容器平臺(tái)的HTTP API，完成容器的編排、部署、彈性伸縮，監(jiān)控、服務(wù)治理等功能，對(duì)上面的業(yè)務(wù)層通過HTTP API或者Web的方式提供服務(wù)。 IaaS控制層：提供容器平臺(tái)的API處理、調(diào)度、網(wǎng)絡(luò)、用戶鑒權(quán)、鏡像倉庫等管理功能，對(duì)PaaS提供HTTP API接口。 宿主機(jī)資源層：Docker宿主機(jī)集群，由多個(gè)機(jī)房，數(shù)百個(gè)節(jié)點(diǎn)組成。每個(gè)節(jié)點(diǎn)部署HostServer、Docker、監(jiān)控?cái)?shù)據(jù)采集模塊，Volume管理模塊，OVS網(wǎng)絡(luò)管理模塊，Cgroup管理模塊等。 容器平臺(tái)中的絕大部分組件是基于美團(tuán)私有云已有組件擴(kuò)展開發(fā)的，例如API，鏡像倉庫、平臺(tái)控制器、HostServer、網(wǎng)絡(luò)管理模塊，下面將分別介紹。

API

API是容器平臺(tái)對(duì)外提供服務(wù)的接口，PaaS層通過API來創(chuàng)建、部署云主機(jī)。我們將容器和虛擬機(jī)看作兩種不同的虛擬化計(jì)算模型，可以用統(tǒng)一的API來管理。即虛擬機(jī)等同于set（后面將詳細(xì)介紹），磁盤等同于容器。這個(gè)思路有兩點(diǎn)好處：1. 業(yè)務(wù)用戶不需要改變?cè)浦鳈C(jī)的使用邏輯，原來基于虛擬機(jī)的業(yè)務(wù)管理流程同樣適用于容器，因此可以無縫地將業(yè)務(wù)從虛擬機(jī)遷移到容器之上；2. 容器平臺(tái)API不必重新開發(fā)，可以復(fù)用美團(tuán)私有云的API處理流程 創(chuàng)建虛擬機(jī)流程較多，一般需要經(jīng)歷調(diào)度、準(zhǔn)備磁盤、部署配置、啟動(dòng)等多個(gè)階段，平臺(tái)控制器和Host-SRV之間需要很多的交互過程，帶來了一定量的延遲。容器相對(duì)簡單許多，只需要調(diào)度、部署啟動(dòng)兩個(gè)階段。因此我們對(duì)容器的API做了簡化，將準(zhǔn)備磁盤、部署配置和啟動(dòng)整合成一步完成，經(jīng)簡化后容器的創(chuàng)建和啟動(dòng)延遲不到3秒鐘，基本達(dá)到了Docker的啟動(dòng)性能。

Host-SRV

Host-SRV是宿主機(jī)上的容器進(jìn)程管理器，負(fù)責(zé)容器鏡像拉取、容器磁盤空間管理、以及容器創(chuàng)建、銷毀等運(yùn)行時(shí)的管理工作。

鏡像拉取：Host-SRV接到控制器下發(fā)的創(chuàng)建請(qǐng)求后，從鏡像倉庫下載鏡像、緩存，然后通過Docker Load接口加載到Docker里。

容器運(yùn)行時(shí)管理：Host-SRV通過本地Unix Socker接口與Docker Daemon通信，對(duì)容器生命周期的控制，并支持容器Logs、exec等功能。

容器磁盤空間管理：同時(shí)管理容器Rootfs和Volume的磁盤空間，并向控制器上報(bào)磁盤使用量，調(diào)度器可依據(jù)使用量決定容器的調(diào)度策略。

Host-SRV和Docker Daemon通過Unix Socket通信，容器進(jìn)程由Docker-Containerd托管，所以Host-SRV的升級(jí)發(fā)布不會(huì)影響本地容器的運(yùn)行。

鏡像倉庫

容器平臺(tái)有兩個(gè)鏡像倉庫： - Docker Registry: 提供Docker Hub的Mirror功能，加速鏡像下載，便于業(yè)務(wù)團(tuán)隊(duì)快速構(gòu)建業(yè)務(wù)鏡像； - Glance: 基于Openstack組件Glance擴(kuò)展開發(fā)的Docker鏡像倉庫，用以托管業(yè)務(wù)部門制作的Docker鏡像。

鏡像倉庫不僅是容器平臺(tái)的必要組件，也是私有云的必要組件。美團(tuán)私有云使用Glance作為鏡像倉庫，在建設(shè)容器平臺(tái)之前，Glance只用來托管虛擬機(jī)鏡像。每個(gè)鏡像有一個(gè)UUID，使用Glance API和鏡像UUID，可以上傳、下載虛擬機(jī)鏡像。Docker鏡像實(shí)際上是由一組子鏡像組成，每個(gè)子鏡像有獨(dú)立的ID，并帶有一個(gè)Parent ID屬性，指向其父鏡像。我們稍加改造了一下Glance，對(duì)每個(gè)Glance鏡像增加Parent ID的屬性，修改了鏡像上傳和下載的邏輯。經(jīng)過簡單擴(kuò)展，使Glance具有托管Docker鏡像的能力。通過Glance擴(kuò)展來支持Docker鏡像有以下優(yōu)點(diǎn)： - 可以使用同一個(gè)鏡像倉庫來托管Docker和虛擬機(jī)的鏡像，降低運(yùn)維管理成本； - Glance已經(jīng)十分成熟穩(wěn)定，使用Glance可以減少在鏡像管理上踩坑； - 使用Glance可以使Docker鏡像倉庫和美團(tuán)私有云“無縫”對(duì)接，使用同一套鏡像API，可以同時(shí)支持虛擬機(jī)和Docker鏡像上傳、下載，支持分布式的存儲(chǔ)后端和多租戶隔離等特性； - Glance UUID和Docker Image ID是一一對(duì)應(yīng)的關(guān)系，利用這個(gè)特性我們實(shí)現(xiàn)了Docker鏡像在倉庫中的唯一性，避免冗余存儲(chǔ)。

可能有人疑問，用Glance做鏡像倉庫是“重新造輪子”。事實(shí)上我們對(duì)Glance的改造只有200行左右的代碼。Glance簡單可靠，我們?cè)诤芏痰臅r(shí)間就完成了鏡像倉庫的開發(fā)上線，目前美團(tuán)點(diǎn)評(píng)已經(jīng)托管超過16,000多個(gè)業(yè)務(wù)方的Docker鏡像，平均上傳和下載鏡像的延遲都是秒級(jí)的。

高性能、高彈性的容器網(wǎng)絡(luò)

網(wǎng)絡(luò)是十分重要的，又有技術(shù)挑戰(zhàn)性的領(lǐng)域。一個(gè)好的網(wǎng)絡(luò)架構(gòu)，需要有高網(wǎng)絡(luò)傳輸性能、高彈性、多租戶隔離、支持軟件定義網(wǎng)絡(luò)配置等多方面的能力。早期Docker提供的網(wǎng)絡(luò)方案比較簡單，只有None、Bridge、Container和Host這四種網(wǎng)絡(luò)模式，也沒有用戶開發(fā)接口。2015年Docker在1.9版本集成了Libnetwork作為其網(wǎng)絡(luò)的解決方案，支持用戶根據(jù)自身需求，開發(fā)相應(yīng)的網(wǎng)絡(luò)驅(qū)動(dòng)，實(shí)現(xiàn)網(wǎng)絡(luò)功能自定義的功能，極大地增強(qiáng)了Docker的網(wǎng)絡(luò)擴(kuò)展能力。

從容器集群系統(tǒng)來看，只有單宿主機(jī)的網(wǎng)絡(luò)接入是遠(yuǎn)遠(yuǎn)不夠的，網(wǎng)絡(luò)還需要提供跨宿主機(jī)、機(jī)架和機(jī)房的能力。從這個(gè)需求來看，Docker和虛擬機(jī)來說是共通的，沒有明顯的差異，從理論上也可以用同一套網(wǎng)絡(luò)架構(gòu)來滿足Docker和虛擬機(jī)的網(wǎng)絡(luò)需求。基于這種理念，容器平臺(tái)在網(wǎng)絡(luò)方面復(fù)用了美團(tuán)云網(wǎng)絡(luò)基礎(chǔ)架構(gòu)和組件。

美團(tuán)點(diǎn)評(píng)容器平臺(tái)網(wǎng)絡(luò)架構(gòu)

數(shù)據(jù)平面: 我們采用萬兆網(wǎng)卡，結(jié)合OVS-DPDK方案，并進(jìn)一步優(yōu)化單流的轉(zhuǎn)發(fā)性能，將幾個(gè)CPU核綁定給OVS-DPDK轉(zhuǎn)發(fā)使用，只需要少量的計(jì)算資源即可提供萬兆的數(shù)據(jù)轉(zhuǎn)發(fā)能力。OVS-DPDK和容器所使用的CPU完全隔離，因此也不影響用戶的計(jì)算資源。

控制平面: 我們使用OVS方案。該方案是在每個(gè)宿主機(jī)上部署一個(gè)自研的軟件Controller，動(dòng)態(tài)接收網(wǎng)絡(luò)服務(wù)下發(fā)的網(wǎng)絡(luò)規(guī)則，并將規(guī)則進(jìn)一步下發(fā)至OVS流表，決定是否對(duì)某網(wǎng)絡(luò)流放行。

MosBridge

在MosBridge之前，我們配置容器網(wǎng)絡(luò)使用的是None模式。所謂None模式也就是自定義網(wǎng)絡(luò)的模式，配置網(wǎng)絡(luò)需要如下幾步： 1. 在創(chuàng)建容器時(shí)指定—net=None，容器創(chuàng)建啟動(dòng)后沒有網(wǎng)絡(luò)； 2. 容器啟動(dòng)后，創(chuàng)建eth-pair； 3. 將eth-pair一端連接到OVS Bridge上； 4. 使用nsenter這種Namespace工具將eth-pair另一端放到容器的網(wǎng)絡(luò)Namespace中，然后改名、配置IP地址和路由。

然而，在實(shí)踐中，我們發(fā)現(xiàn)None模式存在一些不足： - 容器剛啟動(dòng)時(shí)是無網(wǎng)絡(luò)的，一些業(yè)務(wù)在啟動(dòng)前會(huì)檢查網(wǎng)絡(luò)，導(dǎo)致業(yè)務(wù)啟動(dòng)失敗； - 網(wǎng)絡(luò)配置與Docker脫離，容器重啟后網(wǎng)絡(luò)配置丟失； - 網(wǎng)絡(luò)配置由Host-SRV控制，每個(gè)網(wǎng)卡的配置流程都是在Host-SRV中實(shí)現(xiàn)的。以后網(wǎng)絡(luò)功能的升級(jí)和擴(kuò)展，例如對(duì)容器添加網(wǎng)卡，或者支持VPC，會(huì)使Host-SRV越來越難以維護(hù)。

為了解決這些問題，我們將眼光投向Docker Libnetwork。Libnetwork為用戶提供了可以開發(fā)Docker網(wǎng)絡(luò)的能力，允許用戶基于Libnetwork實(shí)現(xiàn)網(wǎng)絡(luò)驅(qū)動(dòng)來自定義其網(wǎng)絡(luò)配置的行為。就是說，用戶可以編寫驅(qū)動(dòng)，讓Docker按照指定的參數(shù)為容器配置IP、網(wǎng)關(guān)和路由。基于Libnetwork，我們開發(fā)了MosBridge – 適配美團(tuán)云網(wǎng)絡(luò)架構(gòu)的Docker網(wǎng)絡(luò)驅(qū)動(dòng)。在創(chuàng)建容器時(shí)，需要指定容器創(chuàng)建參數(shù)—net=mosbridge，并將IP地址、網(wǎng)關(guān)、OVS Bridge等參數(shù)傳給Docker，由MosBridge完成網(wǎng)絡(luò)的配置過程。有了MosBridge，容器創(chuàng)建啟動(dòng)后便有了網(wǎng)絡(luò)可以使用。容器的網(wǎng)絡(luò)配置也持久化在MosBridge中，容器重啟后網(wǎng)絡(luò)配置也不會(huì)丟失。更重要的是，MosBridge使Host-SRV和Docker充分解耦，以后網(wǎng)絡(luò)功能的升級(jí)也會(huì)更加方便。

解決Docker存儲(chǔ)隔離性的問題

業(yè)界許多公司使用Docker都會(huì)面臨存儲(chǔ)隔離性的問題。就是說Docker提供的數(shù)據(jù)存儲(chǔ)的方案是Volume，通過mount bind的方式將本地磁盤的某個(gè)目錄掛載到容器中，作為容器的“數(shù)據(jù)盤”使用。這種本地磁盤Volume的方式無法做到容量限制，任何一個(gè)容器都可以不加限制地向Volume寫數(shù)據(jù)，直到占滿整個(gè)磁盤空間。

LVM-Volume方案

針對(duì)這一問題，我們開發(fā)了LVM Volume方案。該方案是在宿主機(jī)上創(chuàng)建一個(gè)LVM VG作為Volume的存儲(chǔ)后端。創(chuàng)建容器時(shí)，從VG中創(chuàng)建一個(gè)LV當(dāng)作一塊磁盤，掛載到容器里，這樣Volume的容量便由LVM加以強(qiáng)限制。得益于LVM機(jī)強(qiáng)大的管理能力，我們可以做到對(duì)Volume更精細(xì)、更高效的管理。例如，我們可以很方便地調(diào)用LVM命令查看Volume使用量，通過打標(biāo)簽的方式實(shí)現(xiàn)Volume偽刪除和回收站功能，還可以使用LVM命令對(duì)Volume做在線擴(kuò)容。值得一提地是，LVM是基于Linux內(nèi)核Devicemapper開發(fā)的，而Devicemapper在Linux內(nèi)核的歷史悠久，早在內(nèi)核2.6版本時(shí)就已合入，其可靠性和IO性能完全可以信賴。

適配多種監(jiān)控服務(wù)的容器狀態(tài)采集模塊

容器監(jiān)控是容器管理平臺(tái)極其重要的一環(huán)，監(jiān)控不僅僅要實(shí)時(shí)得到容器的運(yùn)行狀態(tài)，還需要獲取容器所占用的資源動(dòng)態(tài)變化。在設(shè)計(jì)實(shí)現(xiàn)容器監(jiān)控之前，美團(tuán)點(diǎn)評(píng)內(nèi)部已經(jīng)有了許多監(jiān)控服務(wù)，例如Zabbix、Falcon和CAT。因此我們不需要重新設(shè)計(jì)實(shí)現(xiàn)一套完整的監(jiān)控服務(wù)，更多地是考慮如何高效地采集容器運(yùn)行信息，根據(jù)運(yùn)行環(huán)境的配置上報(bào)到相應(yīng)的監(jiān)控服務(wù)上。簡單來說，我們只需要考慮實(shí)現(xiàn)一個(gè)高效的Agent，在宿主機(jī)上可以采集容器的各種監(jiān)控?cái)?shù)據(jù)。這里需要考慮兩點(diǎn)： 1. 監(jiān)控指標(biāo)多，數(shù)據(jù)量大，數(shù)據(jù)采集模塊必須高效率； 2. 監(jiān)控的低開銷，同一個(gè)宿主機(jī)可以跑幾十個(gè)，甚至上百個(gè)容器，大量的數(shù)據(jù)采集、整理和上報(bào)過程必須低開銷。

監(jiān)控?cái)?shù)據(jù)采集方案

針對(duì)業(yè)務(wù)和運(yùn)維的監(jiān)控需求，我們基于Libcontainer開發(fā)了Mos-Docker-Agent監(jiān)控模塊。該模塊從宿主機(jī)proc、CGroup等接口采集容器數(shù)據(jù)，經(jīng)過加工換算，再通過不同的監(jiān)控系統(tǒng)driver上報(bào)數(shù)據(jù)。該模塊使用GO語言編寫，既可以高效率，又可以直接使用Libcontainer。而且監(jiān)控的數(shù)據(jù)采集和上報(bào)過程不經(jīng)過Docker Daemon，因此不會(huì)加重Daemon的負(fù)擔(dān)。

在監(jiān)控配置這塊，由于監(jiān)控上報(bào)模塊是插件式的，可以高度自定義上報(bào)的監(jiān)控服務(wù)類型，監(jiān)控項(xiàng)配置，因此可以很靈活地適應(yīng)不同的監(jiān)控場景的需求。

支持微服務(wù)架構(gòu)的設(shè)計(jì)

近幾年，微服務(wù)架構(gòu)在互聯(lián)網(wǎng)技術(shù)領(lǐng)域興起。微服務(wù)利用輕量級(jí)組件，將一個(gè)大型的服務(wù)拆解為多個(gè)可以獨(dú)立封裝、獨(dú)立部署的微服務(wù)實(shí)例，大型服務(wù)內(nèi)在的復(fù)雜邏輯由服務(wù)之間的交互來實(shí)現(xiàn)。

美團(tuán)點(diǎn)評(píng)的很多在線業(yè)務(wù)是微服務(wù)架構(gòu)的。例如美團(tuán)點(diǎn)評(píng)的服務(wù)治理框架，會(huì)為每一個(gè)在線服務(wù)配置一個(gè)服務(wù)監(jiān)控Agent，該Agent負(fù)責(zé)收集上報(bào)在線服務(wù)的狀態(tài)信息。類似的微服務(wù)還有許多。對(duì)于這種微服務(wù)架構(gòu)，使用Docker可以有以下兩種封裝模式。 1. 將所有微服務(wù)進(jìn)程封裝到一個(gè)容器中。但這樣使服務(wù)的更新、部署很不靈活，任何一個(gè)微服務(wù)的更新都要重新構(gòu)建容器鏡像，這相當(dāng)于將Docker容器當(dāng)作虛擬機(jī)使用，沒有發(fā)揮出Docker的優(yōu)勢(shì)。 2. 將每個(gè)微服務(wù)封裝到單獨(dú)的容器中。Docker具有輕量、環(huán)境隔離的優(yōu)點(diǎn)，很適合用來封裝微服務(wù)。不過這樣可能產(chǎn)生額外的性能問題。一個(gè)是大型服務(wù)的容器化會(huì)產(chǎn)生數(shù)倍的計(jì)算實(shí)例，這對(duì)分布式系統(tǒng)的調(diào)度和部署帶來很大的壓力；另一個(gè)是性能惡化問題，例如有兩個(gè)關(guān)系緊密的服務(wù)，相互通信流量很大，但被部署到不同的機(jī)房，會(huì)產(chǎn)生相當(dāng)大的網(wǎng)絡(luò)開銷。

對(duì)于支持微服務(wù)的問題，Kubernetes的解決方案是Pod。每個(gè)Pod由多個(gè)容器組成，是服務(wù)部署、編排、管理的最小單位，也是調(diào)度的最小單位。Pod內(nèi)的容器相互共享資源，包括網(wǎng)絡(luò)、Volume、IPC等。因此同一個(gè)Pod內(nèi)的多個(gè)容器相互之間可以高效率地通信。

我們借鑒了Pod的思想，在容器平臺(tái)上開發(fā)了面向微服務(wù)的容器組，我們內(nèi)部稱之為set。一個(gè)set邏輯示意如下圖所示。

Set邏輯示意圖

set是容器平臺(tái)的調(diào)度、彈性擴(kuò)容/縮容的基本單位。每個(gè)set由一個(gè)BusyBox容器和若干個(gè)業(yè)務(wù)容器組成， BusyBox容器不負(fù)責(zé)具體業(yè)務(wù)，只負(fù)責(zé)管理set的網(wǎng)絡(luò)、Volume和IPC配置。

 set的配置json

set內(nèi)的所有容器共享網(wǎng)絡(luò)，Volume和IPC。set配置使用一個(gè)JSON描述(如圖6所示)，每一個(gè)set實(shí)例包含一個(gè)Container List，Container的字段描述了該容器運(yùn)行時(shí)的配置，重要的字段有： - Index，容器編號(hào)，代表容器的啟動(dòng)順序； - Image，Docker鏡像在Glance上的name或者ID； - Options，描述了容器啟動(dòng)時(shí)的參數(shù)配置。其中CPU和MEM都是百分比，表示這個(gè)容器相對(duì)于整個(gè)set在CPU和內(nèi)存的分配情況（例如，對(duì)于一個(gè)4核的set而言，容器CPU:80，表示該容器將最多使用3.2個(gè)物理核）。

通過set，我們將美團(tuán)點(diǎn)評(píng)的所有容器業(yè)務(wù)都做了標(biāo)準(zhǔn)化，即所有的線上業(yè)務(wù)都是用set描述，容器平臺(tái)內(nèi)只有set，調(diào)度、部署、啟停的單位都是set。 對(duì)于set的實(shí)現(xiàn)上我們還做了一些特殊處理： - Busybox具有Privileged權(quán)限，可以自定義一些sysctl內(nèi)核參數(shù)，提升容器性能。 - 為了穩(wěn)定性考慮，用戶不允許SSH登陸B(tài)usybox，只允許登陸其他業(yè)務(wù)容器。 - 為了簡化Volume管理，每一個(gè)set只有一個(gè)Volume，并掛載到Busybox下，每個(gè)容器相互共享這個(gè)Volume。

很多時(shí)候一個(gè)set內(nèi)的容器來自不同的團(tuán)隊(duì)，鏡像更新頻度不一，我們?cè)趕et基礎(chǔ)上設(shè)計(jì)了一個(gè)灰度更新的功能。該功能允許業(yè)務(wù)只更新set中的部分容器鏡像，通過一個(gè)灰度更新的API，即可將線上的set升級(jí)。灰度更新最大的好處是可以在線更新部分容器，并保持線上服務(wù)不間斷。

Docker穩(wěn)定性和特性的解決方案：MosDocker

眾所周知，Docker社區(qū)非常火熱，版本更新十分頻繁，大概2～4個(gè)月左右會(huì)有一個(gè)大版本更新，而且每次版本更新都會(huì)伴隨大量的代碼重構(gòu)。Docker沒有一個(gè)長期維護(hù)的LTS版本，每次更新不可避免地會(huì)引入新的Bug。由于時(shí)效原因，一般情況下，某個(gè)Bug的修復(fù)要等到下一個(gè)版本。例如1.11引入的Bug，一般要到1.12版才能解決，而如果使用了1.12版，又會(huì)引入新的Bug，還要等1.13版。如此一來，Docker的穩(wěn)定性很難滿足生產(chǎn)場景的要求。因此十分有必要維護(hù)一個(gè)相對(duì)穩(wěn)定的版本，如果發(fā)現(xiàn)Bug，可以在此版本基礎(chǔ)上，通過自研修復(fù)，或者采用社區(qū)的BugFix來修復(fù)。

除了穩(wěn)定性的需求之外，我們還需要開發(fā)一些功能來滿足美團(tuán)點(diǎn)評(píng)的需求。美團(tuán)點(diǎn)評(píng)業(yè)務(wù)的一些需求來自于我們自己的生產(chǎn)環(huán)境，而不屬于業(yè)界通用的需求。對(duì)于這類需求，開源社區(qū)通常不會(huì)考慮。業(yè)界許多公司都存在類似的情況，作為公司基礎(chǔ)服務(wù)團(tuán)隊(duì)就必須通過技術(shù)開發(fā)來滿足這種需求。

基于以上考慮，我們從Docker 1.11版本開始，自研維護(hù)一個(gè)分支，我們稱之為MosDocker。之所以選擇從版本1.11開始，是因?yàn)閺脑摪姹鹃_始，Docker做了幾項(xiàng)重大改進(jìn)： Docker Daemon重構(gòu)為Daemon、Containerd和runC這3個(gè)Binary，并解決Daemon的單點(diǎn)失效問題； - 支持OCI標(biāo)準(zhǔn)，容器由統(tǒng)一的rootfs和spec來定義； - 引入了Libnetwork框架，允許用戶通過開發(fā)接口自定義容器網(wǎng)絡(luò)； - 重構(gòu)了Docker鏡像存儲(chǔ)后端，鏡像ID由原來的隨即字符串轉(zhuǎn)變?yōu)榛阽R像內(nèi)容的Hash，使Docker鏡像安全性更高。

到目前為止，MosDocker自研的特性主要有： 1. MosBridge，支持美團(tuán)云網(wǎng)絡(luò)架構(gòu)的網(wǎng)絡(luò)驅(qū)動(dòng), 基于此特性實(shí)現(xiàn)容器多IP，VPC等網(wǎng)絡(luò)功能； 2. Cgroup持久化，擴(kuò)展Docker Update接口，可以使更多的CGroup配置持久化在容器中，保證容器重啟后CGroup配置不丟失。 3. 支持子鏡像的Docker Save，可以大幅度提高Docker鏡像的上傳、下載速度。

總之，維護(hù)MosDocker使我們可以將Docker穩(wěn)定性逐漸控制在自己手里，并且可以按照公司業(yè)務(wù)的需求做定制開發(fā)。

在實(shí)際業(yè)務(wù)中的推廣應(yīng)用

在容器平臺(tái)運(yùn)行的一年多時(shí)間里，已經(jīng)接入了美團(tuán)點(diǎn)評(píng)多個(gè)大型業(yè)務(wù)部門的業(yè)務(wù)，業(yè)務(wù)類型也是多種多樣。通過引入Docker技術(shù)，為業(yè)務(wù)部門帶來諸多好處，典型的好處包括以下兩點(diǎn)。 - 快速部署，快速應(yīng)對(duì)業(yè)務(wù)突發(fā)流量。由于使用Docker，業(yè)務(wù)的機(jī)器申請(qǐng)、部署、業(yè)務(wù)發(fā)布一步完成，業(yè)務(wù)擴(kuò)容從原來的小時(shí)級(jí)縮減為秒級(jí)，極大地提高了業(yè)務(wù)的彈性能力。 - 節(jié)省IT硬件和運(yùn)維成本。Docker在計(jì)算上效率更高，加之高彈性使得業(yè)務(wù)部門不必預(yù)留大量的資源，節(jié)省大量的硬件投資。以某業(yè)務(wù)為例，之前為了應(yīng)對(duì)流量波動(dòng)和突發(fā)流量，預(yù)留了32臺(tái)8核8G的虛擬機(jī)。使用容器彈性方案，即3臺(tái)容器+彈性擴(kuò)容的方案取代固定32臺(tái)虛擬機(jī)，平均單機(jī)QPS提升85%， 平均資源占用率降低44-56%(如圖7，8所示)。 - Docker在線擴(kuò)容能力，保障服務(wù)不中斷。一些有狀態(tài)的業(yè)務(wù)，例如數(shù)據(jù)庫和緩存，運(yùn)行時(shí)調(diào)整CPU、內(nèi)存和磁盤是常見的需求。之前部署在虛擬機(jī)中，調(diào)整配置需要重啟虛擬機(jī)，業(yè)務(wù)的可用性不可避免地被中斷了，成為業(yè)務(wù)的痛點(diǎn)。Docker對(duì)CPU、內(nèi)存等資源管理是通過Linux的CGroup實(shí)現(xiàn)的，調(diào)整配置只需要修改容器的CGroup參數(shù)，不必重啟容器。

 某業(yè)務(wù)虛擬機(jī)和容器平均單機(jī)QPS  某業(yè)務(wù)虛擬機(jī)和容器資源使用量

結(jié)束語

本文介紹了美團(tuán)點(diǎn)評(píng)Docker的實(shí)踐情況。經(jīng)過一年的推廣實(shí)踐，從部門內(nèi)部自己使用，到覆蓋公司大部分業(yè)務(wù)部門和產(chǎn)品線；從單一業(yè)務(wù)類型到公司線上幾十種業(yè)務(wù)類型，證明了Docker這種容器虛擬化技術(shù)在提高運(yùn)維效率，精簡發(fā)布流程，降低IT成本等方面的價(jià)值。

目前Docker平臺(tái)還在美團(tuán)點(diǎn)評(píng)深入推廣中。在這個(gè)過程中，我們發(fā)現(xiàn)Docker（或容器技術(shù)）本身存在許多問題和不足，例如，Docker存在IO隔離性不強(qiáng)的問題，無法對(duì)Buffered IO做限制；偶爾Docker Daemon會(huì)卡死，無反應(yīng)的問題；容器內(nèi)存OOM導(dǎo)致容器被刪除，開啟OOM_kill_disabled后可能導(dǎo)致宿主機(jī)內(nèi)核崩潰等問題。因此Docker技術(shù)，在我們看來和虛擬機(jī)應(yīng)該是互補(bǔ)的關(guān)系，不能指望在所有場景中Docker都可以替代虛擬機(jī)，因此只有將Docker和虛擬機(jī)并重，才能滿足用戶的各種場景對(duì)云計(jì)算的需求。

總結(jié)

以上是生活随笔為你收集整理的美团点评Docker容器管理平台的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。