狂揽1592亿！京东京麦平台618备战实践总结

　　快速失败策略实际上是一种自我保护措施，比如调用第三方接口超时，如果超时时间设置过长，访问量大的时候，就会导致请求线程积压;如果此时有线程隔离还好，若刚好没有，那么访问量一上来就会迅速导致 CPU 飙高。

　　京麦平台的特点之一，会大量调用第三方接口服务，我们会对每个方法动态的设置超时时间。

　　如果 UMP 报警再结合 JVM 性能数据，我们会将这个接口的超时时间阈值调小，通过 Zookeeper 下发到每一个服务节点上。

　　在大促前，我们会重点检查 MySQL、Redis、JSF 等 RPC 调用的超时设置，确保每一次 RPC 调用都要有上限阈值。

　　关于 RPC 调用超时，这里多说一下，有时候我们会发现调用端性能比如超过 500ms，但是服务端却是在 100ms 上线徘徊。

　　这里面我们除了检查网关延时，TCP 重传，还要注意一点，就是任何一个成熟的 RPC 框架都不会让业务线程直接参与网络请求。

　　RPC 会提供一个消息队列，调用端直接跟消息队列打交道。此时，我们就要想到队列这块是否有问题了。

　　降级限流

　　这种技术实际上是保命的措施。降级一般有屛蔽降级和容错降级两种，对一些非核心的功能，比如京麦的麦圈，服务号，论坛等功能，而它们恰恰又请求着 MySQL，Redis 等公共资源。

　　为了减少这种竞争我们就会对这些功能进行屛蔽降级，直接切断 RPC 调用，不再发起远程调用，返回空或者其他异常提示，减少公共资源的访问。

　　降级开关，目前京麦是采用统一配置中心来使用。同样，限流技术在京麦平台中也是异常重要的一个措施，尤其是对京麦网关的调用。

　　我们目前是采用令牌桶的方法，实现方式是 Guava RateLimiter，简单有效，再结合统一配置中心，我们可以动态调整限流阈值。不用重启服务器即可实现快速限流策略调整。

　　我们在网关里面还有一个设置，就是并发度，这个是方法粒度的，对每一个调用第三方的接口都有一个并发度数值设置。

　　而且是动态设置，也是通过 Zookeeper 下发到每一个服务节点上。并发度的具体实现是通过 JDK 的 Semaphore。

　　我们再来说一下，监控配置和性能压测。

　　监控配置是一定不能缺少，我们要求自己一定要第一时间早于用户发现问题。

　　平时开发在上线的时候我们都应该有统一要求每一个 RPC 调用都要有监控和错误栈的输出。

　　在备战期间实际是对监控配置的一个治理过程，监控配置 key 要规则化，比如***.mysql.***,***.redis.***等让我们一眼便知道是操作的哪一个资源。

　　京麦平台这次备战的过程中通过采用 AOP 的方式，把所有类似的调用统一规范化处理，后续结合 Python 脚本对监控阈值进行统一调整。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!