運維是如何看待微服務(wù)和容器的

　　微服務(wù)在帶來良好的設(shè)計和架構(gòu)理念的同時，也帶來了運維上的額外復(fù)雜性，尤其是在服務(wù)部署和服務(wù)監(jiān)控上。那么，運維是如何看待微服務(wù)和容器的呢？傳統(tǒng)的單體應(yīng)用又該如何完成微服務(wù)拆分？如何進(jìn)行微服務(wù)之間的依賴關(guān)系管理？對此，陳愛珍帶來了她的分享。以下是正文：

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

　　讓我們先從運維的真實場景出發(fā)，來看一下單體應(yīng)用存在的問題。這里先分享兩個真實的生產(chǎn)案例：

　　案例一是某核心業(yè)務(wù)系統(tǒng)，所有的業(yè)務(wù)邏輯代碼都打包在同一個WAR包里部署，運行了將近幾百個同構(gòu)的實例在虛擬機上。某次因為應(yīng)用包中的一個功能模塊出現(xiàn)異常，導(dǎo)致實例掛起，整個應(yīng)用都不能用了。因為它是一個單體，所以盡管有幾百個實例在運行，但是這幾百個實例都是異常的。業(yè)務(wù)系統(tǒng)是經(jīng)過多年建設(shè)起來的，排查起來也很復(fù)雜，最終整個業(yè)務(wù)系統(tǒng)癱瘓了近六個小時才恢復(fù)。同時，因為有多個前臺系統(tǒng)也調(diào)用了這個后臺系統(tǒng)，導(dǎo)致所有要調(diào)用的前臺系統(tǒng)也都全部癱瘓了。設(shè)想一下，如果這個場景使用的是微服務(wù)架構(gòu)，每個微服務(wù)都是獨立部署的，那影響的也只是有異常的微服務(wù)和其他相關(guān)聯(lián)的服務(wù)，而不會導(dǎo)致整個業(yè)務(wù)系統(tǒng)都不能使用。

　　另外的案例是一個客服系統(tǒng)，這個系統(tǒng)有一個特點，早上八點的時候會有大量的客服登錄。這個登錄點是全天中業(yè)務(wù)并發(fā)量最高的時間點，登錄時系統(tǒng)需要讀取一些客戶信息，加載到內(nèi)存。后來一到早上客服登錄時，系統(tǒng)經(jīng)常出現(xiàn)內(nèi)存溢出，進(jìn)而導(dǎo)致整個客服系統(tǒng)都用不了。當(dāng)時系統(tǒng)應(yīng)對這種場景做架構(gòu)冗余時，并不是根據(jù)單獨的業(yè)務(wù)按需進(jìn)行擴展，而是按照單體應(yīng)用的長板進(jìn)行冗余。比如說早上八點并發(fā)量最高，單點登陸模塊業(yè)務(wù)需求非常大，為適應(yīng)這個時間點這個模塊的業(yè)務(wù)壓力，系統(tǒng)會由原來的八個實例擴展到十六個實例，這時的擴展是基于整個系統(tǒng)的。但事實上，在其他時間段，這個單點登陸模塊基本不使用，且監(jiān)控的數(shù)據(jù)顯示，主機的資源使用情況基本在40%以下，造成了很大的資源浪費。所以在一個大型的業(yè)務(wù)系統(tǒng)中，每個服務(wù)的并發(fā)壓力不一樣，如果都按壓力最大的模塊進(jìn)行整體擴展，就會造成資源的浪費，而在微服務(wù)的模式下，每個服務(wù)都是按自身壓力進(jìn)行擴展的，就可以有效的提高資源利用率。

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

　　因此，我們當(dāng)時考慮把綜合業(yè)務(wù)拆分，進(jìn)行更好的資源分配和故障隔離。

　　圖 1

　　下面我們看一下單體應(yīng)用和微服務(wù)的對比，如圖1所示。這里從微服務(wù)帶來的好處和額外的復(fù)雜性來講。

　　微服務(wù)的好處：

　　局部修改，局部更新。當(dāng)運維對一個單體應(yīng)用進(jìn)行修改時，可能要先把整個包給停了，然后再去修改，而微服務(wù)只需逐步修改和更新即可；

　　故障隔離，非全局。單體應(yīng)用是跑在一起，所以只要一個模塊有問題，其他就都會有問題。而微服務(wù)的故障隔離性、業(yè)務(wù)可持續(xù)性都非常高；

　　資源利用率高。單體應(yīng)用的資源利用率低，而使用微服務(wù)，可以按需分配資源，資源利用率會非常高。

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

　　微服務(wù)間較強的依賴關(guān)系管理。以前單體應(yīng)用是跑在一起，無依賴關(guān)系管理，如果拆成微服務(wù)依賴關(guān)系該如何處理，比如說某個微服務(wù)更新了會不會對整個系統(tǒng)造成影響。

　　部署復(fù)雜。單體應(yīng)用是集中式的，就一個單體跑在一起，部署和管理的時候非常簡單，而微服務(wù)是一個網(wǎng)狀分布的，有很多服務(wù)需要維護和管理，對它進(jìn)行部署和維護的時候則比較復(fù)雜。

　　如何更好地利用資源。單體應(yīng)用在資源分配時是整體分配，擴展時也是整體擴展，數(shù)量可控，而在使用微服務(wù)的情況下，需要為每一個微服務(wù)按需分配資源，那么該為每個微服務(wù)分配多少資源，啟動多少個實例呢，這也是非常大的問題。

　　監(jiān)控管理難。以前我們用Java，就是一個單體應(yīng)用，監(jiān)控和管理非常簡單，因為它就是一個1，但是使用微服務(wù)它就是N個，監(jiān)控管理變得非常復(fù)雜。另外是微服務(wù)之間還有一個協(xié)作的問題。

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

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