羊年八問：微服務、容器與Docker
作者從八個方面對當下熱門的微服務、容器入手，提出一些問題與建議。讀者可以通過此文理解這些技術在企業中的應用場景，其中一些問題值得讀者深思熟慮。
2014注定會成為IT發展史上的重要一年。毫不夸張地說，Docker（或者說容器）和微服務正在革新交付和運行軟件服務的方式。與這種革新隨之而來的是開發者的興趣和熱情，當然也有很多的炒作和趨之若鶩。但在所有這些議論中，我們要牢記它真的還很年輕，不僅僅是技術，還有圍繞著微服務、容器以及Docker的流程與實踐。
這里有關于容器的8個問題，我認為每個公司都需要在做任何決定之前進行確定：存儲、容錯、交付模式、發布策略、所有權、補丁、支持和許可。
不要誤會我的意思：我覺得微服務和物聯網將成為我們設計與交付IT服務方式的核心部分（在越來越多的分散的計算能力與更大數據量被拉回到中央位置之間有一種有趣的張力。因為我們無法處理它，否則它將是一篇不同博文的話題）。在XebiaLabs roadmap上微服務扮演了重要的功能角色，我認為每一個公司都應該關注他們，并且容器是一個非常有前途的候選實現技術。
那些號稱要“Docker化一切”的公司真的相當勇敢，用一個更微妙的方式來看它：如果你已經認同并證明了容器的優勢，特別是Docker－它可
以用于應用程序的交付，那么你就會有這樣一種任你自由支配的可以解決復雜的、尚未解決的問題的方案的技術資源，并且愿意去通過生產和重新實現附帶任何
1.x版的技術然后并采用，現在來說它也是有道理的。
然而你要是完全基于“containers will make everything better”來容器化一切，并期待能結合現有的現成解決方案，讓你的團隊在一些最佳實踐上訓練，并迅速地有一個穩定、安全的運行平臺并且在運行中，它將會給你帶來很多的驚訝。
我相信微服務會是大的趨勢，所以我認為企業也會不斷探索容器（Docker、Mesos、Rocket或者任何不久我們將無疑會看到的其他替代品）如何融入到工作中。在最近的一些討論的基礎上，我認為2015年企業應該考慮下這八個問題。
1. 存儲</h4>
1. 存儲</h4>
也許現在最明顯的技術問題是：如何處理持久、可寫的存儲容器？如何以及在何處存儲數據？如何從容器中連接到它？如何復制與備份它？在容器啟動的情況下如何讓數據隨著容器遷移以及如何迅速地實現它？
2. 容錯</h4>
2. 容錯</h4>
在一個微服務環境中，尋找其它服務的常見方法是查詢服務Registry，以及/或者為服務使用確定的名稱并通過類似DNS
這樣的方案根據名稱查詢。在之前的環境中，啟動一個新的虛擬機可能需要幾分鐘，而采取服務注冊或是DNS緩存來更新相對來說耗時比較少。用容器的話只需要
幾秒就可以，服務的重新綁定很快會成為一個瓶頸，尤其是當有許多容器同時發生故障時。
我最近看到了一個令人印象深刻的解決方案，它使用的是商品硬件，其能夠從一個全機架故障中恢復－重新啟動、重新掛載和重新綁定10000個容器－不超過10秒。但是這一切都是定制的引擎和實驗...在貨架上你得不到這種東西。
你的容錯要求有哪些？你與容器會如何定位這些？
3. 交付模式</h4>
3. 交付模式</h4>
如果你要部署容器，開發商將要交付什么？他們是否要交付容器的描述符（Dockerfile或者其他類似的）？如果交付
的話，你如何傳送描述所引用的所有外部資源？或者開發商是否會提供“編譯過”的鏡像，使之避免了外部的依賴問題但是增加了可交付的包大小并且使給接收者更
難檢查或驗證什么是真正要運行的。
或者你是否希望避免要求開發者學習另一種“交付格式”（來讓開發人員學習Puppet、Chef或類似配置的“語言”的難度是我們遇到的一些組織
試圖向開發商介紹他們來作為交付方式的主要問題之一），并正在尋找某種方式從開發商交付的同一代碼產品中“自動生成”容器描述或是鏡像呢？
4. 發布策略</h4>
4. 發布策略</h4>
你的服務是否獨立，使你能夠在每一個提交或是設定的安排后都能部署每個服務到生產中？還是說你需要綁定多個服務在最新的
候選版本已經測試過的發布隊列里。如果成功的話，基本上每天發布還是每周發布？如果是后者，那么你會使用多少個發行版本？企業組織一個、每個團隊一個或者
每個業務部門一個呢？
隨著發布隊列里候選版本的的數量上升，測試失敗的機會通常也會增加。你是否會中止發布隊列，如果有測試失敗了，因為這一個問題從而可能會阻止199個“狀態良好”的服務上線嗎？或者嘗試移除那個“爛蘋果”，并重新測試其余的候選版本是否有意義呢？
對于實際生產部署來說，你是否會創建一個完整的“mirror”環境（可能是一個您用于在發布隊列里的最廣泛的測試？）？還是你只是沿著現有的服
務來部署新的服務？如果是這樣，你怎么處理這逐漸的血流不止的問題，請牢記新服務可能不會直接被用戶使用？還是你依靠快速來回切換如果有問題的話，來代替
完全切換到新的服務呢？如果是這樣，你是否會一次切換一個服務（當然是相互依存服務的集群）或者是一次切換所有的服務？
5. 所有權</h4>
5. 所有權</h4>
關于容器的交付模式的決定部分，也是由誰擁有/負責這一塊的交付成果來決定的。業務操作是否簡單地提供容器運行環境以及在
容器內的發生的任何問題的開發商所要負的責任？業務操作是否還負責從每個開發商提供的容器繼承的“基本的描述符”或“基礎鏡像”？如何確定一個問題是否由
鏡像的“基礎“部分造成的，還是說開發商添加的部分，特別是那些允許開發商修改或者覆蓋基礎鏡像的技術部分所造成的？
還有一個與有關安全方面的問題：你是否能充分隔離/沙箱操作你的容器，得以防止其影響其它系統？或者你只是相信，由開發團隊提供的描述符/鏡像不會做“壞事” - 無意或是故意的呢？
如果你想讓開發團隊來責任提供完整的容器描述并且您也信任他們會做正確的事，而且他們的容器配置文件系統的條例來說，你問他們是否會愿意支持生產線上的系統？
6. 補丁</h4>
6. 補丁</h4>
你需要有更改運行系統的能力，如應用安全補丁或其他重要變化？如果你正在考慮采取一成不變的基礎設施建設的原則，你能多快更新所有受影響的容器定義或鏡像，并且發布新版本？如果補丁可以應用到開發團隊使用的基本描述符或鏡像中，你是否能在他們的構建過程中“覆蓋”基礎鏡像，以及是否需要開發團隊來改變他們的源代碼或者構建定義。
如果你正在考慮修改運行的容器，請確保容器技術支持這一點，并且還提供了一個審計線索。您將如何確保對運行容器所做的任何更改可以返回到容器定義？
7. 支持</h4>
7. 支持</h4>
最近我聽說這個故事：一個公司為了一個支持合同在一個操作系統運行Docker。但在Docker中運行容器是使用不支持的操作系統的基礎鏡像。突然，“機器”（即容器）都不能有效托管主機支持的應用程序。當他們面臨這些問題時，他們的支持合同卻幫不了他們。
你是否有必需的支持解決方案無論你的容器運行在什么地方？
8. 許可</h4>
8. 許可</h4>
如果你在每個系統中使用的是被許可的服務組件，你是否檢查了供應商的有關容器的許可政策？供應商是否考慮每個容器里是一個獨
立的系統，還是說他們只是簡單地認為托管容器框架是系統的進程而已？換句話說，如果你現在在一臺機器上運行10個許可程序的實例，你的成本是否會保持不變
如果你在容器內運行它們，還是說在一個完整的訂單或幅度內它將會增加？
這么多的問題...但是答案是什么？不幸的是，基于這么多談話，我覺得在這一點上坦率的回答是：沒有人知道。在一些地區有很多有趣的想法，但還沒有明顯的贏家。其他的問題僅僅現在才顯示在討論的雷達中，而且在許多情況下，“正確”答案很大程度上取決于企業的具體情況。
幸運的是，鑒于正在發生的這些事，我想在明年同一時間我們會了解的多得多。這是一個令人興奮的2015年！
原文鏈接：8 Questions You Need to Ask About Microservices, Containers & Docker in 2015 （翻譯：田浩浩 校對：李穎杰）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
譯者介紹
田浩浩，悉尼大學USYD碩士研究生，目前在珠海從事Android應用開發工作。業余時間專注Docker的學習與研究。希望通過DockerOne把最新最優秀的譯文貢獻給大家，與讀者一起暢游Docker的海洋。
來自：http://dockerone.com/article/151