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

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

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

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

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

微服務(wù)的好處：

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

微服務(wù)帶來的復雜性：

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

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

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

容器的出現(xiàn)給微服務(wù)提供了一個完美的環(huán)境，因為我們可以：

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

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

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

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

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

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

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

日志集中式管理

以前單體的情況下，單體的數(shù)量少，日志數(shù)量也相應比較少，而在微服務(wù)架構(gòu)下，因為拆分成了很多微服務(wù)，相應的日志會非常多且散，這種情況下需要對日志進行集中的管理。我們可以在每個容器里跑日志監(jiān)控，把所有日志采集進行集中管理和存儲，再通過簡易操作的UI界面進行索引和查詢。

監(jiān)控管理

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

但如果所有事情都靠人為去處理，這個量也是非常大的，所以對故障進行自動化隔離和自動化處理也很重要。我們在寫自動化故障處理的時候研究了很多常見的故障，寫了很多算法去判斷，精確到所有的故障，這樣基本的常見的故障和可以策劃處理的故障都可以自動化處理掉。

結(jié)語：

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