譯者 | 李騰輝

數(shù)十年來，人們一直采用單體構(gòu)架來開發(fā)應(yīng)用程序，而現(xiàn)在越來越多的人正在轉(zhuǎn)向微服務(wù)架構(gòu)。微服務(wù)架構(gòu)可以為我們帶來更快的開發(fā)迭代速度，更高的可擴(kuò)展性、可靠性，以及靈活性—使用更合適的技術(shù)棧來開發(fā)各個(gè)組件。微服務(wù)架構(gòu)依賴于各個(gè)獨(dú)立部署的微服務(wù)，每個(gè)微服務(wù)都有自己獨(dú)特的業(yè)務(wù)邏輯和數(shù)據(jù)庫，對它的測試、增強(qiáng)和擴(kuò)縮容也與其他服務(wù)無關(guān)。然而，微服務(wù)架構(gòu)也面臨著許多挑戰(zhàn)，為了解決那些最常見的問題，一些設(shè)計(jì)模式被廣泛地采用和改進(jìn)，本文我們將介紹其中最重要的一部分。

必備的設(shè)計(jì)模式

在微服務(wù)架構(gòu)中，有超過8種必備的設(shè)計(jì)模式，根據(jù)你正在開發(fā)的應(yīng)用類型不同，我們將它們分為兩大類——綠地應(yīng)用（Greenfield application）和棕地應(yīng)用（Brownfield application）。接下來，我們將更詳細(xì)地了解這些模式。

適合綠地應(yīng)用的設(shè)計(jì)模式

當(dāng)我們從頭開始設(shè)計(jì)應(yīng)用時(shí)，我們可以隨心所欲地采用微服務(wù)所需的各種最新、最先進(jìn)的設(shè)計(jì)模式，現(xiàn)在讓我們來一探究竟。

API網(wǎng)關(guān)模式

當(dāng)你將整個(gè)業(yè)務(wù)拆分為多個(gè)微服務(wù)時(shí)會(huì)遇到下述問題：

你如何處理諸如鑒權(quán)、限流、重試、負(fù)載均衡、服務(wù)發(fā)現(xiàn)等問題？

你如何避免由于客戶端直連微服務(wù)引發(fā)的網(wǎng)絡(luò)拓?fù)浠靵y和耦合過高的問題？

如果客戶端只需要部分?jǐn)?shù)據(jù)集，誰來做數(shù)據(jù)過濾和映射？

如果客戶端需要調(diào)用多個(gè)微服務(wù)才能獲取到完整數(shù)據(jù)，誰來做數(shù)據(jù)聚合？

為了解決這些問題，API網(wǎng)關(guān)應(yīng)運(yùn)而生，它位于客戶端和微服務(wù)之間，具有反向代理、請求聚合、優(yōu)雅下線、服務(wù)發(fā)現(xiàn)等功能，它還可以根據(jù)客戶端的不同選擇暴露不同的API接口。

圖1 – API網(wǎng)關(guān)示例UI組合模式

在這種模式下，微服務(wù)由負(fù)責(zé)具體業(yè)務(wù)的不同團(tuán)隊(duì)開發(fā)。而某些UI頁面可能需要來自多個(gè)微服務(wù)的數(shù)據(jù)，例如，購物網(wǎng)站包含類目、購物車、購買選項(xiàng)、用戶評價(jià)等功能，這些數(shù)據(jù)歸屬于各個(gè)微服務(wù)，由不同的團(tuán)隊(duì)負(fù)責(zé)。如何協(xié)調(diào)這個(gè)問題呢？

UI團(tuán)隊(duì)可以創(chuàng)建一個(gè)頁面框架，通過組合多個(gè)UI組件來構(gòu)建完整的頁面，這種框架也稱為單頁應(yīng)用（SPA, single-page application），像AngularJS 和 ReactJS 等前端框架都支持這一功能。這種模式還帶來了更好的用戶體驗(yàn)，允許用戶刷新任何指定的頁面區(qū)域。

獨(dú)立數(shù)據(jù)庫模式

微服務(wù)需要設(shè)計(jì)得獨(dú)立且松耦合，那么對應(yīng)的數(shù)據(jù)庫架構(gòu)應(yīng)該是怎樣的呢？有以下一些問題需要考量：

一個(gè)具體的業(yè)務(wù)場景可能涉及到多個(gè)服務(wù)的查詢、聯(lián)表、持久化等數(shù)據(jù)庫操作，而這些服務(wù)由不同的團(tuán)隊(duì)負(fù)責(zé)

在異構(gòu)的微服務(wù)架構(gòu)中，每個(gè)微服務(wù)可能有不同的數(shù)據(jù)存儲(chǔ)要求，如非結(jié)構(gòu)化數(shù)據(jù)（NoSQL數(shù)據(jù)庫）、結(jié)構(gòu)化數(shù)據(jù)（關(guān)系型數(shù)據(jù)庫）、圖數(shù)據(jù)（Neo4j）

考慮到可伸縮性，數(shù)據(jù)庫需要有備份和分片

圖2 –服務(wù)配置獨(dú)立數(shù)據(jù)庫示例

一個(gè)微服務(wù)事務(wù)必須限制在它自己的數(shù)據(jù)庫中，其它需要該類數(shù)據(jù)的服務(wù)必須調(diào)用這個(gè)微服務(wù)的API接口。如果你使用的是關(guān)系型數(shù)據(jù)庫，那么每個(gè)服務(wù)使用自己獨(dú)立的庫有利于保證數(shù)據(jù)的私有性。同時(shí)為了更好地隔絕數(shù)據(jù)訪問，最好為每個(gè)服務(wù)分配不同的數(shù)據(jù)庫賬號(hào)，這樣確保了開發(fā)人員不能繞過微服務(wù)的API而直接訪問數(shù)據(jù)庫。

獨(dú)立數(shù)據(jù)庫模式使得每個(gè)微服務(wù)都可以選用最合適的數(shù)據(jù)庫類型，如使用Neo4j用于社交圖數(shù)據(jù)，使用Elasticsearch用于文本搜索。

Saga模式

當(dāng)我們?yōu)槊總€(gè)服務(wù)配置一個(gè)獨(dú)立數(shù)據(jù)庫時(shí)，在實(shí)現(xiàn)跨服務(wù)事務(wù)時(shí)會(huì)出現(xiàn)問題，因?yàn)樵谶@種情況下，本地ACID已經(jīng)無法處理，我們?nèi)绾伪ＷC數(shù)據(jù)一致性呢？解決方式是使用saga模式。saga是指一系列本地事務(wù)，其中每個(gè)本地事務(wù)更新完數(shù)據(jù)庫后，會(huì)發(fā)布事件以觸發(fā)下一個(gè)本地事務(wù)，saga模式還要求在任何本地事務(wù)失敗時(shí)進(jìn)行補(bǔ)償。

有兩種實(shí)現(xiàn)saga模式的方式:

• 編排（Choreography）——去掉控制器，由每個(gè)微服務(wù)負(fù)責(zé)監(jiān)聽和發(fā)布事件，并在失敗時(shí)啟用補(bǔ)償事件。
  

控制比編排更容易實(shí)現(xiàn)，在控制機(jī)制下，只有控制器需要協(xié)調(diào)所有事件，而在編排中，每個(gè)微服務(wù)都必須監(jiān)聽并對事件做出反應(yīng)。

熔斷模式

在微服務(wù)架構(gòu)中，一個(gè)操作會(huì)涉及調(diào)用多個(gè)微服務(wù)，如果其中一個(gè)下游的服務(wù)出現(xiàn)故障，它仍會(huì)繼續(xù)調(diào)用該下游服務(wù)，最終導(dǎo)致耗盡所有的網(wǎng)絡(luò)資源，同時(shí)也會(huì)造成較差的用戶體驗(yàn)。那么我們該如何處理級(jí)聯(lián)故障呢？

我們從電路斷路器中得到靈感，設(shè)計(jì)出熔斷模式來解決這個(gè)問題。具體來說，在客戶端和微服務(wù)之間，會(huì)設(shè)置一個(gè)熔斷器，用于追蹤失敗調(diào)用的次數(shù)，如果它超過閾值，它將觸發(fā)熔斷并快速失敗。在一段時(shí)間之后，熔斷器會(huì)再允許小部分請求通過來檢測服務(wù)是否正常，如正常則恢復(fù)流量，否則繼續(xù)保持?jǐn)嗦芬欢螘r(shí)間。

圖3 –熔斷器狀態(tài)機(jī)

按業(yè)務(wù)或子域劃分模式

在微服務(wù)架構(gòu)中，復(fù)雜的大型應(yīng)用必須做到合理劃分、高內(nèi)聚、低耦合，每個(gè)微服務(wù)還應(yīng)該是自治的，并且足夠小，可以由"批薩大小"的團(tuán)隊(duì)（6-8人）開發(fā)維護(hù)。那么，我們應(yīng)該怎么劃分服務(wù)呢？

總體來說有兩種劃分方式——按業(yè)務(wù)能力或者子域：

業(yè)務(wù)能力是指可以產(chǎn)生價(jià)值的行為，例如，在一家航空公司中，業(yè)務(wù)能力可以是預(yù)訂、銷售、支付、座位分配等；子域概念來自于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain-Design Pattern, DDD），一個(gè)領(lǐng)域由多個(gè)子域組成，如產(chǎn)品目錄、訂單管理、配送管理等。

適合棕地應(yīng)用的設(shè)計(jì)模式

由于互聯(lián)網(wǎng)應(yīng)用已經(jīng)發(fā)展了數(shù)十年，大約有80%的公司的業(yè)務(wù)是基于現(xiàn)有的應(yīng)用運(yùn)作的，這些應(yīng)用被稱作棕地應(yīng)用。將棕地應(yīng)用程序遷移到微服務(wù)架構(gòu)是極具挑戰(zhàn)性的工作。讓我們看看有哪些設(shè)計(jì)模式可以幫助我們更好地簡化遷移的工作。

扼殺者模式

扼殺者模式，取名來自于藤蔓這種植物，它通過纏繞殺死它所依附的樹木。在這種模式下，單體應(yīng)用的各功能被逐步地被替換為微服務(wù)，而對于客戶端來說，由于外部API保持不變，客戶端感知不到任何變化，隨著轉(zhuǎn)換進(jìn)度的推進(jìn)，最終所有功能都被重構(gòu)為微服務(wù)，新架構(gòu)"扼殺"取代了原來的單體架構(gòu)。

防腐層模式

當(dāng)新應(yīng)用需要與遺留應(yīng)用集成時(shí)，過時(shí)的基礎(chǔ)協(xié)議、API和數(shù)據(jù)模型是一個(gè)讓人頭大的難題。如果妥協(xié)沿用舊模式和舊語義，可能會(huì)限制和破壞新應(yīng)用的技術(shù)設(shè)計(jì)。要如何才能避免這個(gè)問題呢？

我們需要新增一個(gè)防腐層來轉(zhuǎn)換兩個(gè)系統(tǒng)之間的通信，防腐層同時(shí)兼容新應(yīng)用和舊應(yīng)用的數(shù)據(jù)模型，并根據(jù)與它通信的對象決定采用哪種通信方式。這樣就實(shí)現(xiàn)了雙贏，既不用更改舊應(yīng)用邏輯，也確保新應(yīng)用無需在設(shè)計(jì)和技術(shù)上做妥協(xié)。

圖4 –防腐層示例

總結(jié)

微服務(wù)架構(gòu)為開發(fā)人員帶來了很大的靈活性，但隨著要管理的組件數(shù)量的增加，也帶來了許多難題。在本文中，我們介紹了對于微服務(wù)應(yīng)用開發(fā)來說最必不可少的幾種設(shè)計(jì)模式，供讀者了解和學(xué)習(xí)。

譯者介紹

李騰輝，51CTO社區(qū)編輯，目前在一家東南亞互聯(lián)網(wǎng)金融獨(dú)角獸擔(dān)任資深Java工程師，負(fù)責(zé)金融借貸平臺(tái)架構(gòu)設(shè)計(jì)及核心建設(shè)工作，對互聯(lián)網(wǎng)金融架構(gòu)、微服務(wù)體系有較深入的研究，期望在互金領(lǐng)域持續(xù)深耕。

原文標(biāo)題：Popular Design Patterns for Microservices Architectures，作者：Rajesh Bhojwani

鏈接：https://dzone.com/articles/popular-design-patterns-for-microservices-architec