专业编程教程与实战项目分享平台

网站首页 > 技术文章 正文

闲鱼前端如何做容灾

ins518 2024-11-27 15:15:42 技术文章 12 ℃ 0 评论

项目背景

在我们端侧的开发经验里，大概都会遇到这些问题：

用户反馈页面有时打不开/白屏；

服务端接口返回200，但是页面却没有数据；

由于服务端依赖的二方库/服务出现问题等原因，页面接口突然抽风出错，导致页面展示错乱或者显示内容错误；

流量高峰时候服务端扛不住压力接口挂了；

服务端监控显示接口稳定性有99.99%，但是由于网络、客户端环境等原因，接口的真正可用性可能要打个折扣;

其实，总结起来这些问题都是由于接口可用性差造成的，而提升接口可用性是解决这些问题的不二法门。

前端如何提升页面稳定性

兜底容灾的核心是提前将可用的数据存储在可靠的地方，在需要时能够高效便捷地获取到这份数据。对于这个问题，本地存储往往会浮现在我们的思路中，但是本地存储存在可靠性差、存储容量有限、无法服务端控制等问题。和本地存储相比，OSS + CDN更符合我们的需求，它稳定、可靠、容量不限、可控性强的特点非常适合用于存储兜底数据。（备注：阿里云对象存储服务，简称 OSS，是阿里云提供的海量、安全、低成本、高可靠的云存储服务。）

但是当我们在具体实现时，会措手不及地发现很多其他问题：

?如何及时地更新兜底数据？如何保证兜底数据的正确性？
?如何在前端组件中请求兜底数据？如何保证请求到的兜底数据是正确的？
?如何确定OSS资源的地址？
?如何确定某个接口异常的时候该走兜底？
?如何区分接口是否适用兜底？如果管理？如何判断？
?如何知道某个接口的到底有没有走兜底容灾的流程？兜底容灾的成功率如何？
?如何维护管理远程的兜底数据
等等以上类似问题，但是前端做容灾要解决的问题远远不只是以上这些。

前端兜底容灾的基本流程

让我们先一起来看到前端容灾的基本流程， 在设计兜底容灾组件时，除了 CDN 容灾外，我们还考虑了本地存储兜底方案以及离线数据兜底方案：
本地存储兜底方案：使用端的本地存储能力存储兜底数据 离线数据方案：在离线包发布时将接口数据离线为CDN文件预置其中，作为兜底数据 如此，兜底容灾的基本流程可以简单描述为：

我们将以上流程封装成前端SDK，然后集成到前端request组件的插件。业务方使用的时候只需要通过参数配置即可引入使用。当然，组件不能仅仅实现功能，还要好用！为此在组件设计时考虑了很多问题，最后呈现的容灾组件具备以下特点：
?支持无缝接入：无论是接口API、参数，还是返回结果，都和目前通用的接口请求组件保持一致。接入只需要新增容灾参数即可
?配置控制：对于兜底配置提供了多个参数，提供了简单或复杂的配置方式，开发者可以灵活控制兜底容灾的流程和规则。对于接口的黑白名单和容灾接口管理提供了可视化配置后台。
?扩展服务：正如流程中所述，组件在关键节点采集了日志信息，借助这些日志信息，提供数据分析、自动注册等服务
关于容灾地址唯一key计算
容灾api的地方一定要保证唯一性，主要是参考api地址+参数值+版本号等信息来生成唯一的路由地址，最后将生成的地址转码加密；举个例子：global.alicdn.com/{HTTPTYPE}/{API_NAME}/{API_VERSION}/{PARAMS}
如果是本地容灾，如何将过期信息加入到存储数据里，我为了更快捷的处理速度。是将这个信息也加入到本地路由key信息里的。举个例子：{UPDATE_TIME}/{TAG}/{API_NAME}/{API_VERSION}/{PARAMS} 本地数据更新时间+特殊标记符+api名称+api版本号+相关参数 这样做的好处就是，当我们需要计算本地当前数据是否过期以及读取的时候十分方便，只需要遍历相关key然后和过期时间做对比即可。
这边关于相关参数的设置，是否一个接口的所有参数都需要用来使用生成唯一的key；那么显然也是不合理的，比如pageSize等，一些不会影响到数据准确性的参数。所以这边还有一个必要参数的概念，只使用必要参数来生成唯一KEY

关于数据校验

如何判断返回的数据是否“正确”，不论是服务端的数据还是我们的容灾数据。基本想到数据校验，第一反应想到是维护一套数据的schame，好非常完美，每个字段都校验到了。但是在实际情况下，每个接口都维护和生成一套schame,操作成本和维护成本都是比较高的事情，更糟糕的是，当这个接口数据接口复杂、大的时候，如果对返回的API数据做大而全的数据校验会影响到页面性能。结合我们业务的实际情况是，99%以上的场景下，接口异常都是结构化的异常，比如一个接口重要属性没有了。这么一来我们只需要判断接口的某个重要属性的正确性就可以了，所以数据校验这块最后我们采取是“克制”的校验方案去做这个事情。

关于容灾触发校验

容灾触发校验主要是校验两个方面：
?是否开启容灾
?当前接口异常情况是否适用于容灾 过滤掉不能走容灾的接口异常类型（比如未登录、非法请求等接口异常信息） 过滤掉不能走容灾的接口（比如个人信息数据，权益信息数据等等 ）
相关异常类型的配置我们可以在容灾配套的后台系统进行维护，实时生效。

关于容灾数据配置和维护

后台系统主要提供的是对CDN容灾数据的，增删改查的功能，还有其他相关配置信息维护管理的功能。
同时为了保持容灾远程数据的可用性，还承担着对这些数据管理以及定时更新的任务。
如下图（新增api）

关于数据分析与容灾系统监控

对我们的容灾系统运行的到底如何，我们也需要他各个阶段进行稳定性监控以及数据分析；主要包括：
?容灾成功率
?容灾开启率
?接口的错误率
?接口异常分析
?系统稳定性分析
当我们发现某个接口的异常率激增的时候，会实时反馈给服务端同学进行异常排除；

业务效果

如下图某日接口异常时容灾效果：

某天接口整体出现波动，整体错误率飙升到 8%以上；经过容灾后让错误率降低到0.55%；为什么容灾不是100%，因为在统计上我们把接口的网络异常也计算进来了。CDN容灾的方案无法解决，用户无网络引起的接口异常问题。

整体系统架构图

我们整体系统架构主要划分了：
?端侧：前端容灾SDK
?容灾服务：提供容灾数据的管理以及容灾服务器的维护能力
?容灾后台：提供，业务方配置容灾和管理数据的可视化平台
?数据埋点监控：对整体接口稳定性以及容灾系统稳定性提供数据支持，对异常提供反馈

其他

我作为开发，一直有一个习惯就是让我接一个产品或者组件，我接入的成本越少越好。所以在这个过程中，我们也开发了一些浏览器插件等帮助大家快速注册api等方案。当然最好的就是自动接入，关于这块结合我们自身的业务特点。已经开始去做了。有机会可以再和大家聊一下自动接入的相关流程以及方案和我们遇到的问题。然后以上容灾方案最大的问题就是，关于本地容灾这块还是比较单薄，只利用了浏览器的存储能力。关于如何结合客户端的存储能力，提升和优化本地容灾方案也是即将要做的事情。
至此，有什么建议欢迎留言提问。


Tags：

猜你喜欢

本文暂时没有评论，来添加一个吧(●'◡'●)

欢迎 你 发表评论:

最近发表
标签列表