API加速完全不同于传统CDN的链路加速，通过缓存API返回内容并结合TCP广域网优化技术，对API请求进行优化。白山API加速将每个API的response数据毫秒级缓存在全网边缘节点，节点内存中的response数据以LRU（Least Recently Used）算法交换。在“热点事件”时，最热的信息持续保存在边缘节点，当客户端访问该API时，边缘节点可直接返回结果，不必返回源站。整个架构如下：

　　API加速架构图

　　API加速服务在网络边缘节点提供对API的加速能力，包括：API返回结果缓存能力、API请求回源网络加速能力。

　　传统观点认为，动态资源（API）无法缓存，但白山提出“任何资源都可以被缓存，只是过期时间不同”。对于常见的静态资源，缓存过期时间较长；而API并非不能被缓存，只是过期时间很短。如一个查询股价的API，可设定过期时间为50毫秒；百米运动员起跑反应时间为100-200毫秒，50毫秒对于PC端或移动端的用户体验并不会造成影响。

　　没有缓存时，1秒内如有10000个用户同时访问，后端承受10000个并发；如果设置50毫秒的缓存时间，理论上可将后端并发降低到20个（1秒/50毫秒=20），后端负载降低至五百分之一，其他请求由缓存服务器直接返回给用户。

　　综上所述，白山API加速为客户提供毫秒级缓存，在不影响用户体验的前提下提高终端用户响应速度，同时降低服务端的业务负载压力。

　　API加速还支持自定义缓存规则，使其更贴近业务，包括QueryString、Header、Path三种类型，针对场景，设定如下规则：

　　GET /get_fprod.php?uid={$1}&pid={$2}&sid={$3}，每个理财产品都有独立ID，产品信息不随用户ID和客户端随机信息变化，因此Cache key可忽略URI中参数的{$1}和{$3}，/get_fprod.php?pid={$2}就是在边缘节点存储毫秒级的Cache key。

　　缓存的过期时间如何确定呢？与业务相关，这需要对客户提供的脱敏日志进行分析，可初步设定过期时间为500毫秒，最后还需考虑RTT修正值，以适应广域网环境；RTT则由API加速服务自动捕捉并实时更新。

　　实际效果

　　通过为客户主要的瓶颈接口配置API加速服务，并在峰值时间，从以下两个维度对比API加速服务开启与关闭时的效果：

终端用户请求平均响应时间和响应码200比例

服务集群平均负载

　　最终效果如下：

　　图A

　　图B

　　图C

　　如图A所示，峰值期间终端用户请求平均响应时间，从3秒左右压缩至40毫秒以内；如图B所示，峰值期间所有请求响应码200的比例从70%左右提升至100%；图C表示，峰值期间，后端CPU Idle从10%左右提高至97%左右。实测对比数据表明，API加速对降低平均响应时间、提升用户体验效果十分显著，在降低后端服务器负载方面效果更加明显，使用API加速的后端CPU Idle可保持在91%以上。

　　后续建议

　　数据库失衡和缓存Redis失衡问题已经解决，但除上述问题，还有很多环节可以改善：

　　1. 队列服务异步化请求

　　目前客户最终落地数据库请求直接请求到MySQL，未经队列缓冲，建议使用队列服务排队处理峰值请求，其好处在于能在大访问量时对请求进行调度，并可控制实际到达数据库的并发，从而有效保护数据库后端。

　　2. API防火墙屏蔽恶意Bot

　　用户日志中含有大量明显且规律的扫描软件痕迹，如sqlmap、fimap等，虽然尚未对业务造成较大影响，但却使服务端资源被占用。建议在负载均衡最前端对扫描行为予以屏蔽，以提高安全性，同时提升服务效率。除恶意Bot，抢单、刷单等行为也会对服务产生影响，建议使用API防护服务识别与拦截。

　　3. 产品层考虑服务降级设计

　　该客户在整体业务上，没有服务降级设计，产品功能优先级未做划分，导致重要的数据库、Cache等众多基础服务混杂。一旦“秒杀”导致数据库穿透等严重问题时，整体服务将不可用。这种情况应重新梳理业务单元，按照优先级切分基础服务，首屏、产品列表、购买、订单等信息优先级最高；其次是非重要功能，如评论、账单等；如果后端负载较大，必要时可直接舍弃次要功能，从而降低后端负载，保证服务稳定。

　　总结

　　解决类似“整点秒杀活动”的情景，是一个系统复杂的工程，就文中客户暴露出来的数据库负载不均匀、Cache缓存负载不均匀等问题，可通过采用数据库中间层和API加速等技术解决，最终可取得理想效果。

　　上述“秒杀”案例，只是API加速的一个典型应用场景，接下来我还会撰文对API加速问题进行更为系统的剖析。

转载请注明出处。