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

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

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

用戶界面層（User Interface Layer）：負(fù)責(zé)與用戶進(jìn)行交互的前端組件，常見的包括網(wǎng)頁界面或移動(dòng)應(yīng)用的界面。

業(yè)務(wù)邏輯層（Business Logic Layer）：與用戶界面和數(shù)據(jù)庫操作等進(jìn)行交互，根據(jù)業(yè)務(wù)需求進(jìn)行數(shù)據(jù)處理、驗(yàn)證、計(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)缺點(diǎn)如下。

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

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

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

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

服務(wù)網(wǎng)關(guān)：微服務(wù)統(tǒng)一入口，提供路由，鑒權(quán)、過濾、限流等功能。

注冊(cè)中心：所有微服務(wù)都注冊(cè)到注冊(cè)中心，負(fù)責(zé)服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)。

配置中心：用于管理微服務(wù)應(yīng)用程序的配置信息的中心化服務(wù)。它可以幫助開發(fā)人員集中管理應(yīng)用程序的配置信息，包括數(shù)據(jù)庫連接、API密鑰、環(huán)境變量等等。

服務(wù)通信：負(fù)責(zé)微服務(wù)之間的通信，提供各個(gè)微服務(wù)之間的數(shù)據(jù)交互。

服務(wù)監(jiān)控：對(duì)各個(gè)微服務(wù)實(shí)時(shí)監(jiān)控（每秒的請(qǐng)求數(shù)、成功數(shù)等），提供服務(wù)熔斷和服務(wù)降級(jí)解決雪崩效應(yīng)（一個(gè)服務(wù)宕機(jī)后，另外的服務(wù)還在相繼的調(diào)用它，導(dǎo)致其它的服務(wù)也宕機(jī)）。

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

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

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

基于云的應(yīng)用：微服務(wù)架構(gòu)因?qū)崿F(xiàn)彈性可擴(kuò)展和自動(dòng)化部署是云原生應(yīng)用的理想選擇。

復(fù)雜的企業(yè)應(yīng)用：傳統(tǒng)的單體式應(yīng)用程序隨著業(yè)務(wù)規(guī)模的擴(kuò)大變得越來越復(fù)雜。使用微服務(wù)可以將應(yīng)用程序拆分成更小的部分，使開發(fā)更加容易且每個(gè)服務(wù)更便于管理。

高負(fù)載應(yīng)用：面對(duì)高負(fù)載場(chǎng)景，微服務(wù)的水平擴(kuò)展能力可以通過添加更多的實(shí)例進(jìn)行輕松處理。

多語言和多技術(shù)棧應(yīng)用：每個(gè)微服務(wù)可以使用不同的編程語言和技術(shù)堆棧，因此可以更好地滿足不同的需求。

敏捷開發(fā)需求：微服務(wù)可以實(shí)現(xiàn)團(tuán)隊(duì)的敏捷開發(fā)，因?yàn)殚_發(fā)人員可以在服務(wù)級(jí)別上進(jìn)行更小的更改，而不必?fù)?dān)心影響整個(gè)系統(tǒng)。

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

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

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

單一職責(zé)原則：每個(gè)服務(wù)應(yīng)該只有一個(gè)明確的職責(zé)，不應(yīng)該承擔(dān)過多的職責(zé)。

服務(wù)自治原則：每個(gè)服務(wù)應(yīng)該有自己的數(shù)據(jù)庫和業(yè)務(wù)邏輯，不應(yīng)該依賴于其他服務(wù)的數(shù)據(jù)和業(yè)務(wù)邏輯。例如電商系統(tǒng)中用戶管理微服務(wù)的用戶數(shù)據(jù)存放在用戶信息數(shù)據(jù)庫，訂單管理微服務(wù)中的訂單信息存放在訂單信息數(shù)據(jù)庫中，同理會(huì)員微服務(wù)、物流微服務(wù)都應(yīng)對(duì)應(yīng)有各自的數(shù)據(jù)庫進(jìn)行數(shù)據(jù)管理。

按領(lǐng)域邊界拆分：根據(jù)業(yè)務(wù)領(lǐng)域的不同將應(yīng)用拆分為不同的服務(wù)，每個(gè)服務(wù)可以通過 API 或消息隊(duì)列等方式與其他服務(wù)通信。業(yè)務(wù)領(lǐng)域可以根據(jù)功能職責(zé)劃分，例如用戶管理、基本商品信息、物流物流等模塊進(jìn)行拆分，也可以根據(jù)非功能進(jìn)行業(yè)務(wù)領(lǐng)域邊界拆分，如穩(wěn)定業(yè)務(wù)和高頻迭代業(yè)務(wù)、常規(guī)并發(fā)量業(yè)務(wù)和超高并發(fā)量的業(yè)務(wù)等。

接口隔離原則：為提高應(yīng)用整體安全性，各個(gè)微服務(wù)之間的接口應(yīng)該只暴露必要的操作，而不是全部暴露，即使用多個(gè)專門的接口，而不使用單一的總接口。例如用戶管理微服務(wù)提供了一組跟用戶相關(guān)的API供其它微服務(wù)調(diào)用，比如：注冊(cè)、登錄、獲取用戶信息等，但刪除用戶的接口僅限后臺(tái)管理微服務(wù)調(diào)用，若不加限制地被其他業(yè)務(wù)系統(tǒng)調(diào)用，就有可能導(dǎo)致誤刪用戶。

可重用性原則：將通用的代碼封裝為獨(dú)立的庫，多個(gè)服務(wù)可以共享這些庫。

審核編輯：黃飛