客戶端定制的微服務(wù)

它是什么?

后端到后端的體系結(jié)構(gòu)模式描述了一個世界，其中每個客戶端應(yīng)用程序都有自己的服務(wù)器端組件-特定前端的后端。

如果您有多個具有完全不同需求且都消耗相同基礎(chǔ)資源的客戶端接口，則此模式非常適用。 現(xiàn)實世界中最常見的示例是同時具有Web和移動客戶端的應(yīng)用程序。

要了解為什么"后端對前端"有用，讓我們逐步了解一下網(wǎng)絡(luò)體系結(jié)構(gòu)的一些發(fā)展。

單個通用服務(wù)器上有多個客戶端

> Monolithic application with multiple clients (source: author)

簡單就好吧? 實際上，這只是……但僅限于某一點。 如果您的應(yīng)用程序足夠小，則此體系結(jié)構(gòu)絕對可以正常工作! 但是，整料傾向于隨尺寸分解。 您可能會聽到您的團隊開始說類似……

• 我們的服務(wù)器太臃腫了! 特定于客戶的控制流隨處可見，我們正在努力添加功能而不引入副作用。
• 沒有合并沖突，我無法提交任何更改。 N個團隊正在更改此確切的代碼。 一些我們幾乎不交談的東西!
• 構(gòu)建和測試將永遠運行，而調(diào)試一次間歇性的測試失敗將需要幾天的時間。

這些類型的問題催化了微服務(wù)的興起。

具有微服務(wù)架構(gòu)的多個客戶端

> Microservices! (source: author)

如果在適當?shù)姆秶鷥?nèi)實施微服務(wù)，那么微服務(wù)非常適合擴展規(guī)模并有助于解決一系列問題。

• 后端團隊通常負責一項服務(wù)，而不再互相絆倒。
• 單個微服務(wù)是輕量級的，可定制的，分離的，并且易于擴展。

但是，前端團隊之間仍然存在邊界問題。 處理多個客戶端的職責仍然編碼在一項或多項服務(wù)中。 前端工程師正在努力將多個用例塞入一個API層，并且客戶體驗開始受到影響。 網(wǎng)絡(luò)團隊和移動團隊之間的緊張關(guān)系正在加劇。

為什么我們不能像對待微服務(wù)一樣，圍繞不同的客戶劃定技術(shù)和組織界限?

具有專用后端和微服務(wù)架構(gòu)的多個客戶端

> BFF! (source: author)

輸入后端換前端! 我們利用這樣的事實，即我們的客戶有不同的需求來劃定有用的界限。 BFF應(yīng)用程序是輕量級轉(zhuǎn)換層，可將單個客戶端與下游服務(wù)分離開來，并且僅服務(wù)于一個前端。

BFF的好處

• 前端團隊可以享受其客戶端應(yīng)用程序及其底層資源消耗層的所有權(quán); 導(dǎo)致高速發(fā)展。
• 移動團隊最終能夠進行更改，例如有效載荷大小和降低頻率，而不必擴展和派發(fā)最初為基于Web的用例開發(fā)的API。
• 客戶端應(yīng)用程序只需要知道一個資源服務(wù)器-封裝規(guī)則!
• BFF是特定于客戶的，一維的且與語言無關(guān)。 選擇正確的API技術(shù)從未如此簡單。
• 客戶端應(yīng)用程序受到保護，免受下游服務(wù)中API的更改。
• 網(wǎng)絡(luò)和移動團隊不再為誰首先合并以及誰必須處理合并沖突而戰(zhàn)。

TL; DR，如果…，則使用BFF

• 您有多個具有不同需求的客戶端正在使用相同的基礎(chǔ)資源。
• 您希望基于每個客戶端優(yōu)化后端API，數(shù)據(jù)處理或技術(shù)堆棧。
• 您的客戶需要使用需要大量后端聚合的數(shù)據(jù)。
• 開發(fā)團隊在功能交付方面存在沖突，可以從增加的自主權(quán)中受益。

…但請確保避免這些陷阱

• 跨BFF復(fù)制邏輯。 復(fù)制代碼是同一代碼的多個實例，這些實例解決了相同的用例，并且將經(jīng)歷相同的更改。 例如，執(zhí)行特定的業(yè)務(wù)規(guī)則。
• 不遵循良好的DevOps慣例。 更多的后端意味著更多的可部署服務(wù)和增加的操作復(fù)雜性。
• 無意間將您的BFF轉(zhuǎn)換為功能完善的API服務(wù)器，其中包含業(yè)務(wù)邏輯，數(shù)據(jù)庫，安全性和廚房接收器。 保持BFF輕巧，并專注于主要用例：高效地將數(shù)據(jù)轉(zhuǎn)換為客戶。
• 無法識別或調(diào)整您的BFF是單點故障的事實。 您的BFF可能會與許多服務(wù)通信的事實意味著任何下游服務(wù)的故障都可能傳播到您的BFF。 考慮使用冗余和異步性來解決這些問題，就像使用其他類型的微服務(wù)一樣。