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

本文講的是<b>微服務和容器技術有風險，望君三思而後行</b>，【編者的話】微服務和容器技術擁有令人興奮的潛力，強烈建議客戶開始研究這些技術。但是，這并不是說客戶應該立即全面采用。上述技術領域的發展太快了，必須清晰地了解這些技術能幹什麼，不能幹什麼，才能夠決定是否采用這些技術。畢竟，生産環境不是拿來做研發試驗的競技場。

我個人認為微服務和容器擁有令人興奮的潛力，強烈建議客戶開始研究這些技術。但是，這并不是說客戶應該立即全面采用。

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

1. 業務真的需要

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

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

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

2. 技術實力夠

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

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

3. 願意“邊做邊學”

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

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

4. 微服務 != 容器

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

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

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

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

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

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

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

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

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

總結

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

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

譯者介紹

柳泉波，讀書踢球喝茶寫程式。

原文釋出時間為：2015-04-19

本文作者：bnuhero

本文來自雲栖社群合作夥伴DockerOne，了解相關資訊可以關注DockerOne。

原文标題：微服務和容器技術有風險，望君三思而後行