微服務(wù)作為一種軟件架構(gòu)，正得到越來越多的關(guān)注。微服務(wù)架構(gòu)典型的應(yīng)用行業(yè)有電商、游戲、直播、社交、物聯(lián)網(wǎng)等等。具體的案例應(yīng)用有淘寶、支付寶、微信、微博等應(yīng)用，新興案例應(yīng)用有拼多多、美團、餓了么等應(yīng)用。

但微服務(wù)到底是什么意思？什么樣的架構(gòu)可以叫做微服務(wù)？如何在不同場景下正確使用微服務(wù)？請聽文檔君為您一一解答。

圖片

微服務(wù)之前最常用的架構(gòu)是單體架構(gòu)，俗稱“一個jar（war）包打天下”。即在一個jar包工程中采用MVC（模型(Model)-視圖(View)-控制器(controller)）架構(gòu)，把系統(tǒng)中所有的功能、模塊耦合在一個應(yīng)用中的架構(gòu)方式。單體架構(gòu)的應(yīng)用程序通常由三個主要組件構(gòu)成：

圖片

• 用戶界面層（User Interface Layer）：負(fù)責(zé)與用戶進行交互的前端組件，常見的包括網(wǎng)頁界面或移動應(yīng)用的界面。
• 業(yè)務(wù)邏輯層（Business Logic Layer）：與用戶界面和數(shù)據(jù)庫操作等進行交互，根據(jù)業(yè)務(wù)需求進行數(shù)據(jù)處理、驗證、計算等操作，主要負(fù)責(zé)處理業(yè)務(wù)規(guī)則和邏輯。
• 數(shù)據(jù)訪問層（Data Access Layer）：用于持久化數(shù)據(jù)的后端數(shù)據(jù)庫，通常使用關(guān)系型數(shù)據(jù)庫（如MySQL、Oracle等）。

單體架構(gòu)的優(yōu)缺點如下。

圖片

隨著業(yè)務(wù)擴大，需求持續(xù)增加，單體架構(gòu)很難滿足業(yè)務(wù)快速變化的需要。一方面，代碼的可維護性，擴展性，靈活性在降低，另一方面，系統(tǒng)的測試、構(gòu)建、維護成本在增加，于是隨著應(yīng)用程序越來越龐大，最終需要進行改造和重構(gòu)。為了將復(fù)雜問題簡單化，解決單體架構(gòu)帶來的問題，微服務(wù)架構(gòu)應(yīng)運而生，是具有更高靈活性和可伸縮性的架構(gòu)模式。

微服務(wù)架構(gòu)（Microservices Architecture）是將單一的應(yīng)用程序拆分成一個一個小型的、松耦合的服務(wù)模塊。每個模塊運行在自己的進程中，服務(wù)模塊之間通過輕量級的通信機制（通常是HTTP RESTful API）相互通信，這些服務(wù)模塊們，一起組成了一個完整的應(yīng)用系統(tǒng)。每個服務(wù)模塊都圍繞具體業(yè)務(wù)進行構(gòu)建開發(fā)，并且能夠被獨立地部署到生產(chǎn)環(huán)境。微服務(wù)中的各個服務(wù)模塊無需使用統(tǒng)一的技術(shù)棧（如編程語言、數(shù)據(jù)庫等），技術(shù)?？梢愿鶕?jù)不同的業(yè)務(wù)服務(wù)和開發(fā)團隊進行靈活選擇，以保證最低限度的集中式管理。

微服務(wù)架構(gòu)除了有各個業(yè)務(wù)微服務(wù)，還有多種微服務(wù)組件，如服務(wù)網(wǎng)關(guān)、注冊中心等，提供微服務(wù)治理，下圖是微服務(wù)架構(gòu)圖。

圖片

微服務(wù)架構(gòu)的核心組件的功能介紹如下：

• 服務(wù)網(wǎng)關(guān)：微服務(wù)統(tǒng)一入口，提供路由，鑒權(quán)、過濾、限流等功能。
• 注冊中心：所有微服務(wù)都注冊到注冊中心，負(fù)責(zé)服務(wù)注冊和服務(wù)發(fā)現(xiàn)。
• 配置中心：用于管理微服務(wù)應(yīng)用程序的配置信息的中心化服務(wù)。它可以幫助開發(fā)人員集中管理應(yīng)用程序的配置信息，包括數(shù)據(jù)庫連接、API密鑰、環(huán)境變量等等。
• 服務(wù)通信：負(fù)責(zé)微服務(wù)之間的通信，提供各個微服務(wù)之間的數(shù)據(jù)交互。
• 服務(wù)監(jiān)控：對各個微服務(wù)實時監(jiān)控（每秒的請求數(shù)、成功數(shù)等），提供服務(wù)熔斷和服務(wù)降級解決雪崩效應(yīng)（一個服務(wù)宕機后，另外的服務(wù)還在相繼的調(diào)用它，導(dǎo)致其它的服務(wù)也宕機）。

微服務(wù)架構(gòu)的優(yōu)勢如下。

圖片

圖片

在產(chǎn)品初期，團隊規(guī)模較小，業(yè)務(wù)復(fù)雜度較低時，一般選擇單體架構(gòu)。微服務(wù)架構(gòu)相比于單體架構(gòu)要求更高的資源配置和團隊技術(shù)水平，只有對業(yè)務(wù)規(guī)模、高并發(fā)、迭代維護等有一定要求的時候，我們可以考慮結(jié)合實際需求和團隊技術(shù)水平，權(quán)衡利弊，去合理規(guī)劃和設(shè)計使用微服務(wù)架構(gòu)。

微服務(wù)架構(gòu)適用于以下場景：

• 基于云的應(yīng)用：微服務(wù)架構(gòu)因?qū)崿F(xiàn)彈性可擴展和自動化部署是云原生應(yīng)用的理想選擇。
• 復(fù)雜的企業(yè)應(yīng)用：傳統(tǒng)的單體式應(yīng)用程序隨著業(yè)務(wù)規(guī)模的擴大變得越來越復(fù)雜。使用微服務(wù)可以將應(yīng)用程序拆分成更小的部分，使開發(fā)更加容易且每個服務(wù)更便于管理。
• 高負(fù)載應(yīng)用：面對高負(fù)載場景，微服務(wù)的水平擴展能力可以通過添加更多的實例進行輕松處理。
• 多語言和多技術(shù)棧應(yīng)用：每個微服務(wù)可以使用不同的編程語言和技術(shù)堆棧，因此可以更好地滿足不同的需求。
• 敏捷開發(fā)需求：微服務(wù)可以實現(xiàn)團隊的敏捷開發(fā)，因為開發(fā)人員可以在服務(wù)級別上進行更小的更改，而不必?fù)?dān)心影響整個系統(tǒng)。

總的來說，微服務(wù)架構(gòu)適用于任何需要靈活、高度可擴展且易于維護的應(yīng)用程序。

圖片

在微服務(wù)架構(gòu)應(yīng)用開發(fā)的時候，微服務(wù)拆分必須遵循一些原則。通過之前微服務(wù)架構(gòu)的介紹，我們可以知道選擇微服務(wù)架構(gòu)是為了將復(fù)雜問題簡單化?！安煌跣模降檬冀K”，只有這樣在后續(xù)拆分過程中，才不會忘記最初的目的。

微服務(wù)拆分原則包括：

• 單一職責(zé)原則：每個服務(wù)應(yīng)該只有一個明確的職責(zé)，不應(yīng)該承擔(dān)過多的職責(zé)。
• 服務(wù)自治原則：每個服務(wù)應(yīng)該有自己的數(shù)據(jù)庫和業(yè)務(wù)邏輯，不應(yīng)該依賴于其他服務(wù)的數(shù)據(jù)和業(yè)務(wù)邏輯。例如電商系統(tǒng)中用戶管理微服務(wù)的用戶數(shù)據(jù)存放在用戶信息數(shù)據(jù)庫，訂單管理微服務(wù)中的訂單信息存放在訂單信息數(shù)據(jù)庫中，同理會員微服務(wù)、物流微服務(wù)都應(yīng)對應(yīng)有各自的數(shù)據(jù)庫進行數(shù)據(jù)管理。
• 按領(lǐng)域邊界拆分：根據(jù)業(yè)務(wù)領(lǐng)域的不同將應(yīng)用拆分為不同的服務(wù)，每個服務(wù)可以通過 API 或消息隊列等方式與其他服務(wù)通信。業(yè)務(wù)領(lǐng)域可以根據(jù)功能職責(zé)劃分，例如用戶管理、基本商品信息、物流物流等模塊進行拆分，也可以根據(jù)非功能進行業(yè)務(wù)領(lǐng)域邊界拆分，如穩(wěn)定業(yè)務(wù)和高頻迭代業(yè)務(wù)、常規(guī)并發(fā)量業(yè)務(wù)和超高并發(fā)量的業(yè)務(wù)等。
• 接口隔離原則：為提高應(yīng)用整體安全性，各個微服務(wù)之間的接口應(yīng)該只暴露必要的操作，而不是全部暴露，即使用多個專門的接口，而不使用單一的總接口。例如用戶管理微服務(wù)提供了一組跟用戶相關(guān)的API供其它微服務(wù)調(diào)用，比如：注冊、登錄、獲取用戶信息等，但刪除用戶的接口僅限后臺管理微服務(wù)調(diào)用，若不加限制地被其他業(yè)務(wù)系統(tǒng)調(diào)用，就有可能導(dǎo)致誤刪用戶。
• 可重用性原則：將通用的代碼封裝為獨立的庫，多個服務(wù)可以共享這些庫。

圖片