7月18日,"云用戶生態(tài)發(fā)展論壇暨第三屆中國(guó)云計(jì)算用戶大會(huì)"在北京國(guó)家會(huì)議中心召開。在下午的會(huì)議中，才云CEO張?chǎng)螏碇黝}為“生產(chǎn)環(huán)境中使用Docker的運(yùn)維實(shí)踐”的精彩演講，以下是他的演講實(shí)錄：

張?chǎng)危合雀蠹伊膬删洌驗(yàn)槲覀兪且粋€(gè)創(chuàng)業(yè)公司，所以可能對(duì)在座的很多人相對(duì)比較陌生。我先自我介紹一下，我叫張?chǎng)危莿?chuàng)始人兼CEO。先簡(jiǎn)單介紹一下我的這個(gè)背景。之前我在美國(guó)讀博士期間主要研究方向就是分布式系統(tǒng)和云計(jì)算。CMU畢業(yè)在美國(guó)Google一個(gè)研發(fā)中心作為技術(shù)帶頭人，主要就是參與并且主導(dǎo)了一些基于容器技術(shù)，怎么樣管理Google內(nèi)部有超過80多個(gè)數(shù)據(jù)中心，超過100萬臺(tái)服務(wù)器，怎么樣用容器，全部用容器，完全不用虛擬化，從2013年開始，這是我們?cè)贕oogle做的事情。

大概從2014年開始，看到AWS的成功和利潤(rùn)，那時(shí)候我們覺得有容器的秘密武器，所以我們要把它作為一個(gè)產(chǎn)品，也作為公有云的一個(gè)形態(tài)去推。所以，2014年以后我參與了Google幾款云產(chǎn)品的研發(fā)，也做了一些市場(chǎng)工作。從去年開始，我們就在杭州成立了一家創(chuàng)業(yè)公司，叫做才云科技，這家公司其實(shí)我們的初衷就是想把Google內(nèi)部我們所用的容器集群的技術(shù)作為產(chǎn)品提供給國(guó)內(nèi)的企業(yè)。所以，我們主要的對(duì)象是私有云。就在上個(gè)月，我們也成為Google和美國(guó)有一個(gè)機(jī)構(gòu)，叫做云原生（音譯）委員會(huì)，我們受邀成為中國(guó)區(qū)唯一的一個(gè)技術(shù)合作伙伴。

我今天主要想聊聊Docker。我今天主要做一些布道的工作，順便總結(jié)一下我們?cè)诼涞剡^程中所落地最佳實(shí)踐，因?yàn)闀r(shí)間有限，這個(gè)最佳實(shí)踐說起來幾天幾夜都說不完，我今天主要拋磚引玉，給大家講一些相對(duì)來說通俗易懂的。

先說一下容器主要解決什么問題，或者說我們?cè)趪?guó)內(nèi)落地企業(yè)當(dāng)中所發(fā)現(xiàn)的企業(yè)的一些痛點(diǎn)。簡(jiǎn)單來說，就是我們的企業(yè)IT面臨著多、快、穩(wěn)、省的挑戰(zhàn)。大概就是業(yè)務(wù)越來越多，用戶越來越多，對(duì)我們的開發(fā)的敏捷性和響應(yīng)的速度的要求也越來越高，同時(shí)怎么樣在這個(gè)快和多的同時(shí)做到快而不亂，多而不亂，使用更少的成本。這是總體來講。

下面我總結(jié)了十個(gè)具體的痛點(diǎn)，可能是我們企業(yè)用私有云，我們用OpenStack也好，用虛擬化也好，其實(shí)還會(huì)面臨一些痛點(diǎn)。

第一，系統(tǒng)成本偏高，物理資源利用率低下。造成這個(gè)的原因是多方面的，一方面虛擬機(jī)的技術(shù)，我們所熟悉的這些對(duì)驅(qū)動(dòng)虛擬化帶來的一些損耗。另一方面，我不同的業(yè)務(wù)和底層的服務(wù)器之間的映射其實(shí)存在一個(gè)一個(gè)孤島，我們有一個(gè)大數(shù)據(jù)業(yè)務(wù)，買了幾十臺(tái)很牛的機(jī)器，專門跑大數(shù)據(jù)，另外一些機(jī)器跑會(huì)員管理業(yè)務(wù)。但是，大家知道大數(shù)據(jù)機(jī)器非常耗資源，可能平時(shí)CPU在70%到80%以上，但是對(duì)于一些服務(wù)器大家晚上都睡覺了，利用率就降下來了，這樣我們系統(tǒng)怎么做動(dòng)態(tài)調(diào)度和彈性優(yōu)化，這樣導(dǎo)致系統(tǒng)成本偏高，資源利用率低。

第二，線上業(yè)務(wù)穩(wěn)定性、可靠性較低。不知道在座企業(yè)是否有跑在單機(jī)說，一旦機(jī)器掛了，這時(shí)候就造成業(yè)務(wù)的宕機(jī)。另外，這個(gè)機(jī)器掛了，沒有一種自動(dòng)的恢復(fù)，甚至自動(dòng)的檢查的一種機(jī)制，這都造成業(yè)務(wù)穩(wěn)定性和可靠性的偏低。

第三，互聯(lián)網(wǎng)時(shí)代我們什么都講究高并發(fā)，高可用。

第四，我們?cè)趺礃討?yīng)對(duì)這么高的流量，怎么樣在每秒應(yīng)付幾百萬，甚至千萬的并發(fā)，今年6.18京東動(dòng)用了10萬個(gè)Docker實(shí)現(xiàn)高可用和高并發(fā)這樣一種性能。

第五，目前很多傳統(tǒng)企業(yè)和應(yīng)用所謂的架構(gòu)是巨石行的，這樣帶來很多弊端。這個(gè)造成很多流程上的僵化。

第六，開發(fā)、測(cè)試、生產(chǎn)環(huán)境不一致，軟件系統(tǒng)難遷。就是怎么保證不同環(huán)境之間可以無縫的遷移，這里頭我講的環(huán)境是軟件環(huán)境。作為程序員來講，大家可能都說過一句話，這個(gè)程序在我的機(jī)器上是好用的，為什么跑到你這塊不好用了，這涉及到不同的同開發(fā)端到測(cè)試端到生產(chǎn)端不同的測(cè)試環(huán)境的控制。

第七，交付流程復(fù)雜，新版本上線缺風(fēng)險(xiǎn)把控。大家有沒有想過怎么樣做自動(dòng)化測(cè)試，怎么樣每個(gè)代碼有更新，可以自動(dòng)化的去對(duì)它進(jìn)行構(gòu)建測(cè)試，測(cè)試的結(jié)果能夠通過郵件等等方式自動(dòng)化的通知給我們，包括最終往生產(chǎn)上發(fā)布的時(shí)候怎么降低風(fēng)險(xiǎn)，采用灰度發(fā)布也好，這些都是在國(guó)內(nèi)的企業(yè)很多所沒有去實(shí)踐的，而在Google內(nèi)部一直在使用這樣一些最佳的實(shí)踐。

第八，環(huán)境配置呈指數(shù)級(jí)增長(zhǎng)，系統(tǒng)難以維護(hù)和調(diào)優(yōu)。我們現(xiàn)在都講究，大家可能采用微服務(wù)架構(gòu)，但是微服務(wù)架構(gòu)也帶來一個(gè)問題，原來一個(gè)程序就能搞定，現(xiàn)在換成很多模塊，不同模塊總能找到對(duì)方，怎么找？IP端口，十個(gè)模塊，相互之間都要寫配置。除此以外，不同的環(huán)境中間可能有一些配置文件，復(fù)雜度逐漸增加。

第九，系統(tǒng)管理使用眾多腳本和工具，學(xué)習(xí)成本高，難使用。后面這兩點(diǎn)可能大家都有這種痛點(diǎn)，包括虛擬化技術(shù)。

第十，缺乏快速調(diào)試，自動(dòng)監(jiān)測(cè)工具，故障修復(fù)時(shí)間過長(zhǎng)。當(dāng)系統(tǒng)出現(xiàn)問題以后，我們?cè)趺礃涌梢钥焖俚恼{(diào)試。有的一個(gè)一個(gè)查看日志，最后定位。怎么樣采用更系統(tǒng)的工具化的方法去做，這就是一個(gè)難題。

做這么多鋪墊，現(xiàn)在回到主題，就是容器這個(gè)東西。有聽過容器技術(shù)的，也有沒聽過的。所以，我現(xiàn)在按照我們就低不就高，按照小白的講法簡(jiǎn)單的總結(jié)一下。首先，容器這個(gè)技術(shù)，之所以2003年在Google就開始被使用，一直到2013年有了Docker這個(gè)產(chǎn)品以后，這個(gè)產(chǎn)品在全球開始風(fēng)靡，其實(shí)有它的本質(zhì)原因，歸根到底就是成本降低，速度提升。剛才我們一直說，后頭加一個(gè)零，減一個(gè)零，至少我們用了這個(gè)東西以后，先把成本后面減掉一個(gè)零。由于成本的美好，所以我們看一下它實(shí)際在美國(guó)落地的情況。我的數(shù)據(jù)來源是兩方面，第一方面是美國(guó)Docker公司官方的4月份所做的一個(gè)調(diào)研和統(tǒng)計(jì)。這個(gè)數(shù)字很多字也很小，大概講幾個(gè)關(guān)鍵的數(shù)字。

2015年截止到2016年4月份，有90%的美國(guó)企業(yè)至少在開發(fā)中使用了Docker這個(gè)技術(shù)，然后同時(shí)根據(jù)另外一個(gè)美國(guó)比較老牌的云計(jì)算公司經(jīng)常發(fā)布一些調(diào)研，已經(jīng)有76%的企業(yè)不光開發(fā)中用Docker，甚至用在生產(chǎn)當(dāng)中，每年基本上翻番。如果看Google內(nèi)部，從2003年開始使用，完全取代虛擬化。在中國(guó)去年浙江移動(dòng)“雙11”采用基于容器的數(shù)據(jù)中心操作系統(tǒng)技術(shù)承載“雙11”的流量。還有京東在6.18大促幾天時(shí)間之內(nèi)動(dòng)用十萬Docker度過這么一個(gè)高峰期。

剛才一直在說容器，容器其實(shí)在中國(guó)落地中遇到了哪些困難。為什么今天肯定我估計(jì)在座各位并不是所有人都已經(jīng)使用了容器。其中一大部分原因，就是作為任何一個(gè)新技術(shù)都帶來潛在的這樣一種風(fēng)險(xiǎn)和一種學(xué)習(xí)的成本，以及對(duì)已有系統(tǒng)的一些顛覆。這里最簡(jiǎn)單的例子，我們之前雖然知道出了問題以后，我們要SSH，很馬上，但是至少我們知道怎么做，但是現(xiàn)在全都裝到容器里，大家傻眼了，這就是對(duì)傳統(tǒng)運(yùn)維系統(tǒng)的一個(gè)顛覆。

除此以外，剛才提到像很多大數(shù)據(jù)的應(yīng)用，本身這個(gè)應(yīng)用自己就是集群化，但是容器有點(diǎn)和虛擬機(jī)類似，只是一個(gè)一個(gè)的單元。當(dāng)我面對(duì)復(fù)雜的應(yīng)用系統(tǒng)，跨主機(jī)的時(shí)候怎么全局的進(jìn)行容器化，怎么樣進(jìn)行分布式，跨主機(jī)的互聯(lián)，以及容器多了以后，怎么樣去管理。還有就是包括我開發(fā)者的時(shí)候，它開發(fā)的時(shí)候我原來代碼寫好直接提交代碼庫就好了，現(xiàn)在有Docker，怎么把Docker潛逃進(jìn)去，我認(rèn)為這些是Docker真正落地需要面臨的核心問題，我們需要解決的地方。

再給大家打個(gè)比喻，容器大家用了Docker都知道，最經(jīng)典的比喻就是一個(gè)集裝箱。所以我們可以把它想象成一個(gè)虛擬機(jī)，雖然理論上有很大差別，但是可以把它想象成一個(gè)虛擬機(jī)。把應(yīng)用裝進(jìn)去，環(huán)境裝進(jìn)去，放在一個(gè)箱子里，一次封裝，處處運(yùn)行。但是，當(dāng)我們這樣做了以后，發(fā)現(xiàn)一個(gè)問題，我們系統(tǒng)里有無數(shù)多個(gè)這樣的集裝箱，全都是新鮮的物種，以前從來沒有見過，這樣我們面臨的就是一整個(gè)碼頭，怎么去管理這么多的箱子，具體包括哪些集裝箱放在哪艘船上，怎么擺更有效，大家坐過飛機(jī)，坐飛機(jī)起飛之前有人工檢查，這個(gè)我們?cè)趺醋詣?dòng)檢查每一艘船，就是每個(gè)服務(wù)器是不是健康，以及出了事，怎么把一艘船上的箱子全都動(dòng)態(tài)的遷移到不同的地方，這些都是Docker運(yùn)行過程中遇到的一些阻礙。后面以點(diǎn)蓋面，拋磚引玉介紹一些我們解決集群管理這樣一些問題所遇到的，或者所采用的一些常見的方法。

第一，先看開發(fā)者。我們所有系統(tǒng)的萌芽都是從一個(gè)一個(gè)代碼開始，所以我們首先要解決在開發(fā)端怎么把這個(gè)Docker融入進(jìn)來。這時(shí)候我們要構(gòu)建一個(gè)大家可能熟悉的持續(xù)集成，持續(xù)發(fā)布的一個(gè)流水線，后面我會(huì)講到，在CICD以外我們有更多的事情要做。

這個(gè)流水線它的設(shè)計(jì)模式大致是這樣的。首先是代碼庫，可以是SDN，可以是本地的Internet。有了代碼庫以后，有這種外擴(kuò)，每當(dāng)我有一個(gè)代碼，提交以后我們要構(gòu)建一個(gè)自動(dòng)化的一個(gè)構(gòu)建的流程，用過Docker的朋友大家都知道，其實(shí)就是跑一個(gè)Docker  View（音譯），然后我們會(huì)自動(dòng)把它存到所謂的靜相倉(cāng)庫，然后再根據(jù)策略把它發(fā)布到目標(biāo)的機(jī)器上，這個(gè)策略兩個(gè)字怎么理解？第一，發(fā)在哪個(gè)環(huán)境，真正的系統(tǒng)里肯定不可能只有一個(gè)環(huán)境，肯定有開發(fā)，首先我們要配置策略，以什么樣的頻率發(fā)布在哪一個(gè)環(huán)境上，比如對(duì)開發(fā)環(huán)境，我們以前的做法每天晚上做一個(gè)構(gòu)建和發(fā)布，對(duì)于生產(chǎn)環(huán)境則是需要人工的手動(dòng)的去觸發(fā)，去進(jìn)行發(fā)布。

另外一個(gè)層面，這個(gè)策略還包括我們發(fā)布的時(shí)候是采取滾動(dòng)更新，還是全部重建，還是灰度測(cè)試，這三者的區(qū)別解決最簡(jiǎn)單的是全部重建。就是先把已有的服務(wù)，舊的版本1.0全部拿下來，再把2.0搞上去，這是全部重建。滾動(dòng)中心，就是先把2.0跑起來，確保沒有問題，再往1.0上。

第三，AB測(cè)試兩者同時(shí)并存，但是控制不同的比例，5%達(dá)到2.0%，然后驗(yàn)證沒有問題，5%提到10%，這些我們要支持不同的策略配置。

當(dāng)我們有一套流水線以后，我們發(fā)現(xiàn)對(duì)于開發(fā)者而言，它完全沒有感覺到流程的任何改變，因?yàn)樗龅倪€僅僅是將代碼發(fā)布到代碼庫，所有后面的構(gòu)建、打包、上傳、發(fā)布，全是由流水線做的。

但是這個(gè)時(shí)候我們也帶來一個(gè)新的問題，因?yàn)槲覀內(nèi)绻蠹铱赡茏鲞@個(gè)發(fā)布，如果比較規(guī)范，我們應(yīng)該知道每次發(fā)布，從代碼庫，代碼級(jí)別應(yīng)該打一個(gè)分支，這個(gè)時(shí)候多次發(fā)布以后，在代碼庫就有不同的分支，1.0、2.0、3.0，但是用過Docker的朋友知道，每次發(fā)布的時(shí)候怎么保證這個(gè)靜項(xiàng)版本和代碼版本一一對(duì)應(yīng)。

另外一個(gè)新問題，大家可能知道這個(gè)容器或者Docker這個(gè)東西非常天然的支持所謂微服務(wù)的架構(gòu)，剛才提到原來的一個(gè)模塊拆分成十個(gè)甚至更多，這個(gè)對(duì)發(fā)布來說帶來很大的問題。原來至少發(fā)布一個(gè)二進(jìn)制就好了，下來每次發(fā)布的時(shí)候十個(gè)模塊，而且關(guān)鍵是它模塊之間還不是獨(dú)立的，可能有一個(gè)后端模塊提供API服務(wù)，前端模塊去調(diào)用它，這個(gè)時(shí)候當(dāng)后端模塊更新以后，前端也必須同時(shí)更新。所以，我們發(fā)布的時(shí)候大家還要怎么樣做到多模塊的聯(lián)合發(fā)布，理解不同模塊之間的依賴關(guān)系和發(fā)布時(shí)候的時(shí)間順序，這些都是我們需要注意或者需要解決的地方。

正好講的微服務(wù)。其實(shí)我們做的時(shí)候很多企業(yè)問我們，都知道微服務(wù)很好，但是我們大家應(yīng)該切分到什么力度？很直觀的想象，為了最大化的發(fā)揮它的價(jià)值，應(yīng)該切分的比較細(xì)。但是，管理的系統(tǒng)很大，因?yàn)檫@個(gè)Docker和容器講的一個(gè)容器里就干一件事情，微服務(wù)，不要干太多，這個(gè)時(shí)候怎么管理？這個(gè)時(shí)候我們采用一個(gè)容器組的概念。容器可以理解為一個(gè)虛擬機(jī)，不同容器之間完全格力，可以想象每個(gè)容器有自己獨(dú)立的批，有自己獨(dú)立的網(wǎng)絡(luò)空間，相互之間也看不到彼此的進(jìn)程和文件系統(tǒng)，隔離性非常好。 但是容器組是基于這個(gè)容器以上，又做了一層封裝，多個(gè)容器可以被放到一個(gè)容器組，然后一個(gè)容器組里面的文件系統(tǒng)也可以共享，所以等于在上面多做了封裝。為什么要講容器組的概念，這是我們?cè)瓉碜鏊接性频暮锰?，它有幾大好處，它很好的解決了微服務(wù)切分的粗還是細(xì)的問題。我們?cè)谧龃a庫的時(shí)候，可以切的粒度很細(xì)，這樣保證獨(dú)立的發(fā)布和管理。但是，運(yùn)行時(shí)，當(dāng)我把這些東西都跑起來的時(shí)候，又可以把聯(lián)系很緊密的一些模塊定義到同一個(gè)容器組，后面管理的時(shí)候，我去做健康檢查的時(shí)候又是在容器組這么一個(gè)層面。所以，既給了大家在開發(fā)時(shí)候的獨(dú)立性，同時(shí)又給了大家當(dāng)東西真正跑起來的時(shí)候，管理的時(shí)候又提供了一層抽象。

時(shí)間不多了，后面我快速的過一下。另外一個(gè)就是當(dāng)我們系統(tǒng)內(nèi)部的組件多了以后，我們管理的時(shí)候怎么樣按照邏輯關(guān)系，按照樹型關(guān)系去管理，這個(gè)最傳統(tǒng)的做法就是把資源建立一個(gè)等級(jí)，但是實(shí)踐證明等級(jí)這個(gè)東西不夠靈活，所以我們推薦使用標(biāo)簽系統(tǒng)。

再快速的說幾個(gè)東西，我一開始提到我們可能潛在面對(duì)單點(diǎn)失效，面對(duì)穩(wěn)定性不夠，吞吐量不夠的問題?；谌萜髯龃笠?guī)模管理的時(shí)候，我們一定要采取面向管理的方法，當(dāng)不同模塊之間相互應(yīng)用的時(shí)候，不要連具體某一個(gè)實(shí)例的IP，我們需要在實(shí)例的前面建一個(gè)虛擬的入口，我們把它叫做服務(wù)的對(duì)象。這個(gè)服務(wù)的對(duì)象同時(shí)它會(huì)提供一個(gè)自動(dòng)的服務(wù)注冊(cè)的一個(gè)機(jī)制。什么叫服務(wù)注冊(cè)？有點(diǎn)類似于DNS的系統(tǒng)，當(dāng)把這個(gè)應(yīng)用跑起來，會(huì)自動(dòng)在DNS里把我的名稱注冊(cè)進(jìn)去。比如我有一個(gè)Redis，這樣的好處就是當(dāng)別的組件想要訪問這個(gè)緩沖服務(wù)的時(shí)候，可以簡(jiǎn)單通過Redis這個(gè)名字進(jìn)行自動(dòng)的服務(wù)的解析，這個(gè)過程叫做服務(wù)發(fā)現(xiàn)。

還有兩個(gè)好處，第一方面評(píng)比了底層IP的變化，可以達(dá)到不同環(huán)境之間的切換，不需要改配置IP。另外，當(dāng)服務(wù)對(duì)象后端真正的實(shí)力，這些副本進(jìn)行彈性伸縮的時(shí)候，或者出了故障進(jìn)行自動(dòng)恢復(fù)，自動(dòng)轉(zhuǎn)移的時(shí)候不會(huì)影響系統(tǒng)的穩(wěn)定性，因?yàn)樗械倪B接都不是直接在具體的實(shí)力上進(jìn)行的。這里當(dāng)然還包括構(gòu)建彈性伸縮，健康檢查等等。時(shí)間關(guān)系，我這邊就不贅述了。

所以，今天就是一個(gè)拋磚引玉，給大家介紹一下我們?cè)谏a(chǎn)過程中，在國(guó)內(nèi)的企業(yè)中使用這種容器和容器集群所達(dá)到的一個(gè)效果，簡(jiǎn)單的可以說一個(gè)數(shù)字。就是我們?cè)谀硞€(gè)運(yùn)營(yíng)商和IBM做了一個(gè)聯(lián)合的公測(cè)，每秒做到36個(gè)CPU，時(shí)間關(guān)系介紹到這里，有興趣的可以關(guān)注我們，跟我們一起討論，謝謝大家！