什么是微服務？為什么會有微服務？讓我們帶著這些疑問開始我們的探索，
我們先看下維基百科和百度百科給出的定義：
維基百科：2014年，Martin Fowler 與 James Lewis 共同提出了微服務的概念，定義了微服務是由以單一應用程式構成的小服務，自己擁有自己的行程與輕量化處理，服務依業務功能設計，以全自動的方式部署，與其他服務使用 HTTP API 通信，同時服務會使用最小的規模的集中管理 (例如 Docker) 能力，服務可以用不同的編程語言與資料庫等組件實作，
百度百科：所謂的微服務是SOA架構下的最終產物，該架構的設計目標是為了肢解業務，使得服務能夠獨立運行，微服務設計原則：1、各司其職 2、服務高可用和可擴展性
概念還是比較抽象的，接下來，我將從單體應用開始，講解為什么會有微服務以及什么是微服務，
單體應用
在初期，互聯網公司的應用技術堆疊大致分為 LAMP（Linux + Apache + MySQL + PHP）和 MVC（Spring + iBatis/Hibernate + Tomcat）兩大流派，兩者都是為單體應用架構設計的，其優點是學習成本低，開發上手快，測驗、部署、運維也比較方便，
以 MVC 架構為例，業務通常是通過部署一個 War 包到 Tomcat 中，然后啟動 Tomcat，監聽某個埠即可對外提供服務，早期在業務規模不大、開發團隊人員規模較小的時候，采用單體應用架構，團隊的開發和運維成本都可控，
然而隨著業務規模的不斷擴大，團隊開發人員的不斷擴張，單體應用架構就會開始出現問題，大概會有以下幾個方面的問題，
- 部署效率低：當單體應用的代碼越來越多，依賴的資源越來越多時，應用編譯打包、部署測驗一次，甚至需要 10 分鐘以上，
- 團隊協作開發成本高：當團隊人員擴張，多人修改代碼，然后一起打包部署，測驗階段只要有一塊功能有問題，就得重新編譯打包部署，然后重新預覽測驗，所有相關的開發人員又都得參與其中，效率低下，開發成本極高，
- 系統高可用性差：因為所有的功能開發最后都部署到同一個 War 包里，運行在同一個 Tomcat 行程之中，一旦某一功能涉及的代碼或者資源有問題，那就會影響整個 WAR 包中部署的功能，
- 線上發布變慢：一旦代碼膨脹，服務啟動的時間就會變長，因此，急需一種方法能夠將應用的不同模塊的解耦，降低開發和部署成本，
想要解決上面這些問題，服務化的思想也就應運而生，
服務化
服務化就是把傳統的單機應用中通過 JAR 包依賴產生的本地方法呼叫，改造成通過 RPC 介面產生的遠程方法呼叫，在撰寫業務代碼時，對于通用的業務邏輯，把它抽象并獨立成為專門的模塊，對于代碼復用和業務理解有很大的好處，
以微博系統為例，微博既包含了內容模塊，也包含了訊息模塊和用戶模塊等，其中訊息模塊依賴內容模塊，訊息模塊和內容模塊又都依賴用戶模塊，當這三個模塊的代碼耦合在一起，應用啟動時，需要同時去加載每個模塊的代碼并連接對應的資源，一旦任何模塊的代碼出現 bug，或者依賴的資源出現問題，整個單體應用都會受到影響，
為此，首先可以把用戶模塊從單體應用中拆分出來，獨立成一個服務部署，以 RPC 介面的形式對外提供服務，微博和訊息模塊呼叫用戶介面，就從行程內的呼叫變成遠程 RPC 呼叫，這樣，用戶模塊就可以獨立開發、測驗、上線和運維，可以交由專門的團隊來做，與主模塊不耦合，進一步的可以再把訊息模塊也拆分出來作為獨立的模塊，交由專門的團隊來開發和維護，
可見通過服務化，可以解決單體應用膨脹、團隊開發耦合度高、協作效率低下的問題，
微服務
從 2014 年開始，容器化技術的成熟以及 DevOps 文化的興起，服務化的思想進一步演變為微服務，
微服務相比于服務化的不同可總結為以下四點：
- 服務拆分粒度更細：微服務可以說是更細維度的服務化，小到一個子模塊，只要該模塊依賴的資源與其他模塊都沒有關系，那么就可以拆分為一個微服務，
- 服務獨立部署：每個微服務都嚴格遵循獨立打包部署的準則，互不影響，比如一臺物理機上可以部署多個 Docker 實體，每個 Docker 實體可以部署一個微服務的代碼，
- 服務獨立維護：每個微服務都可以交由一個小團隊甚至個人來開發、測驗、發布和運維，并對整個生命周期負責，
- 服務治理能力要求高：因為拆分為微服務之后，服務的數量變多，因此需要有統一的服務治理平臺，來對各個服務進行管理，
以微博系統為例，可以進一步對內容模塊的功能進行拆分，比如內容模塊又包含了 feed 模塊、評論模塊和個人頁模塊，通過微服務化，將這三個模塊變成三個獨立的服務，每個服務依賴各自的資源，并獨立部署在不同的服務池中，可以由不同的開發人員進行維護，當評論服務需求變更時，只需要修改評論業務相關的代碼，并獨立上線發布；而 feed 服務和個人頁服務不需要變更，也不會受到發布可能帶來的變更影響，
由此可見，微服務化給服務的發布和部署，以及服務的保障帶來了諸多好處，
單體應用和微服務應用的區別
| 單體式應用 | 微服務應用 | |
|---|---|---|
| 行程數 | 將所有功能放到同一個行程中 | 將功能的每個元素放置到分離的多個服務行程中 |
| 拓展方式 | 通過復制整個應用到多臺服務器實作拓展 | 通過將不同的服務分布于不同的服務器，并按需復制服務的方式實作拓展 |
| 快速回應變更 | 部分更新，都需要重新部署整個應用 | 部署和升級都是獨立的，有助于大大提高系統變更的敏捷性 |
| 團隊結構 | 團隊結構呈現垂直化，每個團隊專門負責專門的一塊 | 團隊結構呈現扁平化，每個團隊服務一整個業務能力 |
| 可用性 | 一個服務的不穩定可能導致整個應用出現問題 | 一個服務不穩定，影響范圍比較小 |
| 創新性 | 很難引入新的技術和框架，所有功能都使用的同一種框架 | 每個微服務可以使用不同的語言和框架，引入新技術方便 |
總結
由單體應用進化到服務化拆分部署，隨著移動互聯網規模的不斷擴大，敏捷開發、持續交付、DevOps 理論的發展和實踐，以及容器化技術的成熟，微服務架構開始流行，
微服務的核心在于服務治理，微服務架構是將復雜臃腫的單體應用進行細粒度的服務化拆分，每個拆分出來的服務各自獨立打包部署，并交由小團隊進行開發和運維，從而極大地提高了應用交付的效率，
參考
https://time.geekbang.org/column/article/13882
https://zh.wikipedia.org/zh-cn/Microservices
https://dwz.cn/YBnkZedT
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/46425.html
標籤：架構設計