缺點一：項目過於臃腫
當大大小小的功能模塊都集中在同一項目的時候，整個項目必然會變得臃腫，讓開發者難以維護。
缺點二：資源無法隔離
就像剛剛小灰的經歷一樣，整個單體系統的各個功能模塊都依賴於同樣的數據庫、內存等資源，一旦某個功能模塊對資源使用不當，整個系統都會被拖垮。
缺點三：無法靈活擴展
當系統的訪問量越來越大的時候，單體系統固然可以進行水平擴展，部署在多臺機器上組成集羣：
但是這種擴展並非靈活的擴展。比如我們現在的性能瓶頸是支付模塊，希望只針對支付模塊做水平擴展，這一點在單體系統是做不到的。
什麼是微服務？
微服務（Microservice Architecture）是近幾年流行的一種架構思想，關於它的概念很難一言以蔽之。
究竟什麼是微服務呢？我們在此引用 ThoughtWorks 公司的首席科學家 Martin Fowler 的一段話：
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
谷歌翻譯如下：
簡而言之，微服務架構風格是一種將單個應用程序作爲一套小型服務開發的方法，每種應用程序都在自己的進程中運行，並與輕量級機制（通常是HTTP資源API）進行通信。 這些服務是圍繞業務功能構建的，可以通過全自動部署機制獨立部署。 這些服務的集中管理最少，可以用不同的編程語言編寫，並使用不同的數據存儲技術。
說了這麼多概念，微服務有什麼樣的具體特點呢？
1.獨立部署，靈活擴展
傳統的單體架構是以整個系統爲單位進行部署，而微服務則是以每一個獨立組件（例如用戶服務，商品服務）爲單位進行部署。
用一張經典的圖來表現，就是下面這個樣子：
圖中左邊是單體架構的集羣，右邊是微服務集羣。
什麼意思呢？比如根據每個服務的吞吐量不同，支付服務需要部署20臺機器，用戶服務需要部署30臺機器，而商品服務只需要部署10臺機器。這種靈活部署只有微服務架構才能實現。
而近幾年流行的Docker，爲微服務架構提供了有效的容器。
2.資源的有效隔離
微服務設計的原則之一，就是每一個微服務擁有獨立的數據源，假如微服務A想要讀寫微服務B的數據庫，只能調用微服務B對外暴露的接口來完成。這樣有效避免了服務之間爭用數據庫和緩存資源所帶來的問題。
同時，由於每一個微服務實例在Docker容器上運行，實現了服務器資源（內存、CPU資源等）的有效隔離。
3.團隊組織架構的調整
微服務設計的思想也改變了原有的企業研發團隊組織架構。傳統的研發組織架構是水平架構，前端有前端的團隊，後端有後端的團隊，DBA有DBA的團隊，測試有測試的團隊。
而微服務的設計思想對團隊的劃分有着一定的影響，使得團隊組織架構的劃分更傾向於垂直架構，比如用戶業務是一個團隊來負責，支付業務是一個團隊來負責。
當然，這種垂直劃分只是一個理想的架構，實際在企業中並不會把團隊組織架構拆分得這麼絕對。
微服務與面向服務架構SOA的區別
SOA是什麼樣子呢？可以是下面這樣的Web Service：
也可以是下面這樣的ESB企業服務總線：
總之，SOA架構強調的是異構系統之間的通信和解耦合，而微服務架構強調的是系統按業務邊界做細粒度的拆分和部署。
微服務架構的不足
喜歡本文的朋友們，歡迎長按下圖關注訂閱號程序員小灰，收看更多精彩內容