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

它是什么?

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

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

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

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

> Monolithic application with multiple clients (source: author)

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

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

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

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

> Microservices! (source: author)

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

• 后端團(tuán)隊(duì)通常負(fù)責(zé)一項(xiàng)服務(wù)，而不再互相絆倒。
• 單個(gè)微服務(wù)是輕量級(jí)的，可定制的，分離的，并且易于擴(kuò)展。

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

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

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

> BFF! (source: author)

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

BFF的好處

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

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

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

…但請(qǐng)確保避免這些陷阱

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