最近, APP 那边要求我们提供一个聚合接口来下发各种增量数据, 从而避免进入 APP 首页需要调用众多获取数据接口.
综合评估后, 认为 APP 的要求合情合理.
目前能考虑的想法, 有两个.
将该接口做在网关层, 通过内部 http 请求, 请求多个微服务, 将数据聚合下发.
目前我司的管理后台已单独提取出来做成了一个报表微服务, 从而能访问多个数据库的数据. 考虑在这个微服务里提供这个接口.
大家有什么建议?
需要一个中台
看描述,这个需求点是两个,一个是增量,一个是聚合接口。
增量的话,性能可以有很大提升。
想要聚合接口,原因是什么?是性能上的考虑,还是编程容易程度上的考虑?
如果只是性能上考虑,还可以考虑下短连转长链。
如果是对前端友好,感觉网关比较合理。报表微服务,可以做这件事,但这个服务做报表的,没有理由管首页的事情。
业务和报表,这个在查询上有很大区别。一般业务不会查很多数据,有一致性、实时性要求。报表,一般有很大查询业务,但实时性,一致性,要求都不高。所以应该是两个单独的服务。
好奇问一下,报表服务,一般都很慢,直接连数据库,会不会拖垮整个服务?
增量主要是考虑小程序需要与 APP 保持数据同步, 而 APP 本身又可以离线使用.
聚合接口更多是从性能上考虑的, 由于 APP 进一次首页需要调用 N 个接口, 故他们想要在一个接口里完成这些数据拉取操作. 他们也认为这样编程更容易. 目前已经是 http1.1 的长连接
这个报表服务本身是后台管理系统. 提供了少数接口用来在 APP 里做周报,年报的生成, 实时性要求不高, 且是低频请求. 故不会拖垮整个服务.
还有另外的报表服务面向内部运营人员, 用 Python 的 superset 做数据可视化.
应该会考虑在网关做, 利用原有微服务的接口代码. 如果在报表服务做, 可能就不算微服务了, 好不容易把后台和接口拆分开来
报表主要是查询一般比较耗时,查询的时候又可能会有锁(mysql 默认隔离级是这种),锁了之后,就不能写了。也就是其他服务写的时候,会卡主那么一会。也许会卡主很多请求。
就是报表有查询,可能卡主其他服务。
这个很常见。
以直播业务来讲,用户进房间时,会调用一个核心接口。 这个接口就是一个 APP 网关提供的,resp 比较大,这个接口内部,会调用 20~40 个下游,通过 golang 并发拉取。 将各个下游的数据及逻辑做统一处理后返回。(见过直播琳琅满目的界面你会懂的)
尽管这个网关接口聚合了 30+ 个下游的逻辑,APP 进房间依然会调用好多个接口,有各种用途。 你让 APP 进房间分别调用这些接口? 肯定不能这么做。
聚合的原因很明显:
slb -> 聚合层 -> 大量调用各种下游 -> 下游再调各种下游 -> 缓存、DB 这种结构,需要将服务端做分层,聚合层、服务层、数据层。 如果业务复杂度不高,建议不搞。