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

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

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

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

“這帶來(lái)了可怕的混亂!”另一位同事補(bǔ)充說(shuō)。

Gianna三次眨巴眼睛，期待著某種闡述，但沒(méi)有一個(gè)往下接著說(shuō)。

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

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

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

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

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

1.增強(qiáng)團(tuán)隊(duì)的自主性

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

利用單一專(zhuān)業(yè)團(tuán)隊(duì)創(chuàng)造價(jià)值

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

利用多學(xué)科團(tuán)隊(duì)創(chuàng)造價(jià)值

2.更大的容錯(cuò)

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

運(yùn)行時(shí)依賴(lài)關(guān)系

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

3.細(xì)粒度的軟件生命周期管理

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

缺乏細(xì)粒度的軟件生命周期管理

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

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

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

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

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

那么為什么他們失敗了?

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

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

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

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

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

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

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

我們?cè)儐?wèn)了Yang、Kavis等人，他們對(duì)有效管理容器化微服務(wù)的***建議。

1.保持簡(jiǎn)單

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

對(duì)于Johnson來(lái)說(shuō)，KISS和管理哲學(xué)一樣重要，“我們的目標(biāo)是通過(guò)對(duì)棘手問(wèn)題的常識(shí)應(yīng)用來(lái)更快更高效地獲得結(jié)果。

對(duì)于IT團(tuán)隊(duì)來(lái)說(shuō)，這些想法有一個(gè)可見(jiàn)的翻譯，特別是在微服務(wù)和容器方面。

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

2.盡早把管理計(jì)劃落實(shí)到位

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

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

3.選擇一個(gè)編排平臺(tái)

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

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

4.制定一套***限度的運(yùn)營(yíng)能力

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

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

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

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

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

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

McGrath說(shuō)：“如果沒(méi)有CI / CD，微服務(wù)的維護(hù)將會(huì)因?yàn)槭謩?dòng)流程而變得不堪重負(fù)，無(wú)法按預(yù)期進(jìn)行擴(kuò)展，并且最終將比基礎(chǔ)設(shè)施和人力資源中的整體應(yīng)用成本更高。”

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

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

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

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

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