2020年初始，因为疫情原因，很多城市的政府推出了口罩预约的服务，产品A也不例外。
因为APP后台并发能力的限制，口罩预约的入口只能放到微信上了。为了后续能把类似活动的入口放到APP，就得提升相关接口的并发。
因为活动大部分都是H5做的，而且很多活动并不需要注册登录，所以入口放到APP上，用户的使用路径可能是：
手机收到APP推送 -> 用户打开APP -> APP跳转到H5页面 -> 用户在H5上根据提示操作
这其中对可能涉及到后台的就是，打开APP时请求后台的一系列接口了。活动H5如果调用了后台，那就是另一回事了。
优化APP打开就可以做到事半功倍了。APP启动时调用的接口大部分都是用来初始化一些数据，比如APP的主页配置，天气接口，首页搜索数据的相关内容，APP常见的弹屏和公告等。这些接口的更新频率不算高，一天一次或几次。
APP请求后台接口经过的路径：
APP -> LVS -> Nginx -> Zuul -> 业务组件A -> 业务组件B
结合接口的功能和请求的处理路径，可以在各个节点使用缓存，减轻对数据库的压力。大概有以下几个方向：
- 业务组件使用缓存：业务组件A和B增加缓存的使用
- APP使用缓存：减少APP调用的接口数量
- 在响应无更新的情况下，减少组件A和B的响应内容
- Nginx使用缓存：将部分响应静态化放到Nginx上
1. 业务组件使用缓存：业务组件A和B增加缓存的使用
增加Redis缓存
2. 在响应无更新的情况下，减少组件A和B的响应内容
大体流程如下：
数据版本处理流程.png
- 首先各个接口增加数据版本的概念，在响应头中增加数据版本（x-data-version），可以是时间戳，或者数字，总之是方便比较大小的内容。
- 请求接口时，在请求头中添加数据版本，如果组件的缓存没有数据版本，则生成一个，获取响应缓存返回。如果请求的数据版本大于等于缓存的数据版本，则返回304的响应码。
- 在相关的数据做了修改后，需要更新对应的数据版本缓存，清除响应的缓存。
好处
- 在APP有最新数据的情况下，减少网络响应内容、带宽、CPU等资源的消耗，提供接口响应速度。
坏处
- 甄别适合做数据版本的接口。不同用户返回不同内容的接口是不适合做数据版本的
- 做好数据库缓存一致性。
3. APP使用缓存：减少APP调用的接口数量
新增一个接口用来获取各个数据的版本号，然后和APP上的版本做比较。然后对过时的数据，调用相应的接口的接口去更新就好。这么做的好处是，APP启动原先要请求20个接口，现在获取到数据版本后，可能只要请求10个接口就可以。效果根据数据的更新频率来定。
4. Nginx使用缓存：将部分响应静态化放到Nginx上
这个优化是将部分接口的响应静态化，放到nginx的服务器上，配合nginx和lua脚本读取返回。
请求响应前置化.png
好处
- 省去后面几个节点的资源消耗
- 少了后面的网络请求时间
坏处
- 增加nginx的处理逻辑
- 可能会返回一定的老数据回去
- 增加了数据修改后的逻辑，可以做成异步
这个方案需要压测，看下有没有提升，提升有多少
网友评论