摘要：說起，必須要介紹是什么東西，為什么中小企業(yè)私有云適合使用?？匆幌卢F(xiàn)在的架構(gòu)圖開個玩笑。上面這四點導(dǎo)致我們必須要統(tǒng)一架構(gòu)，最終把整個業(yè)務(wù)系統(tǒng)遷移到基于的類似于的私有云的平臺。

本文系 ArchSummit 大會 CODING 工程師王振威演講實錄。

大家好，非常高興在這里跟大家分享，我是王振威，來自 Coding 的一個程序員。今天給大家?guī)淼姆窒碇饕俏覀儓F(tuán)隊在使用 Docker 改進(jìn)原有的業(yè)務(wù)系統(tǒng)的演進(jìn)計劃和實施的經(jīng)驗教訓(xùn)。

說起 Docker，必須要介紹 Docker 是什么東西，為什么中小企業(yè)私有云適合使用 Docker。其次是我們做一套架構(gòu)系統(tǒng)的變遷，總是事出有因的，我們必須介紹一下為什么變遷。第三是怎么變遷，作為中小型企業(yè)要想把業(yè)務(wù)假設(shè)到私有云上，如何一步一步來做。最后我們在使用Docker的過程中遇到了比較棘手和麻煩的問題。

第一，Docker，在座有相當(dāng)一部分人已經(jīng)了解了，它是容器技術(shù)，跟私有云有什么關(guān)系？那么首先要解釋一下什么叫私有云。

私有云用這樣一句話來形容是最為貼切的：就是企業(yè)內(nèi)部的服務(wù)于企業(yè)自身的云服務(wù)平臺。企業(yè)內(nèi)部有很多服務(wù)器，有不同的業(yè)務(wù)系統(tǒng)，但是想讓這些業(yè)務(wù)系統(tǒng)高效地運行起來，我們往往會采用類似于 IaaS 或者 PaaS 的技術(shù)來搭建這個平臺。那么 Docker 為什么適用于搭建一個私有云的企業(yè)平臺呢？因為容器技術(shù)比傳統(tǒng)的VM技術(shù)成本更低、效率更高。關(guān)鍵點在于這種技術(shù)是兼容性又好的，可以使我們傳統(tǒng)的架構(gòu)變遷顯得更為平滑，這是最為重要的一點。另外，容器技術(shù)一大特點就是快速實現(xiàn)隔離，統(tǒng)一調(diào)配。有如下三快：

構(gòu)建快
一個應(yīng)用最終的形式往往是環(huán)境加上程序包，形成最終的鏡像，image 就是程序本身外加環(huán)境，Docker 讓我們可以用 Dockerfile 之類的技術(shù)定義鏡像，自動構(gòu)建，免去在很多服務(wù)器上繁雜的安裝配置應(yīng)用程序環(huán)境的過程

啟動快
容器相比虛擬機的啟動速度是非?？斓?，開一臺虛擬機的啟動速度慢一點的一分鐘，快一點的也要十幾秒，但是容器往往可以做到秒級啟動，這為我們后面所講的容器化交付奠定了基礎(chǔ)。

遷移快
應(yīng)用以容器的方式標(biāo)準(zhǔn)化交付，這個主機跟另外一個主機只要安裝了 Docker 就沒有什么差別，image 不管扔到這里還是扔到那里都可以很快地正常運行。而傳統(tǒng)的 VM，只是省去了我們購置租用物理服務(wù)器的過程，本質(zhì)上來講還是一個裸的操作系統(tǒng)，本來這個程序在 A 機運行，但 A 機掛了，現(xiàn)在來配置 B機，裝了 JDK，發(fā)現(xiàn)不行，這個 JDK 版本不對啦，JDK 缺少了本地的庫啦，之類一系列問題。但是如果用了 Docker，用了容器技術(shù)，它把這些依賴環(huán)境全打成 image，只要把 image 下載下來就行了，這是編程語言，框架無關(guān)的，因為應(yīng)用的環(huán)境是跟著應(yīng)用走的。

看一下現(xiàn)在的架構(gòu)圖

開個玩笑。

如果我們的架構(gòu)是這樣的話那就沒什么好講了，我的意思是說一個成熟的以容器來做基層建設(shè)的私有云環(huán)境，最終的效果應(yīng)該像巨輪一樣，可以把所有的貨艙都碼放整齊，可以平穩(wěn)地向前航行，這是基于容器的私有云的愿景。

有人會問了，如果說你之前的架構(gòu)沒問題，為何要遷移到這個環(huán)境來呢？

事出有因，假如傳統(tǒng)的架構(gòu)是很好的，我們沒必要遷移到 Docker 這種私有云環(huán)境來，我們?yōu)槭裁匆w移？

有幾個原因：

第一是我們之前的業(yè)務(wù)系統(tǒng)隨著時間的發(fā)展越來越多，不同的組件需要協(xié)同去做不同的工作，給運維帶來了巨大的挑戰(zhàn)，有 JAVA 寫的程序，還有些程序制定了必須用 JDK7，一些部門覺得 JDK8 有些特性比較好用所以用了 JDK8，還有些組件是用 Ruby 寫的，還有 Golang，NodeJS等等，目前我們系統(tǒng)中牽扯的系統(tǒng)語言已經(jīng)達(dá)到了八九種，這對運維來講是一個巨大的挑戰(zhàn)，我們必須要給各種各樣的程序準(zhǔn)備各種各樣的環(huán)境，維護(hù)，遷移都非常麻煩。

另外配置混亂，當(dāng)你應(yīng)用的服務(wù)器數(shù)量越來越多，有的系統(tǒng)可能是用 upstart 來管理程序，有的是用 Supervisor , 有些程序可能只是個 定時任務(wù)。我們的編程語言每一種都會有自己的構(gòu)建工具，構(gòu)建工具對依賴的管理也不太一樣。最終的結(jié)果是操作系統(tǒng)中的配置文件和各種黑科技補丁腳本散落在系統(tǒng)的各個角落，沒人能找得到，也沒人搞得懂。

最后致命的一點是監(jiān)控和資源的混亂,?監(jiān)控混亂，如果是一個很簡單的程序，往往只需要做到當(dāng)發(fā)生錯誤，把這個錯誤日志打印出來，運維上看一下日志就行了。當(dāng)涉及到幾百臺應(yīng)用服務(wù)器，其中的各個組件每天打印上百萬條、上千萬條各種不同級別的日志的時候，運維是沒有精力去了解的，我們只能做錯誤報告，做消息的推送，但是因整體系統(tǒng)混亂，每個應(yīng)用有各自的方式，最終導(dǎo)致日志，錯誤監(jiān)控都沒能達(dá)到相應(yīng)的預(yù)期。然后是混亂的資源，我們做 WEB 的應(yīng)用往往出現(xiàn)白天是高峰期，晚上是低峰期，低峰期zi"yuanziyuan使用率很低，屬于資源的浪費。另外有些業(yè)務(wù)在申請計算資源的時候不能提前預(yù)估到使用量有多少，申請的過多或者過少，運維又要經(jīng)常承擔(dān)著縮容擴容的問題。

有因必有果，環(huán)境不匹配導(dǎo)致測試跟生產(chǎn)環(huán)境不一樣，比如生產(chǎn)環(huán)境是 JDK8 跑的，某一個開發(fā)者本地用 JDK7 測試的程序，上去發(fā)現(xiàn)這個東西根本不對，雖然 JDK7 和 JDK8 的兼容性已經(jīng)是99%以上，但是一個嚴(yán)謹(jǐn)?shù)臉I(yè)務(wù)系統(tǒng)必須要做到測試環(huán)境跟生產(chǎn)環(huán)境是一致的。

配置混亂導(dǎo)致事故頻發(fā)，做過運維的肯定了解，這個配置被誰改掉了，這個服務(wù)宕掉了，當(dāng)你的組件越來越多的時候根本無從管理。監(jiān)控不一致，資源效率低。計算資源的成本很高，卻達(dá)不到相應(yīng)的目標(biāo)。所以之前那艘看起來航行很平穩(wěn)的巨輪，在上面這四大原因的影響下，事實上是這樣的。

上面這四點導(dǎo)致我們必須要統(tǒng)一架構(gòu)，最終把整個業(yè)務(wù)系統(tǒng)遷移到基于 Docker 的類似于 PaaS 的私有云的平臺。

架構(gòu)變遷，作為一個架構(gòu)團(tuán)隊的 Leader，在做架構(gòu)變遷遵循的時候要掌握如下原則：

即面向未來，又不過于激進(jìn)

即追求穩(wěn)定，又不過與保守

其實就是掌握平衡，追求一個度。我們用新技術(shù)，必然是為了解決舊技術(shù)的問題我們才用，但如果過于追求新技術(shù)，忽略了業(yè)務(wù)的重要性，你會發(fā)現(xiàn)你最終是得不償失的。所以我們遵循的原則是既面向未來，又不過于激進(jìn)，既追求穩(wěn)定，又不過于保守。

關(guān)于技術(shù)選型，這是我們團(tuán)隊的做法。

容器技術(shù)現(xiàn)在有幾種選擇，Docker 本身的底層就是 RunC。谷歌內(nèi)部有自己的容器技術(shù)，VMware 也有容器技術(shù)，但是就目前來講，Docker 是最好的選擇。服務(wù)發(fā)現(xiàn)我們用了 ETCD，我不再講哪個軟件好哪個軟件壞，不同的軟件會適用不同的業(yè)務(wù)場景，只有適合與不適合。

接下來我會講具體的架構(gòu)變遷三步走。

架構(gòu)變遷三步走遵循的最重要的一點是平滑演進(jìn)。我們都知道我們的業(yè)務(wù)系統(tǒng)是脆弱的，經(jīng)不起風(fēng)吹雨打，如果大動干戈搞一下，新的架構(gòu)出問題了，業(yè)務(wù)系統(tǒng)是承受不住，技術(shù)部門也無法承受住其他部門帶來的壓力。所以我們必須有序平穩(wěn)平滑的演進(jìn)升級。微服務(wù)是這套升級的一個基礎(chǔ)點，如果你的這些應(yīng)用不是微服務(wù)，不是無狀態(tài)化的，那你就沒辦法讓多個實例協(xié)同工作。最后是軟硬分離，分割計算資源和具體業(yè)務(wù)的強依賴，其實這個問題，在我們?nèi)孔咄?，只要在配置好的服?wù)器環(huán)境裝一個 Docker 就搞定了。

先把應(yīng)用無狀態(tài)化，你可以采用一些集中式緩存這種技術(shù)讓應(yīng)用變得沒有自己的狀態(tài)，它隨時起停，起多少份都是無所謂的，只要有負(fù)載均衡器就可以讓這些組件對外提供一致的服務(wù)。當(dāng)無狀態(tài)化應(yīng)用實現(xiàn)之后，我們就可以給這個應(yīng)用寫 Dockerfile 了，Dockerfile 構(gòu)建的結(jié)果就是 Docker ?image ，其本身就是應(yīng)用和環(huán)境，第一行是from java jdk7，第二行設(shè)置應(yīng)用程序，第三行把這個程序運行起來。

# Base
FROM java:jdk-7

COPY ./.src/target/app-1.0.jar /app/

# ENTRYPOINT
WORKDIR /app
CMD [ "java", "-Dfile.encoding=UTF-8", "-jar", "./app-1.0.jar" ]

這是很簡單的 Dockerfile，不要看他簡單，我推薦的是各位用 Docker 就應(yīng)該這么用。不需要在 Dockerfile 里寫一堆 apt-get install ,一大堆 run 命令這些東西，記住 Dockerfile 就是聲明應(yīng)用環(huán)境和應(yīng)用本身。Docker 現(xiàn)在做的功能太多了，很多都是不怎么靠譜的，Docker 需要更專注于它本身作為容器的技術(shù)。完成無狀態(tài)化應(yīng)用和寫完 Dockerfile 之后，這個程序就可以被打報成 Docker image 了，放到一個 Docker Host 上運行起來就得到了無狀態(tài)的應(yīng)用容器，也就完成了把應(yīng)用裝容器的過程。

不能說應(yīng)用扔進(jìn)去就不管了，如何管，管的辦法有很多，容器技術(shù)這個圈里爭論最多的就是編排技術(shù)。

容器的管理方式對 Docker 來講，目前就三種：

第一是直接管，我們都知道Docker 官方有一個 CLI 工具，只要裝了 Docker 就可以使用這個 CLI 工具把指定的程序運行在容器里，這是更直接的方式。但明顯我們有幾十臺上百臺服務(wù)器的時候，不能每個都上去搞一下，雖然它更直接，但它比較麻煩。

另外一個是 Docker remote API，更為靈活，提供了相關(guān)的編程接口來管理容器。

最后是編排系統(tǒng)，它們更為復(fù)雜，定義的條條框框更多。我這里不推薦做架構(gòu)漸變演化的團(tuán)隊采用。主要原因是，我們遷移到這些編排系統(tǒng)往往都是跳躍式的升級，不是平滑演進(jìn)，業(yè)務(wù)系統(tǒng)不能容許直接把整個業(yè)務(wù)系統(tǒng)跳躍式升級，無法承擔(dān)風(fēng)險，出問題的回退預(yù)案也很難定制。當(dāng)然如果是一個本身從零開始的系統(tǒng)，那你可以嘗試一下，但也不保證這種編排系統(tǒng)就適應(yīng)于你的業(yè)務(wù)系統(tǒng)。我們推薦一步一步走，先把這種應(yīng)用變成容器，再來想辦法管理這些容器。

很顯然我們采用的是第二種選擇。

配置文件配合 Docker remote API。根據(jù)實際情況，選擇Docker的少量的一些特性，例如文件系統(tǒng)、網(wǎng)絡(luò)、資源限定等這些成熟的，我們最為需要的功能，我們編寫了一個便捷的操作工具 cli/web。

在配置文件中定義一個任務(wù)，名字寫下來，這個任務(wù)用什么 image 跑，什么版本，運行在哪臺機器上，注意這里，機器名并不跟具體的業(yè)務(wù)綁定，而是一個資源池，不管什么應(yīng)用都是無差別的，只要是無狀態(tài)的應(yīng)用，所有的存儲、依賴都通過網(wǎng)絡(luò)的形式來解決，我們整個資源池就可以實現(xiàn)自由調(diào)度。

如果把這個應(yīng)用綁定到某一些具體的特有的機器上的話，局限性比較大，萬一這些機器出問題，將無法快速遷移。有一些選項是沒填的，比如 port， port 其實是 Docker 支持把容器內(nèi)的某個端口映射到容器外，我們沒填這個東西是因為，我們默認(rèn)在全系統(tǒng)級都只使用Docker的 host 網(wǎng)絡(luò)模式。 host 模式下，Docker 內(nèi)部容器的網(wǎng)絡(luò)跟宿主機的網(wǎng)絡(luò)是一樣的，這是 Docker 所有網(wǎng)絡(luò)模式中性能最高的，缺點是不能做隔離。

這里有人可能會問，為什么要放棄隔離呢？這里解釋下沒用 Docker 的高級的網(wǎng)絡(luò)模式，以及 SDN、端口映射等的原因。就是沒必要。注意我們講的是私有云平臺，私有云平臺內(nèi)部都是企業(yè)自身的業(yè)務(wù)，大部分業(yè)務(wù)都基于業(yè)務(wù)層面做隔離和權(quán)限就可以了， 所以 Docker 用 host 的模式運行就跟傳統(tǒng)應(yīng)用沒有差別，不需要做 NAT，SDN，也不需要做端口影射，另外一個好處就是，對于應(yīng)用來講他們的依賴用容器和不用容器都是一樣的，這完全符合我們要求的平滑演進(jìn)。

下面還有其他的配置，我們會通過環(huán)境變量控制一些應(yīng)用內(nèi)部的參數(shù)，因為我們的配置文件往往是打包到 image 里面，但是 Docker 這點挺煩的，改一個配置文件都要重新打一個 image，我們最終把配置項做成環(huán)境變量或者 CMD 參數(shù)，這樣可以在組件間共享一些 image。

這是我們用CLI在更新某個實例的時候打印出的內(nèi)容，這是我們自己的定制的，它會告訴我們當(dāng)前運行的實例的名字是什么，運行時間是什么等等一系列內(nèi)容，只要選擇指定版本代碼的 Docker image，我們就可以完成全自動化的更新。

另外我們還部署了一套 DockerUI，這個軟件總體用下來不是特別好用，這是它大概的界面，跟我們 CLI 的功能比較類似，我們之后會自己定制一個運維的系統(tǒng)級 DashBoard。

釜底抽薪，這個形容是比較貼切的。我們的服務(wù)都是無狀態(tài)化的，這個服務(wù)運行在哪里是無關(guān)緊要的，運行多少份也是無關(guān)緊要的，只要把這些新的容器化的交付應(yīng)用替換掉之前的以各種雜亂的形式運行的應(yīng)用，由于演進(jìn)是平滑的，直接替換即可，整個系統(tǒng)就有機結(jié)合起來了。

完成架構(gòu)變遷前兩部之后，假如現(xiàn)在系統(tǒng)有50個組件，只完成了5個組件的 Docker 化、無狀態(tài)化、編排。沒問題，我們的原則就是平滑，漸進(jìn)，你不需要全部搞定，就可以開始應(yīng)用到生產(chǎn)環(huán)境了。目前 Coding 的 95% 的組件都運行在 Docker里面，為什么留5%，是因為有一些極其邊緣的組件，因歷史遺留原因還沒有遷移過去。事實上我們發(fā)現(xiàn)只要前兩步做的好，第三步是很容易的，簡單來說就是停掉舊服務(wù)，啟動新服務(wù)。

這里值得一提的是，不光我們的主業(yè)務(wù)系統(tǒng)需要這么做，我們的一些附屬業(yè)務(wù)系統(tǒng)包括監(jiān)控系統(tǒng)、負(fù)載均衡系統(tǒng)、服務(wù)發(fā)現(xiàn)等等，都應(yīng)該按照這個架構(gòu)一步一步替換過來。最后實現(xiàn)計算和存儲分離，軟件和硬件分離。因之前不是在容器中運行，應(yīng)用對某個服務(wù)器可能都是一種強依賴的狀態(tài)，而現(xiàn)在把這些組件替換掉之后，你所有應(yīng)用的環(huán)境都封裝在 Docker image 里面，這些服務(wù)器上本身沒有任何各個語言的執(zhí)行環(huán)境，他們都是 Docker 宿主機，自動就變成無差別化的了。Docker Image只要放到任何一臺裝有 Docker 的環(huán)境上，就可以很快運行起來。

這是線上的 Docker 容器的列表截圖，這是某一臺服務(wù)器運行的實例。最終形成的架構(gòu)是這樣的：

當(dāng)你們看到這個架構(gòu)的時候覺得它并不高端也并不奇怪，因為很多傳統(tǒng)架構(gòu)就是這樣。而我想說的是我們完成這些東西其實也并不違背傳統(tǒng)的高可用分布式架構(gòu)，只是釜底抽薪，把底層的進(jìn)程組件換成了容器，把原來管理應(yīng)用的方式換成了管理容器的方式。

我們現(xiàn)在運維的流程是這樣，運維有兩種方式來操作這些容器，分別是 CLI 和 UI 界面，運維操作都是發(fā)往這個工具，這個工具是可以管理現(xiàn)有所有的容器，所有的容器的定義都會存放在相應(yīng)的配置文件里，這些配置文件還會在 ETCD 里做一個副本，LB 系統(tǒng)監(jiān)控系統(tǒng)等等需要知道這些組件的狀態(tài)。

LB系統(tǒng)是內(nèi)部服務(wù)的總?cè)肟冢热鐑?nèi)部有一個很小的服務(wù)，這個服務(wù)做的事情很簡單，所以它屬于微服務(wù)的特點，微服務(wù)就是某一個組件每一個服務(wù)只做好一件事情，把這個事情做到極致。而 LB 就是把對這些服務(wù)的請求轉(zhuǎn)發(fā)給相應(yīng)的無狀態(tài)組件。

我們有一個微服務(wù)的組件 md2html 就做一件事情，就是編譯 Markdown ，所有其他組件但凡有需要編譯 Markdown 的都通過 LB 系統(tǒng)調(diào)它。這個組件使用 Ruby 寫的，其運行環(huán)境比較難配置，牽扯到一些原生的 C 的庫，會對一些本地庫有些版本需求，新增服務(wù)器很容易配置錯誤。現(xiàn)在就沒問題了，這個應(yīng)用的環(huán)境已經(jīng)被我們打包成 image 存入了 Docker registry ，即便我們裝有運行環(huán)境的那臺機器宕了，我們只要用 Docker pull 下來，立馬就能遷移到另外一臺服務(wù)器。

我們的監(jiān)控系統(tǒng)跟 LB 是什么關(guān)系？監(jiān)控系統(tǒng)會對每一個容器的關(guān)鍵指標(biāo)做數(shù)據(jù)收集，比如 LB，比如剛提到的 md2html ，都會維護(hù)一個 Http 接口，這個接口里提供它的關(guān)鍵指標(biāo)的數(shù)據(jù)信息。計算資源服務(wù)器的關(guān)鍵指標(biāo)有內(nèi)存使用量，CPU 使用率等等。應(yīng)用程序的關(guān)鍵指標(biāo)都由各個業(yè)務(wù)應(yīng)用自己定義。

例如我們這個 md2html 他的一個關(guān)鍵指標(biāo)就是每秒鐘處理的MD數(shù)量。

我們的監(jiān)控系統(tǒng)會定時抓取這些關(guān)鍵指標(biāo)，要求較高的是 5 秒一次，要求低的可能是1分鐘，抓取之后存入數(shù)據(jù)庫，再配上一些監(jiān)控的報警規(guī)則。比如一個 md2html 實例，正常業(yè)務(wù)量可能是每秒鐘處理10個編譯的任務(wù)，但是監(jiān)控系統(tǒng)查到連續(xù)五分鐘處理量都低于3，我們就認(rèn)為這個實例有問題了。

監(jiān)控系統(tǒng)在遇到問題時，一方面會發(fā)一條消息到 ETCD 里面，告知現(xiàn)在這個實例異常，LB 系統(tǒng)訂閱ETCD，LB 系統(tǒng) watch 到相應(yīng)的改變之后就會把自己的配置改一下然后做一次 reload，這個實例就自動下線了。另外，監(jiān)控系統(tǒng)監(jiān)測到問題的時候會發(fā)一條消息到通知中心，通知中心會把錯誤的信息直接通過手機 APP 推送給運維人員。另外我們還支持包括發(fā)郵件，發(fā)短信，打電話等等形式。通知中心是我們這個系統(tǒng)中組件共用的，還有些普通的業(yè)務(wù)應(yīng)用也會用到通知中心這個組件。

這些組件都是運行的多個實例，不要覺得業(yè)務(wù)量不大何必運行這么多實例，對一個服務(wù)來講，它沒什么負(fù)載，它運行著也不會占你太多的計算資源，據(jù)我的了解我接觸大多數(shù)人的系統(tǒng)架構(gòu)里計算資源都屬于過剩的狀態(tài)，他們卻不愿意去多運行幾個實例來提升可靠度。

這里是我們這個架構(gòu)圖的一些細(xì)節(jié)：

LB 系統(tǒng)： Nginx / HAProxy / confd / Etcd

監(jiān)控系統(tǒng)： Prometheus / cAdvisor / Http Metrics

Docker Registry V1

Docker 網(wǎng)絡(luò)：Host

Docker 日志：Mount 宿主機

HAProxy/ nginx這些很普通的負(fù)載均衡軟件。confd 是一個很簡單的程序，就做一件事情，confd 一直 watch ?Etcd 中服務(wù)的容器應(yīng)用狀態(tài)，一旦有改動，就生成新的LB 配置文件，并 reload LB 程序。這也印證了我們堅持的一點，系統(tǒng)中所有的組件只做一件事情，而且把這件事情做到極致。

假如說我們現(xiàn)在有三個 md2html 實例，當(dāng)某一個實例掛了，監(jiān)控系統(tǒng)檢查到了相關(guān)問題，知道它掛了，這時監(jiān)控系統(tǒng)會兩件事情，把它掛的消息通知到 ETCD，推送到ETCD 后，confd 會自動 reload LB，實現(xiàn) LB 系統(tǒng)的自動切換。另外就是發(fā)送通知給運維人員，好讓運維查出系統(tǒng)的問題，從而做出響應(yīng)。

我們搭建一個 Docker RegistryV1 版本，現(xiàn)在已經(jīng)發(fā)布了V2 版本，Docker 官方 V1 和 V2 版本不兼容，V2 也改了名字，叫做 Distribution。我們用到現(xiàn)在沒出特別大的問題，完全沒有激發(fā)我們升級新版本的動力，因為V1用得挺好的。

Docker 網(wǎng)絡(luò)，Host 模式，優(yōu)點在于性能高，平滑。如果不用Host的模式，用 NAT 模式會非常痛苦，NAT 模式雖然安全，但是對于私有云內(nèi)部來講沒有危險的應(yīng)用，所有程序都是自己寫的，沒有不安全的，就算它不安全，你之前沒有用 Docker 的時候它也是這樣，所以用這個 Host 模式并沒有增加不安全度。最后是 Docker 日志，我們之前踩了一些坑，現(xiàn)在的做法是讓它直接寫到宿主機的日志文件里。

我們的架構(gòu)接下來的改進(jìn)方向是如下幾個點：

Job-Tool 進(jìn)化成 Job DashBoard ，集成監(jiān)控(cAdivsor)，日志(ELK)等功能

利用監(jiān)控系統(tǒng)的硬件指標(biāo)，根據(jù)業(yè)務(wù)用量實現(xiàn)自動擴容，縮容

分析各個業(yè)務(wù)對硬件資源的使用量和高低峰，設(shè)計混布實現(xiàn)提升硬件使用率

Docker image 的構(gòu)建和管理

動態(tài)調(diào)整 container 的資源限制

吐槽一下Docker的問題。Dockerfile 有點用，但沒什么大用，就是幾句話的問題非要編譯那么大的鏡像，改一行配置都需要重新編譯一個 image。Docker Daemon，很不穩(wěn)定，我們出的很多問題都是它導(dǎo)致的，它功能太多，很多問題也就是他這些無用的功能導(dǎo)致，我們認(rèn)為 Docker daemon 只需要做幾件簡單的事情，幫你管理容器，起、停、刪除就完了。Docker 官方最近剛推出了一個 ContainerD，就是一個簡化版的 Docker Daemon，基于 RunC 的，就非常符合我們對于 Container 管理的看法。

我們之前踩了兩個比較大的坑，一個是容器標(biāo)準(zhǔn)輸出輸出大量數(shù)據(jù)，會導(dǎo)致內(nèi)存泄露，從而導(dǎo)致 Docker Daemon crash。另外一個是Docker Daemon 在頻繁創(chuàng)建刪除容器（每天幾十萬個）會出現(xiàn)性能嚴(yán)重下降等問題，只能重啟 Docker Daemon。標(biāo)準(zhǔn)輸出問題，必須要滿足的兩個條件是輸出數(shù)據(jù)量大、輸出速度快。

這里列出了我們關(guān)于標(biāo)準(zhǔn)輸出問題的簡易重現(xiàn)方式和最終 Docker 的修復(fù)方案。

重現(xiàn)方式一： docker run ubuntu yes “something long”

重現(xiàn)方式二：docker run -i ubuntu dd if=/dev/zero of=/proc/self/fd/1 bs=1M count=1000

Issue: https://github.com/docker/docker/issues/14460

Fix By: https://github.com/docker/docker/pull/17877

最后，關(guān)于并發(fā)性能問題，測試環(huán)境比較復(fù)雜，還在進(jìn)一步研究中，歡迎各位來 Coding.net 冒泡 共同探討。

謝謝大家。