微服務(wù)和容器時(shí)代，研發(fā)還需要運(yùn)維嗎？

IT那活兒發(fā)布于2023-01-11 13:20 / 1671人閱讀

微服務(wù)和容器時(shí)代，研發(fā)與運(yùn)維都面臨諸多挑戰(zhàn)，微服務(wù)在帶來(lái)良好的設(shè)計(jì)和架構(gòu)理念的同時(shí)，也帶來(lái)了運(yùn)維上的額外復(fù)雜性，尤其是在服務(wù)部署和服務(wù)監(jiān)控上。那么，運(yùn)維是如何看待微服務(wù)和容器的呢？傳統(tǒng)的單體應(yīng)用又該如何完成微服務(wù)拆分？如何進(jìn)行微服務(wù)之間的依賴(lài)關(guān)系管理？

單體應(yīng)用 VS 微服務(wù)

單體應(yīng)用存在如下兩個(gè)問(wèn)題：一個(gè)是橫向擴(kuò)展時(shí)需要整體擴(kuò)展，資源分配最大化，不能按需擴(kuò)展和分配資源；另一個(gè)是如果單體中有一個(gè)業(yè)務(wù)模塊出現(xiàn)問(wèn)題，就會(huì)是全局性災(zāi)難，因?yàn)樗袠I(yè)務(wù)跑在同一個(gè)實(shí)例中，發(fā)生異常時(shí)不具備故障隔離性，會(huì)影響整個(gè)業(yè)務(wù)系統(tǒng)，整個(gè)入口都會(huì)存在問(wèn)題。

微服務(wù)的好處：

局部修改，局部更新。當(dāng)運(yùn)維對(duì)一個(gè)單體應(yīng)用進(jìn)行修改時(shí)，可能要先把整個(gè)包給停了，然后再去修改，而微服務(wù)只需逐步修改和更新即可；
故障隔離，非全局。單體應(yīng)用是跑在一起，所以只要一個(gè)模塊有問(wèn)題，其他就都會(huì)有問(wèn)題。而微服務(wù)的故障隔離性、業(yè)務(wù)可持續(xù)性都非常高；
資源利用率高。單體應(yīng)用的資源利用率低，而使用微服務(wù)，可以按需分配資源，資源利用率會(huì)非常高。

微服務(wù)帶來(lái)的復(fù)雜性：

微服務(wù)間較強(qiáng)的依賴(lài)關(guān)系管理。以前單體應(yīng)用是跑在一起，無(wú)依賴(lài)關(guān)系管理，如果拆成微服務(wù)依賴(lài)關(guān)系該如何處理，比如說(shuō)某個(gè)微服務(wù)更新了會(huì)不會(huì)對(duì)整個(gè)系統(tǒng)造成影響。
部署復(fù)雜。單體應(yīng)用是集中式的，就一個(gè)單體跑在一起，部署和管理的時(shí)候非常簡(jiǎn)單，而微服務(wù)是一個(gè)網(wǎng)狀分布的，有很多服務(wù)需要維護(hù)和管理，對(duì)它進(jìn)行部署和維護(hù)的時(shí)候則比較復(fù)雜。
如何更好地利用資源。單體應(yīng)用在資源分配時(shí)是整體分配，擴(kuò)展時(shí)也是整體擴(kuò)展，數(shù)量可控，而在使用微服務(wù)的情況下，需要為每一個(gè)微服務(wù)按需分配資源，那么該為每個(gè)微服務(wù)分配多少資源，啟動(dòng)多少個(gè)實(shí)例呢，這也是非常大的問(wèn)題。
監(jiān)控管理難。以前我們用Java，就是一個(gè)單體應(yīng)用，監(jiān)控和管理非常簡(jiǎn)單，因?yàn)樗褪且粋€(gè)1，但是使用微服務(wù)它就是N個(gè)，監(jiān)控管理變得非常復(fù)雜。另外是微服務(wù)之間還有一個(gè)協(xié)作的問(wèn)題。

基于容器構(gòu)建微服務(wù)架構(gòu)

使用微服務(wù)，第一步是要構(gòu)建一個(gè)一體化的DevOps平臺(tái)。如果你不使用DevOps做微服務(wù)的話，整個(gè)環(huán)境會(huì)變得非常的亂、非常的糟糕。它會(huì)給你的整個(gè)開(kāi)發(fā)、測(cè)試和運(yùn)維增加很多成本，所以第一步我們是提高DevOps的能力，能夠把它的開(kāi)發(fā)、部署和維護(hù)進(jìn)行很完美的結(jié)合，才可以說(shuō)我們真正能夠享受到微服務(wù)架構(gòu)的福利。

容器的出現(xiàn)給微服務(wù)提供了一個(gè)完美的環(huán)境，因?yàn)槲覀兛梢裕?/span>

基于容器做標(biāo)準(zhǔn)化構(gòu)建和持續(xù)集成、持續(xù)交付等。
基于標(biāo)準(zhǔn)工具對(duì)部署在微服務(wù)里面的容器做服務(wù)發(fā)現(xiàn)和管理。
透過(guò)容器的編排工具對(duì)容器進(jìn)行自動(dòng)化的伸縮管理、自動(dòng)化的運(yùn)維管理。

所以說(shuō)，容器的出現(xiàn)和微服務(wù)的發(fā)展是非常相關(guān)的，它們共同發(fā)展，形成了一個(gè)非常好的生態(tài)圈。

持續(xù)集成與持續(xù)發(fā)布

持續(xù)集成的關(guān)鍵是完全的自動(dòng)化，讀取源代碼、編譯、連接、測(cè)試，整個(gè)創(chuàng)建過(guò)程自動(dòng)完成。我們來(lái)看一下如何用Docker、Maven、Jenkins完成持續(xù)集成。

首先是開(kāi)發(fā)人員把程序代碼更新后上傳到Git，然后其他的事情都將由Jenkins自動(dòng)完成。那Jenkins這邊發(fā)生什么了呢？Git在接收到用戶(hù)更新的代碼后，會(huì)把消息和任務(wù)傳遞給Jenkins，然后Jenkins會(huì)自動(dòng)構(gòu)建一個(gè)任務(wù)，下載Maven相關(guān)的軟件包。下載完成后，就開(kāi)始利用Maven Build新的項(xiàng)目包，然后重建Maven容器，構(gòu)建新的Image并Push到Docker私有庫(kù)中。然后刪除正在運(yùn)行的Docker容器，再基于新的鏡像重新把Docker容器拉起來(lái)，自動(dòng)完成集成測(cè)試。整個(gè)過(guò)程都是自動(dòng)的，這樣就簡(jiǎn)化了原本復(fù)雜的集成工作，一天可以集成一次，甚至是多次。

服務(wù)發(fā)現(xiàn)與負(fù)載均衡

服務(wù)發(fā)現(xiàn)與負(fù)載均衡使用的是Kubernetes的架構(gòu)。每一個(gè)微服務(wù)都有一個(gè)IP和PORT，當(dāng)調(diào)用一個(gè)微服務(wù)時(shí)，只需要知道微服務(wù)的IP，而不需要關(guān)心容器的IP，也不需要關(guān)心pod的IP。雖然每個(gè)pod也有IP和PORT，但當(dāng)一個(gè)pod啟動(dòng)時(shí)，就會(huì)把pod的IP和PORT注冊(cè)到服務(wù)發(fā)現(xiàn)模塊，再進(jìn)行負(fù)載均衡。所以當(dāng)多個(gè)pod啟動(dòng)時(shí)，對(duì)于用戶(hù)來(lái)說(shuō)還是只需要知道service的IP，不需要知道后端啟動(dòng)了多少pod、IP是多少，這就解決了網(wǎng)絡(luò)的問(wèn)題。

日志集中式管理

以前單體的情況下，單體的數(shù)量少，日志數(shù)量也相應(yīng)比較少，而在微服務(wù)架構(gòu)下，因?yàn)椴鸱殖闪撕芏辔⒎?wù)，相應(yīng)的日志會(huì)非常多且散，這種情況下需要對(duì)日志進(jìn)行集中的管理。我們可以在每個(gè)容器里跑日志監(jiān)控，把所有日志采集進(jìn)行集中管理和存儲(chǔ)，再通過(guò)簡(jiǎn)易操作的UI界面進(jìn)行索引和查詢(xún)。

監(jiān)控管理

然后就是監(jiān)控方面了。微服務(wù)的量是非常大的，這個(gè)時(shí)候如何有效地監(jiān)控是極其重要的。我們剛開(kāi)始做監(jiān)控的時(shí)候，有幾百個(gè)實(shí)例對(duì)同一個(gè)關(guān)鍵字進(jìn)行監(jiān)控，出故障后會(huì)收到幾百條短信，因?yàn)槊恳粋€(gè)實(shí)例都會(huì)發(fā)一條短信。這時(shí)候嚴(yán)重的致命性的報(bào)警就會(huì)看不到，因?yàn)槭謾C(jī)信息已經(jīng)爆炸了，所以要對(duì)報(bào)警進(jìn)行分級(jí)，精確告警，最重要的是盡量讓故障在發(fā)生之前滅亡。因此，在做監(jiān)控時(shí)要對(duì)故障提前進(jìn)行判斷，先自動(dòng)化處理，再看是否需要人為處理，然后通過(guò)人為的干預(yù)，有效的把故障在發(fā)生之前進(jìn)行滅亡。

但如果所有事情都靠人為去處理，這個(gè)量也是非常大的，所以對(duì)故障進(jìn)行自動(dòng)化隔離和自動(dòng)化處理也很重要。我們?cè)趯?xiě)自動(dòng)化故障處理的時(shí)候研究了很多常見(jiàn)的故障，寫(xiě)了很多算法去判斷，精確到所有的故障，這樣基本的常見(jiàn)的故障和可以策劃處理的故障都可以自動(dòng)化處理掉。

結(jié)語(yǔ)：

技術(shù)發(fā)展到了今天，不管是業(yè)務(wù)規(guī)模，還是機(jī)器數(shù)量都變得異常的龐大，傳統(tǒng)依靠人肉運(yùn)維的方式變得不可取，在微服務(wù)和容器時(shí)代，運(yùn)維人員和研發(fā)人員需要更加依賴(lài)機(jī)器去管理機(jī)器，這也是以后的發(fā)展方向。