什麼是微服務通俗易懂(什麼是微服務)
2023-10-04 04:43:56 4
1.單體架構vs微服務架構1.1從單體架構說起一個工程對應一個war包,這個war包包含了該工程的所有功能。我們稱這種應用為單體應用,也就是我們說的單體架構。
優點:
①架構簡單明了,從前端到後臺結構清晰,沒有其他花裡胡哨的東西
②開發測試,部署簡單(尤其運維,睡著都會笑醒)
缺點:
①隨著業務發展,代碼越來越複雜,代碼質量參差不⻬(開發人員水平不一)
②部署慢(想像一下幾百M的代碼部署速度)
③擴展成本高,如用戶模塊是一個cpu密集型(涉及大量運算)的模塊,我們需要更加牛逼的cou,訂單模塊是一個io密集型(涉及大量磁碟讀寫)的模塊,那麼我們就需要更加牛逼的內存以及更加牛逼的內存和高效的磁碟,但是我們單體架構無法針對單個功能模塊進行擴展
④阻礙了新技術的發展(將struts2遷到spingboot,將是災難性的)
1.3微服務架構微服務核心就是將傳統的單機應用,根據具體的業務將單機應用拆分成一個一個的服務,徹底解耦,每一個服務提供一個特定的功能,一個服務只做一件事,職責劃分,每個服務都能單獨部署,這樣一個一個小的服務就是微服務
優點:
①每個服務只針對一個業務功能點,代碼更加容易理解
②開發簡單,一個服務員只幹一件事情,提高效率
③按需伸縮,前後端分離,只需關心後端接口的安全性以及性能
④一個服務可以有自己的資料庫
缺點:
①增加運維人員的工作量,單體只部署一個war包,現在可能需要部署成百上千的包
②服務之間相互調用,增加通信成本,代理一系列超時,限流熔斷,以及兜底處理
③數據一致性問題(分布式事務)
④系統全鏈路監控,問題定位
1.5微服務適用場景適合:
①大型複雜的項目(單體架構幾百M的代碼)
②快速迭代的項目(一天發一版)
③並發高(考慮彈性伸縮擴容)
不適合:
①業務穩定,就是改改bug,改改資料庫
②迭代周期⻓,半個月或者一個月發版一次
,