建站
咨詢
售后
建站咨詢
新聞中心
容器和微服務(wù)是不是天生一對(duì)?容器化環(huán)境是否能更好地實(shí)施微服務(wù)?本文作者走訪了數(shù)位親身實(shí)踐者，給出了一些進(jìn)行容器化微服務(wù)管理的6大建議。如果您也在評(píng)估考慮微服務(wù)技術(shù)，此文不要錯(cuò)過。
網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、重慶小程序開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了南樂免費(fèi)建站歡迎大家使用！
一、微服務(wù)的悖論
Gianna作為高級(jí)軟件工程師加入了Avidoo公司，這是一家生產(chǎn)力平臺(tái)。在與其他團(tuán)隊(duì)的會(huì)議上，她提出了微服務(wù)的問題，以及團(tuán)隊(duì)是否開始采用。她立即得到了強(qiáng)烈的反應(yīng)。
拜倫表示：“我們嘗試過采用微服務(wù)，但是它們不起作用。
“這帶來(lái)了可怕的混亂!”另一位同事補(bǔ)充說。
Gianna三次眨巴眼睛，期待著某種闡述，但沒有一個(gè)往下接著說。
Gianna沉默了一會(huì)兒，問：“發(fā)生了什么事?
“起初很棒。每次我們被要求做新的東西時(shí)，我們都可以添加一個(gè)服務(wù)，并使用想要實(shí)驗(yàn)的任何語(yǔ)言和框架。我們將REST API 公布在需要與之協(xié)作或在其數(shù)據(jù)庫(kù)上工作的系統(tǒng)上。但過了一段時(shí)間，事情開始越來(lái)越頻繁地割裂，開發(fā)速度放慢了。 Gianna嘆了口氣。聽起來(lái)像她的團(tuán)隊(duì)一直在建立一個(gè)分布式的巨石應(yīng)用，而他們打算建立的是微服務(wù)。
分布式巨石應(yīng)用和其他龐然大物
Gianna所遇到的問題太常見了。微服務(wù)是靈丹妙藥，IT經(jīng)理和工程師傾向于區(qū)分哪些優(yōu)勢(shì)與他們的組織相適應(yīng)。
卻忘記了天下沒有免費(fèi)的午餐這件事。除了優(yōu)勢(shì)之外，精心打造的微服務(wù)架構(gòu)也有被微辭的一面。沒有任何“錯(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è)特性。
利用單一專業(yè)團(tuán)隊(duì)創(chuàng)造價(jià)值
微服務(wù)通過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è)功能通常依賴于另一個(gè)。在大多數(shù)環(huán)境中，通信通過REST接口，按需和pull-based。當(dāng)這種互動(dòng)是關(guān)鍵任務(wù)時(shí)，依靠這種通信的服務(wù)要么必須有合理的fall-back，要么就會(huì)失敗。這種不健康的模式常常被系統(tǒng)運(yùn)行狀況檢查所證明，如果系統(tǒng)的一個(gè)依賴性不健康，系統(tǒng)運(yùn)行就會(huì)失敗。除了導(dǎo)致部署順序難以管理之外，它還說明了系統(tǒng)依賴性的困難。
運(yùn)行時(shí)依賴關(guān)系
使用正確的軟件架構(gòu)(如event sourcing)，可能補(bǔ)充CQRS，可以完全消除大多數(shù)功能之間的運(yùn)行時(shí)依賴。這主要是由于從pull-based系統(tǒng)向push-based系統(tǒng)的轉(zhuǎn)變。
3.細(xì)粒度的軟件生命周期管理
開發(fā)和業(yè)務(wù)人員一個(gè)共同的愿望是，盡快用新程序替換應(yīng)用程序中的某個(gè)功能。無(wú)論是因?yàn)橐蟾淖兓蛘咧貙?，又或由于緊張的上市周期需求而導(dǎo)致的技術(shù)債務(wù)，都使得開發(fā)速度落后了。有人可能天真地認(rèn)為，這些是可以快速被替代的，但其實(shí)不然。經(jīng)常更換功能導(dǎo)致不得不對(duì)其所依賴的許多系統(tǒng)進(jìn)行更改，反之亦然。
缺乏細(xì)粒度的軟件生命周期管理
通過高度調(diào)節(jié)系統(tǒng)間通信，可以完全切換一個(gè)或多個(gè)功能，而不必觸發(fā)任何依賴系統(tǒng)。
4.靈活的技術(shù)選擇
不可否認(rèn)，這是一個(gè)棘手的問題。在需求或個(gè)人興趣的推動(dòng)下，入職和培訓(xùn)員工切換到通用技術(shù)有助于團(tuán)隊(duì)間的流動(dòng)性。但是對(duì)于使用不同技術(shù)的幾個(gè)部門的員工，坦白地說，這可能導(dǎo)致大規(guī)模的罷工。
迫使技術(shù)做出選擇
只要這些技術(shù)可以集成到自動(dòng)化測(cè)試和部署工作流程中，一個(gè)團(tuán)隊(duì)就可以保持自己的技術(shù)選擇。為什么要改變一個(gè)團(tuán)結(jié)在對(duì)C#所有東西都非常熱愛的勝利團(tuán)隊(duì)呢?只要他們能夠產(chǎn)出符合平臺(tái)監(jiān)控，日志記錄和通信規(guī)則的組件。
那么為什么他們失敗了?
因?yàn)椴恢缿?yīng)該如何去做微服務(wù)。采用微服務(wù)并不會(huì)失敗，因?yàn)槿藗儾恢廊绾稳プ?，他們?jīng)常不記得首先要解決什么問題。與其他任何決定一樣，采用微服務(wù)會(huì)帶來(lái)一些成本。軟件架構(gòu)師往往會(huì)忘記，他們不應(yīng)該幫助企業(yè)的管理者采用微服務(wù)，而應(yīng)該幫助他們解決真正的業(yè)務(wù)問題。恰當(dāng)?shù)睾饬窟@些方面的成本和收益對(duì)企業(yè)的需求至關(guān)重要。
二、微服務(wù)和容器：6大長(zhǎng)期管理技巧
部署基于容器的微服務(wù)僅僅是個(gè)開始，如何有效管理它呢?在我們最近發(fā)布的有關(guān)微服務(wù)和容器入門的文章中，Cloud Technology Partners公司副總裁兼***云架構(gòu)師 Mike Kavis分享了一個(gè)好消息：“部署容器非常容易。
他言簡(jiǎn)意賅的說：“盡管部署容器很容易，但是要多思考這些系統(tǒng)的運(yùn)維。”
你可以用容器化的微服務(wù)深入到生產(chǎn)環(huán)境，但大多數(shù)專家不會(huì)推薦它，特別是如果這是你***次使用這個(gè)強(qiáng)大的技術(shù)。
基于容器的微服務(wù)有相當(dāng)多的優(yōu)勢(shì)：正如紅帽技術(shù)布道者(Gordon Haff)最近寫到的：“即使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說：“***天之后，所有事情都變得更加復(fù)雜。
我們?cè)儐柫薡ang、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)說，KISS和管理哲學(xué)一樣重要，“我們的目標(biāo)是通過對(duì)棘手問題的常識(shí)應(yīng)用來(lái)更快更高效地獲得結(jié)果。
對(duì)于IT團(tuán)隊(duì)來(lái)說，這些想法有一個(gè)可見的翻譯，特別是在微服務(wù)和容器方面。
“為確保今后的成功運(yùn)營(yíng)，讓每個(gè)微服務(wù)做一件事，做得非常好。不要將附加功能擴(kuò)大到現(xiàn)有的執(zhí)行良好的微服務(wù)里?！?/p>
2.盡早把管理計(jì)劃落實(shí)到位
微服務(wù)和容器可以實(shí)現(xiàn)更快，更靈活，更彈性，響應(yīng)速度更快的軟件團(tuán)隊(duì)。但首要的事情是，在部署到生產(chǎn)之前制定一個(gè)計(jì)劃。這樣一個(gè)計(jì)劃的范例框架如下：
開發(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說?！袄?，一旦微服務(wù)不報(bào)告或者正在被超載，就可以用一個(gè)新服務(wù)替換或者被復(fù)制?！?/p>
4.制定一套***限度的運(yùn)營(yíng)能力
一個(gè)容器管理平臺(tái)不會(huì)為你做所有的工作。Retriever Communications***技術(shù)官Nic Grange 說，除了像Kubernetes這樣的編排系統(tǒng)之外，還需要確保每個(gè)容器化的微服務(wù)都遵循“***限度的運(yùn)營(yíng)能力”，以便在這樣的環(huán)境下運(yùn)行良好。他提供了以下這些功能的關(guān)鍵示例列表：
編排系統(tǒng)需要能夠訪問每個(gè)微服務(wù)上的API，確定它是否準(zhǔn)備好接收流量，以及是否健康。需要告知微服務(wù)何時(shí)正常關(guān)閉的方法。需要微服務(wù)公開指標(biāo)和日志記錄。在大多數(shù)情況下，微服務(wù)需要能夠水平擴(kuò)展，并且在某些情況下具備集群意識(shí)。
Grange也為開發(fā)人員分享了一些好消息：特定語(yǔ)言的微服務(wù)模板庫(kù)(如go-kit for Go)和dropwizard for Java，可以節(jié)省大量的開發(fā)這些***功能的前期工作。
Grange說：“這些讓開發(fā)人員更容易做正確的事情，獲得許多開箱即用的功能，而不必編寫更多的代碼。
5.實(shí)施持續(xù)集成和持續(xù)交付
Sungard Availability Services CTO& 高級(jí)架構(gòu)師 Kevin McGrath 表示，持續(xù)集成和持續(xù)交付實(shí)踐對(duì)于基于容器的微服務(wù)的長(zhǎng)期管理是一個(gè)巨大的好處，尤其是作為支撐企業(yè)編排工具的基礎(chǔ)。
McGrath說：“如果沒有CI / CD，微服務(wù)的維護(hù)將會(huì)因?yàn)槭謩?dòng)流程而變得不堪重負(fù)，無(wú)法按預(yù)期進(jìn)行擴(kuò)展，并且最終將比基礎(chǔ)設(shè)施和人力資源中的整體應(yīng)用成本更高?！?/p>
隨著時(shí)間的推移，CI / CD將幫助團(tuán)隊(duì)釋放編排或管理工具的潛力，尤其是在管理如何在主機(jī)池中分配CPU，內(nèi)存和存儲(chǔ)時(shí)。
McGrath解釋說：“一旦CI / CD成為產(chǎn)品生命周期一個(gè)自然的組成部分，管理系統(tǒng)就非常好，它們處理各種基礎(chǔ)架構(gòu)需求，并將其作為工程師的邏輯配置參數(shù)?！皩?duì)于運(yùn)維來(lái)說，要全面了解主機(jī)，容器和服務(wù)的資源消耗情況，以便更好地了解需要更多資源的位置。當(dāng)服務(wù)不再與特定的基礎(chǔ)設(shè)施綁定，而是與基礎(chǔ)設(shè)施需求相聯(lián)系時(shí)，這一點(diǎn)非常重要?！?/p>
6.不斷重新審視并重新投資業(yè)務(wù)
容器和微服務(wù)不是一勞永逸的技術(shù)。DigitalOcean公司的工程經(jīng)理 Mac Browning 建議說，為了正確使用他們，需要不斷在如何運(yùn)行基于容器的微服務(wù)上進(jìn)行投資。這個(gè)建議適用于企業(yè)的人員、流程和工具。編排平臺(tái)是一個(gè)好的開始。
Browning說：“如果完全投資并使用像Kubernetes這樣的編排平臺(tái)，那就意味著要花時(shí)間和資源來(lái)跟上項(xiàng)目和更新，并在自己的部署中體現(xiàn)這些變化?！坝捎谄髽I(yè)微服務(wù)現(xiàn)在集中運(yùn)行，這項(xiàng)投資將對(duì)所有要運(yùn)行的服務(wù)產(chǎn)生積極影響，而不是一個(gè)或兩個(gè)特定的單一服務(wù)?！?/p>
本文標(biāo)題：號(hào)稱“天生一對(duì)”的容器+微服務(wù)，能躲開微服務(wù)的悖論陷阱嗎？
當(dāng)前URL：http://www.5511xx.com/article/cojcdce.html
