微服務(wù)究竟是“靈丹”還是“毒藥”？

微服務(wù)架構(gòu)是從單體架構(gòu)演化而來的。所謂單體架構(gòu)，指的是整個互聯(lián)網(wǎng)系統(tǒng)所有代碼打包在一個程序中，部署在一個集群上，一個單體應(yīng)用構(gòu)成整個系統(tǒng)。

而微服務(wù)架構(gòu)則是將這個大的應(yīng)用里面的一些模塊拆分出來，這些模塊獨(dú)立部署在一些相對較小的服務(wù)器集群上，應(yīng)用通過遠(yuǎn)程調(diào)用的方式依賴這些獨(dú)立部署的模塊完成業(yè)務(wù)處理。這些被獨(dú)立部署的模塊被稱為微服務(wù)，而這樣的應(yīng)用架構(gòu)也被稱為微服務(wù)架構(gòu)。

應(yīng)該說，模塊化、低耦合一直以來都是軟件設(shè)計(jì)追求的目標(biāo)，獨(dú)立部署的微服務(wù)使模塊之間的依賴關(guān)系更加清晰，隔離得也更好，讓系統(tǒng)更易于開發(fā)、維護(hù)，代表了正確的技術(shù)方向。但是在實(shí)踐中，有時使用了微服務(wù)系統(tǒng)反而變得更加難以開發(fā)、維護(hù)，技術(shù)團(tuán)隊(duì)痛苦不堪，覺得是微服務(wù)的“鍋”，于是主張放棄微服務(wù)，退回到單體架構(gòu)。

那么，究竟該不該使用微服務(wù)？微服務(wù)是“靈丹”還是“毒藥”？

單體架構(gòu)的困難和挑戰(zhàn)

阿里巴巴大約是國內(nèi)最早嘗試微服務(wù)的企業(yè)之一。讓我們先回顧一下這段歷史，看看當(dāng)年阿里巴巴為什么要使用微服務(wù)架構(gòu)？微服務(wù)架構(gòu)能解決什么問題？用好微服務(wù)需要做哪些準(zhǔn)備？

阿里巴巴開始嘗試微服務(wù)架構(gòu)大約是在2008年。在此之前，一個網(wǎng)站就是一個大應(yīng)用，一個用Java開發(fā)的war包就包含了整個應(yīng)用。系統(tǒng)更新時，即使只是更新其中極小的一部分，也要重新打包整個war包，發(fā)布整個系統(tǒng)。

隨著業(yè)務(wù)的不斷發(fā)展，這樣的單體巨無霸系統(tǒng)遇到了越來越多的困難。

1. 編譯、部署困難

一個應(yīng)用系統(tǒng)一個war包，這個war包的大小可能是幾個GB。對于開發(fā)工程師來說，開發(fā)編譯和部署這個war包都是非常困難的，當(dāng)時我用自己的電腦編譯，大約花了半個多小時。工程師在開發(fā)的過程中，即使只改了龐大系統(tǒng)中的一行代碼，也必須重新打包完整的系統(tǒng)才能做開發(fā)測試。對這樣的單體系統(tǒng)進(jìn)行開發(fā)部署和測試都是非常困難的，有時甚至一天都寫不了幾行代碼。

2. 代碼分支管理困難

因?yàn)閱误w應(yīng)用非常龐大，所以代碼模塊也是由多個團(tuán)隊(duì)共同維護(hù)的，但最后還是要編譯成一個單體應(yīng)用，統(tǒng)一發(fā)布。這就要求把各個團(tuán)隊(duì)的代碼合并在一起，這個過程很容易發(fā)生代碼沖突。而合并的時候又是應(yīng)用要發(fā)布的時候，發(fā)布本就是復(fù)雜的過程，再加上代碼合并帶來的風(fēng)險，各種情況糾纏在一起，極易出錯。所以，在單體應(yīng)用時代，每一次應(yīng)用發(fā)布都需要搞到深更半夜。

3. 數(shù)據(jù)庫連接耗盡

對于一個巨型的應(yīng)用而言，因?yàn)橛写罅康挠脩暨M(jìn)行訪問，所以必須部署到大規(guī)模的服務(wù)器集群上，且每個應(yīng)用都需要與數(shù)據(jù)庫建立連接。大量的應(yīng)用服務(wù)器連接到數(shù)據(jù)庫，會對數(shù)據(jù)庫的連接產(chǎn)生巨大的壓力，某些情況下甚至?xí)谋M數(shù)據(jù)庫的連接。

4. 新增業(yè)務(wù)困難

因?yàn)樗械臉I(yè)務(wù)都耦合在一個單一的大系統(tǒng)里，隨著時間的推移，這個系統(tǒng)會變得非常復(fù)雜，想要維護(hù)這樣一個系統(tǒng)是非常困難的。很多新入職的工程師不熟悉業(yè)務(wù)，于是熟悉系統(tǒng)的老員工要加班加點(diǎn)地干活，不熟悉系統(tǒng)的新員工雖然一幫忙就出亂，但也免不了要跟著加班。整個公司熱火朝天地干活，但最后還是常常出故障，新的功能遲遲不能上線。

5. 發(fā)布困難

單體系統(tǒng)一個war包就包含了所有的代碼，新版本發(fā)布的時候，即使跟自己開發(fā)的代碼一點(diǎn)關(guān)系都沒有，但就因?yàn)榘俗约旱拇a，所以也不得不跟著發(fā)布值班，真正更新代碼功能的只有幾個人，他們汗流浹背地處理代碼沖突和修復(fù)發(fā)布Bug，沒有代碼更新的同事則陪著聊天、打瞌睡、打游戲。

這些單體架構(gòu)帶來的問題很多工程師都是有切身體會的。所以，在開始重構(gòu)微服務(wù)架構(gòu)時，雖然也遇到了很多挑戰(zhàn)和困難，但是大家為了自身的利益，還是團(tuán)結(jié)一致，成功完成了微服務(wù)架構(gòu)重構(gòu)。

微服務(wù)框架原理

當(dāng)時，阿里自己開發(fā)了一個微服務(wù)框架重構(gòu)微服務(wù)架構(gòu)，這個微服務(wù)框架就是著名的Dubbo。Dubbo借鑒了此前更早的SOA架構(gòu)方案，即面向服務(wù)的體系架構(gòu)。SOA架構(gòu)如圖27-1所示。

在面向服務(wù)的體系架構(gòu)里面，服務(wù)提供者向注冊中心注冊自己的服務(wù)后，服務(wù)調(diào)用者要到注冊中心去發(fā)現(xiàn)服務(wù)，發(fā)現(xiàn)服務(wù)以后，根據(jù)服務(wù)注冊中心提供的訪問接口和訪問路徑對服務(wù)發(fā)起請求，由服務(wù)的提供者完成請求，返回結(jié)果給調(diào)用者。后來的各種微服務(wù)框架其實(shí)都可以認(rèn)為是SOA架構(gòu)的一種實(shí)現(xiàn)。但是在早期的SOA架構(gòu)實(shí)踐中，WSDL、SOAP這些協(xié)議都比較重，服務(wù)的注冊與發(fā)現(xiàn)描述協(xié)議很復(fù)雜，服務(wù)的調(diào)用效率也比較低。

Dubbo在借鑒SOA架構(gòu)的基礎(chǔ)上進(jìn)行了優(yōu)化，拋棄了SOA一些不必要的規(guī)范約束，使用二進(jìn)制協(xié)議進(jìn)行服務(wù)注冊與調(diào)用，這使得執(zhí)行效率和使用的簡潔性都得到了極大提升。Dubbo架構(gòu)如圖27-2所示。

Dubbo架構(gòu)和SOA架構(gòu)一樣，最核心的組件也是三個，分別是服務(wù)提供者、服務(wù)消費(fèi)者和服務(wù)注冊中心。

顧名思義，服務(wù)的提供者就是微服務(wù)的具體提供者，它通過微服務(wù)容器對外提供服務(wù)，而服務(wù)的消費(fèi)者就是應(yīng)用系統(tǒng)或是其他微服務(wù)。

具體過程是服務(wù)的提供者程序在Dubbo的服務(wù)容器中啟動，通過服務(wù)管理容器向服務(wù)注冊中心進(jìn)行注冊，聲明服務(wù)提供者提供的接口參數(shù)和規(guī)范，并且注冊自己所在服務(wù)器的IP地址和端口。

服務(wù)的消費(fèi)者如果想要調(diào)用某個服務(wù)，只需依賴服務(wù)提供者的接口進(jìn)行編程即可。而服務(wù)接口通過Dubbo框架的代理訪問機(jī)制，調(diào)用Dubbo的服務(wù)框架客戶端，服務(wù)框架客戶端會根據(jù)服務(wù)接口聲明，去注冊中心查找對應(yīng)的服務(wù)提供者啟動在哪些服務(wù)器上，并且將這個服務(wù)器列表返回給客戶端?？蛻舳烁鶕?jù)某種負(fù)載均衡策略，選擇某一個服務(wù)器，通過遠(yuǎn)程通信模塊發(fā)送具體的服務(wù)調(diào)用請求。

服務(wù)調(diào)用請求通過Dubbo底層的遠(yuǎn)程通信模塊，也就是RPC調(diào)用方式，將請求發(fā)送到服務(wù)的提供者服務(wù)器，服務(wù)提供者服務(wù)器收到請求以后，將該請求發(fā)送給服務(wù)提供者程序，執(zhí)行服務(wù)，并將服務(wù)執(zhí)行的結(jié)果通過遠(yuǎn)程調(diào)用通信模塊RPC返回給服務(wù)消費(fèi)者客戶端，服務(wù)消費(fèi)者客戶端將結(jié)果返回給服務(wù)調(diào)用程序，從而完成遠(yuǎn)程服務(wù)的調(diào)用，獲得服務(wù)處理的結(jié)果。

微服務(wù)架構(gòu)的落地實(shí)踐

阿里當(dāng)時進(jìn)行微服務(wù)架構(gòu)重構(gòu)的目標(biāo)比較明確，要解決的問題也是工程師們?nèi)粘ｉ_發(fā)的痛點(diǎn)，大家積極參與其中，所以阿里的微服務(wù)重構(gòu)過程還是比較成功的。

即使在單體時代，war包內(nèi)的模塊關(guān)系也是比較清晰的。所以在重構(gòu)微服務(wù)時，只需要對這些模塊進(jìn)行較小的改動，進(jìn)行微服務(wù)部署就可以了。這也是阿里微服務(wù)重構(gòu)成功的另外一個重要因素。

那么，回到本章開始的問題，為什么有些企業(yè)會覺得用了微服務(wù)之后，反而問題更多了呢？

有些實(shí)施微服務(wù)的技術(shù)團(tuán)隊(duì)，既沒有達(dá)成共識，又沒有做好模塊劃分，模塊的職責(zé)邊界不清，依賴關(guān)系混亂，很多單體架構(gòu)下隱藏的問題到了微服務(wù)上反而變得更加嚴(yán)重，于是有人覺得是微服務(wù)這個技術(shù)有問題。

微服務(wù)不同于分布式緩存、分布式消息隊(duì)列或者分布式數(shù)據(jù)庫這些技術(shù)。這些技術(shù)相對來說是比較“純粹”的，和業(yè)務(wù)的耦合關(guān)系并不大，使用這些技術(shù)的場景也比較明確。而微服務(wù)本身和業(yè)務(wù)強(qiáng)相關(guān)，如果業(yè)務(wù)關(guān)系沒梳理好，模塊設(shè)計(jì)不清晰，使用微服務(wù)架構(gòu)很可能得不償失，帶來各種問題。

很多技術(shù)團(tuán)隊(duì)在實(shí)施微服務(wù)的時候，把關(guān)注的重點(diǎn)放在了微服務(wù)技術(shù)框架上。事實(shí)上，微服務(wù)技術(shù)框架作為一個工具對于成功實(shí)施微服務(wù)不是最重要的，最重要的是使用微服務(wù)究竟能得到什么，也就是自己的需求是什么。實(shí)施微服務(wù)的關(guān)注點(diǎn)應(yīng)該是如圖27-3所示的倒三角模型。

首先明確自己的需求，即我們到底想用微服務(wù)達(dá)到什么樣的目的。需求清晰了，再去考慮具體要實(shí)現(xiàn)的價值，并根據(jù)價值構(gòu)建我們的設(shè)計(jì)原則，根據(jù)設(shè)計(jì)原則尋找最佳實(shí)踐，最后根據(jù)實(shí)踐去選擇最合適的工具。

如果先找到一個工具，然后用工具硬往上套需求，只會導(dǎo)致技術(shù)用不好，業(yè)務(wù)也做不好，所有人都疲憊不堪，事情變得一團(tuán)糟，最后還要反過來找技術(shù)的毛病。

小結(jié)

微服務(wù)和業(yè)務(wù)的關(guān)系是非常緊密的，僅僅用好微服務(wù)技術(shù)框架是無法成功實(shí)施微服務(wù)的。成功實(shí)施微服務(wù)最重要的是做好業(yè)務(wù)的模塊化設(shè)計(jì)，模塊之間要低耦合、高聚合，模塊之間的依賴關(guān)系要清晰簡單。只有實(shí)現(xiàn)這樣的模塊化設(shè)計(jì)，才能構(gòu)建出良好的微服務(wù)架構(gòu)。如果系統(tǒng)本身就是一團(tuán)糟，強(qiáng)行將它們拆分在不同的微服務(wù)里，只會使系統(tǒng)變得更加混亂。

本文摘自機(jī)械工業(yè)出版出版的《架構(gòu)師的自我修煉:技術(shù)、架構(gòu)和未來》一書，作者李智慧，經(jīng)出版方授權(quán)發(fā)布。

推薦閱讀

 

《架構(gòu)師的自我修煉：技術(shù)、架構(gòu)和未來》從四個方面，全方位闡述了架構(gòu)師必須具備的各項(xiàng)知識。本書既包含了成為一個軟件架構(gòu)師必須具備的各種知識技能體系，也包含了修煉成為一個架構(gòu)師的學(xué)習(xí)成長思考。閱讀本書，相信您從中不但可以領(lǐng)會各種技術(shù)的內(nèi)在聯(lián)系，也可以領(lǐng)悟到更深刻的技術(shù)和成長之道。

直播預(yù)告

成為架構(gòu)師是很多程序員的夢想，如何才能成為架構(gòu)師呢？成為架構(gòu)師需要掌握哪些技術(shù)能力呢？如何融會貫通所有這些知識，信手拈來運(yùn)用到自己的架構(gòu)設(shè)計(jì)中呢？

由同程旅行首席架構(gòu)師、《架構(gòu)師的自我修煉：技術(shù)、架構(gòu)和未來》一書作者李智慧為你梳理在職業(yè)進(jìn)階的道路上必須牢固掌握的各種技術(shù)技能，幫助你建立起自己的知識體系。