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

本文系 ArchSummit 大會(huì) CODING 工程師王振威演講實(shí)錄。

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

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

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

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

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

啟動(dòng)快
容器相比虛擬機(jī)的啟動(dòng)速度是非常快的，開一臺(tái)虛擬機(jī)的啟動(dòng)速度慢一點(diǎn)的一分鐘，快一點(diǎn)的也要十幾秒，但是容器往往可以做到秒級(jí)啟動(dòng)，這為我們后面所講的容器化交付奠定了基礎(chǔ)。

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

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

開個(gè)玩笑。

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

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

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

有幾個(gè)原因：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 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" ]

這是很簡(jiǎn)單的 Dockerfile，不要看他簡(jiǎn)單，我推薦的是各位用 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 之后，這個(gè)程序就可以被打報(bào)成 Docker image 了，放到一個(gè) Docker Host 上運(yùn)行起來就得到了無狀態(tài)的應(yīng)用容器，也就完成了把應(yīng)用裝容器的過程。

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

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

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

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

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

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

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

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

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

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

下面還有其他的配置，我們會(huì)通過環(huán)境變量控制一些應(yīng)用內(nèi)部的參數(shù)，因?yàn)槲覀兊呐渲梦募谴虬?image 里面，但是 Docker 這點(diǎn)挺煩的，改一個(gè)配置文件都要重新打一個(gè) image，我們最終把配置項(xiàng)做成環(huán)境變量或者 CMD 參數(shù)，這樣可以在組件間共享一些 image。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這里是我們這個(gè)架構(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 宿主機(jī)

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

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

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

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

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

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

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

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

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

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

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

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

這里列出了我們關(guān)于標(biāo)準(zhǔn)輸出問題的簡(jiǎ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ā)性能問題，測(cè)試環(huán)境比較復(fù)雜，還在進(jìn)一步研究中，歡迎各位來 Coding.net 冒泡 共同探討。

謝謝大家。