[[141893]]

作者介紹

李建業(yè)，前阿里巴巴員工（花名：李福），2002年本科畢業(yè)，之后一直從事軟件開發(fā)，涉及辦公自動化、電信網(wǎng)管/增值業(yè)務(wù)系統(tǒng)以及互聯(lián)網(wǎng)；2009年12月加入淘寶的廣告應(yīng)用開發(fā)團隊；從2011年底開始，關(guān)注軟件研發(fā)本身，主要工作包括運維自動化系統(tǒng)和持續(xù)集成服務(wù)平臺。

前言

微服務(wù)這個話題也算有段時間了，而且并不神秘，很多公司都在走這條路。

有條推是這么解釋微服務(wù)的，很有趣，引用一下：

@arungupta Microservices = SOA -ESB -SOAP -Centralized governance/persistence -Vendors +REST/HTTP +CI/CD +DevOps +True Polyglot +Containers +PaaS

從微服務(wù)的角度看，Docker意味著什么？這兩種技術(shù)之間應(yīng)該是什么關(guān)系呢？

我認為，Docker和微服務(wù)的關(guān)系應(yīng)該是——好基友 :-)。為什么這么說？且聽下文分解。以下為本文的目錄結(jié)構(gòu)，請享用：

1. 微服務(wù)和單體架構(gòu)

2. 應(yīng)用開發(fā)

3. 組織結(jié)構(gòu)

4. 系統(tǒng)變更碎片化

5. 運維相關(guān)設(shè)施

好吧！我們正式開始。

1. 微服務(wù)和單體架構(gòu)

微服務(wù)的要點是“微”，與之對立的另一方是所謂的單體架構(gòu)（monolith）。在團隊實踐中，這兩種思路在不同的方面體現(xiàn)出了優(yōu)劣差異：

• 應(yīng)用開發(fā)

  • 微服務(wù)便于支持多元技術(shù)棧

  • 單體架構(gòu)有利于IDE和其它開發(fā)工具的配合支持

• 組織結(jié)構(gòu)

  • 微服務(wù)便于團隊分裂，促進局部功能的業(yè)務(wù)深入

  • 單體架構(gòu)有利于開發(fā)者從全局角度理解和掌控功能

• 系統(tǒng)演化

  • 微服務(wù)能夠有助于用“碎片化”的方式推動系統(tǒng)演化，降低變更風險

  • 單體架構(gòu)便于”整體交付“，可以減少向下兼容的需要

• 運維相關(guān)設(shè)施

  • 微服務(wù)增加了運維單元數(shù)量，對自動化運維比較依賴

  • 單體架構(gòu)可以手工運維，或者配合簡單的自動化發(fā)布工具

其實，微服務(wù)架構(gòu)還有符合單一職責原則和便于接口依賴等好處，不過這些和Docker沒什么關(guān)系，是單獨在設(shè)計環(huán)節(jié)有價值的優(yōu)點，所以這里就不提了。

簡單來說，微服務(wù)區(qū)別于單體架構(gòu)的地方就在于“分而治之”，即通過切分服務(wù)以明確模塊或者功能邊界。

然而，僅有“分”是不行的，軟件系統(tǒng)是一個整體，很多功能來自若干服務(wù)模塊的配合，因此必然要有“合”的手段，這對矛盾會體現(xiàn)在多個方面，我們分別說明。

2. 應(yīng)用開發(fā)

之前已經(jīng)討論過語言技術(shù)棧多元化的趨勢，但是，對于單體應(yīng)用來說，多元化技術(shù)棧并不是值得推薦的實踐方法，因為這里涉及到混合語言編程和不兼容的軟件組織方式。

實際上，現(xiàn)實中一些團隊之所以沒有辦法擁抱多元化的技術(shù)棧，往往首先是因為他們的系統(tǒng)是一個或者幾個“單體”應(yīng)用，開發(fā)者已經(jīng)習慣了原有的IDE和相關(guān)開發(fā)工具，引入其它技術(shù)帶來的好處還不如制造的麻煩多。

微服務(wù)則可以很好地避免這種情況，它通過切分系統(tǒng)的方式為不同功能模塊劃定了清晰的邊界，邊界之間的通信方式很容易可以做到獨立于某種技術(shù)棧，因此也就為納入其它技術(shù)帶來了空間。

現(xiàn)實中也可以看到這樣的例子，一些公司在初期會固定一個技術(shù)選型（比如facebook用php，google用python，阿里巴巴用java），而發(fā)展（或者收購）新的部門和組織以后，要么原有的應(yīng)用被分裂，要么新的業(yè)務(wù)催生出新的獨立應(yīng)用，這時往往逐漸開始擴展技術(shù)選擇。

有拆就有合，不同技術(shù)棧的微服務(wù)之間，除了需要考慮通信機制，還要確保這些技術(shù)能夠（以較低成本）變成一個系統(tǒng)——不同服務(wù)可以使用不同的語言框架，但是在線上應(yīng)當成為一個整體。

于是我們會在發(fā)布中遇到“合”的困難，而這正是docker能解決的問題，具體討論之前已經(jīng)展開過，這里強調(diào)一下結(jié)論——docker將所有應(yīng)用都標準化為可管理、可測試、易遷移的鏡像/容器，因此為不同技術(shù)棧提供了整合管理的途徑。

在這種情況下，開發(fā)人員可以自由選擇或者保持自己的常用工具，不必因為微服務(wù)的分裂產(chǎn)生過高的學習成本。

#p#

3. 組織結(jié)構(gòu)

說到團隊和組織，不能繞開的一個話題就是“康威定律”(Conway’s law)：

軟件系統(tǒng)的結(jié)構(gòu)受制于其生產(chǎn)者組織的溝通結(jié)構(gòu)。

從這個角度看，微服務(wù)的拆分會對團隊擴張帶來幫助，這不難理解，因為系統(tǒng)拆分為若干微服務(wù)會促進這些微服務(wù)之間的邊界更清晰，我們知道，邊界清晰等于在邊界之間協(xié)作信息量少，如果按照微服務(wù)拆分團隊，團隊之間的協(xié)作成本將是比較低的。

然而，“邊界之間協(xié)作信息少”是有代價的。這代價就是團隊的每個人對系統(tǒng)失去了整體視角和掌控能力，在這一點上，單體架構(gòu)顯然要好很多——每個開發(fā)者的開發(fā)環(huán)境都有完整的系統(tǒng)構(gòu)建，所以很容易就可以獲得對系統(tǒng)的整體印象和理解。

這是微服務(wù)的短板，但是這個問題要分兩種情況考慮：

1. 目前的技術(shù)發(fā)展使得在本機搭建一個完整的系統(tǒng)成本越來越高，即使不考慮微服務(wù)的影響，也會因為其它因素而推高這個代價。比如：一個普通的Web應(yīng)用也許會購買push.io這樣的手機端推送服務(wù)，因此期望本機能夠重現(xiàn)所有的系統(tǒng)功能有時并不現(xiàn)實。

2. 微服務(wù)架構(gòu)在這方面的短板，其核心在于構(gòu)建成本，由于微服務(wù)來自不同團隊和部門，因此如何搭建它就成為一個謎，同時由于不能低成本的獲得一個完整的系統(tǒng)，系統(tǒng)整體的知識也就容易被開發(fā)者忽略，最終導致整體視角缺失。

問題不同，處理起來也是各異：

1. 對于關(guān)系不大的其它服務(wù)，可以保持我們常見的與外部服務(wù)進行協(xié)作的方案——要么單獨申請（或分配）開發(fā)測試用的只讀賬號，要么進行mock，不影響系統(tǒng)的整體性即可。

2. 對于大多數(shù)外部服務(wù)，我們需要考慮建立自動化系統(tǒng)構(gòu)建和測試的方法，這是微服務(wù)架構(gòu)帶來的研發(fā)挑戰(zhàn)。

顯然，方法一是繞道而行，適合少數(shù)場景，方法二是正面強攻，能夠應(yīng)對絕大多數(shù)情況。這個方法二就是Docker可以發(fā)力的地方。

筆者之前曾經(jīng)在公司內(nèi)部做過持續(xù)集成平臺，服務(wù)的研發(fā)團隊不少，其中有些雖然沒有提出微服務(wù)的概念，但是“將系統(tǒng)功能服務(wù)化，然后再整合”的做法其實已經(jīng)有很多運用了，于是我們也在建立自動化聯(lián)調(diào)和測試機制。

大致的作法是每個服務(wù)說明自己如何構(gòu)建（給出構(gòu)建腳本），并申明依賴的外部服務(wù)（運行時依賴，不同于軟件包的依賴），然后由CI系統(tǒng)進行全局構(gòu)建，這種做法非常好的節(jié)約了聯(lián)調(diào)時間，并使這一工作變得可重復。

遺憾的是，由于沒有Docker這樣的技術(shù)，構(gòu)建這件事很難做到“整齊劃一”：

為了讓它們相互配合，需要編寫一些協(xié)作的腳本，這加重了研發(fā)團隊的工作，因此真正能夠自動聯(lián)調(diào)的應(yīng)用系統(tǒng)并不多。

微服務(wù)架構(gòu)中的一個系統(tǒng)往往是運行時的多個系統(tǒng)，而多系統(tǒng)聯(lián)調(diào)通常費時費力的，這不僅是由于編譯時間往往很長，更由于多系統(tǒng)的構(gòu)建過程往往互不相同，服務(wù)之間的依賴往往又不太簡單，所以自動化的成本很高。

但是，如果首先對各系統(tǒng)進行Docker化，就很容易通過統(tǒng)一的docker build，建立一致性的構(gòu)建服務(wù)，再結(jié)合compose等基礎(chǔ)設(shè)施處理服務(wù)依賴，這些工作最終就可以產(chǎn)生一個平臺，（自動化的）將被微服務(wù)打散的整個系統(tǒng)再構(gòu)建出來（由于使用了微服務(wù)，構(gòu)建速度在理論上就可以是并行的，因此甚至會比單體架構(gòu)更敏捷）。

這個思路最有意思的地方在于：

建立這樣的基礎(chǔ)設(shè)施，是可以與具體公司的技術(shù)路線無關(guān)的，因此實際上可以構(gòu)建獨立的服務(wù)平臺為多個公司提供服務(wù)。

可能有人覺得這個平臺很像一個PaaS，確實，這么發(fā)展下去有可能演化出一個獨立的PaaS平臺，不過它可以做的更多，而且沒有傳統(tǒng)PaaS那樣對技術(shù)進行限制，這是一個很有吸引力的方向，也是很多Docker創(chuàng)業(yè)公司可以做的事情。

4.系統(tǒng)變更碎片化

理論上，由于進行了分解，微服務(wù)架構(gòu)的系統(tǒng)應(yīng)該更加有利于系統(tǒng)的“改良”，不必動輒就傷筋動骨甚至另起爐灶。

但是實際上并不一定會這樣。

微服務(wù)架構(gòu)是一種思想，它的合理運用還是要依靠團隊成員的，如果是從“單體”應(yīng)用演變過來的系統(tǒng)，團隊成員很容易感受到相反的體驗——系統(tǒng)升級更復雜更難了。

比如下面這個變更（以java應(yīng)用為例）：

- public ListgetUser(String id)
+ public ListgetUser(Long id)

對于單體應(yīng)用來說，開發(fā)過程就是使用IDE的refactory功能變更一下，上線也很簡單，更換一下war文件即可，而對于微服務(wù)來說就復雜了。

微服務(wù)的開發(fā)過程可能是這樣的：

1. 變更接口，發(fā)布新的接口jar包。

2. 找到所有使用getUser(String id)這個接口的調(diào)用方應(yīng)用。

3. 升級調(diào)用方的pom.xml文件，修改相應(yīng)代碼，提交、測試，但不上線。

4. 同時修改服務(wù)提供方的代碼，對新接口進行實現(xiàn)。

而發(fā)布過程是這樣的：

1. 調(diào)用方服務(wù)停止。

2. 服務(wù)方服務(wù)停止。

3. 服務(wù)方服務(wù)升級軟件包。

4. 服務(wù)方服務(wù)啟動。

5. 服務(wù)方驗證服務(wù)是否正常。

6. 調(diào)用方服務(wù)啟動。

7. 調(diào)用方驗證服務(wù)是否正常。

這種操作十分脆弱，一旦發(fā)現(xiàn)服務(wù)上線失敗就會陷入兩難，有時會導致開發(fā)人員在線上解決問題，更進一步引入了風險。

當然，這個問題其實有標準解決方法——向下兼容，也就是每個服務(wù)的升級都至少兼容之前一個版本，這樣所有的依賴服務(wù)的升級就可以靈活進行而不必將上線變成一件大事。

但是這樣做增加了向下兼容的壓力:

雖然是比較好的實踐，但并不能覆蓋所有情況，有時升級的內(nèi)容影響并不是很大，大家都會覺得“還不如一塊搞掉更簡單些”。

而如果使用docker，由于每個服務(wù)打包可以封裝為一個docker鏡像，每個運行時的服務(wù)都表現(xiàn)為一個獨立容器，我們之前建立的容器依賴就可以很容易的對應(yīng)到服務(wù)依賴上，基于這種統(tǒng)一性，系統(tǒng)升級就很容易配合一些自動化工具實現(xiàn)“整體升級”（甚至還可以“整體降級”）。

#p#

5. 運維相關(guān)設(shè)施

運維環(huán)節(jié)的情形和研發(fā)環(huán)節(jié)有同有異。

應(yīng)用的依賴

相同之處是，運維環(huán)節(jié)的工作和研發(fā)一樣，都會因為引入了微服務(wù)而“支離破碎”，容易丟失全局視角，服務(wù)間的聯(lián)系可能會變成管理的灰色地帶，這些地方在討論組織結(jié)構(gòu)的時候已經(jīng)涉及到了。

不同之處在于，服務(wù)間關(guān)系的信息其實是來自研發(fā)環(huán)節(jié)的，如果這些信息能夠完整無誤的傳遞到運維環(huán)節(jié)，那么服務(wù)治理將會變得容易很多。所以，在對微服務(wù)進行運維管理時，我們其實是可以“偷懶”的。

之前已經(jīng)提到，在Docker的幫助下，持續(xù)集成平臺可以建立統(tǒng)一的服務(wù)，在不涉及具體技術(shù)細節(jié)的情況下為研發(fā)團隊提供服務(wù)，同時又不至于需要維護大量形式各異的腳本……其實故事并沒有結(jié)束，持續(xù)集成最終是要推進到持續(xù)交付的，這時就會和運維發(fā)生聯(lián)系。

在持續(xù)集成平臺上，我們要解決多服務(wù)協(xié)作的問題，辦法是讓每個服務(wù)聲明自己的依賴，然后在平臺上獲得全局圖像，當這個平臺延伸或者對接至交付環(huán)節(jié)時，之前的全局圖像信息將發(fā)揮作用，我們可以在它的指導下更加“智能”的進行系統(tǒng)擴容、自動故障降級等一系列工作。

舉個例子，開發(fā)人員在編寫服務(wù)A時顯然會知道它所依賴的服務(wù)（假定叫B），所以可以在源碼中使用docker-compose.yml申明，那么在服務(wù)A進行持續(xù)集成時，持續(xù)集成平臺將會找到服務(wù)B的鏡像，并創(chuàng)建相應(yīng)的容器和A連接，此時這個依賴信息是為了測試，但它可以被平臺獲得并記錄下來（這是真正有效的信息）。

當線上進行服務(wù)B擴容時，平臺根據(jù)之前的依賴信息，反向查詢到依賴B的其它服務(wù)（包括服務(wù)A），于是我們就可以根據(jù)預先的擴容策略，自動化的執(zhí)行對服務(wù)A等一些服務(wù)的restart/reload操作（這里的reload針對的是整個服務(wù)，實際上基于Docker的服務(wù)reload一般也就是依次restart而已）

上述的例子也適用于有依賴的服務(wù)自動升級降級，做法類似。

打包構(gòu)建

對運維而言，還有一個話題值得專門提出——打包構(gòu)建，作為基礎(chǔ)設(shè)施之一的構(gòu)建系統(tǒng)，面對微服務(wù)的趨勢，需要有什么樣的變化呢？

為了說明問題，我寫了一篇文章討論軟件打包，文章結(jié)尾提到了Docker對軟件打包的價值，這里結(jié)合微服務(wù)話題簡單總結(jié)一下文中要點：

軟件打包的目的是為了降低軟件交付物對外部環(huán)境的依賴，這個目的對于大規(guī)模分布式或者集群應(yīng)用特別有意義。因此這種以“自帶干糧”為特征的很多技術(shù)（比如靜態(tài)編譯的golang）會從google這樣的大規(guī)模互聯(lián)網(wǎng)公司中誕生，而為分布式系統(tǒng)服務(wù)的J2EE技術(shù)族中會出現(xiàn)專門為打包設(shè)計的war/ear規(guī)范。

顯然，按照微服務(wù)架構(gòu)的系統(tǒng)，特點正是分布式越來越復雜，其中某些服務(wù)可能會擴展成很大的集群，這和Google、facebook這樣的公司面臨的是同樣性質(zhì)的問題，所以解決方向也類似——讓構(gòu)建系統(tǒng)輸出的軟件交付物更加完備，即所謂的“自帶干糧”。

Docker技術(shù)交付的正是這樣“自帶干糧”的鏡像文件，通過這個文件，打包系統(tǒng)交付的產(chǎn)品可以自由分發(fā)和管理，大大降低對環(huán)境的依賴。

總結(jié)

面對膨脹的未來，微服務(wù)走了一條拆解之路，但要想完整的實現(xiàn)你的業(yè)務(wù)，還要能夠在某些情況下自由融合、彼此協(xié)作，Docker開啟的正是這樣一個方便之門。

無論是協(xié)同不同語言技術(shù)棧，降低運維的成本，還是支持分布式系統(tǒng)的自動化測試和持續(xù)交付，甚至是從單體架構(gòu)向微服務(wù)的逐步演化，Docker相關(guān)技術(shù)都可以為微服務(wù)提供有力幫助。

如何一起愉快地發(fā)展

高效運維系列微信群是國內(nèi)高端運維圈子、運維行業(yè)垂直社交的典范。現(xiàn)有會員1000余名，其中運維總監(jiān)及以上級別會員300多名。

“高效運維”公眾號值得您的關(guān)注，作為高效運維系列微信群的唯一官方公眾號，每周發(fā)表多篇干貨滿滿的原創(chuàng)好文：來自于系列群的討論精華、運維講壇線上/線下活動精彩分享及部分群友原創(chuàng)。“高效運維”也是互聯(lián)網(wǎng)專欄《高效運維最佳實踐》及運維2.0官方公眾號。

提示：目前高效運維兩個微信主群僅有少量珍貴席位，如您愿意，可添加蕭田國個人微信號 xiaotianguo 為好友，進行申請；或申請加入我們技術(shù)交流群（技術(shù)討論為主，沒有主群那么多規(guī)矩，更熱鬧）。

重要提示：除非事先獲得授權(quán)，請在本公眾號發(fā)布2天后，才能轉(zhuǎn)載本文。尊重知識，請必須全文轉(zhuǎn)載，并包括本行及如下二維碼。