2、服务边界定义：什么是服务边界、报表导出服务的核心职责、边界内外的交互原则
2.1 服务边界的本质
在分布式系统设计中，服务边界是一个逻辑与物理的双重概念。它划定了某个微服务所拥有的数据、行为、职责以及对外暴露的通信协议范围。边界内部是服务的自治领域，外部则是其他服务或客户端。清晰的边界是避免“大泥球”架构、实现独立部署与扩展的前提。
核心判断标准： 如果一个功能变更需要同时修改两个服务的代码，则说明边界划分不合理。
服务边界通常由以下三个维度定义：
| 维度 | 说明 | 示例（报表导出） |
|---|---|---|
| 数据边界 | 服务拥有哪些数据的读写权限 | 报表模板元数据、导出任务状态、生成的文件路径 |
| 行为边界 | 服务负责执行哪些业务逻辑 | 报表数据聚合、格式渲染、文件压缩、过期清理 |
| 通信边界 | 服务通过何种协议与外界交互 | gRPC 同步接口（创建任务）、异步消息（状态回调） |
2.2 报表导出服务的核心职责
报表导出服务（Report Export Service, RES）是一个典型的异步任务型微服务。其核心职责不是“实时返回报表文件”，而是可靠地编排导出流程。我们将职责拆解为以下五个关键领域：
- 任务接收与校验：通过 gRPC 接口接收导出请求，校验参数合法性（如时间范围、报表类型、格式）。
- 任务持久化与状态管理：将任务写入数据库，维护任务生命周期（待处理 → 处理中 → 成功/失败）。
- 数据聚合与渲染：从数据源（如 OLAP 引擎、业务数据库）拉取原始数据，按模板渲染为 Excel/PDF/CSV。
- 文件存储与生命周期：将生成的文件上传至对象存储（如 MinIO、S3），并设置过期自动清理策略。
- 结果通知：通过异步消息（如 RabbitMQ、Kafka）将导出结果（成功/失败 + 下载链接）推送给调用方。
设计原则： 报表导出服务不负责用户权限校验、不负责原始业务数据的存储、不负责文件的分发加速（CDN）。这些职责应交给边界外的其他服务。
2.3 边界内外的交互原则
为了保持报表导出服务的独立性与可替换性，边界内外的交互必须遵循以下四项硬性原则：
| 原则 | 描述 | 违反后果 |
|---|---|---|
| 1. 协议隔离 | 对外只暴露 gRPC 接口（同步）和消息队列（异步），不暴露内部数据库或文件系统 | 外部服务直接访问数据库导致耦合，无法独立演进 |
| 2. 数据所有权 | 报表模板、任务状态、生成文件路径等数据只能由 RES 读写，其他服务必须通过接口获取 | 数据不一致，缓存与源数据冲突 |
| 3. 异步优先 | 导出操作默认采用异步模式：立即返回任务 ID，结果通过消息通知；避免长时间阻塞 gRPC 连接 | gRPC 超时、客户端线程池耗尽、服务雪崩 |
| 4. 契约先行 | gRPC proto 文件和消息队列 topic/消息格式必须先定义、评审，再实现代码 | 接口不兼容，联调成本剧增 |
常见误区： 有些团队为了“方便”，让报表导出服务直接读取业务数据库的原始表。这破坏了数据边界，一旦业务库表结构变更，导出服务必须同步修改，失去了独立部署的意义。正确的做法是：业务服务通过 gRPC 或消息将所需数据推送给 RES，或 RES 通过专用的数据视图/API 获取。
2.4 交互模式总览
结合上述原则，报表导出服务与外部系统的交互模式可以归纳为两种：
- 同步交互（gRPC Unary RPC）： 用于创建导出任务、查询任务状态、获取任务列表。这些操作要求低延迟、强一致性。
- 异步交互（消息队列）： 用于导出完成通知、导出失败告警、文件过期清理事件。这些操作允许秒级延迟，追求高吞吐与解耦。
2.5 边界定义检查清单
在实际设计过程中，可以使用以下清单来验证服务边界是否合理：
- ☐ 报表导出服务是否拥有独立的数据库或 schema？
- ☐ 外部服务是否只能通过 gRPC 或消息队列与 RES 通信？
- ☐ 导出任务的状态变更是否完全由 RES 内部驱动？
- ☐ 文件存储路径是否对 RES 外部透明？
- ☐ 修改报表模板格式时，是否需要修改其他服务的代码？
- ☐ 如果 RES 完全宕机，是否会影响核心业务服务的可用性？（期望：不影响）
最佳实践： 在项目初期，将服务边界定义写入 ADR（架构决策记录），并附带一张类似上文的边界职责图。这能有效防止后续迭代中的边界腐化。