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

　　这样走下来一方面把我们平时可能漏掉的监控给补全，另外一方面我们的监控配置按照统一的规则来生成。

　　性能压测这一块，可以很好的检验我们优化的结果，压测的过程中我们关注 QPS 的同时，还要结合服务器的 CPU、IO、内存等机器性能指标来定位我们的性能瓶颈。

　　最后来预估我们系统的承载能力，提供数据支撑来申请服务器或者 Docker 资源。

　　压测工具研发可以自己写脚本，借助 jmeter、loadrunner 等工具，也可以有计划的联系性能压测组他们协助执行。最困难的还是产生真实的压力。

　　还有一个备战点，返璞归真，回到代码，重点核心功能检查一遍，把坏味道的代码查出来。

　　比如 join 了很多张表的 SQL 语句、日志输出没有采用条件方式或者占位符的方式、日志重复打印、try 代码块放到了事务中、循环体中含有低性能的语句、锁代码块中进行 RPC 调用，等等。

　　最后，我们可以想一下备战备的是什么，总结历次的大促，我认为主要在工具、知识、经验三个方面的备战：

　　工欲善其事，必先利其器，我们要有一些好的工具辅助我们解决问题，比如 MDC(里面含有 CPU，网络等监控)、UMP(京东自研方法性能，可用率等监控平台)、CAP(容器的总体监控，也含有 CPU 负载等信息查看)。

　　知识层面，是我们历来的积累，我们认识的提高，使用工具时候的指导。

　　经验是我们以往的大大小小的教训的总结，前车之鉴，防止我们再次发生类似的事情。

　　以“结硬寨，打呆账”这句话结束对 618 备战的总结，最重要的一点，还是要求我们备战在平时。

　　作者：王新栋

　　简介：目前就职于京东，一直从事京麦平台的架构设计与开发工作，熟悉各种开源软件架构。在 Web 开发，架构优化上有较丰富实战经历。有多年在 NIO 领域的设计、开发经验，对 HTTP、TCP 长连接技术有深入研究与领悟，目前主要致力于移动与 PC 平台网关技术的优化与实现。

（编辑：西安站长网）

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