优化APP启动时请求后台

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

1. 首先各个接口增加数据版本的概念，在响应头中增加数据版本（x-data-version），可以是时间戳，或者数字，总之是方便比较大小的内容。
2. 请求接口时，在请求头中添加数据版本，如果组件的缓存没有数据版本，则生成一个，获取响应缓存返回。如果请求的数据版本大于等于缓存的数据版本，则返回304的响应码。
3. 在相关的数据做了修改后，需要更新对应的数据版本缓存，清除响应的缓存。

好处

• 在APP有最新数据的情况下，减少网络响应内容、带宽、CPU等资源的消耗，提供接口响应速度。

坏处

• 甄别适合做数据版本的接口。不同用户返回不同内容的接口是不适合做数据版本的
• 做好数据库缓存一致性。

3. APP使用缓存：减少APP调用的接口数量

新增一个接口用来获取各个数据的版本号，然后和APP上的版本做比较。然后对过时的数据，调用相应的接口的接口去更新就好。这么做的好处是，APP启动原先要请求20个接口，现在获取到数据版本后，可能只要请求10个接口就可以。效果根据数据的更新频率来定。

4. Nginx使用缓存：将部分响应静态化放到Nginx上

这个优化是将部分接口的响应静态化，放到nginx的服务器上，配合nginx和lua脚本读取返回。

请求响应前置化.png

好处

• 省去后面几个节点的资源消耗
• 少了后面的网络请求时间

坏处

• 增加nginx的处理逻辑
• 可能会返回一定的老数据回去
• 增加了数据修改后的逻辑，可以做成异步

这个方案需要压测，看下有没有提升，提升有多少