微服務(wù)架構(gòu)可謂是當(dāng)前軟件開發(fā)領(lǐng)域的技術(shù)熱點(diǎn)，它在各種博客、知識(shí)媒體和業(yè)界知名會(huì)議演講上的出鏡率非常之高，無論是做基礎(chǔ)架構(gòu)還是做業(yè)務(wù)系統(tǒng)的工程師，對(duì)微服務(wù)都相當(dāng)關(guān)注，而這個(gè)現(xiàn)象與熱度已經(jīng)持續(xù)了近 5 年之久，經(jīng)久不衰。

然而，隨著云原生技術(shù)的推廣，以及大量的微服務(wù)落地，反微服務(wù)的聲音越發(fā)響亮。尤其是在今年 3 月初，服務(wù)網(wǎng)格的著名開源項(xiàng)目 Istio 發(fā)布了 1.5 版本，其控制面由原先的多個(gè)微服務(wù)組件，合并成了一個(gè)單體應(yīng)用，大大簡(jiǎn)化了其架構(gòu)與部署運(yùn)維的復(fù)雜性，贏得了滿堂喝彩。社區(qū)關(guān)于微服務(wù)模式質(zhì)疑的聲音此起彼伏，也有文章大聲呼喊：“醒醒，你不是真的需要微服務(wù)！”

那么，在云原生時(shí)代，是否需要微服務(wù)？什么時(shí)候應(yīng)該采用微服務(wù)？微服務(wù)究竟能給業(yè)務(wù)帶來哪些好處？如何在不同環(huán)境下正確合理地落地微服務(wù)？希望讀完本文后，每位讀者都能在心中有個(gè)答案。

微服務(wù)是什么

2014 年，Martin Fowler 與 James Lewis 共同提出微服務(wù)的概念，定義了微服務(wù)架構(gòu)是以一組小型服務(wù)的方式來開發(fā)一個(gè)獨(dú)立的應(yīng)用系統(tǒng)，每個(gè)服務(wù)都以一個(gè)獨(dú)立進(jìn)程的方式運(yùn)行，每個(gè)服務(wù)與其他服務(wù)使用輕量級(jí)(通常是 HTTP )通信機(jī)制。這些服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，可以通過全自動(dòng)部署機(jī)制獨(dú)立部署，同時(shí)服務(wù)會(huì)使用最小規(guī)模的集中管理能力，也可以采用不同的編程語言和數(shù)據(jù)庫(kù)，實(shí)現(xiàn)去中心化的服務(wù)管理。

而早在 2005 年，Peter Rodgers 博士在云端運(yùn)算博覽會(huì)上就提出了為 Web 服務(wù)，將程序設(shè)計(jì)成細(xì)粒度的服務(wù)(Granular Service)，以作為 Microsoft 下一階段的軟件架構(gòu)。

由此可以看出，微服務(wù)并不是一個(gè)新的概念，在很早之前就有了充足的理論基礎(chǔ)。大系統(tǒng)終究會(huì)拆解成小系統(tǒng)，“合久必分，分而治之”；傳統(tǒng)行業(yè)的系統(tǒng)架構(gòu)大多都是龐大的單體架構(gòu)，微服務(wù)是架構(gòu)發(fā)展的一個(gè)非常自然的演變狀態(tài)。

遺憾的是，微服務(wù)模式并非“銀彈”，微服務(wù)也有其弊端和痛點(diǎn)。Martin Fowler 也在他的博客中寫道：“除非你的系統(tǒng)太復(fù)雜，作為單體應(yīng)用會(huì)很難管理，否則不要考慮微服務(wù)。絕大多數(shù)軟件系統(tǒng)都應(yīng)該構(gòu)建為單體應(yīng)用。要注重在單體應(yīng)用中實(shí)現(xiàn)良好的模塊化，但不要試圖將其拆分成單獨(dú)的服務(wù)。”

微服務(wù)架構(gòu)的優(yōu)點(diǎn)

通常來說，架構(gòu)沒有好壞優(yōu)劣之分，只有適合與不適合。但是當(dāng)把微服務(wù)架構(gòu)與單體架構(gòu)進(jìn)行比較，會(huì)發(fā)現(xiàn)微服務(wù)有如下一些優(yōu)點(diǎn)：

微服務(wù)還有許多優(yōu)點(diǎn)，如“反脆弱性(anti-fragility)”、架構(gòu)抽象、技術(shù)隔離等。但并不是說采用了微服務(wù)就自然地具備了這些特性。

微服務(wù)的先決條件

準(zhǔn)確地來講，要想享受微服務(wù)的福利，需要具備一些先決條件。

一、團(tuán)隊(duì)調(diào)整

需要重新組建團(tuán)隊(duì)，以服務(wù)為核心，按照業(yè)務(wù)領(lǐng)域劃分全功能團(tuán)隊(duì)，改變?cè)械难邪l(fā)流程、決策機(jī)制。例如，倡導(dǎo)敏捷文化、快速迭代，做更多的自動(dòng)化測(cè)試，加強(qiáng) Code Review 等。

在新的團(tuán)隊(duì)組織里面，一切以人為本，需要建立開放自由的環(huán)境。領(lǐng)導(dǎo)對(duì)下級(jí)高度信任，增強(qiáng)其自我驅(qū)動(dòng)，充分發(fā)揮每一個(gè)人的力量，而不是讓工程師成為“螺絲釘”。

微服務(wù)框架可以封裝、抽象分布式場(chǎng)景下的一些常用能力，例如負(fù)載均衡、服務(wù)注冊(cè)發(fā)現(xiàn)、容錯(cuò)、遠(yuǎn)程通信等能力，可以讓開發(fā)人員快速地開發(fā)出高質(zhì)量的服務(wù)。因此，在采用微服務(wù)架構(gòu)之前，應(yīng)該先進(jìn)行微服務(wù)架構(gòu)的選型、學(xué)習(xí)和試用。整個(gè)團(tuán)隊(duì)要對(duì)微服務(wù)的基本概念、微服務(wù)框架的實(shí)現(xiàn)原理，微服務(wù)治理與監(jiān)控等知識(shí)需要有一定的儲(chǔ)備。

二、基礎(chǔ)設(shè)施建設(shè)

基礎(chǔ)設(shè)施即代碼，可以通過編程的方式管理虛機(jī)或容器，免去了手動(dòng)配置、更新各個(gè)硬件的環(huán)節(jié)，這就使得基礎(chǔ)設(shè)施極具彈性，能夠快速、高效、準(zhǔn)確地進(jìn)行重復(fù)性操作。開發(fā)人員使用同一套代碼或配置，就可以部署并管理成千上萬臺(tái)物理機(jī)。

當(dāng)服務(wù)數(shù)量增多、交付頻繁的時(shí)候，故障次數(shù)可能會(huì)大幅度上升，我們需要通過全面地監(jiān)控發(fā)現(xiàn)故障，及時(shí)處理并發(fā)出警報(bào)。當(dāng)生產(chǎn)環(huán)境出現(xiàn)問題的時(shí)候，需要將故障進(jìn)行分級(jí)，評(píng)估影響面，并分配給相應(yīng)的負(fù)責(zé)人。

微服務(wù)架構(gòu)的一個(gè)大優(yōu)勢(shì)就是快速交付，快速交付不止體現(xiàn)在服務(wù)的力度更小，可以獨(dú)立交付，還體現(xiàn)在整個(gè)流程更快速。微服務(wù)架構(gòu)基于自動(dòng)化的工具鏈，以流水線交付的方式串聯(lián)整個(gè) DevOps 流程。小團(tuán)隊(duì)可以基于服務(wù)獨(dú)立開發(fā)、測(cè)試、部署、運(yùn)維。

以上這兩點(diǎn)不是采用微服務(wù)模式的充分必要條件，但當(dāng)團(tuán)隊(duì)滿足了上述兩個(gè)條件后，微服務(wù)化的過程將事半功倍，后續(xù)維護(hù)和迭代也會(huì)順風(fēng)順?biāo)?#xff0c;而不是叫苦連天。

微服務(wù)是逐步拆分出來的

其次，微服務(wù)是應(yīng)該隨著業(yè)務(wù)的演進(jìn)逐步拆分出來的。

避免在設(shè)計(jì)系統(tǒng)的時(shí)候直接劃分微服務(wù)。幾乎所有成功的微服務(wù)架構(gòu)都是從一個(gè)巨大的單體架構(gòu)拆分出來的；幾乎所有在一開始就構(gòu)建微服務(wù)架構(gòu)的案例，后續(xù)都遇到了巨大的困難。

面對(duì)一個(gè)新的業(yè)務(wù)和領(lǐng)域，很難在開始階段就對(duì)業(yè)務(wù)梳理得很清晰，往往是經(jīng)過一段時(shí)間踩過一些坑，經(jīng)過模塊調(diào)整后，業(yè)務(wù)內(nèi)部架構(gòu)才能逐漸清晰起來。并且從一個(gè)已有的模塊清晰的單體架構(gòu)逐步劃分服務(wù)，要比一開始就構(gòu)建微服務(wù)簡(jiǎn)單的多。如果一開始就劃分了微服務(wù)，其一，第一版交付的時(shí)間會(huì)延后許多，因?yàn)橛性S多公共服務(wù)需要去構(gòu)建起來；其二，服務(wù)很容易拆分得不合理，大大影響整個(gè)調(diào)用流程的性能，甚至可能需要花費(fèi)很大的精力去處理分布式事務(wù)，最后不得不再將多個(gè)微服務(wù)整合成一個(gè)單體。

只有當(dāng)業(yè)務(wù)復(fù)雜度達(dá)到一定的程度后，微服務(wù)架構(gòu)消耗的成本才會(huì)體現(xiàn)其優(yōu)勢(shì)，這個(gè)時(shí)候就可以開始設(shè)計(jì)微服務(wù)架構(gòu)、進(jìn)行微服務(wù)劃分了。微服務(wù)設(shè)計(jì)應(yīng)該優(yōu)先尊重垂直劃分優(yōu)先原則，垂直劃分服務(wù)可以讓團(tuán)隊(duì)自上而下地關(guān)注業(yè)務(wù)實(shí)現(xiàn)，端到端負(fù)責(zé)，避免跨服務(wù)多次調(diào)用引起的性能與溝通成本。微服務(wù)需要監(jiān)控與治理

拆分之前，整個(gè)系統(tǒng)擁有的服務(wù)數(shù)一般只有個(gè)位數(shù)；拆分之后，服務(wù)可能變成了數(shù)十上百個(gè)，實(shí)例數(shù)可能會(huì)達(dá)到成千上萬個(gè)。這么多服務(wù)與實(shí)例，需要構(gòu)建一套監(jiān)控系統(tǒng)，能夠監(jiān)控所有服務(wù)日常運(yùn)行狀態(tài)，并且需要在服務(wù)出錯(cuò)的時(shí)候給對(duì)應(yīng)負(fù)責(zé)人發(fā)出報(bào)警信息；在出現(xiàn)故障時(shí)，能夠通過調(diào)用鏈查詢以及服務(wù)拓?fù)鋱D等功能進(jìn)行分析查看，也可以進(jìn)一步查看到全息日志等具體信息。

除了監(jiān)控，服務(wù)治理也至關(guān)重要。可以通過 SDK/Sidecar 手段提供服務(wù)高可用的治理策略，這些策略往往對(duì)業(yè)務(wù)是非侵入或者弱侵入的，能夠讓絕大多數(shù)服務(wù)輕松實(shí)現(xiàn)服務(wù)高可用。

微服務(wù)之間一旦建立起路由，就意味著會(huì)有數(shù)據(jù)在服務(wù)之間流通。由于不同服務(wù)可以提供的資源和對(duì)數(shù)據(jù)流量的承載能力不盡相同，為了防止單個(gè) Consumer 占用 Provider 過多的資源，或者突發(fā)的大流量沖擊導(dǎo)致 Provider 故障，需要服務(wù)限流來保證服務(wù)的高可用。

在服務(wù)治理中，雖然我們可以通過限流規(guī)則盡量避免服務(wù)承受過高的流量，但是在實(shí)際生產(chǎn)中服務(wù)故障依然難以完全避免。當(dāng)整個(gè)系統(tǒng)中某些服務(wù)產(chǎn)生故障時(shí)，如果不及時(shí)采取措施，這種故障就有可能因?yàn)榉?wù)之間的互相訪問而被傳播開來，最終導(dǎo)致故障規(guī)模的擴(kuò)大，甚至導(dǎo)致整個(gè)系統(tǒng)崩潰，這種現(xiàn)象我們稱之為“雪崩”。熔斷降級(jí)其實(shí)不只是服務(wù)治理中，在金融行業(yè)也有很廣泛的應(yīng)用。比如當(dāng)股指的波動(dòng)幅度超過規(guī)定的熔斷點(diǎn)時(shí)，交易所為了控制風(fēng)險(xiǎn)采取的暫停交易措施。

負(fù)載均衡是高可用架構(gòu)的一個(gè)關(guān)鍵組件，主要用來提高性能和可用性，通過負(fù)載均衡將流量分發(fā)到多個(gè)服務(wù)器，同時(shí)多服務(wù)器能夠消除這部分的單點(diǎn)故障。

如何在云原生時(shí)代落地微服務(wù)

一、選擇合適的時(shí)機(jī)

就像前面提到的，組織架構(gòu)與團(tuán)隊(duì)文化要適應(yīng)云原生的節(jié)奏，需要足夠敏捷、足夠自主，構(gòu)建全功能團(tuán)隊(duì)，產(chǎn)品、UI、前后端研發(fā)、測(cè)試等角色要齊全；需要提前做好自動(dòng)化的流水線，可以一鍵構(gòu)建、發(fā)布、部署，可以快速擴(kuò)縮容等；服務(wù)提前做好容器化部署改造，服務(wù)容器化更適合在云原生場(chǎng)景下集成其他功能與組件。等上述一切都 ready 了之后，并且業(yè)務(wù)也逐步發(fā)展到了一定規(guī)模急需拆分了，這個(gè)時(shí)候就應(yīng)該果斷進(jìn)行微服務(wù)拆分和架構(gòu)設(shè)計(jì)了。

二、選擇合適的微服務(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ù)治理的需求，并且借此快速推進(jìn)微服務(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)推出就備受矚目，成為了各大廠商和開發(fā)者爭(zhēng)相追捧的對(duì)象。很多人相信，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)用無需做任何改造即可輕松接入微服務(wù)，享受云原生各項(xiàng)福利。

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

之所以提到云廠商，是因?yàn)榇蟛糠种行⌒凸净蛘邆鹘y(tǒng)行業(yè)都面臨著單體應(yīng)用和傳統(tǒng)微服務(wù)框架的各種弊端和詬病，急需進(jìn)行云原生與微服務(wù)改造，但是缺乏足夠的人力與技術(shù)，去維護(hù)一套功能齊全的云原生底座與基礎(chǔ)架構(gòu)服務(wù)。例如 Istio 框架，其版本迭代頻繁，控制面與數(shù)據(jù)面在提供了強(qiáng)大的功能的同時(shí)，代碼實(shí)現(xiàn)相當(dāng)復(fù)雜，在遇到了異常的時(shí)候，很多工程師往往很難定位問題。

而云廠商則提供了一整套云原生應(yīng)用編排與微服務(wù)管理解決方案，所有技術(shù)都得到產(chǎn)品化，方便使用與查看效果，并且避免或者快速解決運(yùn)行期間可能遇到的各種問題。在一定程度上，這不僅提高的服務(wù)的效率，也大大降低了各種成本，可以快速充分地享受云原生福利，助力內(nèi)部業(yè)務(wù)穩(wěn)定對(duì)外服務(wù)，快速擴(kuò)張。

總結(jié)

最后，我們?cè)倩氐介_篇的疑問，我們是否還需要微服務(wù)？

這個(gè)問題沒有唯一與正確的答案，每個(gè)人所處的場(chǎng)景不同，正如一千個(gè)人心中有一千個(gè)哈姆雷特。任何軟件或者架構(gòu)都有其利弊，沒有十全十美的東西。大家需要思考和衡量的是，當(dāng)前的軟件與系統(tǒng)是否滿足了微服務(wù)化改造的前提，微服務(wù)化改造后其帶來的收益是否大于損失、利是否大于弊，團(tuán)隊(duì)各個(gè)方面是否做好了準(zhǔn)備，如果還沒有，那么請(qǐng)你再等等，單體架構(gòu)也挺好！

參考文獻(xiàn)

• 《持續(xù)演進(jìn)的 Cloud Native 》 王啟軍 / 著
• 《Istio Handbook——Istio 服務(wù)網(wǎng)格進(jìn)階實(shí)戰(zhàn)》ServiceMesher 社區(qū)聯(lián)合編著： https://www.servicemesher.com/istio-handbook/
• 《混合微服務(wù)高可用在企業(yè)級(jí)生產(chǎn)中的實(shí)踐》 羅廣明： https://cloudnative.to/blog/microservices-ha-practice/

關(guān)注我并轉(zhuǎn)發(fā)此篇文章，私信我“領(lǐng)取資料”，即可免費(fèi)獲得InfoQ價(jià)值4999元迷你書，點(diǎn)擊文末「了解更多」，即可移步InfoQ官網(wǎng)，獲取最新資訊～

總結(jié)

以上是生活随笔為你收集整理的微服务的好处与弊端_在云原生时代，就一定要用微服务吗？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。