在DevOps社群中，微服務和容器最近受到很多關注。

已經成熟，並且正在從主要使用在構建/測試階段擴充套件到生產開發。同樣的，微服務正在從主要使用在green field web服務擴充套件到在企業內使用——作為組織分解他們龐大的應用，支援更快的釋出週期的探索方式。

作為組織努力擴充套件他們的應用開發和釋出，實現持續交付，雖然有挑戰性，但是微服務和容器越來越多的被企業考慮。雖然這兩者都會帶來好處，但是他們並不是“一刀切”，並且我們看到企業為了他們特定的用例和環境仍然通過這些技術和設計模式進行試驗。

為什麼用Microservices?為什麼用容器?

微服務是一個吸引人的DevOps

容器提供一個良好的明確的、隔離的執行時環境。代替人工釋出和所有的變數，容器支援將所有東西打包到一個Docker-type檔案中，通過管道提升為一致的環境中的一個單獨容器。除了隔離和一致的環境，容器執行一個容器程序開銷也非常低。這支援了環境的一致性從開發到生產，和極快的準備，適應調整，與擴充套件，加速和簡化了開發與操作。

為什麼在容器中執行微服務？

在容器化的環境中執行基於微服務的應用很有意義。Docker和微服務是天然的夥伴，形成現代應用交付的基礎。

在一個較高的水平，微服務和Docker一起是DevOps的PB&J是因為：

• 它們的目的都在於把一件事做好，並且都是免費的。
• 你需要學會把擅長的轉化到另一個上。

更具體的說：

目標

微服務（通常）是一個單獨的程序，集中於應用的一個方面，儘可能在隔離環境中操作。

Docker容器在一個邊界清晰的環境中執行一個單獨的程序。

複雜性

通過微服務，你現在需要知道部署，協調，和執行多重服務（幾十到幾百個），然而在這之前你可能有一個更為傳統的三層/整體架構。當微服務支援敏捷開發——特別是在開發方面——他們會遇到許多技術挑戰，主要是在操作方面。

容器對這些複雜性有幫助，因為容器可以使它們變得簡單並且在容器中快速部署服務，這主要對於開發人員來說。

擴充套件

微服務讓擴充套件變得更為簡便，因為每個服務可以獨立於其他服務進行擴充套件。

原生容器叢集編排工具，例如Kubernetes，和雲環境，例如Amazon ECS和Google Container Engine(GKE)，提供容易的擴充套件容器機制，基於載入和業務規則。

系統理解

微服務和容器本質上都促使你更好的理解系統——如果你不能徹底的理解你的架構、拓撲、功能、操作和效能，你不會在這些技術上取得成功。

挑戰

管理微服務和大規模Docker部署，給IT企業造成了獨特的挑戰。因為非常多的重疊部分,為了成功部署和更改微服務和容器，組織必須熟練運用，在挑戰和實施容器最佳實踐和微服務擴充套件的方面有相當多的重複。

• 增加管道變化。隨著更多的遷移部分，操作交付管道變得更為複雜。當你分離一個整體，變成若干個微服務，管道的數量也許會從1跳到50（或者然而你已經建立很多微服務）。你需要考慮將來需要多少不同的團隊，是否有足夠的人員來支援每個微服務/管道。
• 測試變得更復雜。有大量的測試需要考慮——整合測試，API契約測試，靜態分析等等。
• 增加部署複雜性。當擴充套件容器化的應用相當簡單的時候，有許多活動需要先設定。在釋出到生產環境之前，必須多次部署開發和測試，貫穿管道。如此多的不同的服務獨立開發，部署量急劇增加。
• 監控、日誌和修復變得非常重要並且日益困難，因為有更多的遷移部分和不同的分散式服務，包含整體的使用者體驗和應用效能。
• 有許多不同的工具鏈、架構和環境需要管理。
• 需要考慮到目前的應用程式，並且如何協調這些新服務和容器功能–或者基於微服務的應用。
• 隨著如此大量的分散式環境，和組織需要同時支援容器和微服務，與傳統的釋出和整體的應用程式，管理和審計（特別是在企業層面）變的更為複雜。

除了這些常見的挑戰，微服務和容器還有它們自己獨有的挑戰。如果你正在考慮微服務，最好知道下面這些：

• 分散式系統是困難的，並要求很強大的系統理解。
• 服務組裝是一個棘手的問題，而且改變很昂貴。以整體作為開始，避免過早分解，直到你徹底理解應用行為。需要描述程序間失效模式，雖然抽象在紙上看著不錯，但是易於遇到瓶頸。
• 注意事物邊界和外來鍵關係，它們將會很難分解。
• 考慮基於事件的技術，來減少進一步的耦合。
• 為了API和服務SLA：“自己保守的做，寬大的接受別人所做的。”
• 狀態管理是難處理的，快取和其他有趣的事……
• 測試（特別是在服務間的整合測試）和監控（因為服務數量的增長）變得更為複雜。
• 服務虛擬化，服務發現，和API整合點的合理設計和反向相容是必不可少的。
• 故障排除失敗：“每次斷電都是一起神祕謀殺。”
• 即便一個服務很小，部署路徑仍然要考慮到。
• 一切你都要依靠網際網路——需要考慮寬頻，延遲和可靠性。
• 當前應用該怎麼處理：重寫？忽略？還是混合？

容器挑戰

安全是一個關鍵的挑戰——因為它還是一個相對較新的技術，由於關注安全問題，因此下載一個映象。對OpSes來講容器是一個黑匣子：更少的控制，容器內更少的可見性，和現有的工具無法理解容器。一定要簽署和掃描映象，驗證庫等；加強容器環境；早點放棄許可權分配，並且使用細粒度的訪問控制，因此它不是所有的root。瞭解認證資訊（容器服務可以幫你）。

監控是很棘手的，因為容器例項可能連續下降或者span-up。需要考慮用記錄和監控來解除失效的容器或者儲存日誌和業務資料，定位資料，合規資料，日誌，來自其他（時間）例項的diagnostics-from。

知道在哪執行，並且為什麼執行，避免映象臃腫和容器蔓延。

由於容器託管和叢集編排市場仍然是新興市場，我們看到使用者嘗試很多跨環境執行容器，或者使用不同的叢集編排工具和APIs。這些早期的採用者需要管理容器，在鎖定特定的雲廠商或point-tool時最小化風險，或者在重寫複雜的指令碼上投入更大的工作量（並且學習路線曲折），為了重新決定他們的部署和釋出程序，一個新容器環境或者工具。

微服務和容器的最佳實踐

然而，公認的，當談到部署微服務和容器會有相當多的挑戰，最終結果將是減少管理成本並更快的投入市場。如果微服務和容器對你的應用程式用例很有意義，有大量的計劃需要在把應用分解成成上百組不同的服務前實現，或是遷移你的資料中心到一個容器環境。沒有精細的計劃和緊跟產業最佳實踐，很容易失去微服務和容器帶來的優勢。

為了成功的執行微服務和大規模容器，有一些技能，組織需要在整個軟體交付週期中運用：

• 建立相關領域知識。部署微服務之前理解相關領域是至關重要的，在做困難決定前，在哪把問題分割到不同的服務中去的。先保持一個整體。保持模組化和優質程式碼。
• 每個服務需要獨立CI和部署管道，所以你可以獨立的建立，驗證和部署每個服務，無需考慮其他服務的交付狀態。
• 管道自動化：票務系統沒有自動化。隨著大量增加的管道和管道複雜性，你必須會編排端到端的程序，包括所有的point-tools，環境，和配置。需要自動全部的程序——從CI，測試，配置，基礎設施配置，開發，應用釋出程序，和生產反饋迴圈。
• 測試自動化：如果不首先建立自動化測試，微服務和容器將變成噩夢。一個自動化測試框架將會檢查在管道最終所有準備好的一切，並且增加生產團隊的信心。
• 為容器使用企業登錄檔。知道資料在哪儲存並且重視安全，通過在軟體管道中增加模組化安全工具。
• 知道什麼在執行，在哪和為什麼。理解平臺限制，避免映象臃腫。
• 管道必須與工具/環境無關的，因此可以支援每個工作流和工具鏈，無論他們是什麼，你可以方便的在服務和容器環境之間轉移。
• 一致的日誌和監控貫穿所有的服務，規定迴圈反饋到管道。確保管道自動化插入到監控以便警報觸發自動程序，例如回滾一個服務，在藍/綠部署間調動，擴充套件等等。監控/效能測試工具需要允許追蹤一個請求，穿過系統，即使它在不同服務間彈跳。
• 處理失敗要更加仔細（考慮使用Hystrix）。
• 為微服務靈活的配置人員和組織設計。考慮每個服務每個團隊是否有足夠的人員。

對微服務和容器興趣不斷增加，並且有很好的理由。無論如何，企業需要確保他們有技巧和知識來克服挑戰，可靠的管理大規模技術。計劃和軟體交付模型是關鍵，運用正確的技術和工具，微服務和容器就可以實現更快的釋出和減少開銷。

更多DevOps精華內容