狂揽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 脚本对监控阈值进行统一调整。 这样走下来一方面把我们平时可能漏掉的监控给补全，另外一方面我们的监控配置按照统一的规则来生成。 性能压测这一块，可以很好的检验我们优化的结果，压测的过程中我们关注 QPS 的同时，还要结合服务器的 CPU、IO、内存等机器性能指标来定位我们的性能瓶颈。 最后来预估我们系统的承载能力，提供数据支撑来申请服务器或者 Docker 资源。 压测工具研发可以自己写脚本，借助 jmeter、loadrunner 等工具，也可以有计划的联系性能压测组他们协助执行。最困难的还是产生真实的压力。 还有一个备战点，返璞归真，回到代码，重点核心功能检查一遍，把坏味道的代码查出来。 比如 join 了很多张表的 SQL 语句、日志输出没有采用条件方式或者占位符的方式、日志重复打印、try 代码块放到了事务中、循环体中含有低性能的语句、锁代码块中进行 RPC 调用，等等。 最后，我们可以想一下备战备的是什么，总结历次的大促，我认为主要在工具、知识、经验三个方面的备战： 工欲善其事，必先利其器，我们要有一些好的工具辅助我们解决问题，比如 MDC(里面含有 CPU，网络等监控)、UMP(京东自研方法性能，可用率等监控平台)、CAP(容器的总体监控，也含有 CPU 负载等信息查看)。 知识层面，是我们历来的积累，我们认识的提高，使用工具时候的指导。 经验是我们以往的大大小小的教训的总结，前车之鉴，防止我们再次发生类似的事情。 以“结硬寨，打呆账”这句话结束对 618 备战的总结，最重要的一点，还是要求我们备战在平时。 作者：王新栋 简介：目前就职于京东，一直从事京麦平台的架构设计与开发工作，熟悉各种开源软件架构。在 Web 开发，架构优化上有较丰富实战经历。有多年在 NIO 领域的设计、开发经验，对 HTTP、TCP 长连接技术有深入研究与领悟，目前主要致力于移动与 PC 平台网关技术的优化与实现。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
