摘要：這里我想從我在谷歌內(nèi)部使用容器，并基于容器研發(fā)大規(guī)模生產(chǎn)平臺(tái)的經(jīng)驗(yàn)中談?wù)劕F(xiàn)有和谷歌容器環(huán)境的差別，并通過的實(shí)際案例落地經(jīng)驗(yàn)總結(jié)下自身所帶來的一些謊言和誤區(qū)。

我與容器的緣分起源于我在 Google 內(nèi)部研發(fā)容器集群管理系: Cluster Management。谷歌內(nèi)部一切皆容器，搜索、視頻、大數(shù)據(jù)、內(nèi)部工具等核心業(yè)務(wù)都以容器的方式運(yùn)行在容器編排系統(tǒng) Borg 上。2014年，隨著公司內(nèi)部的“Ursquake” (注：Urs 是負(fù)責(zé)基礎(chǔ)設(shè)施的高級(jí)副總裁)，我轉(zhuǎn)投到了公有云 Google Cloud Platform 的建設(shè)當(dāng)中。2014年3月份，在由各部門基礎(chǔ)設(shè)計(jì)技術(shù)帶頭人參加的谷歌內(nèi)部的云峰會(huì)中，我做為早期參與者之一加入到了 Kubernetes 的項(xiàng)目中。

從2015年回國(guó)創(chuàng)業(yè)至今，我親身感受到了國(guó)內(nèi)對(duì)于 Docker 的追捧熱度。如今，Docker已經(jīng)迅速在國(guó)內(nèi)形成了“要是不知道 Docker 都不好意思和人打招呼”的火熱勢(shì)態(tài)；在互聯(lián)網(wǎng)巨頭和獨(dú)角獸企業(yè)中，甚有從“誰在用 Docker”轉(zhuǎn)變?yōu)椤罢l沒用 Docker”之勢(shì)。

Caicloud 基于 Kubernetes 開源技術(shù)，力爭(zhēng)為企業(yè)提供 Gifee（Google’s Infrastructure for Everyone Else）的體驗(yàn)。目前已經(jīng)成功落地于多家國(guó)內(nèi)大型企業(yè)，其中不乏傳統(tǒng)國(guó)有企業(yè)。在不少案例中，我們都發(fā)現(xiàn)一個(gè)明顯的趨勢(shì)：很多企業(yè)一開始受到 Docker 現(xiàn)象的鼓吹，認(rèn)為 Docker 是萬靈藥，然而在自己嘗試進(jìn)行開發(fā)、生產(chǎn)使用時(shí)才發(fā)現(xiàn) Docker 帶來的不僅僅是“坑”，更多的是局限和對(duì)已有流程的顛覆。這里我想從我在谷歌內(nèi)部使用容器，并基于容器研發(fā)大規(guī)模生產(chǎn)平臺(tái)的經(jīng)驗(yàn)中談?wù)劕F(xiàn)有 Docker 和谷歌容器環(huán)境的差別，并通過 Caicloud 的實(shí)際案例落地經(jīng)驗(yàn)總結(jié)下 Docker 自身所帶來的一些“謊言”和誤區(qū)。希望能拋磚引玉，并在產(chǎn)品上填補(bǔ)空白，實(shí)現(xiàn) Gifee。

這里用“謊言”略有夸大其詞之嫌，Docker 也確實(shí)為軟件開發(fā)帶來了巨大的好處。而我想表達(dá)的是人們對(duì)于 Docker 的一些常見預(yù)期在現(xiàn)實(shí)使用中并非像理論中那般完美。

幾乎所有的 Docker 介紹或教程中提到的前幾個(gè) Docker 帶來的好處之一，必有“環(huán)境一致性”。然而這句話表述的并不準(zhǔn)確，“環(huán)境”是一個(gè)模糊和相對(duì)的概念。Docker 實(shí)現(xiàn)的是鏡像內(nèi)部的小環(huán)境一致性，它保證了一個(gè)應(yīng)用程序在一臺(tái)機(jī)器上使用 Jetty 9, 在另一臺(tái)機(jī)器上也使用Jetty 9（通過封裝軟件中間件如 Jetty 9）。然而大中型企業(yè)用戶很快意識(shí)到，真正的難點(diǎn)在于如何保證“大環(huán)境”一致，即整個(gè)業(yè)務(wù)系統(tǒng)中眾多容器、組件、服務(wù)之間如何配置、互聯(lián)、依賴，如何保證開發(fā)、測(cè)試、生產(chǎn)環(huán)境能相互轉(zhuǎn)化、克隆等。這些環(huán)境、配置在容器概念之上，是容器自身無法解決的，只能依賴集群層面的管理工具。

微服務(wù)與 Docker 是兩個(gè)完全獨(dú)立的維度，微服務(wù)所帶來的好處完全不依賴于你是否使用 Docker，同時(shí)微服務(wù)所帶來的問題 Docker 也無法解決。例如，如今大家都流行將原來的巨石型應(yīng)用進(jìn)行微服務(wù)細(xì)粒度切分，而第一個(gè)難點(diǎn)就是切分的粒度。雖然不乏最佳實(shí)踐和 Rule of Thumb, 但總的邏輯是切分的粒度越細(xì)，軟件開發(fā)靈敏度越高。然而帶來的問題是管理成本的增加：更多的模塊如何進(jìn)行各自的配置，更多的 API 通信、互聯(lián)如何管理，更多的二進(jìn)制（容器）如何發(fā)布。這些問題都是 Docker 自身不能解決的，也必須通過第三方工具來進(jìn)行彌補(bǔ)（例如 Kubernetes 的 Pod 機(jī)制就是谷歌基于內(nèi)部的經(jīng)驗(yàn)教訓(xùn)設(shè)計(jì)的一個(gè)解決方案）。

Docker 的大火也讓”App Centric”, “Cloud Native”煥發(fā)了青春，Docker 確實(shí)在為實(shí)現(xiàn)這兩者的道路上提供了便利，但Docker本身還遠(yuǎn)遠(yuǎn)不能和這兩個(gè)詞劃等號(hào)。Docker 對(duì)應(yīng)用雖然進(jìn)行了封裝，但是應(yīng)用的開發(fā)者在實(shí)踐中還遠(yuǎn)無法做到只要關(guān)心到 Docker 這一層即可。首先我們還是要關(guān)注操作系統(tǒng)，是否有合適的內(nèi)核，是否有合適的 API 支持。其實(shí)我們甚至要關(guān)心硬件，是 x86 架構(gòu)還是 power pc 架構(gòu)。此外，我們還需要關(guān)心引擎，是 Docker 還是 Rocket 還是 runC。最后，開發(fā)、運(yùn)維者還要關(guān)心平臺(tái)，是 Kubernetes 還是 Mesos 來進(jìn)行生產(chǎn)集群管理，并需要針對(duì)具體的底層平臺(tái)做完全針對(duì)該平臺(tái)的部署、配置（甚至需要修改應(yīng)用、框架等）。而這些都不是應(yīng)用、業(yè)務(wù)所應(yīng)該關(guān)心的范疇。

Docker 有很多開發(fā)、發(fā)布敏捷性方面的亮點(diǎn)，然而不少企業(yè)用戶認(rèn)為 Docker自身就邁向了 Devops，而殘酷的現(xiàn)實(shí)是他們往往在真正開始使用后很快發(fā)現(xiàn) Docker 帶來了額外的負(fù)擔(dān)，例如基于 Docker 的發(fā)布流程應(yīng)該是怎么樣，應(yīng)用程序打包的最佳實(shí)踐應(yīng)如何（如何避免打出一個(gè)上G的包），Docker 的鏡像倉(cāng)庫(kù)該如何管理（如何有效利用存儲(chǔ)空間、識(shí)別 Dockerhub 里的惡意鏡像）。總之，Docker 畢竟給系統(tǒng)中引入了新的一層?xùn)|西，業(yè)務(wù)出了問題，到底是應(yīng)用的問題還是 Docker 的問題？最后（among many others），Docker 自身主要是進(jìn)程級(jí)別的，而對(duì)于復(fù)合型、集群化的場(chǎng)景（翻譯：任何一個(gè)認(rèn)真的生產(chǎn)場(chǎng)景）則需要第三方的工具和系統(tǒng)來補(bǔ)足。在機(jī)器層面，如何做到跨主機(jī)的通信、數(shù)據(jù)的遷移、跨主機(jī)的任務(wù)調(diào)度；在應(yīng)用層面，如何做到用多個(gè) Docker 鏡像/容器構(gòu)造成一個(gè)復(fù)合性應(yīng)用（Codis 就是一個(gè)很好的例子）。當(dāng)然，Docker 的安全性也是經(jīng)久不衰、流行的議題。

還是要說明上述的論點(diǎn)旨在讓企業(yè)用戶認(rèn)識(shí)到 Docker 自身不是萬靈藥，但是我們也不可否認(rèn) Docker 對(duì)于軟件開發(fā)、發(fā)布和計(jì)算上所帶來的變革性優(yōu)勢(shì)。如何基于 Docker 自身的優(yōu)勢(shì)更上一層樓，我認(rèn)為需要順應(yīng)“社會(huì)專業(yè)化分工”，讓專業(yè)的人做專業(yè)的事，通過第三方工具一起打造一個(gè)完善的生態(tài)系統(tǒng)。

谷歌在十年間打造了三個(gè)集群管理系統(tǒng)：Borg、Omega、Kubernetes，原因就是基于它領(lǐng)先于外界多年的容器使用經(jīng)驗(yàn)，它清楚地意識(shí)到容器自身的局限性（只是應(yīng)用運(yùn)行的一個(gè)“載體”，和其他的載體諸入虛擬機(jī)、物理機(jī)在這個(gè)角度上甚至沒有本質(zhì)區(qū)別）。在雖有 Mesos 這一開源項(xiàng)目的情況下，谷歌還是在2014年決定大力推廣 Kubernetes 項(xiàng)目（內(nèi)部代號(hào)為 “Project 7”），是出于幾點(diǎn)深思熟慮。這些出發(fā)點(diǎn)也在 Kubernetes 在國(guó)外眾多知名企業(yè)（如 ebay 等互聯(lián)網(wǎng)巨頭，或高盛、 Bloomberg 等金融巨頭）和 Caicloud 在國(guó)內(nèi)一些大型甚至傳統(tǒng)國(guó)有企業(yè)的成功落地中得到了驗(yàn)證。

谷歌有著更多年的大規(guī)模生產(chǎn)級(jí)別容器管理經(jīng)驗(yàn)，這里說的“大規(guī)模”是百個(gè)數(shù)據(jù)中心、百萬臺(tái)機(jī)器、億萬個(gè)容器，且這個(gè)“經(jīng)驗(yàn)”既有成功也有教訓(xùn)。例如通過設(shè)計(jì) Borg 我們清楚地意識(shí)到配置管理的重要性，聲明性管理的重要性，為每個(gè)服務(wù)分配獨(dú)立IP地址來避免端口沖突的重要性等。通過 Omega 也意識(shí)到了可插拔調(diào)度器的重要性，模塊化系統(tǒng)的重要性，以及對(duì)于任務(wù)的完成時(shí)間的不可控性等。因此 Kubernetes 希望能夠?qū)⒐雀鑳?nèi)部多年容器管理的理念、經(jīng)驗(yàn)、教訓(xùn)以開源項(xiàng)目的形式傳遞給大家，而這個(gè)經(jīng)驗(yàn)是獨(dú)一無二的。

另外與 Mesos 的關(guān)注點(diǎn)不同（資源分配），Kubernetes 是完全原生態(tài)面向服務(wù)和集群化容器應(yīng)用的（Mesos 面向的是“框架”），它旨在提供更多便捷的容器管理工具、機(jī)制和功能。因此除了常見的任務(wù)調(diào)度、服務(wù)發(fā)現(xiàn)、健康檢查和自動(dòng)修復(fù)，它還提供了獨(dú)特的功能，諸如容器組管理，秘密管理，服務(wù)賬戶管理，配置管理，守護(hù)進(jìn)程管理，寵物應(yīng)用管理等，都是谷歌在內(nèi)部形形色色應(yīng)用、業(yè)務(wù)類型管理中所提煉出來的重要功能。

打造活躍、健康的開源社區(qū)：Kubernetes 是當(dāng)前最活躍的開源社區(qū)，在 github 上已有1萬4千多顆星（相比于其他容器集群項(xiàng)目的數(shù)千顆星）。谷歌做開源社區(qū)也有重要意義：雖然在市場(chǎng)端不同的廠商可以通過花樣繁多的市場(chǎng)手法和資金投入包裝自己的產(chǎn)品領(lǐng)先度，開源社區(qū)的健壯程度卻是無法用錢或市場(chǎng)廣告買來的。谷歌通過打造開源社區(qū)可以更客觀地展現(xiàn)自己在基礎(chǔ)設(shè)施、容器、集群管理方面的技術(shù)優(yōu)勢(shì)。當(dāng)然或許有誤區(qū)認(rèn)為項(xiàng)目不活躍是因?yàn)檐浖俺墒臁保?xiàng)目活躍是因?yàn)轫?xiàng)目不成熟。然而谷歌內(nèi)部的代碼庫(kù)每天仍有近萬個(gè)新的 issues 被開啟，絕不是因?yàn)楣雀?0多年的業(yè)務(wù)系統(tǒng)不成熟，而更多的是創(chuàng)新性的一種表現(xiàn)（大部分 issues 是在不斷迭代更強(qiáng)大的新功能——在保證穩(wěn)定的基礎(chǔ)上）。由于當(dāng)今互聯(lián)網(wǎng)業(yè)務(wù)千變?nèi)f化，創(chuàng)新層出不窮，任何系統(tǒng)都需要不斷的迭代，如果一個(gè)項(xiàng)目因達(dá)到“成熟”而活躍度下降，這只是該項(xiàng)目遭到冷落的表現(xiàn)。

無論是 Docker 還是開源第三方集群管理工具，如要到達(dá) Gifee 都還有很長(zhǎng)的路要走。這里我僅僅拋磚引玉列舉一些空白和我們希望和正在努力的方向。

發(fā)布管理遠(yuǎn)大于 CI/CD

如今談到發(fā)布，大家想到的就是持續(xù)集成（CI）和持續(xù)發(fā)布（CD）。然而我們?cè)诠雀鑳?nèi)部實(shí)踐的發(fā)布管理系統(tǒng)還包括很多其他的方方面面，例如：

如何將鏡像的構(gòu)建與代碼庫(kù)的分支構(gòu)建相整合
如何做微服務(wù)架構(gòu)中的聯(lián)合發(fā)布（最重要的是保證新老版本的API能夠平滑兼容）
如何做版本管理（哪個(gè)鏡像版本運(yùn)行在哪個(gè)數(shù)據(jù)中心上）
如何做灰度發(fā)布（根據(jù)不同的時(shí)間節(jié)點(diǎn)、步調(diào)來有策略的調(diào)整新版本的上線比率，自動(dòng)比對(duì)新舊版本的用戶行為等）

Devops 包含方方面面，其中諸多實(shí)踐都是 Docker 自身層面所不能企及的，以谷歌為例：
配置管理：要做到真正的大環(huán)境一致，必須將配置完全與代碼分離，這里的配置遠(yuǎn)不僅僅是服務(wù)之間的 IP 地址（通過 DNS 服務(wù)發(fā)現(xiàn)可以解決），還包括不同環(huán)境下對(duì)于不同服務(wù)、應(yīng)用的配置參數(shù)等。對(duì)于這些狀態(tài)、配置、數(shù)據(jù)、文件的維護(hù)則需要額外的配置管理系統(tǒng)。

分布式測(cè)試：測(cè)試是 Devops 中不可或缺的一環(huán)，但是在大規(guī)模應(yīng)用系統(tǒng)中，如何有效地、智能地快速自動(dòng)運(yùn)行系統(tǒng)測(cè)試則需要額外的系統(tǒng)；在谷歌內(nèi)部我們構(gòu)建了分布式測(cè)試系統(tǒng)，能夠基于 Borg，有選擇地識(shí)別出收到某個(gè) commit 影響的測(cè)試集進(jìn)行高效自動(dòng)化測(cè)試。

智能預(yù)警：Docker 或容器只是應(yīng)用運(yùn)行的載體，而 Docker 自身失效后需要第三方系統(tǒng)來檢測(cè)并預(yù)警。谷歌打造了復(fù)雜、靈活的預(yù)警系統(tǒng)，可以支持自定義的預(yù)警規(guī)則和報(bào)警行為。

智能故障定位：微服務(wù)架構(gòu)的分布式天性將系統(tǒng)問題調(diào)試變得更加復(fù)雜，一個(gè)用戶的請(qǐng)求在系統(tǒng)內(nèi)部要遍歷多個(gè)服務(wù)模塊，而在出現(xiàn)問題時(shí)如何幫助系統(tǒng)管理員自動(dòng)定位故障也需要額外的工具和系統(tǒng)來完成。

最后想澄清的一個(gè)名詞是”集群管理“。現(xiàn)在當(dāng)人們談及“集群管理”時(shí)，容易直接和 Kubernetes，Mesos 等劃等號(hào)。然而集群管理在谷歌內(nèi)部是一個(gè)非常龐大的組織，Borg 只能算作任務(wù)管理或應(yīng)用管理，除此之外一個(gè)真正的集群管理系統(tǒng)還需要涉及到機(jī)器管理、網(wǎng)絡(luò)管理、安全管理等諸多方面：

機(jī)器管理：如何自動(dòng)配置、安裝機(jī)器，如何自動(dòng)進(jìn)行機(jī)器層面的問題檢查與修復(fù)
網(wǎng)絡(luò)管理：如何與 SDN 聯(lián)動(dòng)
安全管理：如何在容器的基礎(chǔ)上做應(yīng)用、業(yè)務(wù)層面的安全檢測(cè)

本文作者：
才云科技 CEO 張?chǎng)?/p>

曾為美國(guó)谷歌軟件工程師，從事谷歌核心技術(shù)底層系統(tǒng)研發(fā)。 2012年至2014年，作為主要技術(shù)人員從事谷歌數(shù)據(jù)中心（IDC）集群管理系統(tǒng)（Cluster Management）的研發(fā)，該集群系統(tǒng)自動(dòng)管理和維護(hù)95%以上的谷歌集群機(jī)器；帶頭開發(fā)的自動(dòng)故障應(yīng)對(duì)系統(tǒng)將谷歌集群的故障率大大降低，為谷歌節(jié)省了每年千萬美元的運(yùn)維成本；作為核心技術(shù)人員參與了谷歌云計(jì)算平臺(tái)的系統(tǒng)到產(chǎn)品的全棧式開發(fā)；開發(fā)的圖形化應(yīng)用部署（Click-to-deploy）、部署經(jīng)理（Deployment Manager）等產(chǎn)品上線后即獲得用戶廣泛使用；設(shè)計(jì)了谷歌倡導(dǎo)的新一代“云服務(wù)”（Managed Cloud）的設(shè)計(jì)，此理念獲得了美國(guó)IBM，VMWare，Redhat等云計(jì)算巨頭公司一致響應(yīng)。

于2012獲美國(guó)頂級(jí)計(jì)算機(jī)學(xué)府Carnegie Mellon University (CMU)大學(xué)計(jì)算機(jī)博士學(xué)位，發(fā)表國(guó)際學(xué)術(shù)論文數(shù)十篇，成為分布式系統(tǒng)和網(wǎng)絡(luò)安全方向的學(xué)術(shù)專家，曾為美國(guó)個(gè)性醫(yī)療初創(chuàng)公司SMART-MD, AllPancreas提供應(yīng)用軟件平臺(tái)構(gòu)架、安全技術(shù)咨詢和基于云平臺(tái)的系統(tǒng)開發(fā)。