什麼是微服務？為什麼會有微服務？讓我們帶著這些疑問開始我們的探索。 我們先看下維基百科和百度百科給出的定義： 維基百科：2014年，Martin Fowler 與 James Lewis 共同提出了微服務的概念，定義了微服務是由以單一應用程式構成的小服務，自己擁有自己的行程與輕量化處理，服務依業務功 ...
什麼是微服務？為什麼會有微服務？讓我們帶著這些疑問開始我們的探索。
我們先看下維基百科和百度百科給出的定義：
維基百科：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
