微服務(wù)架構(gòu)的優(yōu)點和缺點都有哪些？

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

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

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

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

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

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

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

圍繞核心模塊，我們再設(shè)計各種接口適配器，如同數(shù)據(jù)庫對接，同移動端的api接口，web頁面，對其他外部組織對接接口等等。

然后我們就可以打成一個包，進行部署。

在項目的早期，這沒有太大問題。我們還可以通過負(fù)載均衡器在做多個實例的負(fù)載均衡。

然而，成功的應(yīng)用有一個趨勢，隨著時間推移而變得越來越臃腫。

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

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

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

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

同時伴隨而來的是，單體應(yīng)用的部署時間越來越長。一個單體應(yīng)用對服務(wù)器的要求也越來越高。

單體應(yīng)用的另一個問題是可靠性。因為所有模塊都運行在同一進程中。任何模塊的一個 bug，比如內(nèi)存泄漏，可能會拖垮整個進程。此外，由于應(yīng)用程序的所有實例都是相同的，該錯誤將影響到整個應(yīng)用的可用性。

總結(jié)：

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

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

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

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

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

總結(jié)：

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

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

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

3，部署更快捷和方便。

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

微服務(wù)的缺點：

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

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

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

當(dāng)前文章：微服務(wù)架構(gòu)的優(yōu)點和缺點都有哪些？
網(wǎng)頁網(wǎng)址：http://www.bm7419.com/news17/101117.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、手機網(wǎng)站建設(shè)、做網(wǎng)站、關(guān)鍵詞優(yōu)化、網(wǎng)站排名、外貿(mào)建站

廣告

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