譯者 | 李騰輝

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Saga模式

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

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

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

控制比編排更容易實(shí)現(xiàn)，在控制機(jī)制下，只有控制器需要協(xié)調(diào)所有事件，而在編排中，每個(gè)微服務(wù)都必須監(jiān)聽(tīng)并對(duì)事件做出反應(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)。那么我們?cè)撊绾翁幚砑?jí)聯(lián)故障呢？

我們從電路斷路器中得到靈感，設(shè)計(jì)出熔斷模式來(lái)解決這個(gè)問(wèn)題。具體來(lái)說(shuō)，在客戶端和微服務(wù)之間，會(huì)設(shè)置一個(gè)熔斷器，用于追蹤失敗調(diào)用的次數(shù)，如果它超過(guò)閾值，它將觸發(fā)熔斷并快速失敗。在一段時(shí)間之后，熔斷器會(huì)再允許小部分請(qǐng)求通過(guò)來(lái)檢測(cè)服務(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人）開(kāi)發(fā)維護(hù)。那么，我們應(yīng)該怎么劃分服務(wù)呢？

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

業(yè)務(wù)能力是指可以產(chǎn)生價(jià)值的行為，例如，在一家航空公司中，業(yè)務(wù)能力可以是預(yù)訂、銷售、支付、座位分配等；子域概念來(lái)自于領(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ì)模式可以幫助我們更好地簡(jiǎn)化遷移的工作。

扼殺者模式

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

防腐層模式

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

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

圖4 –防腐層示例

總結(jié)

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

譯者介紹

李騰輝，51CTO社區(qū)編輯，目前在一家東南亞互聯(lián)網(wǎng)金融獨(dú)角獸擔(dān)任資深Java工程師，負(fù)責(zé)金融借貸平臺(tái)架構(gòu)設(shè)計(jì)及核心建設(shè)工作，對(duì)互聯(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