億級用戶萬臺服務器背後，vivo雲服務容器化如何破繭化蝶？

2018年數人云Meetup第一站，聯合vivo在深圳舉辦 Building Microservice 系列活動第一期。本次技術沙龍vivo、中興通信、華爲、數人云共同派出技術大咖，爲開發者們帶來有關微服務、容器化、配置中心、服務網格等領域的實戰與乾貨分享。

數人云Meetup每個月一期，歡迎你們來面基、學習。本文爲vivo雲計算架構師袁樂林分享的「vivo雲服務容器化實踐」現場演講實錄。

今天講的內容主要是介紹技術背景，產品的技術架構，咱們關鍵技術的實踐，前車可鑑，以及對下一代雲服務架構的設想。

技術背景

vivo這些年的業務增加很是快，用戶數已經上億，服務器到了萬級，業務域好幾百，後端系統的複雜度在迅速攀升，不光是運維方面、架構體系複雜度也很是高，vivo技術架構也是到了破繭化蝶的時候。

咱們作過容器、虛擬機與物理機性能對比測試。上面這張圖是當時作的性能測試架構圖。得出了一些測試結論：

1.容器化app（4c8g）在性能上略優於非容器化app測試指標

2.容器化app（32c64g）性能相較於裸跑同物理機有近4%左右性能損耗，其中TPS有3.85%損耗，平均響應時間3.95%（1毫秒）的增長，對業務請求無影響。

3.容器化app在12h的穩定性測試中表現正常

4.容器化app在cpu相對配額，cpu綁定以及絕對配額場景下，業務性能CPU相對配額 > CPU綁定 > 絕對配額。

5.容器化app在組部件異常，單計算節點，控制異常場景下，容器運行正常。

綜上所述，容器化app性能上接近物理機，在多測試場景下，表現相對穩定可靠。同時，對計算密集型app，相對權重配額能實現CPU資源利用率最大化。

vivo容器化雲服務框架

正是由於這個性能測試數據的支撐，就有了vivo容器化雲服務框架，咱們給它取名 Kiver，提供輕量級、高可靠的容器化生產方案。

在這個框架之上vivo一共有八個雲服務，按照後來統計數據來看，MySQL加上其餘兩個服務佔到80%的比例，這也很是符合「二八」原則。

vivo整個雲服務容器化產品的架構，左邊是運維自動化的工具集，好比日誌、監控等，日誌在業界應用很是普遍，咱們用採集容器的數據、容器的監控指標。

這裏有兩個日誌，上面是中間件的業務日誌平臺，全部業務基於中間件日誌規範，輸出日誌後都會送到這裏面收集起來，可是這個業務日誌平臺功能目前比較薄弱，對新增長的一些組件，好比ECTD等不支持。vivo又引入瞭如今容器領域比較常見的日誌方案EFK，從此會規劃把兩個日誌整合到一塊兒。

vivo在運維方面作了一些工具，如 vivo MachineCtl和 KiverCtl，兩個工具主要實現宿主機的自動化，簡單來講能夠把宿主機操做系統自動化地裝起來，裝完以後變成Kiver的計算節點或者控制節點。還有KiverPerfermance，是咱們內嵌的一個小的性能測試插件。

再來看右邊，是vivo的基礎設施，物理機和交換機，網絡設備和防火牆等，上面是Docker，Docker容器虛擬化技術把物理機上面的相關資源虛擬化用起來。

右邊有 Ceph 塊存儲，實現數據備份，上面是vivo自研的DevOps平臺，作了調度框架，右邊是用harbor作的鏡像倉庫，再往上就是雲服務Portal，前面所說的那些雲服務，同時也能夠跑長生命週期應用。

宿主機自動化實踐

下面咱們講一下vivo的實踐。如今物理機一旦上了規模以後，裝操做系統就成爲一件大事，咱們提供了 vivoMachineCtl，這個工具是一個命令行給運維人員使用，能夠實現宿主機集中化的參數配置和自動化。

利用 vivoMachineCtl，首先和物理機管理卡作一個交互，交互以後拿到物理機的MAC地址，這裏有個BMC，也有廠商叫iDrac卡，它能夠取得這臺服務器網卡的MAC地址，建立以MAC地址命名的Bootfile，指明如今須要裝什麼操做系統，和其餘一些參數。再進一步給它一個ipmi消息對服務器復位，而後服務器開始重啓。

重啓以後，服務器第一次會發dhcp請求，拿到IP地址，以後會走一個pxe的協議，拿到bootfile，下載Bootfile所指明的小系統和內存文件系統文件下來，加載到物理機中，而後開始進行操做系統安裝。這就是操做系統安裝的過程。操做系統安裝完成以後，把安裝類和文件系統切換成正在啓動的文件系統，在post階段到集中化的配置中心，把相關的配置拉下來，包括IP地址，主機名和網關等信息，這是宿主機的自動化部署。

KiverCtl實際上就是把操做系統的宿主機變成計算節點或者控制節點。計算節點有以下幾個功能：第一，基本的包安裝，第二，Docker、Netplugin初始化，啓動kiver-guard/flume/cadvisor容器，完成日誌和監控指標的採集。

控制節點上面有Etcd和Netmaster，也會可選地Prometheus/alertmanager/grafana/啓動起來。vivoMachineCtl和KiverCtl實現了雲服務器節點從物理機到宿主機的轉變。

業務日誌集成到日誌平臺實踐

這是vivo日誌採集的實踐，在宿主機上作日誌分區，容器運行起來以後掛這個目錄，每一個容器起來以後會建立一個本身的文件目錄。外面有kiver-guard，用來偵聽內核文件系統的新日誌文件建立的通知。

根據通知會建立軟件連接，連接到上一級Flume監控的日誌目錄，由Flume推到kafka。大數據平臺會來消費這裏的數據，業務日誌平臺也會消費這個數據，而後持久化到ES裏，最後由中間件日誌平臺來實現對日誌的檢索和展現。

爲何要這麼作？當時用的flume版本不支持自動收集遞歸子目錄下日誌新增內容的收集，完整的文件能夠收集進去，可是日誌文件在遞歸子目錄下有不停地追加是輸不進去的。

kiver-guard自己也是一個容器，它起來以後把宿主機日誌目錄掛上去，在容器裏面偵聽日誌目錄下的create事件。

無論這些日誌路徑有多深或者在哪裏，均可以連接出來。作連接的時候有一點須要注意，要確保連接過來以後文件名稱是惟一的。有些容器被刪除了，或者日誌被輪轉刪除了，一樣也會針對Delete事件，偵測到delete是件以後刪除上層flume監控日誌路徑的對應連接。

基礎組件日誌收集實踐

基礎組件日誌採用Etcd、Ceph、CentOS、Netmaster等一些網上比較熱門的EFK組件，開箱即用。

監控與告警實踐

這是監控和告警實踐，在容器領域比較常見，vivo採用的是Promethus和Alertmanager。Promethus採用雙節點，雙拉（拉兩遍），兩個Promethus之間沒有作主從，爲了解決高可用問題，掛了一個另一個還在。

以後接短信郵件中心，後面接Grafana做爲監控面板，前面用了telegraf。咱們作的東西不只僅有容器，還有其餘的組件像Ceph。咱們用Cadvisor收集容器監控指標。

咱們對集羣健康作監控，也對集羣資源使用狀況進行監控，集羣的健康性採用telegraf能夠調用外部shell腳本的特性。咱們在控制節點寫了腳本，用來檢查Etcd的健康狀況，也和各個節點進行通信，檢查各個節點是否是健康。以後會返回數值，給出集羣健康狀態碼。

這個就是前面講的自定義的一些監控指標，這是集羣的健康檢查，這是集羣的資源利用率，大體兩條數據鏈進來。一個腳本由telegraf去拉，推到Prometheus裏面，最後展示在Grafana上面。另外一個，由DevOps框架把數據寫到Mysql裏面，再由Grafana定義Mysql的軟件源。

這邊拉出來的自定義的健康指標支持返回碼，這個返回碼須要翻譯成文字，實際上Grafana已經具有這個特性，咱們能夠去作一個映射，好比1表明監控，2表明網絡問題等等，它能夠自動翻譯來。

數據持久化實踐

說到雲服務你們都會關注這個問題，數據怎麼作到持久化，作到不丟。容器啓動的時候會掛在宿主機上面的一個數據目錄，和日誌相似，有容器的啓動進程，直接寫腳本也能夠，創造二級目錄。

用主機名，是在容器默認的主機名，就是它的默認ID號。若是這個ID已經存在就不用建立，說明容器是起用一箇舊的容器，最後創建軟連接到數據目錄。這樣確保每一個容器日誌數據都持久化到宿主機，還能夠確保容器重啓後數據不丟。

第二，數據自己有一個單獨的備份系統，它會天天晚上凌晨2點跑一遍，把Mysql數據推到Ceph塊存儲當中，實現數據的可靠性。

集羣可靠性實踐

這是容器集羣可靠性實踐，最典型的是三個副本，副本可以實現數據和服務的可靠性。

失效重試，在集羣各節點提供一個crontab定時任務，每隔一段時間探測一次docker服務進程健康情況，若不健康，則拉起Docker服務進程。同時咱們開啓了docker的Restartalways選項，確保容器服務異常退出後，能被從新拉起來。

關於隔離，首先是分區隔離，宿主機業務日誌目錄/app/log獨立分區，避免日誌量過大時侵佔宿主機系統分區或者業務分區磁盤。

第二，資源隔離，flume當時是跑進程的，咱們作的第一件事情是進行容器化，以後作配額，限制能使用的資源使用量，避免大日誌傳輸時侵佔宿主機過多資源。

第三，故障隔離，開啓dockerlive-restore選項，保障docker服務進程不影響容器服務。

前車之轍

咱們犯過一些錯誤，不負責物理機運營的童鞋可能感覺不明顯。若是磁盤引導分區被破壞，就可能致使操做系統被重裝，這個問題是很嚴重的。緣由也很簡單，服務器通常有多引導的選項，好比磁盤、網絡、CD，通常在順序上磁盤第一，網絡第二。

但若是磁盤引導分區壞了，服務器會認爲沒有操做系統，而後就從第二個上引導。這時候不幸的事情是，在你的網絡環境裏若是以前恰好裝過操做系統，採用了第三方開源的部署服務器，而沒有把以前的文件刪掉，那麼它就會把那些操做從新裝上。

解決辦法很簡單，咱們提供了定時任務，對兩個小時前建立的引導文件，能看見它的建立時間、訪問時間，並進行強制性刪除。

第二個前車之轍，在收集Ceph日誌時碰到困難，當時是用fluent-plugin-ceph插件來作。具體的狀況是，第一，官方配置文檔不正確，由於提交者沒按官方文檔格式編碼，致使看到的配置是一行，拿回來根本不知道怎麼辦。第二，它和td-agent1.0 版本不兼容。摸索出的解決方法就是圖片上顯示的辦法。

下一代雲服務架構

這是咱們下一代雲服務架構，與上一代的主要區別在於，把編排框架換成了Kubernetes。目前AI這塊已經用起來了，AI部分在線上大概有一百臺物理機，跑Job任務，短任務天天能夠跑到三萬個，一次性能夠調動3000個容器，將來會把這個些換成Kubnernetes，包括咱們的AI、雲服務都會跑在Kubernetes上。

XaaS on Kubernetes

若是把雲服務跑到Kubernetes上，第一個要作的事情，可能會採用ceph塊存儲作後面的數據和數據持久化。目前vivo已經有了數據ceph塊存儲，但功能還不強大。第二，要解決pod漂移調度問題，若是不用ceph塊存儲，pod失效調度到其餘節點上有問題，調過去沒用的，沒有數據。 第三，也是最多見的一個，固定POD IP，看到網上有人討論這個事情，以爲容器壞了，不必把容器固定起來，由於有違微服務的原則。這種觀點不太對，有一些場景，好比在vivo的企業IT架構裏面，不少東西都跟IP掛鉤，好比安全策略，它不是跟域名掛鉤，而是PODIP掛鉤，交換機、防火牆等不少的配置都跟這個相關。因此vivo要乾的很重要的事情，就是把POD IP固定。 目前業界對這塊也有一些實踐，好比京東最近有這方面的分享，把PODIP放在一個APP的IP 小池子裏面，小池子裏面還有IP的話，就從小池子裏拿，沒有的話就從大池子裏去申請。

在數人云微信公衆號後臺回覆「127」，便可獲取本次演講PPT《vivo雲服務容器化實踐》。