運維是如何看待微服務和容器的

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

　　單體應用 VS 微服務

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

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

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

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

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

　　圖 1

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

　　微服務的好處：

　　局部修改，局部更新。當運維對一個單體應用進行修改時，可能要先把整個包給停了，然后再去修改，而微服務只需逐步修改和更新即可；

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

　　資源利用率高。單體應用的資源利用率低，而使用微服務，可以按需分配資源，資源利用率會非常高。

　　微服務帶來的復雜性：

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

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

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

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

　　基于容器構建微服務架構

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