微服務(wù)是當(dāng)前軟件開發(fā)領(lǐng)域的技術(shù)熱點(diǎn)。不過，隨著云原生技術(shù)的推廣以及大量微服務(wù)的落地，反微服務(wù)的聲音越來越響亮。特別是今年 Istio 1.5 版本發(fā)布，其控制面由原來的多個(gè)微服務(wù)組件合并成了一個(gè)單體應(yīng)用，極大地簡(jiǎn)化了架構(gòu)以及部署運(yùn)維的復(fù)雜性，獲得了一致好評(píng)，社區(qū)中對(duì)微服務(wù)模式質(zhì)疑的聲音也接連不斷。

那么，微服務(wù)到底能給業(yè)務(wù)帶來哪些好處呢？在云原生時(shí)代又該如何更合理地落地微服務(wù)呢？

架構(gòu)沒有好壞優(yōu)劣之分，只有適合與不適合。但將微服務(wù)架構(gòu)與單體架構(gòu)進(jìn)行比較，就會(huì)發(fā)現(xiàn)微服務(wù)具有以下優(yōu)點(diǎn)：

首先，微服務(wù)獨(dú)立運(yùn)行，以進(jìn)程方式隔離，能夠有效控制故障范圍，讓架構(gòu)更可靠。

其次，微服務(wù)架構(gòu)因?yàn)楣收媳挥行Ц綦x，整體可用性更高，降低了單點(diǎn)故障對(duì)整體的影響。

再者，微服務(wù)粒度更小，架構(gòu)演進(jìn)的影響面也更小，不需要大規(guī)模重構(gòu)，只需調(diào)整個(gè)別微服務(wù)就行。

然后，微服務(wù)架構(gòu)可以實(shí)現(xiàn)以服務(wù)為粒度，通過接口共享重用，可重用性更高。接著，微服務(wù)架構(gòu)能夠根據(jù)服務(wù)對(duì)資源的要求以服務(wù)為粒度進(jìn)行擴(kuò)展，可擴(kuò)展性更靈活。最后，服務(wù)拆分后，各個(gè)服務(wù)可以獨(dú)立并行開發(fā)、測(cè)試、部署，交付效率大幅提升，產(chǎn)品更新?lián)Q代速度加快，用戶體驗(yàn)也更好。

圖片

1. 團(tuán)隊(duì)調(diào)整

團(tuán)隊(duì)需要重新組建，要以服務(wù)作為核心，按照業(yè)務(wù)領(lǐng)域來劃分全功能團(tuán)隊(duì)，同時(shí)對(duì)原有的研發(fā)流程和決策機(jī)制進(jìn)行改變。比如，要倡導(dǎo)敏捷文化、做到快速迭代，進(jìn)行更多的自動(dòng)化測(cè)試，并且加強(qiáng)代碼審查（Code Review）等工作。此外，微服務(wù)框架能夠?qū)Ψ植际綀?chǎng)景下的一些常用能力（如負(fù)載均衡、容錯(cuò)、遠(yuǎn)程通信等能力）進(jìn)行封裝和抽象，這樣開發(fā)人員就可以快速開發(fā)出高質(zhì)量的服務(wù)了。所以，在采用微服務(wù)之前，應(yīng)該先進(jìn)行微服務(wù)架構(gòu)的選型、學(xué)習(xí)和試用工作，使整個(gè)團(tuán)隊(duì)儲(chǔ)備一定的微服務(wù)相關(guān)知識(shí)。

2. 基礎(chǔ)設(shè)施建設(shè)

基礎(chǔ)設(shè)施即代碼，它能通過編程來管理虛擬機(jī)或容器，無需手動(dòng)配置和更新各個(gè)硬件，這讓基礎(chǔ)設(shè)施富有彈性，能夠快速、高效且準(zhǔn)確地進(jìn)行重復(fù)性操作。開發(fā)人員利用同一套代碼或配置，就能部署并管理數(shù)量眾多的物理機(jī)。

此外，當(dāng)服務(wù)數(shù)量增多、交付頻繁時(shí)，故障次數(shù)可能大幅增加，所以需要構(gòu)建全面的監(jiān)控體系來發(fā)現(xiàn)故障并及時(shí)處理。在生產(chǎn)環(huán)境出現(xiàn)問題時(shí)，還需對(duì)故障進(jìn)行分級(jí)，評(píng)估影響范圍，再分配給相應(yīng)負(fù)責(zé)人。

微服務(wù)架構(gòu)的一大優(yōu)勢(shì)是快速交付，這既體現(xiàn)在服務(wù)粒度更小，也體現(xiàn)在整個(gè)流程更加快速。因此需要打造基于自動(dòng)化的工具鏈，以流水線交付的方式將整個(gè) DevOps 流程串聯(lián)起來。這樣一來，小團(tuán)隊(duì)就可以基于服務(wù)進(jìn)行獨(dú)立的開發(fā)、測(cè)試、部署和運(yùn)維。這兩點(diǎn)并非采用微服務(wù)模式的充分必要條件，但如果能夠滿足，微服務(wù)化的過程會(huì)更加順利，后續(xù)的維護(hù)和迭代也會(huì)很輕松，而不是困難重重。

另外需要注意，微服務(wù)應(yīng)該隨著業(yè)務(wù)的發(fā)展逐步拆分。幾乎所有成功的微服務(wù)架構(gòu)都是從龐大的單體架構(gòu)拆分而來，而幾乎所有一開始就構(gòu)建微服務(wù)架構(gòu)的案例，后續(xù)都遇到了很大的困難。面對(duì)新的業(yè)務(wù)和領(lǐng)域，我們?cè)陂_始階段很難把業(yè)務(wù)梳理得非常清晰，往往是經(jīng)過一段時(shí)間、經(jīng)歷一些挫折后，業(yè)務(wù)內(nèi)部的架構(gòu)才逐漸清晰。從已有的模塊清晰的單體架構(gòu)逐步劃分服務(wù)，比一開始就構(gòu)建微服務(wù)要簡(jiǎn)單得多。否則會(huì)有兩個(gè)弊端：一是第一版的交付時(shí)間會(huì)大大延遲，因?yàn)樾枰獦?gòu)建很多公共服務(wù)；二是服務(wù)很容易拆分不合理，嚴(yán)重影響整個(gè)調(diào)用流程的性能，甚至可能需要花費(fèi)大量精力處理分布式事務(wù)，最后不得不把多個(gè)微服務(wù)重新整合成一個(gè)單體。

而且，只有當(dāng)業(yè)務(wù)復(fù)雜度達(dá)到一定程度后，微服務(wù)架構(gòu)消耗的成本才會(huì)體現(xiàn)出優(yōu)勢(shì)。微服務(wù)設(shè)計(jì)應(yīng)該遵循垂直劃分優(yōu)先原則，這樣可以讓團(tuán)隊(duì)自上而下地關(guān)注業(yè)務(wù)實(shí)現(xiàn)，做到端到端負(fù)責(zé)，避免因跨服務(wù)多次調(diào)用而產(chǎn)生的性能和溝通成本。

圖片

1. 選擇合適的時(shí)機(jī)

在實(shí)際落地過程中，若想享受到微服務(wù)帶來的好處，就需要做好一些前期準(zhǔn)備工作。例如，組織架構(gòu)和團(tuán)隊(duì)文化要與云原生的節(jié)奏相適應(yīng)，要足夠敏捷且足夠自主；要構(gòu)建全功能團(tuán)隊(duì)，將產(chǎn)品、UI、前后端研發(fā)、測(cè)試等角色配備齊全；要提前打造自動(dòng)化的流水線，實(shí)現(xiàn)一鍵構(gòu)建、發(fā)布、部署以及快速擴(kuò)縮容等功能；服務(wù)也要提前進(jìn)行容器化部署改造，因?yàn)榉?wù)容器化更有利于在云原生場(chǎng)景下集成其他功能組件。當(dāng)上述準(zhǔn)備工作全部完成，并且業(yè)務(wù)也逐漸發(fā)展到一定規(guī)模、急需進(jìn)行拆分的時(shí)候，就應(yīng)該當(dāng)機(jī)立斷地進(jìn)行微服務(wù)拆分和架構(gòu)設(shè)計(jì)了。

2. 選擇合適的微服務(wù)框架

現(xiàn)在主流的微服務(wù)框架主要分為兩類：侵入式與非侵入式。

主流的侵入式框架包括 Spring Cloud、Dubbo、brpc 等，這些框架的功能特色各有不同，在不同場(chǎng)景中均有應(yīng)用，大部分架構(gòu)師對(duì)它們都比較熟悉，其社區(qū)和文檔的成熟度也都較高。雖然像 Spring Cloud 這樣的傳統(tǒng)侵入式微服務(wù)框架存在版本碎片化嚴(yán)重、升級(jí)成本高等問題，但總體而言，它們已經(jīng)能夠滿足絕大部分服務(wù)治理的需求。

現(xiàn)在大部分人更關(guān)注非侵入式框架的選型，也就是近幾年興起的服務(wù)網(wǎng)格技術(shù)。2017 年，隨著 Linkerd 的傳入，Service Mesh 被翻譯成服務(wù)網(wǎng)格，并開始進(jìn)入國(guó)內(nèi)社區(qū)的視野。部分大公司也同步自研了適合公司內(nèi)部應(yīng)用場(chǎng)景和依賴的服務(wù)網(wǎng)格框架，以此助力內(nèi)部服務(wù)的快速迭代與發(fā)展。

而 Istio 作為一個(gè)開源的 Service Mesh 框架，一經(jīng)推出就備受關(guān)注，成為各大廠商和開發(fā)者追捧的對(duì)象。很多人認(rèn)為，Istio 會(huì)成為繼 Kubernetes 之后又一個(gè)明星級(jí)產(chǎn)品。有了 Istio，基本上不再需要其他微服務(wù)框架，也無需自己去實(shí)現(xiàn)服務(wù)治理等功能。只要把網(wǎng)絡(luò)層委托給 Istio，它就能完成這一系列工作。簡(jiǎn)單來說，Istio 是一個(gè)提供服務(wù)治理能力的服務(wù)網(wǎng)格。

此外，Istio 還具備完善的可觀察性方面的能力，包括對(duì)所有網(wǎng)格控制下的流量進(jìn)行自動(dòng)化度量、日志記錄和追蹤。換句話說，選擇了 Istio，單體應(yīng)用無需進(jìn)行任何改造就能輕松接入微服務(wù)，享受云原生的各項(xiàng)好處。

3. 借助云廠商產(chǎn)品快速進(jìn)行云原生與微服務(wù)落地

之所以提及云廠商，是因?yàn)榇蠖鄶?shù)中小型公司或者傳統(tǒng)行業(yè)都被單體應(yīng)用和傳統(tǒng)微服務(wù)框架的種種弊端所困擾，迫切需要進(jìn)行云原生和微服務(wù)的改造。然而，它們?nèi)狈ψ銐虻娜肆图夹g(shù)來維護(hù)一套具備齊全功能的云原生底座和基礎(chǔ)架構(gòu)服務(wù)。以 Istio 框架為例，它的版本更新頻繁，控制面和數(shù)據(jù)面在提供強(qiáng)大功能的同時(shí)，其代碼實(shí)現(xiàn)也相當(dāng)復(fù)雜。當(dāng)出現(xiàn)異常時(shí)，很多工程師往往難以定位問題所在。而云廠商提供了一整套云原生應(yīng)用編排和微服務(wù)管理的解決方案，所有技術(shù)都實(shí)現(xiàn)了產(chǎn)品化，方便使用且易于查看效果，還能避免或者快速解決運(yùn)行期間可能遇到的各類問題。從一定程度上來說，這既提高了服務(wù)效率，又大幅降低了各種成本，能夠讓人快速且充分地享受到云原生的好處。

總的來說，任何軟件或者架構(gòu)都有其優(yōu)缺點(diǎn)，不存在十全十美的事物。當(dāng)大家在考慮是否要落地微服務(wù)時(shí)，需要思考和權(quán)衡的是：當(dāng)前的軟件和系統(tǒng)是否滿足微服務(wù)化改造的前提條件，微服務(wù)化改造后所帶來的收益是否大于損失、好處是否多于弊端，團(tuán)隊(duì)在各個(gè)方面是否做好了準(zhǔn)備。如果還沒有準(zhǔn)備好，那么不妨再等等，畢竟單體架構(gòu)也有其自身的優(yōu)勢(shì)。