運(yùn)維是如何看待微服務(wù)和容器的
推薦 + 挑錯(cuò) + 收藏(0) + 用戶評(píng)論（0）
微服務(wù)在帶來良好的設(shè)計(jì)和架構(gòu)理念的同時(shí)，也帶來了運(yùn)維上的額外復(fù)雜性，尤其是在服務(wù)部署和服務(wù)監(jiān)控上。那么，運(yùn)維是如何看待微服務(wù)和容器的呢？傳統(tǒng)的單體應(yīng)用又該如何完成微服務(wù)拆分？如何進(jìn)行微服務(wù)之間的依賴關(guān)系管理？對(duì)此，陳愛珍帶來了她的分享。以下是正文：
單體應(yīng)用 VS 微服務(wù)
讓我們先從運(yùn)維的真實(shí)場(chǎng)景出發(fā)，來看一下單體應(yīng)用存在的問題。這里先分享兩個(gè)真實(shí)的生產(chǎn)案例：
案例一是某核心業(yè)務(wù)系統(tǒng)，所有的業(yè)務(wù)邏輯代碼都打包在同一個(gè)WAR包里部署，運(yùn)行了將近幾百個(gè)同構(gòu)的實(shí)例在虛擬機(jī)上。某次因?yàn)閼?yīng)用包中的一個(gè)功能模塊出現(xiàn)異常，導(dǎo)致實(shí)例掛起，整個(gè)應(yīng)用都不能用了。因?yàn)樗且粋€(gè)單體，所以盡管有幾百個(gè)實(shí)例在運(yùn)行，但是這幾百個(gè)實(shí)例都是異常的。業(yè)務(wù)系統(tǒng)是經(jīng)過多年建設(shè)起來的，排查起來也很復(fù)雜，最終整個(gè)業(yè)務(wù)系統(tǒng)癱瘓了近六個(gè)小時(shí)才恢復(fù)。同時(shí)，因?yàn)橛卸鄠€(gè)前臺(tái)系統(tǒng)也調(diào)用了這個(gè)后臺(tái)系統(tǒng)，導(dǎo)致所有要調(diào)用的前臺(tái)系統(tǒng)也都全部癱瘓了。設(shè)想一下，如果這個(gè)場(chǎng)景使用的是微服務(wù)架構(gòu)，每個(gè)微服務(wù)都是獨(dú)立部署的，那影響的也只是有異常的微服務(wù)和其他相關(guān)聯(lián)的服務(wù)，而不會(huì)導(dǎo)致整個(gè)業(yè)務(wù)系統(tǒng)都不能使用。
另外的案例是一個(gè)客服系統(tǒng)，這個(gè)系統(tǒng)有一個(gè)特點(diǎn)，早上八點(diǎn)的時(shí)候會(huì)有大量的客服登錄。這個(gè)登錄點(diǎn)是全天中業(yè)務(wù)并發(fā)量最高的時(shí)間點(diǎn)，登錄時(shí)系統(tǒng)需要讀取一些客戶信息，加載到內(nèi)存。后來一到早上客服登錄時(shí)，系統(tǒng)經(jīng)常出現(xiàn)內(nèi)存溢出，進(jìn)而導(dǎo)致整個(gè)客服系統(tǒng)都用不了。當(dāng)時(shí)系統(tǒng)應(yīng)對(duì)這種場(chǎng)景做架構(gòu)冗余時(shí)，并不是根據(jù)單獨(dú)的業(yè)務(wù)按需進(jìn)行擴(kuò)展，而是按照單體應(yīng)用的長板進(jìn)行冗余。比如說早上八點(diǎn)并發(fā)量最高，單點(diǎn)登陸模塊業(yè)務(wù)需求非常大，為適應(yīng)這個(gè)時(shí)間點(diǎn)這個(gè)模塊的業(yè)務(wù)壓力，系統(tǒng)會(huì)由原來的八個(gè)實(shí)例擴(kuò)展到十六個(gè)實(shí)例，這時(shí)的擴(kuò)展是基于整個(gè)系統(tǒng)的。但事實(shí)上，在其他時(shí)間段，這個(gè)單點(diǎn)登陸模塊基本不使用，且監(jiān)控的數(shù)據(jù)顯示，主機(jī)的資源使用情況基本在40%以下，造成了很大的資源浪費(fèi)。所以在一個(gè)大型的業(yè)務(wù)系統(tǒng)中，每個(gè)服務(wù)的并發(fā)壓力不一樣，如果都按壓力最大的模塊進(jìn)行整體擴(kuò)展，就會(huì)造成資源的浪費(fèi)，而在微服務(wù)的模式下，每個(gè)服務(wù)都是按自身壓力進(jìn)行擴(kuò)展的，就可以有效的提高資源利用率。
從這兩個(gè)例子中，我們可以看出，單體應(yīng)用存在如下兩個(gè)問題：一個(gè)是橫向擴(kuò)展時(shí)需要整體擴(kuò)展，資源分配最大化，不能按需擴(kuò)展和分配資源；另一個(gè)是如果單體中有一個(gè)業(yè)務(wù)模塊出現(xiàn)問題，就會(huì)是全局性災(zāi)難，因?yàn)樗袠I(yè)務(wù)跑在同一個(gè)實(shí)例中，發(fā)生異常時(shí)不具備故障隔離性，會(huì)影響整個(gè)業(yè)務(wù)系統(tǒng)，整個(gè)入口都會(huì)存在問題。
因此，我們當(dāng)時(shí)考慮把綜合業(yè)務(wù)拆分，進(jìn)行更好的資源分配和故障隔離。
圖 1
下面我們看一下單體應(yīng)用和微服務(wù)的對(duì)比，如圖1所示。這里從微服務(wù)帶來的好處和額外的復(fù)雜性來講。
微服務(wù)的好處：
局部修改，局部更新。當(dāng)運(yùn)維對(duì)一個(gè)單體應(yīng)用進(jìn)行修改時(shí)，可能要先把整個(gè)包給停了，然后再去修改，而微服務(wù)只需逐步修改和更新即可；
故障隔離，非全局。單體應(yīng)用是跑在一起，所以只要一個(gè)模塊有問題，其他就都會(huì)有問題。而微服務(wù)的故障隔離性、業(yè)務(wù)可持續(xù)性都非常高；
資源利用率高。單體應(yīng)用的資源利用率低，而使用微服務(wù)，可以按需分配資源，資源利用率會(huì)非常高。
微服務(wù)帶來的復(fù)雜性：
微服務(wù)間較強(qiáng)的依賴關(guān)系管理。以前單體應(yīng)用是跑在一起，無依賴關(guān)系管理，如果拆成微服務(wù)依賴關(guān)系該如何處理，比如說某個(gè)微服務(wù)更新了會(huì)不會(huì)對(duì)整個(gè)系統(tǒng)造成影響。
部署復(fù)雜。單體應(yīng)用是集中式的，就一個(gè)單體跑在一起，部署和管理的時(shí)候非常簡單，而微服務(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í)例呢，這也是非常大的問題。
監(jiān)控管理難。以前我們用Java，就是一個(gè)單體應(yīng)用，監(jiān)控和管理非常簡單，因?yàn)樗褪且粋€(gè)1，但是使用微服務(wù)它就是N個(gè)，監(jiān)控管理變得非常復(fù)雜。另外是微服務(wù)之間還有一個(gè)協(xié)作的問題。
基于容器構(gòu)建微服務(wù)架構(gòu)
使用微服務(wù)，第一步是要構(gòu)建一個(gè)一體化的DevOps平臺(tái)，如圖2。如果你不使用DevOps做微服務(wù)的話，整個(gè)環(huán)境會(huì)變得非常的亂、非常的糟糕。它會(huì)給你的整個(gè)開發(fā)、測(cè)試和運(yùn)維增加很多成本，所以第一步我們是提高DevOps的能力，能夠把它的開發(fā)、部署和維護(hù)進(jìn)行很完美的結(jié)合，才可以說我們真正能夠享受到微服務(wù)架構(gòu)的福利。
非常好我支持^.^
(0) 0%
不好我反對(duì)
(0) 0%