嘉賓簡介

資深質(zhì)量優(yōu)化專家，12年軟件測試與質(zhì)量管理經(jīng)驗

《軟件性能測試診斷分析與優(yōu)化》等多本IT暢銷書作者

演講實錄

今天主要交流的主題是基于Docker的開發(fā)模式如何驅(qū)動持續(xù)集成落地實施，這里會涉及兩個主要的話題，一個是所謂Docker的開發(fā)模式是怎樣的，與傳統(tǒng)的開發(fā)模式有什么區(qū)別;另外一個是持續(xù)集成作為敏捷開發(fā)的最佳實踐，結(jié)合Docker來實施會有什么樣的效果，會不會有更好的促進(jìn)作用，尤其是在傳統(tǒng)企業(yè)中實施。

也希望跟大家一起交流一下關(guān)于Docker的一些具體實施問題、實施經(jīng)驗

首先我們來看看，在傳統(tǒng)的開發(fā)運(yùn)維模式下，會存在哪些問題。我稍微歸納總結(jié)了一下，大概會有以下三個問題：

1. 從需求到版本上線中間是個黑箱子，風(fēng)險不可控
2. 開發(fā)設(shè)計時未過多考慮運(yùn)維，導(dǎo)致后續(xù)部署及維護(hù)的困難
3. 開發(fā)各自為政，煙囪式開發(fā)，未考慮共享重用、聯(lián)調(diào)，開發(fā)的資產(chǎn)積累不能快速交移到運(yùn)維手中

應(yīng)對這樣的問題，我們通常倡導(dǎo)的解決之道是：運(yùn)維前移，統(tǒng)一運(yùn)維，建立持續(xù)交付服務(wù)體系。

但是這樣空喊是沒用的，我們要來點實際的，嘗試?yán)靡恍┘夹g(shù)手段真正解決開發(fā)運(yùn)維一體化的問題，具體推進(jìn)DevOps的實施。

那好，我們看看最近1、2年非?；鸬腄ocker技術(shù)，看能否在解決上述問題上帶來一些具體的突破，或者給我們帶來一些解決具體問題的啟發(fā)。

我們先從Docker的一些技術(shù)特性來看，這些新的技術(shù)可能帶來的改變：

1. Docker首先是一個容器級虛擬化技術(shù)，相比傳統(tǒng)虛擬化技術(shù)，容器級的虛擬技術(shù)是操作系統(tǒng)內(nèi)核層的虛擬，所以能節(jié)省更多資源、提升性能，意味著單位機(jī)器資源消耗下，能承載更復(fù)雜更龐大的應(yīng)用系統(tǒng)架構(gòu)。
2. 啟動速度更快，毫秒級的啟動速度，這對于快速部署開發(fā)測試及運(yùn)維環(huán)境非常有利。
3. 鏡像分層，部署時可以按需獲取鏡像生成容器并快速啟動運(yùn)行，因此有利于快速的部署擴(kuò)容，解決運(yùn)維中水平擴(kuò)容的問題。
4. 由于Docker鏡像的天然可移植性，就像集裝箱一樣快速打包應(yīng)用以及依賴項，在開發(fā)、測試、運(yùn)維之間移動，所以可以推進(jìn) 開發(fā)-測試-運(yùn)維 環(huán)境的統(tǒng)一，持續(xù)集成(CI)能發(fā)揮更大的作用，例如通過CI構(gòu)建應(yīng)用、檢查代碼，打包到Docker、分發(fā)部署到測試和準(zhǔn)生產(chǎn)環(huán)境，進(jìn)行各類測試，都可以更方便快捷和統(tǒng)一。

既然Docker的一些技術(shù)特性看起來確實能給開發(fā)測試運(yùn)維帶來一些新的東西，那么我們接下來就具體看看，這些新的技術(shù)特性具體如何應(yīng)用，以及應(yīng)用過程中可能帶來的問題。

容器可以把應(yīng)用以及它的依賴項進(jìn)行打包，這樣帶來的好處就是應(yīng)用隔離，能否把這種隔離特性用于解決一些架構(gòu)問題呢?因為架構(gòu)設(shè)計不好的話，給開發(fā)、測試，尤其是運(yùn)維以及后續(xù)的維護(hù)管理帶來很多麻煩，例如隨著業(yè)務(wù)復(fù)雜度越來越高，可維護(hù)性和敏捷程度隨之變差。

#p#

傳統(tǒng)的應(yīng)用通常采用所謂的三層架構(gòu)，例如：界面層 – 業(yè)務(wù)邏輯層 – 數(shù)據(jù)層，通常我們會把所有實現(xiàn)業(yè)務(wù)邏輯層的代碼編譯構(gòu)建后部署到中間件，再通過負(fù)載均衡、集群等解決分流、災(zāi)備等問題。但是這種架構(gòu)設(shè)計帶來的問題是：

開發(fā)效率低

隨著應(yīng)用復(fù)雜度的增加，越來越少開發(fā)人員對應(yīng)用能有全局性的深度理解。新功能開發(fā)和缺陷修復(fù)難度呈幾何性增加。代碼修改的正確性無法保障。而龐大的代碼庫需要更龐大的開發(fā)團(tuán)隊來維護(hù)，無形中又增添了管理、溝通和協(xié)調(diào)的成本。另外，新加入的團(tuán)隊成員需要花費(fèi)大量的時間和精力來熟悉一個復(fù)雜的代碼庫。

交付周期長

在單一進(jìn)程的單塊架構(gòu)下，任何微小的改動都需要重新編譯、集成、測試和部署整個應(yīng)用。隨著應(yīng)用體積的增大，交付流程和反饋周期都會相應(yīng)變長，應(yīng)用發(fā)布的代價也隨之增加。于是應(yīng)用交付周期變緩，交付間隙積累的代碼變動增加，從而對于下次交付產(chǎn)生更大的壓力，形成惡性循環(huán)。

技術(shù)轉(zhuǎn)型難

單一進(jìn)程、單塊架構(gòu)意味著中心化的技術(shù)選型。比如，應(yīng)用的不同邏輯組建通常需要采用相對統(tǒng)一的編程語言、框架和技術(shù)棧。這些在項目初始階段便已定型。之后，即便是應(yīng)用中全新的邏輯組件，也很難采用不同的技術(shù)棧。而當(dāng)應(yīng)用達(dá)到一定規(guī)模后，全局化的技術(shù)棧更新會面臨很高的風(fēng)險。所以，單塊架構(gòu)應(yīng)用一旦定型，就很難再享受行業(yè)技術(shù)變更、發(fā)展所帶來的紅利。

有了容器技術(shù)之后，微服務(wù)設(shè)計也被大家慢慢提到架構(gòu)設(shè)計的前沿進(jìn)行討論了，這方面推薦大家看一本書《Building Microservices》。

微服務(wù)架構(gòu)的誕生和容器技術(shù)的流行，幾乎是同時發(fā)生的，這并非偶然，而是互聯(lián)網(wǎng)時代倒逼傳統(tǒng)技術(shù)和架構(gòu)而產(chǎn)生的變革，而以Docker為代表的容器技術(shù)則為微服務(wù)理念提供了匹配的實現(xiàn)機(jī)制。

在微服務(wù)架構(gòu)下，我們將原本單一的應(yīng)用按照功能邊界分解成一系列獨(dú)立、專注的微服務(wù)。每個微服務(wù)對應(yīng)傳統(tǒng)應(yīng)用中的一個組件，但是可以獨(dú)立編譯、部署和擴(kuò)展。相對單塊架構(gòu)，微服務(wù)具備以下優(yōu)勢：

(1)復(fù)雜度可控：在將應(yīng)用分解的同時，規(guī)避了原本復(fù)雜度無止境的積累。每一個微服務(wù)專注于單一功能，并通過定義良好的接口清晰表述服務(wù)邊界。由于體積小、復(fù)雜度低，每個微服務(wù)可由一個小規(guī)模開發(fā)團(tuán)隊完全掌控，易于保持高可維護(hù)性和開發(fā)效率。

(2)獨(dú)立部署：由于微服務(wù)具備獨(dú)立的運(yùn)行進(jìn)程，所以每個微服務(wù)也可以獨(dú)立部署。當(dāng)某個微服務(wù)發(fā)生變更時無需編譯、部署整個應(yīng)用。由微服務(wù)組成的應(yīng)用相當(dāng)于具備一系列可并行的發(fā)布流程，使得發(fā)布更加高效，同時降低對生產(chǎn)環(huán)境所造成的風(fēng)險，最終縮短應(yīng)用交付周期。

(3)技術(shù)選型靈活：微服務(wù)架構(gòu)下，技術(shù)選型是去中心化的。每個團(tuán)隊可以根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術(shù)棧。由于每個微服務(wù)相對簡單，當(dāng)需要對技術(shù)棧進(jìn)行升級時所面臨的風(fēng)險較低，甚至完全重構(gòu)一個微服務(wù)也是可行的。

微服務(wù)架構(gòu)中，可為每個服務(wù)選擇一個新的適合業(yè)務(wù)邏輯的數(shù)據(jù)庫系統(tǒng)，比如MongoDB、PostgreSQL。這樣做的好處：首先我們可以根據(jù)業(yè)務(wù)類型(讀多還是寫多等)來決定使用哪種類型的數(shù)據(jù)庫，其次這樣可以減小單個數(shù)據(jù)庫的負(fù)載。

(4)容錯：當(dāng)某一組建發(fā)生故障時，在單一進(jìn)程的傳統(tǒng)架構(gòu)下，故障很有可能在進(jìn)程內(nèi)擴(kuò)散，形成應(yīng)用全局性的不可用。在微服務(wù)架構(gòu)下，故障會被隔離在單個服務(wù)中。若設(shè)計良好，其他服務(wù)可通過重試、平穩(wěn)退化等機(jī)制實現(xiàn)應(yīng)用層面的容錯。

(5)擴(kuò)展：單塊架構(gòu)應(yīng)用也可以實現(xiàn)橫向擴(kuò)展，就是將整個應(yīng)用完整的復(fù)制到不同的節(jié)點。當(dāng)應(yīng)用的不同組件在擴(kuò)展需求上存在差異時，微服務(wù)架構(gòu)便體現(xiàn)出其靈活性，因為每個服務(wù)可以根據(jù)實際需求獨(dú)立進(jìn)行擴(kuò)展。

看起來微服務(wù)的架構(gòu)設(shè)計優(yōu)勢明顯，也是未來架構(gòu)設(shè)計的一大趨勢方向，但是，如果采用微服務(wù)的架構(gòu)設(shè)計，基于容器包裝微服務(wù)進(jìn)行部署，給運(yùn)維會帶來哪些新的挑戰(zhàn)呢?我認(rèn)為會從以下幾個方面體現(xiàn)：

(1)運(yùn)營開銷：更多的服務(wù)也就意味著更多的運(yùn)營，需要保證所有的相關(guān)服務(wù)都有完善的監(jiān)控等基礎(chǔ)設(shè)施，傳統(tǒng)的架構(gòu)開發(fā)者只需要保證一個應(yīng)用正常運(yùn)行，而現(xiàn)在卻需要保證幾十甚至上百道工序高效運(yùn)轉(zhuǎn)，這是一個艱巨的任務(wù)。

(2)DevOps要求：使用微服務(wù)架構(gòu)后，團(tuán)隊需要高品質(zhì)的DevOps和自動化技術(shù)，需要懂更多不同類型的技術(shù)棧。

(3)隱式接口：服務(wù)和服務(wù)之間通過接口來“聯(lián)系”，當(dāng)某一個服務(wù)更改接口格式時，可能涉及到此接口的所有服務(wù)都需要做調(diào)整。

(4)分布式系統(tǒng)的復(fù)雜性：微服務(wù)通過REST API或消息來將不同的服務(wù)聯(lián)系起來，這在之前可能只是一個簡單的遠(yuǎn)程過程調(diào)用。分布式系統(tǒng)也就意味著開發(fā)者需要考慮網(wǎng)絡(luò)延遲、容錯、消息序列化、不可靠的網(wǎng)絡(luò)、異步、版本控制、負(fù)載等，而面對如此多的微服務(wù)都需要分布式時，整個產(chǎn)品需要有一整套完整的機(jī)制來保證各個服務(wù)可以正常運(yùn)轉(zhuǎn)。

幸好，業(yè)界已經(jīng)從運(yùn)維管理的角度出發(fā)，做了不少工作來嘗試解決上述問題，例如Google開源的Kubernetes容器集群管理系統(tǒng)，提供應(yīng)用部署、維護(hù)、 擴(kuò)展機(jī)制等功能，利用Kubernetes能方便地管理跨機(jī)器運(yùn)行容器化的應(yīng)用，其主要功能如下：

1. 使用Docker對應(yīng)用程序包裝(package)、實例化(instantiate)、運(yùn)行(run)。
2. 以集群的方式運(yùn)行、管理跨機(jī)器的容器。
3. 解決Docker跨機(jī)器容器之間的通訊問題。
4. Kubernetes的自我修復(fù)機(jī)制使得容器集群總是運(yùn)行在用戶期望的狀態(tài)。

#p#

前面我們探討了一下基于容器的微服務(wù)架構(gòu)設(shè)計給傳統(tǒng)開發(fā)運(yùn)維模式帶來的改變，看起來更多的還是正面的改變。

容器化微服務(wù)解決的更多的是架構(gòu)設(shè)計的問題，按軟件工程來講，設(shè)計之后的下一步就是開發(fā)實現(xiàn)的事情了，在這個階段，傳統(tǒng)的開發(fā)測試會有不少的問題，例如環(huán)境的問題：

1. 軟件安裝麻煩、來源不一致、安裝方式不一致、雜亂無章。
2. 共用一個服務(wù)器開發(fā)環(huán)境，隔離性差，互相沖突。
3. 可移植性差，例如和生產(chǎn)環(huán)境不一致，開發(fā)人員之間也無法共享;新人入職通常又折騰一遍開發(fā)環(huán)境，無法快速搭建。

那么，隨著容器技術(shù)的引入，是否能帶來一些改觀呢?答案是明顯的!開發(fā)測試環(huán)境的容器化帶來的是標(biāo)準(zhǔn)化的開發(fā)測試環(huán)境，這對開發(fā)測試及運(yùn)維的意義體現(xiàn)在：

(1)對開發(fā)測試的意義：測試環(huán)境搭建效率的提高，高效利用硬件資源同時又能敏捷輕便地搭建功能完備的開發(fā)測試環(huán)境，例如在一個資源有限的環(huán)境下面(比如開發(fā)人員的筆記本電腦)例如Chef 把系統(tǒng)的各個模塊按照清晰的邏輯結(jié)構(gòu)部署并運(yùn)轉(zhuǎn)起來，從而快速高效地進(jìn)行開發(fā)與測試

(2)對運(yùn)維部署的意義：開發(fā)測試(環(huán)境、依賴包) - Docker Hub - 運(yùn)維(環(huán)境、依賴包) 的環(huán)境一致性

關(guān)于Docker在測試領(lǐng)域的一些應(yīng)用，大家可以看看我寫的一篇文章，《淺談Docker在測試領(lǐng)域的應(yīng)用》。

在傳統(tǒng)模式下，開發(fā)自測通常沒問題，但是到了測試或生產(chǎn)環(huán)境程序無法運(yùn)行，讓開發(fā)團(tuán)隊排查，經(jīng)過長時間排查最后發(fā)現(xiàn)是測試環(huán)境的一個第三方庫過時了。這樣的現(xiàn)象在軟件開發(fā)中很普遍，已經(jīng)不適用如今的快速開發(fā)和部署。

而在Docker模式下，應(yīng)用是以容器的形式存在，所有和該應(yīng)用相關(guān)的依賴都會在容器中，因此移植非常方便，不會存在像傳統(tǒng)模式那樣的環(huán)境不一致。

在開發(fā)測試環(huán)境容器化的背景下，研發(fā)模式的改變：

項目開始，架構(gòu)師根據(jù)項目預(yù)期創(chuàng)建好需要的基礎(chǔ)鏡像(Nginx、Tomcat、MySQL鏡像)，或者將Dockerfile分發(fā)給所有開發(fā)人員，開發(fā)人員根據(jù)Dockerfile創(chuàng)建的容器或從內(nèi)部倉庫下載的鏡像來進(jìn)行開發(fā)，如果開發(fā)過程中需要添加新的軟件，則向架構(gòu)師申請修改基礎(chǔ)鏡像的 Dockerfile;

開發(fā)任務(wù)結(jié)束后，架構(gòu)師調(diào)整Dockerfile或image，分發(fā)給測試部門，測試部門馬上就可以進(jìn)行測試，消除了部署困難等難纏的問題。

在開發(fā)測試環(huán)境容器化的背景下，持續(xù)集成的模式也會發(fā)生一些必然的改變：持續(xù)集成各步驟圍繞任務(wù)Docker模塊進(jìn)行工作。

開發(fā)人員的代碼嵌入會觸發(fā)開發(fā)環(huán)境中新的Docker鏡像的構(gòu)建(代碼的編譯、構(gòu)建、檢查、部署都基于Docker進(jìn)行)，測試人員發(fā)現(xiàn)有新的Docker 鏡像構(gòu)建出來，就會部署到測試環(huán)境中進(jìn)行各類測試和驗證，測試通過后，會把鏡像放到公共鏡像庫，由運(yùn)維人員進(jìn)行生產(chǎn)環(huán)境的部署和發(fā)布。

好，那看完Docker在開發(fā)測試階段的應(yīng)用，尤其是對持續(xù)集成方式的改變后，我們來看看，Docker對于傳統(tǒng)業(yè)務(wù)上線方式帶來的改變。

傳統(tǒng)業(yè)務(wù)上線存在的問題是：

1. 上線環(huán)節(jié)多，跨越多個部門，溝通成本高;
2. 涉及多個部門的審核，包括資源的申請、環(huán)境權(quán)限的批準(zhǔn)、需求測試驗收等，耗時長;
3. 再加上上線部署過程涉及到的技術(shù)環(huán)節(jié)多，例如代碼獲取、編譯構(gòu)建、代碼檢查、軟硬件安裝配置、應(yīng)用裝載、啟動，導(dǎo)致發(fā)布周期很長。

#p#

針對傳統(tǒng)應(yīng)用交付過程中的這些問題，Docker的引入帶來了明顯的改變，Docker把應(yīng)用及相關(guān)依賴項打包成一個輕量、可移植、自包含的容器，讓應(yīng)用的部署和發(fā)布基于容器進(jìn)行，而不是基于代碼部署。由此，Docker重新定義了打包程序的方法：

Docker容器 + 用戶應(yīng)用 = 部署單位(構(gòu)件)

容器級部署帶來的最大的好處就是開發(fā)者本地測試、CI服務(wù)器測試、測試人員測試，以及生產(chǎn)環(huán)境運(yùn)行的都可以是同一個Docker鏡像。因此可以實現(xiàn)應(yīng)用的自動化快速部署及上線發(fā)布。

由于Docker技術(shù)的標(biāo)準(zhǔn)化通用化，可以方便地實現(xiàn)云服務(wù)器之間的移植，不依賴具體的某一個云服務(wù)商，降低了云部署的風(fēng)險，因此，從這個角度來看，Docker能極大地促進(jìn)企業(yè)做應(yīng)用云部署的積極性，難怪各大IaaS和PaaS供應(yīng)商都熱烈地?fù)肀ocker容器技術(shù)。

基于Docker的應(yīng)用部署和發(fā)布，還可以方便地實施藍(lán)-綠部署，例如：保持兩套一樣的生產(chǎn)環(huán)境，而實際上只有一套環(huán)境真正的對外提供服務(wù)(綠環(huán)境)，而另一套環(huán)境則處于待機(jī)狀態(tài)(藍(lán)環(huán)境)。

先上線到藍(lán)環(huán)境，如果測試沒問題，再將路由切換到新的服務(wù)上。帶來的好處是明顯的：

• 最小化停機(jī)時間
• 快速回滾
• 熱備份

但是具體實現(xiàn)藍(lán)綠部署可能還會碰到更多細(xì)節(jié)的問題，例如數(shù)據(jù)的處理，這些都有待實踐。

最后，我們來聊聊容器微服務(wù)運(yùn)維，前面我們有聊到基于容器化微服務(wù)設(shè)計給運(yùn)維帶來的挑戰(zhàn)以及一些應(yīng)對措施。

在容器微服務(wù)的模式下，功能模塊被隔離到一個個可單獨(dú)開發(fā)、測試和部署的容器中，所以當(dāng)某個功能出現(xiàn)問題的時候，可以單獨(dú)把其對應(yīng)的容器撤銷，開發(fā)進(jìn)行修復(fù)，再上線，在這個過程中其它的功能(容器)不受影響，仍然正常運(yùn)行。

微服務(wù)帶來的運(yùn)維問題：

拆分成微服務(wù)后，部署變得復(fù)雜，監(jiān)控的復(fù)雜度也隨之提高，要理解在微服務(wù)之間產(chǎn)生的復(fù)雜交互，需要優(yōu)秀的診斷與監(jiān)控工具，同時對運(yùn)維技能的要求也提高了，例如要了解多種技術(shù)棧。

我覺得可以從以下幾個方面去考慮：

(1)自動化管理：自動構(gòu)建、自動測試、自動部署、自動運(yùn)維...，盡可能自動化一切，從而控制好復(fù)雜度、工作量、降低人為操作失誤的風(fēng)險;

(2)圍繞業(yè)務(wù)能力建模服務(wù)：運(yùn)維需要對開發(fā)提出需求，例如：服務(wù)部署的獨(dú)立性、失敗隔離性、可監(jiān)控性，構(gòu)建中心化的配置服務(wù)管理;

(3)充分利用容器技術(shù)實施服務(wù)流控，例如：降級、限流;

(4)充分利用容器技術(shù)實施服務(wù)恢復(fù)，多考慮故障快速恢復(fù)而非避免。

最后，給大家推薦一些Docker相關(guān)的書，有些是國內(nèi)的，有些是國外的。

原文鏈接：dbaplus.cn/news-21-123-1.html