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