嘉賓簡(jiǎn)介

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

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

演講實(shí)錄

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

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

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

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

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

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

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

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

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

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

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

#p#

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

開(kāi)發(fā)效率低

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

交付周期長(zhǎng)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#p#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#p#

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

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

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

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

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

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

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

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

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

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

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

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

我覺(jué)得可以從以下幾個(gè)方面去考慮：

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

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

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

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

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

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