最近, 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 这种结构，需要将服务端做分层，聚合层、服务层、数据层。 如果业务复杂度不高，建议不搞。