正在改造单体为微服务，请教一些问题

[Chad0000]

1. 聚合查询
按我的理解是跨服务并可能会使用列表查询和排序的才需要聚合，否则可以使用主服务查主记录，关联的服务数据可根据 Ids 在前端异步加载。

详情查询则更不需要。

2. 审计日志
如果使用单独的审计服务然后远程调用则可能会浪费太多性能，如果通过服务各自的事件则会导致事件特别多，目前想的是由各服务将审计数据放入指定消息队列中，然后由审计服务消费统一写入。

有了审计日志后，有没有必要再保留单独的日志，比如订单操作日志表？

系统操作要不要也加到审计日志？

3. Event Source
感觉没必要。

[Chad0000]

看来在 V 站问得越专业越没人回。

[sujin190]

都微服务了，肯定不允许跨服务表 join ，关联数据那不就是正常的数据加载么，如果真的有需要聚合查询，那么聚合查询也是一个微服务，按业务流程汇流数据到自己这然后再对外提供服务

审计日志那就要看你要的是哪种了，审计日志一般说的是后台操作日志吧，那么网关完成鉴权后完成请求之后写操作日志就可以了啊，毕竟要求记录的是操作日志，和服务请求日志是两回事，并不需要记录整个链路，既浪费资源也用处不大，服务日志也会按请求日志、链路追踪日志、纯文本自己再代码里写的各种七七八八的日志、性能状态日志都各有各的要求，所以都是要单独处理的，一般来说可以把链路追踪日志和请求日志合并记录会方便很多

[Chad0000]

@sujin190
感谢回复。

聚合查询我的理解应该一样：如果能先查主服务数据再根据记录查对应服务就没必要聚合。只是不能通过主服务之外的数据排序（甚至搜索），如果需要则必须启用聚合服务用来收集各服务的数据并提供查询功能（会有延迟甚至万一消息消费有问题会有出入）。

审计日志我是想记录用户关键操作记录，是需要落库的，业务人员可见。应该不会放网关或链路追踪里（这部分由更底层的日志系统收集），由开发和系统维护人员查看。订单日志则是用户也可见，所以我感觉应该还是需要单独保留。

[yoahang]

1. 能用 api 就用 api 聚合, 应该放后端吧? 如果需要用到其他微服务做 filter, 可以考虑订阅一份子域放自己的微服务这边. 或者 CQRS.
2. 看需求-0-
3. 确实

[Chad0000]

@yoahang
API 聚合的话可能得放在 API Gateway 那边了。如果需要其他微服务做 Filter ，我可能就会做聚合了：因为我想尽量保证每个服务的独立性。