什麼情況需要微服務（什麼是微服務）

2023-10-04 04:37:36 2

什麼是微服務？為什麼會有微服務？讓我們帶著這些疑問開始我們的探索。

我們先看下維基百科和百度百科給出的定義：

維基百科：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 理論的發展和實踐，以及容器化技術的成熟，微服務架構開始流行。

微服務的核心在於服務治理，微服務架構是將複雜臃腫的單體應用進行細粒度的服務化拆分，每個拆分出來的服務各自獨立打包部署，並交由小團隊進行開發和運維，從而極大地提高了應用交付的效率。