Rails 微服务如何做聚合接口?

ThxFly · 2020年04月09日 · 最后由 early 回复于 2020年04月10日 · 4939 次阅读

最近, APP 那边要求我们提供一个聚合接口来下发各种增量数据, 从而避免进入 APP 首页需要调用众多获取数据接口.

综合评估后, 认为 APP 的要求合情合理.

目前能考虑的想法, 有两个.

第一种

将该接口做在网关层, 通过内部 http 请求, 请求多个微服务, 将数据聚合下发.

第二种

目前我司的管理后台已单独提取出来做成了一个报表微服务, 从而能访问多个数据库的数据. 考虑在这个微服务里提供这个接口.


大家有什么建议?

需要一个中台

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

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

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

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

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

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

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

yfractal 回复

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

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

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

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

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

ThxFly 回复

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

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

7 楼 已删除
需要 登陆 后方可回复, 如果你还没有账号请 注册新账号