摘要：綜上所述，容器化性能上接近物理機(jī)，在多測(cè)試場(chǎng)景下，表現(xiàn)相對(duì)穩(wěn)定可靠。和實(shí)現(xiàn)了云服務(wù)器節(jié)點(diǎn)從物理機(jī)到宿主機(jī)的轉(zhuǎn)變。

2018年數(shù)人云Meetup第一站，聯(lián)合vivo在深圳舉辦 Building Microservice 系列活動(dòng)第一期。本次技術(shù)沙龍vivo、中興通訊、華為、數(shù)人云共同派出技術(shù)大咖，為開(kāi)發(fā)者們帶來(lái)有關(guān)微服務(wù)、容器化、配置中心、服務(wù)網(wǎng)格等領(lǐng)域的實(shí)戰(zhàn)與干貨分享。

數(shù)人云Meetup每月一期，歡迎大家來(lái)面基、學(xué)習(xí)。本文為vivo云計(jì)算架構(gòu)師袁樂(lè)林分享的“vivo云服務(wù)容器化實(shí)踐”現(xiàn)場(chǎng)演講實(shí)錄。

今天講的內(nèi)容主要是介紹技術(shù)背景，產(chǎn)品的技術(shù)架構(gòu)，我們關(guān)鍵技術(shù)的實(shí)踐，前車之鑒，以及對(duì)下一代云服務(wù)架構(gòu)的設(shè)想。

技術(shù)背景

vivo這些年的業(yè)務(wù)增長(zhǎng)非?？欤脩魯?shù)已經(jīng)上億，服務(wù)器到了萬(wàn)級(jí)，業(yè)務(wù)域好幾百，后端系統(tǒng)的復(fù)雜度在迅速攀升，不光是運(yùn)維方面、架構(gòu)體系復(fù)雜度也非常高，vivo技術(shù)架構(gòu)也是到了破繭化蝶的時(shí)候。

我們做過(guò)容器、虛擬機(jī)與物理機(jī)性能對(duì)比測(cè)試。上面這張圖是當(dāng)時(shí)做的性能測(cè)試架構(gòu)圖。得出了一些測(cè)試結(jié)論：
1.容器化app（4c8g）在性能上略優(yōu)于非容器化app測(cè)試指標(biāo)
2.容器化app（32c64g）性能相較于裸跑同物理機(jī)有近4%左右性能損耗，其中TPS有3.85%損耗，平均響應(yīng)時(shí)間3.95%（1毫秒）的增加，對(duì)業(yè)務(wù)請(qǐng)求無(wú)影響。
3.容器化app在12h的穩(wěn)定性測(cè)試中表現(xiàn)正常
4.容器化app在cpu相對(duì)配額，cpu綁定以及絕對(duì)配額場(chǎng)景下，業(yè)務(wù)性能CPU相對(duì)配額 > CPU綁定 > 絕對(duì)配額。
5.容器化app在組部件異常，單計(jì)算節(jié)點(diǎn)，控制異常場(chǎng)景下，容器運(yùn)行正常。
綜上所述，容器化app性能上接近物理機(jī)，在多測(cè)試場(chǎng)景下，表現(xiàn)相對(duì)穩(wěn)定可靠。同時(shí)，對(duì)計(jì)算密集型app，相對(duì)權(quán)重配額能實(shí)現(xiàn)CPU資源利用率最大化。
vivo容器化云服務(wù)框架
正是因?yàn)檫@個(gè)性能測(cè)試數(shù)據(jù)的支撐，就有了vivo容器化云服務(wù)框架，我們給它取名 Kiver，提供輕量級(jí)、高可靠的容器化生產(chǎn)方案。

在這個(gè)框架之上vivo一共有八個(gè)云服務(wù)，按照后來(lái)統(tǒng)計(jì)數(shù)據(jù)來(lái)看，MySQL加上其他兩個(gè)服務(wù)占到80%的比例，這也非常符合“二八”原則。

vivo整個(gè)云服務(wù)容器化產(chǎn)品的架構(gòu)，左邊是運(yùn)維自動(dòng)化的工具集，比如日志、監(jiān)控等，日志在業(yè)界應(yīng)用非常廣泛，我們用采集容器的數(shù)據(jù)、容器的監(jiān)控指標(biāo)。

這里有兩個(gè)日志，上面是中間件的業(yè)務(wù)日志平臺(tái)，所有業(yè)務(wù)基于中間件日志規(guī)范，輸出日志后都會(huì)送到這里面收集起來(lái)，但是這個(gè)業(yè)務(wù)日志平臺(tái)功能目前比較薄弱，對(duì)新增加的一些組件，比如ECTD等不支持。vivo又引入了現(xiàn)在容器領(lǐng)域比較常見(jiàn)的日志方案EFK，今后會(huì)規(guī)劃把兩個(gè)日志整合到一起。

vivo在運(yùn)維方面做了一些工具，如 vivo MachineCtl和 KiverCtl，兩個(gè)工具主要實(shí)現(xiàn)宿主機(jī)的自動(dòng)化，簡(jiǎn)單來(lái)說(shuō)可以把宿主機(jī)操作系統(tǒng)自動(dòng)化地裝起來(lái)，裝完之后變成Kiver的計(jì)算節(jié)點(diǎn)或者控制節(jié)點(diǎn)。還有KiverPerfermance，是我們內(nèi)嵌的一個(gè)小的性能測(cè)試插件。

再來(lái)看右邊，是vivo的基礎(chǔ)設(shè)施，物理機(jī)和交換機(jī)，網(wǎng)絡(luò)設(shè)備和防火墻等，上面是Docker，Docker容器虛擬化技術(shù)把物理機(jī)上面的相關(guān)資源虛擬化用起來(lái)。

右邊有 Ceph 塊存儲(chǔ)，實(shí)現(xiàn)數(shù)據(jù)備份，上面是vivo自研的DevOps平臺(tái)，做了調(diào)度框架，右邊是用harbor做的鏡像倉(cāng)庫(kù)，再往上就是云服務(wù)Portal，前面所說(shuō)的那些云服務(wù)，同時(shí)也可以跑長(zhǎng)生命周期應(yīng)用。

宿主機(jī)自動(dòng)化實(shí)踐

下面我們講一下vivo的實(shí)踐?，F(xiàn)在物理機(jī)一旦上了規(guī)模之后，裝操作系統(tǒng)就成為一件大事，我們提供了 vivoMachineCtl，這個(gè)工具是一個(gè)命令行給運(yùn)維人員使用，可以實(shí)現(xiàn)宿主機(jī)集中化的參數(shù)配置和自動(dòng)化。

利用 vivoMachineCtl，首先和物理機(jī)管理卡做一個(gè)交互，交互之后拿到物理機(jī)的MAC地址，這里有個(gè)BMC，也有廠商叫iDrac卡，它可以取得這臺(tái)服務(wù)器網(wǎng)卡的MAC地址，創(chuàng)建以MAC地址命名的Bootfile，指明現(xiàn)在需要裝什么操作系統(tǒng)，和其他一些參數(shù)。再進(jìn)一步給它一個(gè)ipmi消息對(duì)服務(wù)器復(fù)位，然后服務(wù)器開(kāi)始重啟。

重啟之后，服務(wù)器第一次會(huì)發(fā)dhcp請(qǐng)求，拿到IP地址，之后會(huì)走一個(gè)pxe的協(xié)議，拿到bootfile，下載Bootfile所指明的小系統(tǒng)和內(nèi)存文件系統(tǒng)文件下來(lái)，加載到物理機(jī)中，然后開(kāi)始進(jìn)行操作系統(tǒng)安裝。這就是操作系統(tǒng)安裝的過(guò)程。操作系統(tǒng)安裝完成之后，把安裝類和文件系統(tǒng)切換成正在啟動(dòng)的文件系統(tǒng)，在post階段到集中化的配置中心，把相關(guān)的配置拉下來(lái)，包括IP地址，主機(jī)名和網(wǎng)關(guān)等信息，這是宿主機(jī)的自動(dòng)化部署。

KiverCtl實(shí)際上就是把操作系統(tǒng)的宿主機(jī)變成計(jì)算節(jié)點(diǎn)或者控制節(jié)點(diǎn)。計(jì)算節(jié)點(diǎn)有如下幾個(gè)功能：第一，基本的包安裝，第二，Docker、Netplugin初始化，啟動(dòng)kiver-guard/flume/cadvisor容器，完成日志和監(jiān)控指標(biāo)的采集。

控制節(jié)點(diǎn)上面有Etcd和Netmaster，也會(huì)可選地把Prometheus/alertmanager/grafana/啟動(dòng)起來(lái)。vivoMachineCtl和KiverCtl實(shí)現(xiàn)了云服務(wù)器節(jié)點(diǎn)從物理機(jī)到宿主機(jī)的轉(zhuǎn)變。

業(yè)務(wù)日志集成到日志平臺(tái)實(shí)踐

這是vivo日志采集的實(shí)踐，在宿主機(jī)上做日志分區(qū)，容器運(yùn)行起來(lái)之后掛這個(gè)目錄，每個(gè)容器起來(lái)之后會(huì)創(chuàng)建一個(gè)自己的文件目錄。外面有kiver-guard，用來(lái)偵聽(tīng)內(nèi)核文件系統(tǒng)的新日志文件創(chuàng)建的通知。

根據(jù)通知會(huì)創(chuàng)建軟件鏈接，鏈接到上一級(jí)Flume監(jiān)控的日志目錄，由Flume推到kafka。大數(shù)據(jù)平臺(tái)會(huì)來(lái)消費(fèi)這里的數(shù)據(jù)，業(yè)務(wù)日志平臺(tái)也會(huì)消費(fèi)這個(gè)數(shù)據(jù)，然后持久化到ES里，最后由中間件日志平臺(tái)來(lái)實(shí)現(xiàn)對(duì)日志的檢索和展示。

為什么要這么做？當(dāng)時(shí)用的flume版本不支持自動(dòng)收集遞歸子目錄下日志新增內(nèi)容的收集，完整的文件可以收集進(jìn)去，但是日志文件在遞歸子目錄下有不停地追加是輸不進(jìn)去的。

kiver-guard本身也是一個(gè)容器，它起來(lái)之后把宿主機(jī)日志目錄掛上去，在容器里面?zhèn)陕?tīng)日志目錄下的create事件。

不管這些日志路徑有多深或者在哪里，都可以鏈接出來(lái)。做鏈接的時(shí)候有一點(diǎn)需要注意，要確保鏈接過(guò)來(lái)之后文件名稱是唯一的。有些容器被刪除了，或者日志被輪轉(zhuǎn)刪除了，同樣也會(huì)針對(duì)Delete事件，偵測(cè)到delete是件之后刪除上層flume監(jiān)控日志路徑的對(duì)應(yīng)鏈接。

基礎(chǔ)組件日志收集實(shí)踐

基礎(chǔ)組件日志采用Etcd、Ceph、CentOS、Netmaster等一些網(wǎng)上比較熱門(mén)的EFK組件，開(kāi)箱即用。
監(jiān)控與告警實(shí)踐

這是監(jiān)控和告警實(shí)踐，在容器領(lǐng)域比較常見(jiàn)，vivo采用的是Promethus和Alertmanager。Promethus采用雙節(jié)點(diǎn)，雙拉（拉兩遍），兩個(gè)Promethus之間沒(méi)有做主從，為了解決高可用問(wèn)題，掛了一個(gè)另外一個(gè)還在。

之后接短信郵件中心，后面接Grafana作為監(jiān)控面板，前面用了telegraf。我們做的東西不僅僅有容器，還有其他的組件像Ceph。我們用Cadvisor收集容器監(jiān)控指標(biāo)。

我們對(duì)集群健康做監(jiān)控，也對(duì)集群資源使用情況進(jìn)行監(jiān)控，集群的健康性采用telegraf可以調(diào)用外部shell腳本的特性。我們?cè)诳刂乒?jié)點(diǎn)寫(xiě)了腳本，用來(lái)檢查Etcd的健康情況，也和各個(gè)節(jié)點(diǎn)進(jìn)行通訊，檢查各個(gè)節(jié)點(diǎn)是不是健康。之后會(huì)返回?cái)?shù)值，給出集群健康狀態(tài)碼。

這個(gè)就是前面講的自定義的一些監(jiān)控指標(biāo)，這是集群的健康檢查，這是集群的資源利用率，大致兩條數(shù)據(jù)鏈進(jìn)來(lái)。一個(gè)腳本由telegraf去拉，推到Prometheus里面，最后展現(xiàn)在Grafana上面。另一個(gè)，由DevOps框架把數(shù)據(jù)寫(xiě)到Mysql里面，再由Grafana定義Mysql的軟件源。

這邊拉出來(lái)的自定義的健康指標(biāo)支持返回碼，這個(gè)返回碼需要翻譯成文字，實(shí)際上Grafana已經(jīng)具備這個(gè)特性，我們可以去做一個(gè)映射，比如1代表監(jiān)控，2代表網(wǎng)絡(luò)問(wèn)題等等，它可以自動(dòng)翻譯來(lái)。

數(shù)據(jù)持久化實(shí)踐

說(shuō)到云服務(wù)大家都會(huì)關(guān)注這個(gè)問(wèn)題，數(shù)據(jù)怎么做到持久化，做到不丟。容器啟動(dòng)的時(shí)候會(huì)掛在宿主機(jī)上面的一個(gè)數(shù)據(jù)目錄，和日志類似，有容器的啟動(dòng)進(jìn)程，直接寫(xiě)腳本也可以，創(chuàng)造二級(jí)目錄。

用主機(jī)名，是在容器默認(rèn)的主機(jī)名，就是它的默認(rèn)ID號(hào)。如果這個(gè)ID已經(jīng)存在就不用創(chuàng)建，說(shuō)明容器是起用一個(gè)舊的容器，最后建立軟鏈接到數(shù)據(jù)目錄。這樣確保每個(gè)容器日志數(shù)據(jù)都持久化到宿主機(jī)，還可以確保容器重啟后數(shù)據(jù)不丟。

第二，數(shù)據(jù)本身有一個(gè)多帶帶的備份系統(tǒng)，它會(huì)每天晚上凌晨2點(diǎn)跑一遍，把Mysql數(shù)據(jù)推到Ceph塊存儲(chǔ)當(dāng)中，實(shí)現(xiàn)數(shù)據(jù)的可靠性。

集群可靠性實(shí)踐

這是容器集群可靠性實(shí)踐，最典型的是三個(gè)副本，副本能夠?qū)崿F(xiàn)數(shù)據(jù)和服務(wù)的可靠性。

失效重試，在集群各節(jié)點(diǎn)提供一個(gè)crontab定時(shí)任務(wù)，每隔一段時(shí)間探測(cè)一次docker服務(wù)進(jìn)程健康狀況，若不健康，則拉起Docker服務(wù)進(jìn)程。同時(shí)我們開(kāi)啟了docker的Restartalways選項(xiàng)，確保容器服務(wù)異常退出后，能被重新拉起來(lái)。

關(guān)于隔離，首先是分區(qū)隔離，宿主機(jī)業(yè)務(wù)日志目錄/app/log獨(dú)立分區(qū)，避免日志量過(guò)大時(shí)侵占宿主機(jī)系統(tǒng)分區(qū)或者業(yè)務(wù)分區(qū)磁盤(pán)。

第二，資源隔離，flume當(dāng)時(shí)是跑進(jìn)程的，我們做的第一件事情是進(jìn)行容器化，之后做配額，限制能使用的資源使用量，避免大日志傳輸時(shí)侵占宿主機(jī)過(guò)多資源。

第三，故障隔離，開(kāi)啟dockerlive-restore選項(xiàng)，保障docker服務(wù)進(jìn)程不影響容器服務(wù)。

前車之轍

我們犯過(guò)一些錯(cuò)誤，不負(fù)責(zé)物理機(jī)運(yùn)營(yíng)的童鞋可能感受不明顯。如果磁盤(pán)引導(dǎo)分區(qū)被破壞，就可能導(dǎo)致操作系統(tǒng)被重裝，這個(gè)問(wèn)題是很嚴(yán)重的。原因也很簡(jiǎn)單，服務(wù)器一般有多引導(dǎo)的選項(xiàng)，比如磁盤(pán)、網(wǎng)絡(luò)、CD，一般在順序上磁盤(pán)第一，網(wǎng)絡(luò)第二。

但如果磁盤(pán)引導(dǎo)分區(qū)壞了，服務(wù)器會(huì)認(rèn)為沒(méi)有操作系統(tǒng)，然后就從第二個(gè)上引導(dǎo)。這時(shí)候不幸的事情是，在你的網(wǎng)絡(luò)環(huán)境里如果之前剛好裝過(guò)操作系統(tǒng)，采用了第三方開(kāi)源的部署服務(wù)器，而沒(méi)有把之前的文件刪掉，那么它就會(huì)把那些操作重新裝上。

解決辦法很簡(jiǎn)單，我們提供了定時(shí)任務(wù)，對(duì)兩個(gè)小時(shí)前創(chuàng)建的引導(dǎo)文件，能看見(jiàn)它的創(chuàng)建時(shí)間、訪問(wèn)時(shí)間，并進(jìn)行強(qiáng)制性刪除。

第二個(gè)前車之轍，在收集Ceph日志時(shí)碰到困難，當(dāng)時(shí)是用fluent-plugin-ceph插件來(lái)做。具體的情況是，第一，官方配置文檔不正確，因?yàn)樘峤徽邲](méi)按官方文檔格式編碼，導(dǎo)致看到的配置是一行，拿回來(lái)根本不知道怎么辦。第二，它和td-agent1.0 版本不兼容。摸索出的解決方法就是圖片上顯示的辦法。

下一代云服務(wù)架構(gòu)

這是我們下一代云服務(wù)架構(gòu)，與上一代的主要區(qū)別在于，把編排框架換成了Kubernetes。目前AI這塊已經(jīng)用起來(lái)了，AI部分在線上大概有一百臺(tái)物理機(jī)，跑Job任務(wù)，短任務(wù)每天可以跑到三萬(wàn)個(gè)，一次性可以調(diào)動(dòng)3000個(gè)容器，未來(lái)會(huì)把這個(gè)些換成Kubnernetes，包括我們的AI、云服務(wù)都會(huì)跑在Kubernetes上。
XaaS on Kubernetes

如果把云服務(wù)跑到Kubernetes上，第一個(gè)要做的事情，可能會(huì)采用ceph塊存儲(chǔ)做后面的數(shù)據(jù)和數(shù)據(jù)持久化。目前vivo已經(jīng)有了數(shù)據(jù)ceph塊存儲(chǔ)，但功能還不強(qiáng)大。第二，要解決pod漂移調(diào)度問(wèn)題，如果不用ceph塊存儲(chǔ)，pod失效調(diào)度到其他節(jié)點(diǎn)上有問(wèn)題，調(diào)過(guò)去沒(méi)用的，沒(méi)有數(shù)據(jù)。
第三，也是最常見(jiàn)的一個(gè)，固定POD IP，看到網(wǎng)上有人討論這個(gè)事情，覺(jué)得容器壞了，沒(méi)必要把容器固定起來(lái)，因?yàn)橛羞`微服務(wù)的原則。這種觀點(diǎn)不太對(duì)，有一些場(chǎng)景，比如在vivo的企業(yè)IT架構(gòu)里面，很多東西都跟IP掛鉤，比如安全策略，它不是跟域名掛鉤，而是PODIP掛鉤，交換機(jī)、防火墻等很多的配置都跟這個(gè)相關(guān)。所以vivo要干的很重要的事情，就是把POD IP固定。
目前業(yè)界對(duì)這塊也有一些實(shí)踐，比如京東最近有這方面的分享，把PODIP放在一個(gè)APP的IP 小池子里面，小池子里面還有IP的話，就從小池子里拿，沒(méi)有的話就從大池子里去申請(qǐng)。

在微信公眾號(hào)后臺(tái)回復(fù)“127”，即可獲取本次演講PPT《vivo云服務(wù)容器化實(shí)踐》。