需要一个中台

看描述，这个需求点是两个，一个是增量，一个是聚合接口。

增量的话，性能可以有很大提升。

想要聚合接口，原因是什么？是性能上的考虑，还是编程容易程度上的考虑？

如果只是性能上考虑，还可以考虑下短连转长链。

如果是对前端友好，感觉网关比较合理。报表微服务，可以做这件事，但这个服务做报表的，没有理由管首页的事情。

业务和报表，这个在查询上有很大区别。一般业务不会查很多数据，有一致性、实时性要求。报表，一般有很大查询业务，但实时性，一致性，要求都不高。所以应该是两个单独的服务。

好奇问一下，报表服务，一般都很慢，直接连数据库，会不会拖垮整个服务？

增量主要是考虑小程序需要与 APP 保持数据同步, 而 APP 本身又可以离线使用.

聚合接口更多是从性能上考虑的, 由于 APP 进一次首页需要调用 N 个接口, 故他们想要在一个接口里完成这些数据拉取操作. 他们也认为这样编程更容易. 目前已经是 http1.1 的长连接

这个报表服务本身是后台管理系统. 提供了少数接口用来在 APP 里做周报,年报的生成, 实时性要求不高, 且是低频请求. 故不会拖垮整个服务.

还有另外的报表服务面向内部运营人员, 用 Python 的 superset 做数据可视化.

应该会考虑在网关做, 利用原有微服务的接口代码. 如果在报表服务做, 可能就不算微服务了, 好不容易把后台和接口拆分开来

报表主要是查询一般比较耗时，查询的时候又可能会有锁（mysql 默认隔离级是这种），锁了之后，就不能写了。也就是其他服务写的时候，会卡主那么一会。也许会卡主很多请求。

就是报表有查询，可能卡主其他服务。

这个很常见。

以直播业务来讲，用户进房间时，会调用一个核心接口。 这个接口就是一个 APP 网关提供的，resp 比较大，这个接口内部，会调用 20～40 个下游，通过 golang 并发拉取。 将各个下游的数据及逻辑做统一处理后返回。（见过直播琳琅满目的界面你会懂的）

尽管这个网关接口聚合了 30+ 个下游的逻辑，APP 进房间依然会调用好多个接口，有各种用途。 你让 APP 进房间分别调用这些接口？ 肯定不能这么做。

聚合的原因很明显：

• 降低了页面打开的耗时。 聚合接口将页面核心数据用一路 tcp 请求解决。如果几十个接口同时请求，用户侧到 SLB 的公网连接非常多，受网络影响的可能性大增。
• 降低了客户端代码的复杂性。 一个页面，渲染的数据通过多个接口获取，客户端的渲染逻辑不敢想象，数据达到时间不一致，页面会很不稳定，要不就等所有接口都返回才渲染，那耗时就是最差的那个连接。 安卓端处理了这种多请求的逻辑，IOS 是不是还要处理一次？ 服务端一个接口就可以把这个复杂性解决，而且很简单，一个并发等待就可以解决。
• 提升可靠性。假设上百万人短时间窗口进房间，请求一个核心接口，很容易对这个接口的数据统一做降级、缓存、保障。如果单独请求几十个请求，配限流就把人累死了。
• 改善工程水平。服务端逻辑聚合、复用能力提升。代码都在一起，查看逻辑、扩展、解决问题都很快。更重要的是，服务端的业务治理可以自然分层、拆分。数据流的聚合、分层、分流链路清晰，便于统一规划。
• 其他

slb -> 聚合层 -> 大量调用各种下游 -> 下游再调各种下游 -> 缓存、DB 这种结构，需要将服务端做分层，聚合层、服务层、数据层。 如果业务复杂度不高，建议不搞。