什麼是微服務通俗易懂-tft每日頭條

1.單體架構vs微服務架構1.1從單體架構說起

一個工程對應一個war包，這個war包包含了該工程的所有功能。我們稱這種應用為單體應用，也就是我們說的單體架構。

什麼是微服務通俗易懂（什麼是微服務）1

1.2單體架構的優缺點

優點：

①架構簡單明了，從前端到後台結構清晰，沒有其他花裡胡哨的東西

②開發測試，部署簡單（尤其運維，睡着都會笑醒)

缺點：

①随着業務發展，代碼越來越複雜，代碼質量參差不⻬（開發人員水平不一）

②部署慢(想象一下幾百M的代碼部署速度)

③擴展成本高，如用戶模塊是一個cpu密集型（涉及大量運算）的模塊，我們需要更加牛逼的cou，訂單模塊是一個io密集型（涉及大量磁盤讀寫）的模塊，那麼我們就需要更加牛逼的内存以及更加牛逼的内存和高效的磁盤，但是我們單體架構無法針對單個功能模塊進行擴展

④阻礙了新技術的發展（将struts2遷到spingboot，将是災難性的）

1.3微服務架構

微服務核心就是将傳統的單機應用，根據具體的業務将單機應用拆分成一個一個的服務，徹底解耦，每一個服務提供一個特定的功能，一個服務隻做一件事，職責劃分，每個服務都能單獨部署，這樣一個一個小的服務就是微服務

什麼是微服務通俗易懂（什麼是微服務）2

1.4微服務架構的優缺點

優點：

①每個服務隻針對一個業務功能點，代碼更加容易理解

②開發簡單，一個服務員隻幹一件事情，提高效率

③按需伸縮，前後端分離，隻需關心後端接口的安全性以及性能

④一個服務可以有自己的數據庫

缺點：

①增加運維人員的工作量，單體隻部署一個war包，現在可能需要部署成百上千的包

②服務之間相互調用，增加通信成本，代理一系列超時，限流熔斷，以及兜底處理

③數據一緻性問題（分布式事務）

④系統全鍊路監控，問題定位

1.5微服務适用場景

适合:

①大型複雜的項目（單體架構幾百M的代碼）

②快速叠代的項目（一天發一版）

③并發高（考慮彈性伸縮擴容）

不适合：

①業務穩定，就是改改bug，改改數據庫

②叠代周期⻓，半個月或者一個月發版一次