目錄docker
@數據庫
今天簡單瞭解一下微服務,在看微服務前,先了解一下傳統的單機系統。編程
全部的業務子模塊都集中在一個系統中,優勢是便於管理,可是規模變大的時候,缺點就很明顯了。
api
缺點:服務器
當產品規模愈來愈大,各類的大大小小模塊都塞在一個項目中,必然會使整個項目變的臃腫,讓開發者難以維護。架構
系統的各個功能模塊都依賴於一樣的數據庫、內存等資源、一旦某個功能模塊對資源處理不當,便可能影響整個系統。異步
當系統的訪問量愈來愈大的時候,單體系統能夠進行水平擴展,部署多臺機器。
可是這種擴展並不靈活,假如咱們的性能瓶頸在支付上,只但願對支付模塊進行水平擴展,單體系統是沒法作到的。編程語言
微服務,是近年來流行起來的一種架構思想,將單個的應用拆分紅一套小型服務,每種應用都是一個獨立的進程,經過輕量級機制(一般爲http資源api)進行通訊。
這些服務圍繞業務功能構建,因爲進程的獨立性,這些小型服務可使用不一樣的編程語言、數據存儲技術。分佈式
微服務的優勢
微服務
單體架構是以整個系統做爲單位部署,而微服務則能夠做爲一個獨立的組件單獨部署。
舉個例子,咱們都知道每一年雙11的爆發訪問量,並且基本會集中在凌晨。
那麼假如系統瓶頸在於支付模塊,須要300臺機器,其次是訂單隻須要200臺,用戶只須要100臺機器,那麼咱們採用微服務的話就能夠進行以下部署。同時docker的流行,也爲微服務器提供了有效的容器。
微服務的一個重要設計原則就是每個微服務擁有獨立的數據源,假如訂單服務想讀取用戶服務的數據庫,那麼只能經過操做用戶服務的接口完成。
同時,docker容器也作好了資源的有效隔離。
相比於傳統架構,微服務架構更強調的是系統按業務邊界作細粒度的拆分和部署。
那麼微服務架構有哪些缺點呢:
微服務須要把原有的系統拆分紅多個獨立工程,同時須要保證不一樣服務之間的數據一致性,引入了分佈式事務和異步補償機制,大大增長了設計和開發的難度。
微服務拆分過細可能會出現添加一個小功能須要改動好幾個工程的狀況,隨着服務數量的增長,管理的複雜性也會隨之增長。
因此說架構設計沒有什麼絕對的,主要仍是看場景,若是不在大廠的話,通常很難遇到複雜的微服務架構吧。