小模块解决大痛点—nginx+lua托底数据解决方案
146 浏览量
2021-01-27
12:50:14
上传
评论
收藏 151KB PDF 举报
小模块解决大痛点小模块解决大痛点—nginx+lua托底数据解决方案托底数据解决方案
随着京东商城的发展，内部也出现了一些比较有意思的小系统小模块来解决一些业务系统的痛点，而这些小系统小模块虽说不
复杂但是解决了当时的痛点。数据托底就是其中一个痛点，因为依赖系统或者其他方面的不稳定性导致用户访问页面是404或
者503、或者出现天窗（页面局部内容没出来），这在一个大流量系统中是不允许的。因此就需要更健壮的系统设计来解决此
问题，解决此问题的方法大家又都是类似的，因此作者就抽象了一个小模块来解决更多人的兜底问题。
大多数以读为主的系统为了提高系统的可用性，会用到各种策略来增强用户体验；其中数据托底就是其中一种策略；数据托底
也可以叫做数据兜底，一般来解决如下几个问题：保证数据”永不消失”(不能开天窗)，即假设依赖的服务出问题了，内容还可
以展示给用户；保证数据的正确性，如果以来的服务数据不正确，可以暂时走托底数据；甚至要保证托底数据的高性能，大促
时可以直接走托底数据，因为托底数据一般会通过缓存或者静态化技术完成。
实际项目中数据托底的方式也是多种多样,最简单直接的一种方式是将托底功能完全耦合在自己业务系统中，后续每开发一个
系统，甚至每增加一种业务功能都要重新实现一次托底功能,并且当系统本身挂掉后托底也就无能为力了。
为了减少代码的冗余,降低代码的维护成本,可以把这块功能抽象数出来(如果业务系统是java语言,可以以jar包的形式提供服务),
然后收集出所有需要托底的业务(可以收集url、业务方法等),将其放到一个配置文件中，用worker去更新托底数据；比如京东
三级列表页通过Worker去爬所有页面的内容然后静态化存储，即存储整个HTML片段，当动态列表页依赖的服务出现问题了，
则直接走托底数据；假设有些页面没有爬到，可以将列表页第一页作为托底数据返回。这种形式显然要比第一种好许多(比如
耦合性降低),但仍然没有足够好。首先他需要准确的知道是哪些业务要托底(明确url或方法入参),不能跨语言使用,系统本身挂掉
后托底也会失败。
另一种方式是将这块功能完全独立成一个系统,并且以http的形式和目标系统通信。假设目标系统有10个页面需要做托底处理,
那么我们可以将这10个页面的url告诉托底系统，托底系统可以定时的去抓取我们的页面,然后将正确的数据放到存储设备上,目
标系统可以通过nginx做判断决定如何以及何时去读取这些数据。可以看到这种方式可以做到对目标系统无侵入,也可以跨语言,
并且即使目标系统挂掉只要nginx不挂就仍然可以提供服务。但是这种方法无法动态获取要托底的资源,他在抓取托底数据时需
要明确url,试想如果目标系统有几亿的页面要托底,根本没法告知托底系统；多个目标系统依赖同一个托底系统，会有单点风
险。
可以看到以上方法都或多或少有些缺陷,因此为了更好地解决这些问题。
该方法具有以下几个特性：
a. 对目标系统零侵入
b. 可动态拦截请求(不需要预先配置url)
c. 可以选择数据存储设备
d. 可以选择何时更新托底数据
e. 可以校验托底数据
f. 记录性能日志
g. 配置简单
数据流向图:
资源评论
