最近，APP 那边要求我们提供一个聚合接口来下发各种增量数据，从而避免进入 APP 首页需要调用众多获取数据接口。
综合评估后，认为 APP 的要求合情合理。
目前能考虑的想法，有两个。
第一种
将该接口做在网关层，通过内部 http 请求，请求多个微服务，将数据聚合下发。
第二种
目前我司的管理后台已单独提取出来做成了一个报表微服务，从而能访问多个数据库的数据。考虑在这个微服务里提供这个接口。
大家有什么建议？
看描述，这个需求点是两个，一个是增量，一个是聚合接口。
增量的话，性能可以有很大提升。
想要聚合接口，原因是什么？是性能上的考虑，还是编程容易程度上的考虑？
如果只是性能上考虑，还可以考虑下短连转长链。
如果是对前端友好，感觉网关比较合理。报表微服务，可以做这件事，但这个服务做报表的，没有理由管首页的事情。
业务和报表，这个在查询上有很大区别。一般业务不会查很多数据，有一致性、实时性要求。报表，一般有很大查询业务，但实时性，一致性，要求都不高。所以应该是两个单独的服务。
好奇问一下，报表服务，一般都很慢，直接连数据库，会不会拖垮整个服务？
yfractal
回复
增量主要是考虑小程序需要与 APP 保持数据同步，而 APP 本身又可以离线使用。
聚合接口更多是从性能上考虑的，由于 APP 进一次首页需要调用 N 个接口，故他们想要在一个接口里完成这些数据拉取操作。他们也认为这样编程更容易。目前已经是 http1.1 的长连接
这个报表服务本身是后台管理系统。提供了少数接口用来在 APP 里做周报，年报的生成，实时性要求不高，且是低频请求。故不会拖垮整个服务。
还有另外的报表服务面向内部运营人员，用 Python 的 superset 做数据可视化。
应该会考虑在网关做，利用原有微服务的接口代码。如果在报表服务做，可能就不算微服务了，好不容易把后台和接口拆分开来
ThxFly
回复
报表主要是查询一般比较耗时，查询的时候又可能会有锁（mysql 默认隔离级是这种），锁了之后，就不能写了。也就是其他服务写的时候，会卡主那么一会。也许会卡主很多请求。
就是报表有查询，可能卡主其他服务。
这个很常见。
以直播业务来讲，用户进房间时，会调用一个核心接口。这个接口就是一个 APP 网关提供的，resp 比较大，这个接口内部，会调用 20～40 个下游，通过 golang 并发拉取。将各个下游的数据及逻辑做统一处理后返回。（见过直播琳琅满目的界面你会懂的）
尽管这个网关接口聚合了 30+ 个下游的逻辑，APP 进房间依然会调用好多个接口，有各种用途。你让 APP 进房间分别调用这些接口？肯定不能这么做。
聚合的原因很明显：
- 降低了页面打开的耗时。聚合接口将页面核心数据用一路 tcp 请求解决。如果几十个接口同时请求，用户侧到 SLB 的公网连接非常多，受网络影响的可能性大增。
- 降低了客户端代码的复杂性。一个页面，渲染的数据通过多个接口获取，客户端的渲染逻辑不敢想象，数据达到时间不一致，页面会很不稳定，要不就等所有接口都返回才渲染，那耗时就是最差的那个连接。安卓端处理了这种多请求的逻辑，IOS 是不是还要处理一次？服务端一个接口就可以把这个复杂性解决，而且很简单，一个并发等待就可以解决。
- 提升可靠性。假设上百万人短时间窗口进房间，请求一个核心接口，很容易对这个接口的数据统一做降级、缓存、保障。如果单独请求几十个请求，配限流就把人累死了。
- 改善工程水平。服务端逻辑聚合、复用能力提升。代码都在一起，查看逻辑、扩展、解决问题都很快。更重要的是，服务端的业务治理可以自然分层、拆分。数据流的聚合、分层、分流链路清晰，便于统一规划。
- 其他
slb -> 聚合层 -> 大量调用各种下游 -> 下游再调各种下游 -> 缓存、DB 这种结构，需要将服务端做分层，聚合层、服务层、数据层。如果业务复杂度不高，建议不搞。