先用漫畫引入微服務概念~
缺點一：項目過於臃腫當大大小小的功能模塊都集中在同一項目的時候，整個項目必然會變得臃腫，讓開發者難以維護。
缺點二：資源無法隔離就像剛剛小灰的經歷一樣，整個單體系統的各個功能模塊都依賴於同樣的數據庫、內存等資源，一旦某個功能模塊對資源使用不當，整個系統都會被拖垮。
缺點三：無法靈活擴展當系統的訪問量越來越大的時候，單體系統固然可以進行水平擴展，部署在多臺機器上組成集群：
但是這種擴展並非靈活的擴展。比如我們現在的性能瓶頸是支付模塊，希望只針對支付模塊做水平擴展，這一點在單體系統是做不到的。
什麼是微服務？微服務（Microservice Architecture）是近幾年流行的一種架構思想，簡而言之，微服務架構是一種將單應用程序作為一套小型服務開發的方法，每種應用程序都在其自己的進程中運行，並與輕量級機制（通常是HTTP資源的API）進行通信。這些服務是圍繞業務功能構建的，可以通過全自動部署機制進行獨立部署。這些服務的集中化管理已經是最少的，它們可以用不同的編程語言編寫，並使用不同的數據存儲技術。
微服務的特點
1.獨立部署，靈活擴展傳統的單體架構是以整個系統為單位進行部署，而微服務則是以每一個獨立組件（例如用戶服務，商品服務）為單位進行部署。
用一張經典的圖來表現，就是下面這個樣子：
左邊是單體架構的集群，右邊是微服務集群
比如根據每個服務的吞吐量不同，支付服務需要部署20臺機器，用戶服務需要部署30臺機器，而商品服務只需要部署10臺機器。這種靈活部署只有微服務架構才能實現。
而近幾年流行的Docker，為微服務架構提供了有效的容器。
2.資源的有效隔離微服務設計的原則之一，就是每一個微服務擁有獨立的數據源，假如微服務A想要讀寫微服務B的數據庫，只能調用微服務B對外暴露的接口來完成。這樣有效避免了服務之間爭用數據庫和緩存資源所帶來的問題。
同時，由於每一個微服務實例在Docker容器上運行，實現了服務器資源（內存、CPU資源等）的有效隔離。
3.團隊組織架構的調整微服務設計的思想也改變了原有的企業研發團隊組織架構。傳統的研發組織架構是水平架構，前端有前端的團隊，後端有後端的團隊，DBA有DBA的團隊，測試有測試的團隊。
而微服務的設計思想對團隊的劃分有著一定的影響，使得團隊組織架構的劃分更傾向於垂直架構，比如用戶業務是一個團隊來負責，支付業務是一個團隊來負責。
這種垂直劃分只是一個理想的架構，實際在企業中並不會把團隊組織架構拆分得這麼絕對。
微服務與SOA的區別
什麼是SOA？soa可以是下面這樣的Web Service：
總之，SOA架構強調的是異構系統之間的通信和解耦合，而微服務架構強調的是系統按業務邊界做細粒度的拆分和部署。
微服務架構不足
總結：
微服務架構風格主要體現的是一個重要的思想—一個為企業應用認真思考的思想，也有在某種程度上開創了這種架構風格的例子，包括亞馬遜、Netflix、衛報、英國政府數字服務、realestate.com.au、Forwardh和comparethemarket.com等等。
實際軟件開發不太建議直接從微服務架構開始，而應從單一（龐大）的項目開始，一旦這一項目遇到問題，就拆分模塊，劃分不同的微服務。
後面會分享更多devops和DBA方面的內容，感興趣的朋友可以關注下~
閱讀更多 波波說運維 的文章
