前端架構模式之如何理解支持前端的后端

這篇文章主要講解了“前端架構模式之如何理解支持前端的后端”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“前端架構模式之如何理解支持前端的后端”吧！

客戶端定制的微服務

它是什么?

后端到后端的體系結構模式描述了一個世界，其中每個客戶端應用程序都有自己的服務器端組件-特定前端的后端。

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

要了解為什么"后端對前端"有用，讓我們逐步了解一下網絡體系結構的一些發展。

單個通用服務器上有多個客戶端

> Monolithic application with multiple clients (source: author)

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

• 我們的服務器太臃腫了! 特定于客戶的控制流隨處可見，我們正在努力添加功能而不引入副作用。

• 沒有合并沖突，我無法提交任何更改。 N個團隊正在更改此確切的代碼。 一些我們幾乎不交談的東西!

• 構建和測試將永遠運行，而調試一次間歇性的測試失敗將需要幾天的時間。

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

具有微服務架構的多個客戶端

> Microservices! (source: author)

如果在適當的范圍內實施微服務，那么微服務非常適合擴展規模并有助于解決一系列問題。

• 后端團隊通常負責一項服務，而不再互相絆倒。

• 單個微服務是輕量級的，可定制的，分離的，并且易于擴展。

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

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

具有專用后端和微服務架構的多個客戶端

> BFF! (source: author)

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

BFF的好處

• 前端團隊可以享受其客戶端應用程序及其底層資源消耗層的所有權; 導致高速發展。

• 移動團隊最終能夠進行更改，例如有效載荷大小和降低頻率，而不必擴展和派發最初為基于Web的用例開發的API。

• 客戶端應用程序只需要知道一個資源服務器-封裝規則!

• BFF是特定于客戶的，一維的且與語言無關。 選擇正確的API技術從未如此簡單。

• 客戶端應用程序受到保護，免受下游服務中API的更改。

• 網絡和移動團隊不再為誰首先合并以及誰必須處理合并沖突而戰。

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

• 您有多個具有不同需求的客戶端正在使用相同的基礎資源。

• 您希望基于每個客戶端優化后端API，數據處理或技術堆棧。

• 您的客戶需要使用需要大量后端聚合的數據。

• 開發團隊在功能交付方面存在沖突，可以從增加的自主權中受益。

…但請確保避免這些陷阱

• 跨BFF復制邏輯。 復制代碼是同一代碼的多個實例，這些實例解決了相同的用例，并且將經歷相同的更改。 例如，執行特定的業務規則。

• 不遵循良好的DevOps慣例。 更多的后端意味著更多的可部署服務和增加的操作復雜性。

• 無意間將您的BFF轉換為功能完善的API服務器，其中包含業務邏輯，數據庫，安全性和廚房接收器。  保持BFF輕巧，并專注于主要用例：高效地將數據轉換為客戶。

• 無法識別或調整您的BFF是單點故障的事實。 您的BFF可能會與許多服務通信的事實意味著任何下游服務的故障都可能傳播到您的BFF。  考慮使用冗余和異步性來解決這些問題，就像使用其他類型的微服務一樣。

感謝各位的閱讀，以上就是“前端架構模式之如何理解支持前端的后端”的內容了，經過本文的學習后，相信大家對前端架構模式之如何理解支持前端的后端這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！