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

### 事件驱动微服务架构中用户界面的利用策略 #### 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 承担的责任也会增加，可能出现类似单体应用的局限性。因此，可以将单个 UI 应用分解为更小的部分。 - **简单 UI 应用的选择**：当 UI 职责有限、简单直接时，使用单个 UI 应用可能更有优势。就像后端单体应用一样，小团队开发单个应用可以避免管理多个小应用的复杂性。但随着应用发展和责任增加，开发团队也会扩大，导致边界模糊、发布复杂、团队协调时间增加等问题。 - **微前端模式的出现**：为解决上述问题，微前端模式应运而生。它将 UI 拆分为独立开发和部署的小应用，不同团队负责不同的微前端。这种模式还能组建全栈团队，负责架构中的小领域，实现 UI 和平台功能。全栈团队通常能更稳定地交付价值，相比前后端分离的团队，在交付方面可能更灵活。微前端通常可通过应用分解、页面分解和部分分解来实现。 #### 3. UI 应用分解模式 应用分解是将不同用途的功能分离到不同应用中，这是将大型 UI 应用分解为小型应用的有效方法。综合型 UI 可能聚合了多个不同职责，将其代码库、团队所有权和发布周期分离可能会带来好处。这与将单体应用拆分为微服务的思路一致，构建具有明确用途的小型 UI 应用有助于实现领域分离，也能促使小团队从微服务到 UI 进行端到端的功能开发。 当应用中存在明显独立的领域、用例和用户群体时，可能意味着该 UI 应用责任过重，需要进行分离。例如，电子商务管理应用可拆分为订单履行应用和客户管理应用。订单履行流程和客户管理应用具有不同的目的和业务流程，将应用拆分并为每个用例构建微前端可能更有利。理想情况下，每个应用应对应一个微服务，但随着微服务粒度变细，实现起来可能有难度。客户管理应用适合这种方法，开发用户服务的团队也可开发该应用；而订单履行应用责任和概念较多，可能依赖多个服务，此时可考虑更细粒度的分解模式，如页面分解和部分分解。 以下是应用分解的示例表格： | 应用类型 | 对应服务 | 优势 | | ---- | ---- | ---