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

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

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

6楼 已删除
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册