容器和微服務是不是天生一對?容器化環境是否能更好地實施微服務?本文作者走訪了數位親身實踐者，給出了一些進行容器化微服務管理的6大建議。如果您也在評估考慮微服務技術，此文不要錯過。

一、微服務的悖論

Gianna作為高級軟件工程師加入了Avidoo公司，這是一家生產力平臺。在與其他團隊的會議上，她提出了微服務的問題，以及團隊是否開始采用。她立即得到了強烈的反應。

拜倫表示：“我們嘗試過采用微服務，但是它們不起作用。

“這帶來了可怕的混亂!”另一位同事補充說。

Gianna三次眨巴眼睛，期待著某種闡述，但沒有一個往下接著說。

Gianna沉默了一會兒，問：“發生了什么事?

“起初很棒。每次我們被要求做新的東西時，我們都可以添加一個服務，并使用想要實驗的任何語言和框架。我們將REST API 公布在需要與之協作或在其數據庫上工作的系統上。但過了一段時間，事情開始越來越頻繁地割裂，開發速度放慢了。 Gianna嘆了口氣。聽起來像她的團隊一直在建立一個分布式的巨石應用，而他們打算建立的是微服務。

分布式巨石應用和其他龐然大物

Gianna所遇到的問題太常見了。微服務是靈丹妙藥，IT經理和工程師傾向于區分哪些優勢與他們的組織相適應。

卻忘記了天下沒有免費的午餐這件事。除了優勢之外，精心打造的微服務架構也有被微辭的一面。沒有任何“錯誤”的微服務，只有微服務不能提供的好處，或者由于它們的缺點而造成的不可接受的風險。使用微服務的優勢選擇采用微服務應該首先決定哪種優勢適合自身的企業。以下是一些突出的優點：

1.增強團隊的自主性

許多公司圍繞團隊成員具備的知識或組件組織團隊。在創造真正的客戶價值時，這要求團隊之間進行大量的協調，不可能同時處理一個特性。

利用單一專業團隊創造價值

微服務通過cover一個功能來促進自治。因此，一個團隊可以完全擁有它，而不需要多個團隊一起，這有助于減少跨團隊的協調。

利用多學科團隊創造價值

2.更大的容錯

團隊自治的地方也應該有自治的特點。一個功能通常依賴于另一個。在大多數環境中，通信通過REST接口，按需和pull-based。當這種互動是關鍵任務時，依靠這種通信的服務要么必須有合理的fall-back，要么就會失敗。這種不健康的模式常常被系統運行狀況檢查所證明，如果系統的一個依賴性不健康，系統運行就會失敗。除了導致部署順序難以管理之外，它還說明了系統依賴性的困難。

運行時依賴關系

使用正確的軟件架構(如event sourcing)，可能補充CQRS，可以完全消除大多數功能之間的運行時依賴。這主要是由于從pull-based系統向push-based系統的轉變。

3.細粒度的軟件生命周期管理

開發和業務人員一個共同的愿望是，盡快用新程序替換應用程序中的某個功能。無論是因為要求改變或者重寫，又或由于緊張的上市周期需求而導致的技術債務，都使得開發速度落后了。有人可能天真地認為，這些是可以快速被替代的，但其實不然。經常更換功能導致不得不對其所依賴的許多系統進行更改，反之亦然。

缺乏細粒度的軟件生命周期管理

通過高度調節系統間通信，可以完全切換一個或多個功能，而不必觸發任何依賴系統。

4.靈活的技術選擇

不可否認，這是一個棘手的問題。在需求或個人興趣的推動下，入職和培訓員工切換到通用技術有助于團隊間的流動性。但是對于使用不同技術的幾個部門的員工，坦白地說，這可能導致大規模的罷工。

迫使技術做出選擇

只要這些技術可以集成到自動化測試和部署工作流程中，一個團隊就可以保持自己的技術選擇。為什么要改變一個團結在對C#所有東西都非常熱愛的勝利團隊呢?只要他們能夠產出符合平臺監控，日志記錄和通信規則的組件。

那么為什么他們失敗了?

因為不知道應該如何去做微服務。采用微服務并不會失敗，因為人們不知道如何去做，他們經常不記得首先要解決什么問題。與其他任何決定一樣，采用微服務會帶來一些成本。軟件架構師往往會忘記，他們不應該幫助企業的管理者采用微服務，而應該幫助他們解決真正的業務問題。恰當地衡量這些方面的成本和收益對企業的需求至關重要。

二、微服務和容器：6大長期管理技巧

部署基于容器的微服務僅僅是個開始，如何有效管理它呢?在我們最近發布的有關微服務和容器入門的文章中，Cloud Technology Partners公司副總裁兼***云架構師 Mike Kavis分享了一個好消息：“部署容器非常容易。

他言簡意賅的說：“盡管部署容器很容易，但是要多思考這些系統的運維。”

你可以用容器化的微服務深入到生產環境，但大多數專家不會推薦它，特別是如果這是你***次使用這個強大的技術。

基于容器的微服務有相當多的優勢：正如紅帽技術布道者(Gordon Haff)最近寫到的：“即使Match.com(編者注：一家相親配對網站)也找不到微服務更好的合作伙伴。”但是 IT Heaven所做的大部分工作都需要強大靈活的計劃，持續管理企業的容器化微服務架構。你的企業中可能存在一條學習曲線，需要實施智能***實踐，確保高效運營。

SolarWinds公司的負責人Kong Yang說：“***天之后，所有事情都變得更加復雜。

我們詢問了Yang、Kavis等人，他們對有效管理容器化微服務的***建議。

1.保持簡單

面對不斷增加的復雜性，想要保持高效嗎?那就保持簡單，愚蠢。這種設計和工程原理，通常被認為是航空和系統工程師Clarence “Kelly” Johnson的指導原則。

對于Johnson來說，KISS和管理哲學一樣重要，“我們的目標是通過對棘手問題的常識應用來更快更高效地獲得結果。

對于IT團隊來說，這些想法有一個可見的翻譯，特別是在微服務和容器方面。

“為確保今后的成功運營，讓每個微服務做一件事，做得非常好。不要將附加功能擴大到現有的執行良好的微服務里。”

2.盡早把管理計劃落實到位

微服務和容器可以實現更快，更靈活，更彈性，響應速度更快的軟件團隊。但首要的事情是，在部署到生產之前制定一個計劃。這樣一個計劃的范例框架如下：

開發部署，安全和運維的***實踐微服務和容器利用現代化的日志記錄和監控解決方案探索容器管理工具(又名編排平臺，如Kubernetes)，在云端和非云端點上了解自身的環境定期實行post-mortems，不斷學習和提高

3.選擇一個編排平臺

編排工具對于容器化微服務的長期成功至關重要。

“每個微服務都需要與管理應用程序共享其狀態。這可以決定微服務的生命周期。” ShieldXNetworks ***技術官 Manuel Nedbal說。“例如，一旦微服務不報告或者正在被超載，就可以用一個新服務替換或者被復制。”

4.制定一套***限度的運營能力

一個容器管理平臺不會為你做所有的工作。Retriever Communications***技術官Nic Grange 說，除了像Kubernetes這樣的編排系統之外，還需要確保每個容器化的微服務都遵循“***限度的運營能力”，以便在這樣的環境下運行良好。他提供了以下這些功能的關鍵示例列表：

編排系統需要能夠訪問每個微服務上的API，確定它是否準備好接收流量，以及是否健康。需要告知微服務何時正常關閉的方法。需要微服務公開指標和日志記錄。在大多數情況下，微服務需要能夠水平擴展，并且在某些情況下具備集群意識。

Grange也為開發人員分享了一些好消息：特定語言的微服務模板庫(如go-kit for Go)和dropwizard for Java，可以節省大量的開發這些***功能的前期工作。

Grange說：“這些讓開發人員更容易做正確的事情，獲得許多開箱即用的功能，而不必編寫更多的代碼。

5.實施持續集成和持續交付

Sungard Availability Services CTO& 高級架構師 Kevin McGrath 表示，持續集成和持續交付實踐對于基于容器的微服務的長期管理是一個巨大的好處，尤其是作為支撐企業編排工具的基礎。

McGrath說：“如果沒有CI / CD，微服務的維護將會因為手動流程而變得不堪重負，無法按預期進行擴展，并且最終將比基礎設施和人力資源中的整體應用成本更高。”

隨著時間的推移，CI / CD將幫助團隊釋放編排或管理工具的潛力，尤其是在管理如何在主機池中分配CPU，內存和存儲時。

McGrath解釋說：“一旦CI / CD成為產品生命周期一個自然的組成部分，管理系統就非常好，它們處理各種基礎架構需求，并將其作為工程師的邏輯配置參數。“對于運維來說，要全面了解主機，容器和服務的資源消耗情況，以便更好地了解需要更多資源的位置。當服務不再與特定的基礎設施綁定，而是與基礎設施需求相聯系時，這一點非常重要。”

6.不斷重新審視并重新投資業務

容器和微服務不是一勞永逸的技術。DigitalOcean公司的工程經理 Mac Browning 建議說，為了正確使用他們，需要不斷在如何運行基于容器的微服務上進行投資。這個建議適用于企業的人員、流程和工具。編排平臺是一個好的開始。

Browning說：“如果完全投資并使用像Kubernetes這樣的編排平臺，那就意味著要花時間和資源來跟上項目和更新，并在自己的部署中體現這些變化。“由于企業微服務現在集中運行，這項投資將對所有要運行的服務產生積極影響，而不是一個或兩個特定的單一服務。”