微服務和容器技術有風險，望君三思而后行

微服務和容器技術擁有令人興奮的潛力，強烈建議客戶開始研究這些技術。但是，這并不是說客戶應該立即全面采用。上述技術領域的發展太快了，必須清晰地了解這些技術能干什么，不能干什么，才能夠決定是否采用這些技術。畢竟，生產環境不是拿來做研發試驗的競技場。

XebiaLabs是一家提供大規模持續集成和 DevOps軟件的公司。我們公司經常與客戶討論新近出現的開發風格、應用架構和運行時平臺，內容涉及它們的優勢以及帶來的挑戰。最近一段時間，討論的焦點集中在：

• 應用層的微服務；
• 平臺層的容器及相關框架，包括 Docker, Kubernetes, Mesos, Marathon 等。
</ul>
我個人認為微服務和容器擁有令人興奮的潛力，強烈建議客戶開始研究這些技術。但是，這并不是說客戶應該立即全面采用。

上述技術領域的發展太快了，必須清晰地了解這些技術能干什么，不能干什么，才能夠決定是否采用這些技術。畢竟，生產環境不是拿來做研發試驗的競技場。

根據客戶和合作伙伴的研究，我們自己的使用體會（在我們公司內部，容器的使用已經很普遍）以及 Google和eBay等公司的經驗教訓，我們提出了六個準則，幫助你判斷是否要采用這些新技術。

1. 業務真的需要

在采用微服務或者容器技術之前，需要搞清楚一個最根本的問題：業務當中是否真的存在一個現有技術或手段無法解決的問題？

微服務和容器是比較新的技術，發展快速，但離成熟階段還有距離。必須仔細權衡采用上述技術為團隊和組織帶來的好處和風險。

曾經擔任Etsy公司主任工程師的Dan McKinley在一篇博客中說得好：



問問自己：不用任何新技術，能夠解決掉現在的問題嗎？這個設問有助于你搞清楚一種情況，有人非常渴望使用新技術，但問題的解決實際上并不需要用到這種新技術。如果是這樣，應當堅決停止采用新技術。

2. 技術實力夠

如果微服務/容器確實能夠解決其它方式無法解決的問題，接下來，要確保擁有專家水平的平臺工程師資源。

這不光是指用到的大部分API和框架都是全新的。要讓基于容器的平臺在生產環境運轉起來，需要解決一系列后續問題：優化網絡，選擇存儲策略，備份和失效恢復，安全，等等。

3. 愿意“邊做邊學”

目前，在生產環境中應用微服務和容器技術時，會遇到很多問題，這些問題都沒有現成可用的答案。即使工程團隊實力足以應對這些挑戰，在應用這些技術之后的幾年內，需要不停地實驗和學習。

例如，最初選擇的某些API和框架變化巨大，沒有提供向后兼容保證，甚至完全廢棄了。有些不適合業務情景或者不成熟的API和框架，需要推倒重來。從運維過程到應用交付模式的最佳實踐，都得自己來。

4. 微服務 != 容器

我們與有平臺/運維背景的客戶，或者那些聽過Docker或者其它技術并且想深入了解的客戶交流時，發現他們認為微服務和容器是“同一枚硬幣的兩面”，用了這個技術就必須用另外一個技術。

我同意容器會引導用戶交付更小而不是大型一體的應用（雖然，我也看到很多幾 GB 大小的容器鏡像）。然而，反之并不成立：應用程序采用微服務架構，并不意味著一定要使用容器作為底層的運行時技術。

實際上，如果要把已有的應用程序“微服務化”，而且不能完全重頭再來，那么就更有不用容器的理由了。堅持使用已有的運行時平臺（在服務器上很容易運行幾十個或者幾百個微服務進程，無需把這些進程封裝為容器），相當于從“改變方程式”中消除了容器這個最大的變量，從而降低項目的風險。

5. 處理微服務之間的依賴

我們經常聽到把微服務定義成一個“獨立部署的單元”。從實踐的角度看，如果設計的微服務不依賴任何其它組件就能成功地運行，這當然很好。但在大多數實際用例中，“沒有任何微服務是一個孤島”：一個服務可以啟動，獨自響應 API 調用；但在用戶真實使用情景中，往往需要幾個服務的協調和配合。

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

如果希望用容器實現微服務，有幾個框架提供了容器服務編排的功能，目的是處理容器之間的依賴和鏈接。這些框架包括Kubernetes
Helios、Marathon 和Fig（即 Docker Compose）。

當前，運行時/微服務依賴的管理，特別是虛擬化，還沒有達到構建依賴的管理水平（因此，我們的很多客戶有興趣了解 XL Deploy 提供的依賴管理新特性）。遇到什么問題，都需要自己解決，至少要增強已有工具的功能才能解決。

6. 不光是hello world這樣的應用

Docker特別流行的一個主要原因是它的上手體驗非常棒。在容器中運行某種語言編寫的示例程序（例如Hello World 程序）會有一個非常簡單、有成就感的體驗。接下來，要對容器做些定制也很容易。

然而，如果要在生產環境中用容器運行真實的應用程序，特別是還想把應用封裝為微服務，遇到的挑戰完全不同。構建自有PaaS平臺就是一個工程上的挑戰，除此之外，還有一系列與流程相關的問題需要解決。

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

總結

簡言之，微服務和容器肯定是值得研究的技術之一（為了幫助客戶應對本文提及的種種挑戰，我們在XL Test、XL Release和XL Deploy中提供了一系列與微服務和容器相關的功能特性）。

在你決定采用微服務和容器技術之前，確保自己已經理解所面臨的挑戰，明白需要投入的時間和資源……最重要的是要保證：實際業務真的需要應用這些技術，為此付出的努力和承擔的風險都是值得的。

原文鏈接：Before You Go Over the Container Cliff with Docker, Mesos etc: Points to Consider（翻譯：柳泉波 校對：佚名）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

譯者介紹
柳泉波，讀書踢球喝茶寫程序。

來自：http://dockerone.com/article/327