【學習總結】認識微服務

時間 2019-12-19

標籤學習總結認識微服简体版

原文原文鏈接

參考連接：

漫畫：什麼是微服務

傳統的單體架構的痛點

傳統的MVC架構，全部業務子模塊都集成在一個很重的JVM進程中
-（MVC：一種設計模式，Model-View-Controller（模型-視圖-控制器）模式。這種模式用於應用程序的分層開發。）
單體架構的好處是便於管理，全部代碼都在同一個項目中。

缺點：

缺點一：項目過於臃腫。
- 當大大小小的功能模塊都集中在同一項目的時候，整個項目必然會變得臃腫，讓開發者難以維護。
缺點二：資源沒法隔離。
- 就像剛剛小灰的經歷同樣，整個單體系統的各個功能模塊都依賴於一樣的數據庫、內存等資源，一旦某個功能模塊對資源使用不當，整個系統都會被拖垮。
缺點三：沒法靈活擴展。
- 當系統的訪問量愈來愈大的時候，單體系統當然能夠進行水平擴展，部署在多臺機器上組成集羣。
  
  可是這種擴展並不是靈活的擴展。好比咱們如今的性能瓶頸是支付模塊，但願只針對支付模塊作水平擴展，這一點在單體系統是作不到的。

單體架構痛點的解決

臃腫的單體系統拆分紅微服務。

微服務

微服務（Microservice Architecture）是近幾年流行的一種架構思想
- 微服務架構風格是一種將單個應用程序做爲一套小型服務開發的方法，每種應用程序都在本身的進程中運行，並與輕量級機制（一般是HTTP資源API）進行通訊。這些服務是圍繞業務功能構建的，能夠經過全自動部署機制獨立部署。這些服務的集中管理最少，能夠用不一樣的編程語言編寫，並使用不一樣的數據存儲技術。
微服務的特色：
- 1.獨立部署，靈活擴展
  - 傳統的單體架構是以整個系統爲單位進行部署，而微服務則是以每個獨立組件（例如用戶服務，商品服務）爲單位進行部署。
  - 好比根據每一個服務的吞吐量不一樣，支付服務須要部署20臺機器，用戶服務須要部署30臺機器，而商品服務只須要部署10臺機器。這種靈活部署只有微服務架構才能實現。
  - 而近幾年流行的Docker，爲微服務架構提供了有效的容器。
2.資源的有效隔離
- 微服務設計的原則之一，就是每個微服務擁有獨立的數據源，假如微服務A想要讀寫微服務B的數據庫，只能調用微服務B對外暴露的接口來完成。這樣有效避免了服務之間爭用數據庫和緩存資源所帶來的問題。
- 同時，因爲每個微服務實例在Docker容器上運行，實現了服務器資源（內存、CPU資源等）的有效隔離。
3.團隊組織架構的調整
- 微服務設計的思想也改變了原有的企業研發團隊組織架構。傳統的研發組織架構是水平架構，前端有前端的團隊，後端有後端的團隊，DBA有DBA的團隊，測試有測試的團隊。
- 而微服務的設計思想對團隊的劃分有着必定的影響，使得團隊組織架構的劃分更傾向於垂直架構，好比用戶業務是一個團隊來負責，支付業務是一個團隊來負責。
- 固然，這種垂直劃分只是一個理想的架構，實際在企業中並不會把團隊組織架構拆分得這麼絕對。