无服务器应用微服务架构下报表生成与跨服务数据访问问题咨询

1. 报表的生成与存储实现 #

针对DynamoDB不支持复杂聚合、微服务数据隔离的约束，推荐按以下逻辑设计：

• 提前做数据归集，避免实时跨库计算：不要在报表请求发起时才去拉各个业务服务的数据做聚合，性能和稳定性都没有保障。通过事件驱动模式提前把报表需要的所有维度数据同步到报表服务专属的存储层，存储优先选支持复杂聚合的数据库，比如PostgreSQL、ClickHouse，或者直接用AWS Athena对接S3冷存储，完全避开DynamoDB的聚合短板。
• 报表生成按访问频率分层处理：
  • 常用的固定模板报表（比如月度账单、日访问统计）：采用预生成策略，通过定时任务（可以用你现有技术栈的Lambda做跑批触发器）提前算好结果，存在Redis或者专门的结果表中，用户请求时直接返回，响应速度可以做到毫秒级。
  • 自定义维度的低频报表：采用异步生成策略，用户发起请求后后台触发计算任务，计算完成后通过消息通知用户下载，避免长请求占用服务资源。
• 结果存储做生命周期管理：30天以内的历史报表结果存在热存储方便快速查询，超过30天的归档到S3这类低成本存储，需要时再召回。

2. 跨微服务数据获取方案 #

必须严格遵守“微服务不直接访问其他服务数据库”的架构原则，避免后续业务迭代出现耦合故障，可选三种落地方式：

• 业务服务提供只读OpenAPI：各个业务微服务封装自身数据的只读查询接口，报表服务通过API网关调用接口拉取数据。适合数据量小、更新频率低的维度类数据，调用时要加限流、熔断策略，避免报表的批量拉取请求影响业务服务的正常可用性。
• 领域事件同步：所有业务微服务产生数据变更时，向统一事件总线（可以用AWS EventBridge）抛出结构化的领域事件，报表服务消费事件把数据写入自身的归集库。这是最推荐的方案，完全解耦业务服务和报表服务，数据同步的时效性也可以做到准实时。
• CDC日志同步：如果现有业务微服务不方便改代码加事件抛出逻辑，可以用DynamoDB Streams捕获业务库的变更日志，通过自定义Lambda消费日志同步到报表服务的归集库。需要注意业务库表结构变更时，要同步更新同步任务的字段映射规则，避免数据不一致。

内容的提问来源于stack exchange，提问作者systemdebt