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

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

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

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

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

從最原始的單體應用開始：

在架構核心，設計了乘客管理，司機管理。行程管理，支付，消息通知等核心模塊。

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

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

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

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

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

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

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

最后的結果是：你不要嘗試去重構，就讓他這樣跑著吧。

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

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

總結：

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

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

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

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

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

總結：

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

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

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

3，部署更快捷和方便。

優(yōu)點司空見慣，我們其實更應該關注下微服務的缺點

微服務的缺點：

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

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

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

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

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

廣告

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