阅读 138

后端是否做聚合业务服务支持成本的讨论

背景

一个移动端的首页,功能模块是走配置化的,配置化的模块列表是走接口的,模块内的数据是来源于多个业务的,症结出现在多个业务的具体数据需要前端根据模块提供的请求参数再去做数据的聚合,然后进行展示。

前端期望:后端返回模块详情时,直接聚合多业务的数据

后端不这样做的原因:后续这个接口并发量会比较大,如果在这个接口中做业务数据的聚合请求,会导致接口的响应时长变长,造成阻塞,导致整体达不到期望的用户并发

业务数据背景:最新的推荐文章,产品要求数据实时展示

实时性取决于:文章来源于多类型(业务类型和内容类型),文章来源于多机构(本机构,关联机构,上层机构)

问题定性

从前端或产品侧来考虑,这其实就是业务中台,或者BFF的部分。简单的架构图如下:

按照我们的诉求就是 ,产品侧直接调用课程中心的消费服务即可。

产品侧:推荐课程

课程中心:获取最新课程,获取某机构课程

业务微服务层:业务1课程,业务2课程,业务3课程

是否实时性的判定非常重要

一般情况下,实时性的常识是分钟级别是分界线,比分钟级别更慢的都不会存在大的实时性问题。

非实时性,做同步方案即可

比较常见的包括分钟级别,小时级别,以及按照天的T+1同步。

这种情况下,优先做多级缓存,保证缓存下命中的有效性

对于更新频率特别低,或者明显可感知,同步比较快的,可以做数据的的持久缓存,甚至页面的静态化处理

实时性,比如秒级别

就会真的涉及到高并发的问题了,因为需要实时获取最新数据,并且同时支持,而这个链路有可能较长,并且还会涉及到多级缓存时是否能得到最新数据的情况。

接口的分类处理

按照不同时效性,中间层做分类处理,可以分为三类:

1 通用接口请求,前端可以在应用层做持久缓存,比如用户的登录信息不用每次都去验证。一些枚举数据也是如此。

2 低频更新的,可以中间层做一定的缓存,同时中间层做定时同步,应用使用时除了初次请求,也可以在应用空闲时,请求一次以备用

3 高频更新,每次实时请求,应用和中间层都不建议使用缓存

前端侧的优化方案

预显示

骨架屏

降低首屏请求量

1 只响应必要接口,其他延迟请求,可以考虑放入前端的请求队列

2 针对非实时模块做区分处理,做显示方案

其他的一些补充性常识

\

后端的后续方向

\

1 针对产品侧的业务中台

2 单业务架构如何支持高并发,高时效,更快返回

3 高并发的链路压测

4 多级缓存如何设计

前端的后续方向

1 骨架屏

2 组件的懒加载

3 应用级别缓存

4 请求队列,请求的依赖管理的优雅方式

常识问题

1 架构的调整成本和责任是巨大的,一般后端没有绝对实力是不愿意做类似的事情的,比如分层设计,缓存设计

2 用户基数与并发有关联,但没有绝对因果关系

3 不管用哪种架构,都会存在边界问题,对边界问题要有方案和预期。比如瓶颈下的并发数如何做限流。

彩蛋

不因为一个问题太系统太大就不讨论,或者放弃请教,即使在讨论过程中,你也一定能学到认识到别人比你更擅长在哪里,有没有在真的回答问题,回答到要点,有没有切实的相关经历或者痛点。

讨论的目的,在大多数情况下,不是索要到答案,而要定位为了解大家的参与度,认知度,擅长领域,并通过某些人比较长的论述中得出他的核心观点,行为,依据是什么,对自己的决策提供一个可行性的选项和基本方向。就和我们入职一家公司前要多问问别人一样,不是为了以那个人的答案为准,而是为了减少踩一些巨坑。

语雀原文

前端生涯-原文

文章分类
前端
文章标签