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

一、微服務(wù)的悖論

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

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

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

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

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

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

分布式巨石應(yīng)用和其他龐然大物

Gianna所遇到的問題太常見了。微服務(wù)是靈丹妙藥，IT經(jīng)理和工程師傾向于區(qū)分哪些優(yōu)勢與他們的組織相適應(yīng)。

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

1.增強團隊的自主性

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

利用單一專業(yè)團隊創(chuàng)造價值

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

利用多學(xué)科團隊創(chuàng)造價值

2.更大的容錯

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

運行時依賴關(guān)系

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

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

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

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

通過高度調(diào)節(jié)系統(tǒng)間通信，可以完全切換一個或多個功能，而不必觸發(fā)任何依賴系統(tǒng)。

4.靈活的技術(shù)選擇

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

迫使技術(shù)做出選擇

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

那么為什么他們失敗了?

因為不知道應(yīng)該如何去做微服務(wù)。采用微服務(wù)并不會失敗，因為人們不知道如何去做，他們經(jīng)常不記得首先要解決什么問題。與其他任何決定一樣，采用微服務(wù)會帶來一些成本。軟件架構(gòu)師往往會忘記，他們不應(yīng)該幫助企業(yè)的管理者采用微服務(wù)，而應(yīng)該幫助他們解決真正的業(yè)務(wù)問題。恰當?shù)睾饬窟@些方面的成本和收益對企業(yè)的需求至關(guān)重要。

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

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

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

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

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

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

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

1.保持簡單

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

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

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

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

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

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

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

3.選擇一個編排平臺

編排工具對于容器化微服務(wù)的長期成功至關(guān)重要。

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

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

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

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

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

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

5.實施持續(xù)集成和持續(xù)交付

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

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

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

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

6.不斷重新審視并重新投資業(yè)務(wù)

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

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