近年來(lái)，微服務(wù)是備受關(guān)注的概念。有人主張微服務(wù)是一種革命性的技術(shù)創(chuàng)新，也有人認(rèn)為微服務(wù)并沒(méi)有什么新鮮的，只不過(guò)是對(duì)SOA（面向服務(wù)架構(gòu)）的優(yōu)化重塑。我不想爭(zhēng)論這些，因?yàn)闊o(wú)論是支持還是反對(duì)，都無(wú)法阻擋微服務(wù)在敏捷開(kāi)發(fā)和復(fù)雜的企業(yè)級(jí)應(yīng)用開(kāi)發(fā)中的優(yōu)勢(shì)。

通過(guò)微服務(wù)，我們?cè)趹?yīng)用開(kāi)發(fā)和部署方面取得了顯著的進(jìn)步。將應(yīng)用開(kāi)發(fā)或者重構(gòu)成微服務(wù)以分離服務(wù)，通過(guò) API 以明確的方式來(lái)相互“對(duì)話(huà)”。例如，每個(gè)微服務(wù)都是自包含（self-contained），各自維護(hù)自己的數(shù)據(jù)存儲(chǔ)（這非常有意義），可以獨(dú)立更新其服務(wù)。

使用基于微服務(wù)的方式使得應(yīng)用程序開(kāi)發(fā)變得更快更容易管理，它只需要較少的人力就能實(shí)現(xiàn)更多的功能，可以更快更容易地部署。把應(yīng)用程序設(shè)計(jì)成一套微服務(wù)，更加容易在多臺(tái)具有負(fù)載均衡的服務(wù)器上運(yùn)行，使其能夠輕松應(yīng)對(duì)需求高峰、由于時(shí)間推移而平穩(wěn)增長(zhǎng)的需求和由于硬件或者軟件問(wèn)題導(dǎo)致的宕機(jī)事故。

微服務(wù)的大進(jìn)步在于改變了我們的工作方式。敏捷軟件開(kāi)發(fā)技術(shù)、應(yīng)用遷移云端、DevOps 文化、持續(xù)集成與持續(xù)部署（CI/CD）和容器應(yīng)用都使用了微服務(wù)來(lái)革新應(yīng)用開(kāi)發(fā)與交付。

我們先來(lái)看微服務(wù)的發(fā)展史。

從最原始的單體應(yīng)用開(kāi)始：

在架構(gòu)核心，設(shè)計(jì)了乘客管理，司機(jī)管理。行程管理，支付，消息通知等核心模塊。

圍繞核心模塊，我們?cè)僭O(shè)計(jì)各種接口適配器，如同數(shù)據(jù)庫(kù)對(duì)接，同移動(dòng)端的api接口，web頁(yè)面，對(duì)其他外部組織對(duì)接接口等等。

然后我們就可以打成一個(gè)包，進(jìn)行部署。

在項(xiàng)目的早期，這沒(méi)有太大問(wèn)題。我們還可以通過(guò)負(fù)載均衡器在做多個(gè)實(shí)例的負(fù)載均衡。

然而，成功的應(yīng)用有一個(gè)趨勢(shì)，隨著時(shí)間推移而變得越來(lái)越臃腫。

首先，在業(yè)務(wù)快速發(fā)展的階段，開(kāi)發(fā)人員每天有大量業(yè)務(wù)變更需要開(kāi)發(fā)，在996已經(jīng)不能保證完成工作的情況下，要開(kāi)發(fā)人員保證應(yīng)用架構(gòu)的干凈是強(qiáng)人所難。

在業(yè)務(wù)代碼變得足夠復(fù)雜之后，團(tuán)隊(duì)中很快就沒(méi)有人能完全理清所有業(yè)務(wù)，只能負(fù)責(zé)自己的一小塊。

最終，正確修復(fù)bug和開(kāi)發(fā)新功能都變得越來(lái)越困難，只能不斷的打補(bǔ)丁。最終單體應(yīng)用會(huì)變成一個(gè)無(wú)人可以理解的超大型亂碼。

最后的結(jié)果是：你不要嘗試去重構(gòu)，就讓他這樣跑著吧。

同時(shí)伴隨而來(lái)的是，單體應(yīng)用的部署時(shí)間越來(lái)越長(zhǎng)。一個(gè)單體應(yīng)用對(duì)服務(wù)器的要求也越來(lái)越高。

單體應(yīng)用的另一個(gè)問(wèn)題是可靠性。因?yàn)樗心K都運(yùn)行在同一進(jìn)程中。任何模塊的一個(gè) bug，比如內(nèi)存泄漏，可能會(huì)拖垮整個(gè)進(jìn)程。此外，由于應(yīng)用程序的所有實(shí)例都是相同的，該錯(cuò)誤將影響到整個(gè)應(yīng)用的可用性。

總結(jié)：

所以，一個(gè)成功的應(yīng)用最終會(huì)變成只有少數(shù)人能維護(hù)的巨大單體。使用著陳舊的技術(shù)，很難找到合格的新開(kāi)發(fā)人員。

部署困難，重啟耗時(shí)極長(zhǎng)，可靠性也得不到保障。無(wú)法重構(gòu)，或者重構(gòu)的代價(jià)極大，必須同時(shí)重構(gòu)整個(gè)單體。

每個(gè)迷你應(yīng)用都對(duì)外暴露REST服務(wù)API。各后端服務(wù)可以相互調(diào)用。一些 REST API 也暴露給移動(dòng)端應(yīng)用使用。然而，前端應(yīng)用不能直接訪(fǎng)問(wèn)后端服務(wù)。前端對(duì)后端的服務(wù)調(diào)用要通過(guò)API網(wǎng)關(guān)。API 網(wǎng)關(guān)統(tǒng)一負(fù)責(zé)負(fù)載均衡、緩存、訪(fǎng)問(wèn)控制、API 計(jì)量和監(jiān)控。

微服務(wù)架構(gòu)模式明顯影響到了應(yīng)用程序與數(shù)據(jù)庫(kù)之間的關(guān)系，在單體應(yīng)用中，所有業(yè)務(wù)共享一個(gè)數(shù)據(jù)庫(kù)。然而現(xiàn)在，微服務(wù)建議其每一個(gè)服務(wù)都有自己的數(shù)據(jù)庫(kù)。這樣做的缺點(diǎn)是可能導(dǎo)致部分?jǐn)?shù)據(jù)冗余。但是，從微服務(wù)架構(gòu)的角度去理解，業(yè)務(wù)A的數(shù)據(jù)庫(kù)本就不該存業(yè)務(wù)B的數(shù)據(jù)，所有的關(guān)于業(yè)務(wù)B的數(shù)據(jù)，從應(yīng)該由業(yè)務(wù)B的微服務(wù)對(duì)外提供。

另外，在這種架構(gòu)下，我們可以為業(yè)務(wù)選擇合適的數(shù)據(jù)庫(kù)。比如對(duì)某些業(yè)務(wù)，我們需要選擇支持高效地理位置查詢(xún)的數(shù)據(jù)庫(kù)。

總結(jié)：

微服務(wù)的優(yōu)點(diǎn)：

1，拆分了復(fù)雜的單體應(yīng)用。降低了代碼的服務(wù)度，規(guī)定了微服務(wù)的業(yè)務(wù)邊界。使業(yè)務(wù)代碼能夠容易的開(kāi)發(fā)和修改

2，微服務(wù)架構(gòu)使每個(gè)業(yè)務(wù)模塊有一個(gè)團(tuán)隊(duì)專(zhuān)門(mén)負(fù)責(zé)。技術(shù)團(tuán)隊(duì)可以根據(jù)業(yè)務(wù)的需要做出更合適的技術(shù)選型。同時(shí)因?yàn)閱蝹€(gè)微服務(wù)代碼體量的減小，使代碼重構(gòu)成為可能。

3，部署更快捷和方便。

優(yōu)點(diǎn)司空見(jiàn)慣，我們其實(shí)更應(yīng)該關(guān)注下微服務(wù)的缺點(diǎn)

微服務(wù)的缺點(diǎn)：

1，整體復(fù)雜度更高。微服務(wù)根本上說(shuō)是一個(gè)分布式系統(tǒng)。開(kāi)發(fā)者需要選擇和實(shí)現(xiàn)基于消息或者 RPC 的進(jìn)程間通信機(jī)制。雖然這個(gè)有很多框架可供選擇，并不需要從頭實(shí)現(xiàn)。但是整體上的代碼復(fù)雜度是提高了。

2，事務(wù)。如上面所說(shuō)，微服務(wù)架構(gòu)上每個(gè)業(yè)務(wù)有自己的數(shù)據(jù)庫(kù)。以前在單體應(yīng)用中很好解決的事務(wù)問(wèn)題，現(xiàn)在變得很困難。在基于微服務(wù)的應(yīng)用程序中，需要更新不同服務(wù)所用的數(shù)據(jù)庫(kù)。通常不會(huì)選擇分布式事務(wù)，不僅僅是因?yàn)?CAP 定理。他們根本不支持如今高度可擴(kuò)展的 NoSQL 數(shù)據(jù)庫(kù)和消息代理。最后不得不使用基于最終一致性的方法，這對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)更具挑戰(zhàn)性。

3，測(cè)試微服務(wù)應(yīng)用程序也很復(fù)雜。例如，使用 Spring Boot，我只需要編寫(xiě)一個(gè)測(cè)試類(lèi)來(lái)啟動(dòng)一個(gè)單體 web 應(yīng)用程序并測(cè)試其 REST API。相比之下，一個(gè)類(lèi)似的測(cè)試類(lèi)對(duì)于微服務(wù)來(lái)說(shuō)需要啟動(dòng)該服務(wù)及其所依賴(lài)的所有服務(wù)，或者至少要做服務(wù)mock，雖然這不是一件高深的事情，但不要低估了這多出來(lái)的工作量和復(fù)雜度。

新聞標(biāo)題：微服務(wù)架構(gòu)的優(yōu)點(diǎn)和缺點(diǎn)都有哪些？
鏈接URL：http://www.rwnh.cn/news/101117.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信公眾號(hào)、網(wǎng)站排名、ChatGPT、用戶(hù)體驗(yàn)、網(wǎng)站設(shè)計(jì)公司、標(biāo)簽優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)