云架构（五）BBF模式

本文主要是介绍云架构（五）BBF模式，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

BFF模式（Backends for Frontends pattern）-  

https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends。

创建单独的后台服务用以提供给特定的前端或者接口。当你希望避免为多个接口定制单独的后台时，此模式非常有用。这个模式最开始由Sam Newman提出。

背景和问题

1. 应用程序最初可能针对web、UI。一般来说后端服务是和前端并行开发的，它提供该前端所需的功能。随着应用程序用户群的增长，开发了必须与相同后端交互的移动应用程序。后端服务成为通用后端，同时满足桌面和移动接口的需求。
2. 但是在屏幕大小、性能和显示限制方面，移动设备的功能与桌面浏览器有很大的不同。因此，对移动应用程序后端的需求不同于web、UI。
3. 这些差异导致了后端需求的竞争。后端需要定期进行重大更改，以同时服务于web、UI和移动应用程序。通常，独立的接口团队负责每个前端，导致后端成为开发过程中的瓶颈。冲突的更新需求，以及保持服务在两个前端工作的需要，可能会导致在单个部署资源上花费大量精力。
4. 
5. 当开发活动集中于后端服务时，可能会创建一个单独的团队来管理和维护后端。最终这会导致接口和后端开发团队之间的脱节，给后端团队带来负担，以平衡不同前端团队的需求。当一个接口团队需要对后端进行更改时，必须先与其他接口团队验证这些更改，然后才能将其集成到后端。

解决办法 

1. 为每个用户接口创建一个后端。微调每个后端的行为和性能，以最好地匹配前端环境的需求，而不必担心影响其他前端体验。
2. 
3. 由于每个后端都特定于一个接口，因此可以针对该接口进行优化。因此，它将比试图满足所有接口需求的通用后端更小、更不复杂，并且可能更快。每个接口团队都有自主权来控制他们自己的后端，而不依赖于集中的后端开发团队。这使接口团队在语言选择、发布节奏、工作负载优先级和后端特性集成方面具有灵活性。
4. 关于它更多的信息，可以访问：https://samnewman.io/patterns/architectural/bff/

问题和考虑

1. 考虑由多少个后端要部署。
2. 如果不同的接口(例如移动客户端)将发出相同的请求，请考虑是否有必要为每个接口实现一个后端，还是单个后端就足够了。
3. 在实现此模式时，不同服务的代码复制极有可能发生。
4. 以前端为中心的后端服务应该只包含特定于客户端的逻辑和行为。一般业务逻辑和其他全局特性应该在应用程序的其他地方进行管理。
5. 考虑一下这种模式如何反映在开发团队的职责中。
6. 考虑一下实现这个模式需要多长时间。当您继续支持现有的通用后端时，构建新后端的工作是否会带来技术债务?

什么时候使用 

1. 共享的或通用的后端服务必须用大量的开发开销来维护。
2. 你需要针对特定客户端接口的需求优化后端。
3. 对通用后端进行定制以适应多个接口。
4. 某个编程语言更适合特定用户接口的后端，不是所有用户接口。

不适用 

1. 当接口发送相同或相似的请求给后台。
2. 当时只有一个接口与后台交互时。

相关 

1. Gateway Aggregation pattern
2. Gateway Offloading pattern
3. Gateway Routing pattern 

 欢迎大家留言沟通 

这篇关于云架构（五）BBF模式的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---