微服務(wù)和容器技術(shù)擁有令人興奮的潛力，強(qiáng)烈建議客戶開(kāi)始研究這些技術(shù)。但是，這并不是說(shuō)客戶應(yīng)該立即全面采用。上述技術(shù)領(lǐng)域的發(fā)展太快了，必須清晰地了解這些技術(shù)能干什么，不能干什么，才能夠決定是否采用這些技術(shù)。畢竟，生產(chǎn)環(huán)境不是拿來(lái)做研發(fā)試驗(yàn)的競(jìng)技場(chǎng)。

[[132120]]

XebiaLabs是一家提供大規(guī)模持續(xù)集成和 DevOps軟件的公司。我們公司經(jīng)常與客戶討論新近出現(xiàn)的開(kāi)發(fā)風(fēng)格、應(yīng)用架構(gòu)和運(yùn)行時(shí)平臺(tái)，內(nèi)容涉及它們的優(yōu)勢(shì)以及帶來(lái)的挑戰(zhàn)。最近一段時(shí)間，討論的焦點(diǎn)集中在：

• 應(yīng)用層的微服務(wù);
• 平臺(tái)層的容器及相關(guān)框架，包括 Docker, Kubernetes, Mesos, Marathon 等。

我個(gè)人認(rèn)為微服務(wù)和容器擁有令人興奮的潛力，強(qiáng)烈建議客戶開(kāi)始研究這些技術(shù)。但是，這并不是說(shuō)客戶應(yīng)該立即全面采用。

上述技術(shù)領(lǐng)域的發(fā)展太快了，必須清晰地了解這些技術(shù)能干什么，不能干什么，才能夠決定是否采用這些技術(shù)。畢竟，生產(chǎn)環(huán)境不是拿來(lái)做研發(fā)試驗(yàn)的競(jìng)技場(chǎng)。

根據(jù)客戶和合作伙伴的研究，我們自己的使用體會(huì)(在我們公司內(nèi)部，容器的使用已經(jīng)很普遍)以及 Google和eBay等公司的經(jīng)驗(yàn)教訓(xùn)，我們提出了六個(gè)準(zhǔn)則，幫助你判斷是否要采用這些新技術(shù)。

1. 業(yè)務(wù)真的需要

在采用微服務(wù)或者容器技術(shù)之前，需要搞清楚一個(gè)最根本的問(wèn)題：業(yè)務(wù)當(dāng)中是否真的存在一個(gè)現(xiàn)有技術(shù)或手段無(wú)法解決的問(wèn)題?

微服務(wù)和容器是比較新的技術(shù)，發(fā)展快速，但離成熟階段還有距離。必須仔細(xì)權(quán)衡采用上述技術(shù)為團(tuán)隊(duì)和組織帶來(lái)的好處和風(fēng)險(xiǎn)。

曾經(jīng)擔(dān)任Etsy公司主任工程師的Dan McKinley在一篇博客中說(shuō)得好：

問(wèn)問(wèn)自己：不用任何新技術(shù)，能夠解決掉現(xiàn)在的問(wèn)題嗎?這個(gè)設(shè)問(wèn)有助于你搞清楚一種情況，有人非?？释褂眯录夹g(shù)，但問(wèn)題的解決實(shí)際上并不需要用到這種新技術(shù)。如果是這樣，應(yīng)當(dāng)堅(jiān)決停止采用新技術(shù)。

2. 技術(shù)實(shí)力夠

如果微服務(wù)/容器確實(shí)能夠解決其它方式無(wú)法解決的問(wèn)題，接下來(lái)，要確保擁有專家水平的平臺(tái)工程師資源。

這不光是指用到的大部分API和框架都是全新的。要讓基于容器的平臺(tái)在生產(chǎn)環(huán)境運(yùn)轉(zhuǎn)起來(lái)，需要解決一系列后續(xù)問(wèn)題：優(yōu)化網(wǎng)絡(luò)，選擇存儲(chǔ)策略，備份和失效恢復(fù)，安全，等等。

3. 愿意“邊做邊學(xué)”

目前，在生產(chǎn)環(huán)境中應(yīng)用微服務(wù)和容器技術(shù)時(shí)，會(huì)遇到很多問(wèn)題，這些問(wèn)題都沒(méi)有現(xiàn)成可用的答案。即使工程團(tuán)隊(duì)實(shí)力足以應(yīng)對(duì)這些挑戰(zhàn)，在應(yīng)用這些技術(shù)之后的幾年內(nèi)，需要不停地實(shí)驗(yàn)和學(xué)習(xí)。

例如，最初選擇的某些API和框架變化巨大，沒(méi)有提供向后兼容保證，甚至完全廢棄了。有些不適合業(yè)務(wù)情景或者不成熟的API和框架，需要推倒重來(lái)。從運(yùn)維過(guò)程到應(yīng)用交付模式的***時(shí)間，都得自己來(lái)。

#p#

4. 微服務(wù) != 容器

我們與有平臺(tái)/運(yùn)維背景的客戶，或者那些聽(tīng)過(guò)Docker或者其它技術(shù)并且想深入了解的客戶交流時(shí)，發(fā)現(xiàn)他們認(rèn)為微服務(wù)和容器是“同一枚硬幣的兩面”，用了這個(gè)技術(shù)就必須用另外一個(gè)技術(shù)。

我同意容器會(huì)引導(dǎo)用戶交付更小而不是大型一體的應(yīng)用(雖然，我也看到很多幾 GB 大小的容器鏡像)。然而，反之并不成立：應(yīng)用程序采用微服務(wù)架構(gòu)，并不意味著一定要使用容器作為底層的運(yùn)行時(shí)技術(shù)。

實(shí) 際上，如果要把已有的應(yīng)用程序“微服務(wù)化”，而且不能完全重頭再來(lái)，那么就更有不用容器的理由了。堅(jiān)持使用已有的運(yùn)行時(shí)平臺(tái)(在服務(wù)器上很容易運(yùn)行幾十個(gè) 或者幾百個(gè)微服務(wù)進(jìn)程，無(wú)需把這些進(jìn)程封裝為容器)，相當(dāng)于從“改變方程式”中消除了容器這個(gè)***的變量，從而降低項(xiàng)目的風(fēng)險(xiǎn)。

5. 處理微服務(wù)之間的依賴

我們經(jīng)常聽(tīng)到把微服務(wù)定義成一個(gè)“獨(dú)立部署的單元”。從實(shí)踐的角度看，如果設(shè)計(jì)的微服務(wù)不依賴任何其它組件就能成功地運(yùn)行，這當(dāng)然很好。但在大多數(shù)實(shí)際用例 中，“沒(méi)有任何微服務(wù)是一個(gè)孤島”：一個(gè)服務(wù)可以啟動(dòng)，獨(dú)自響應(yīng) API 調(diào)用;但在用戶真實(shí)使用情景中，往往需要幾個(gè)服務(wù)的協(xié)調(diào)和配合。

例如，訂單服務(wù)啟動(dòng)后，自己就能告訴用戶有多少訂單。但用戶的操作包括瀏覽商品目錄、選擇商品、完成購(gòu)買和跟蹤訂單的完成，這需要同時(shí)運(yùn)行一批相互配合的服務(wù)。

如果希望用容器實(shí)現(xiàn)微服務(wù)，有幾個(gè)框架提供了容器服務(wù)編排的功能，目的是處理容器之間的依賴和鏈接。這些框架包括Kubernetes

Helios、Marathon 和Fig(即 Docker Compose)。

就目前而言，運(yùn)行時(shí)/微服務(wù)的依賴管理，特別是虛擬化，還沒(méi)有到構(gòu)建時(shí)依賴管理的水平(因此，我們的很多客戶有興趣了解 XL Deploy 提供的依賴管理新特性)。遇到什么問(wèn)題，都需要自己解決，至少要增強(qiáng)已有工具的功能才能解決。

6. 不光是hello world這樣的應(yīng)用

Docker特別流行的一個(gè)主要原因是它的上手體驗(yàn)非常棒。在容器中運(yùn)行某種語(yǔ)言編寫(xiě)的示例程序(例如Hello World 程序)會(huì)有一個(gè)非常簡(jiǎn)單、有成就感的體驗(yàn)。接下來(lái)，要對(duì)容器做些定制也很容易。

然而，如果要在生產(chǎn)環(huán)境中用容器運(yùn)行真實(shí)的應(yīng)用程序，特別是還想把應(yīng)用封裝為微服務(wù)，遇到的挑戰(zhàn)完全不同。構(gòu)建自有PaaS平臺(tái)就是一個(gè)工程上的挑戰(zhàn)，除此之外，還有一系列與進(jìn)程相關(guān)的問(wèn)題需要解決。

我在以前的一篇博客中討論了最重要的一些問(wèn)題。在你研究微服務(wù)和容器技術(shù)時(shí)，要找到解決這些問(wèn)題的方法。

總結(jié)

簡(jiǎn)言之，微服務(wù)和容器肯定是值得研究的技術(shù)之一(為了幫助客戶應(yīng)對(duì)本文提及的種種挑戰(zhàn)，我們?cè)赬L Test、XL Release和XL Deploy中提供了一系列與微服務(wù)和容器相關(guān)的功能特性)。

在你決定采用微服務(wù)和容器技術(shù)之前，確保自己已經(jīng)理解所面臨的挑戰(zhàn)，明白需要投入的時(shí)間和資源……最重要的是要保證：實(shí)際業(yè)務(wù)真的需要應(yīng)用這些技術(shù)，為此付出的努力和承擔(dān)的風(fēng)險(xiǎn)都是值得的。

原文鏈接：http://dockerone.com/article/327