引言
在最近的一次公司技术分享会上，我们深入探讨了公司的项目架构。核心议题是BFF架构，这是一种在微服务架构之上增加的额外层级。此外，我们还讨论了DDD（领域驱动设计）理念，它在订单、用户等业务中台中扮演着关键角色。
这是我对架构领域的初步探索，虽然理解尚浅，但我还是尝试着将所学内容进行了整理。
BFF
定义
BFF，即Backend For Frontend，是一种专为前端服务的后端架构。它位于客户端和服务端之间，充当中间件的角色，我更愿意将其视作前端与后端之间的桥梁。
应用动机
BFF是近年来新兴的一种开发模式，也可以看作是一种适配系统。它的出现是为了解决微服务架构下前端和后端接口调用混乱的问题。
在微服务大行其道的今天，大型系统被划分为数十个服务模块，如商品、门店、运费、红包、订单、优惠券、CMS、用户、搜索、推荐、广告等，而前端则包括小程序、APP、网页等多种形式。这种架构带来了诸多挑战：
- 前端挑战：前端开发需要与多个系统对接，以确认接口信息，不同数据来源需要访问不同的系统，导致开发和调试效率极低。
- 后端挑战：后端同样需要包装数据以供前端使用，重心转向如何为前端提供数据，需要根据不同版本、客户端、用户、定位等特征进行判断，导致大量时间浪费在展示层，而非业务逻辑处理。各后端系统各自为战，接口规则不一，历史版本问题难以统一，导致系统间严重耦合。
- 变更困难：产品需求更新时，小改动可能需要在多个系统间协调，大部分系统都需要重新上线。
下图展示了未使用BFF架构时，前后端沟通的复杂性。
BFF的网关角色
针对上述问题，我们引入了中间层BFF，它统一调用所有下游后端接口，这些接口只需提供RPC接口供网关使用。BFF网关提供Web接口供前端调用，并根据前端需求组装数据。
因此，BFF的核心角色是：“统一下游接口，服务前端”。
只有深刻理解服务的本质，才能构建有效的BFF网关系统。其他系统或许可以推诿责任，但BFF网关不行。它的使命是连接前后端，处理所有不合理、不合适、繁琐的逻辑。后端只需专注于业务逻辑，前端专注于展示，其他任务都可交给BFF网关。
BFF网关的特性
作为特殊的网关，BFF具有以下特点：
复杂性
BFF网关主要服务于前端，前端不关心版本、客户端、定位、用户身份等细节，只接收渲染数据。这些逻辑都需要集成到BFF网关中，以版本、客户端、定位、用户等特征为基础，其中版本分支最为复杂，可能需要兼容数十个版本类型，同时还要满足不同客户端的展示要求和用户特征，因此BFF网关中必然包含大量判断分支，根据上百种情况组合生成唯一的数据结构。
数据管理
BFF不需要数据库，这一点将在下文解释。因此，许多数据需要以静态变量的形式存储在代码中，或使用配置中心动态配置，如图片地址、颜色值、模块固定文本、处理标识等。这些琐碎的数据都存储在BFF网关中进行维护。如果放在前端，修改时必须发版，周期过长；而放在后端，则会分散数据，无法集中管理。
逻辑处理
如前所述，BFF网关作为下游接口的聚合器，每次流程需要调用数十个后端接口，再根据版本、端、用户进行逻辑处理。历史逻辑与新需求交织在一起，实现新功能的同时要不断考虑历史逻辑，导致大量分支判断，最终形成复杂的逻辑结构，或使用策略模式进行优化，但无论如何包装，都无法掩盖其复杂性。
性能考量
BFF网关的耗时主要分为两部分：
- 内部处理耗时
- 下游RPC接口耗时
作为与前端直接交互的接口，BFF的耗时直接影响用户体验。因此，
文章整理自互联网，只做测试使用。发布者：Lomu，转转请注明出处：https://www.it1024doc.com/4382.html
