32、事件驱动微服务架构中用户界面的利用策略

事件驱动微服务架构中用户界面的利用策略

1. 后端设计粒度思考

在后端设计时，我们常面临设计粒度的问题。比如，是否真的需要两个产品列表后端？一个合理的做法是，先了解用例以及用户与应用的交互方式。

由于尺寸和带宽限制，Web UI 和移动 UI 呈现信息的方式有所不同。Web UI 可能会展示推荐信息和订单详情，但移动 UI 可能无法全部展示。而且，移动 UI 显示的产品数量可能比 Web UI 少，交互界面也可能不同，Web UI 适合分页浏览，移动 UI 则更适合滚动浏览。这些差异可能是为不同 UI 配备独立后端的有力理由。

团队组织也是一个重要因素。如果是同一团队开发 Web 和移动 UI，那么使用一个后端可能更为合理。但如果后端承担过多责任，且多个团队参与开发，就可能需要构建更细粒度的后端。

当后端和前端团队分开时，后端为前端（BFF）可以抽象下游平台功能，实现更高程度的职责分离。不过，对于功能可集中在单层且无依赖的简单应用，BFF 可能会增加整体架构的复杂性，因此在处理复杂逻辑、聚合多个服务以及面对多样化用例和前端技术时使用 BFF 更为合适。

但 BFF 在处理大数据集和复杂搜索需求时存在局限性。在 BFF 中保存状态（如使用 Redis 等技术）对于专门服务 UI 的后端来说可能不是最佳选择。BFF 和某些模式都依赖 API 组合，在某些用例中管理起来可能较为困难。

2. 微服务架构中的 UI 分解模式

获取 UI 信息的一种方式是从微服务请求数据，还可以通过聚合层优化请求，使其满足 UI 需求。然而，随着 UI 规模扩大和需求变化，UI 承担的责任也会增加，可能出现类似单体应用的局限