如何应对大促流量洪峰？揭秘京东技术人的备战手册

又是一年11.11，大促备战也如期而至，但今年11.11前的大长假给我们备战的准备带来了很大挑战。如何在时间紧、任务重的情况下快速让团队进入状态？如何梳理繁杂的系统风险点、准备资源？作为京东大促的技术基石，京东智联云是如何做到备战的传承和不断迭代优化的？本篇文章中就将为大家一一揭秘。

首先，我们来回顾一下 《大促前技术人的“备战”手册》 ，大促备战需要做好这八步——从资源评估到模拟压测、从预案整理到线上演练，直至最终的大促复盘。

所谓识别保障范围就是为大促活动确定大的边界范围，整个集团的业务线成千上万条，哪些业务是这次大促核心链路上的业务，哪些是核心0级系统，哪些是核心1级系统？在大促备战开始之前需要明确边界范围，明确要保障的业务优先级，才能更方便后面大促保障工作的展开。

例如一个业务访问的网络流量预估是10 Gbps，访问QPS预估是100w/s或者订单数预估每秒有多少万单等，基于评估的业务量就可以去评估整个业务链路上需要的资源量。比如负载均衡器带宽是否足够，应用服务器部署的实例数是否足够，缓存大小是否满足需求，数据库空间以及性能是否满足需求等。如果不够需要扩容的就可以提前进行扩容，如果整个资源池资源紧张，还需要发起采购的就需要提前发起采购，确保大促之前资源能够到位。

各个上层业务团队以及基础系统团队都需要提前整理好预案，尤其是核心预案。所谓核心预案就是大促期间可以快速保命的预案，预案的处理原则要求尽量简单直接高效。如服务的高可用，在真正有异常时，预案可能就是主备切换。当然这种主备切换在很多系统中是自动的，如云数据库RDS。当系统检测到主库宕机时会在几秒钟时间内将从库提升为主库，从而确保整个线上业务几乎不受影响。除了这种自动切换外，我们还需要做好兜底方案，万一主库因为某些特殊情况表现异常，希望可以主动做一下主从切换时也可以人工在控制台一键切换。

▲图1 京东智联云使用界面示意图▲

在预案整理环节中， 服务高可用是非常重要的部分 。 服务高可用可以分为几个级别：首先是Region级别的，如图1所示京东智联云上有提供华北-北京、华南-广州、华东-宿迁、华东-上海地域。Region级别指的就是一个地域，通常是城市级别的，Region下还会再分AZ(Availability Zone, 可用区)，可以简单理解为一个AZ约等于一个独立的机房，比如京东智联云华北-北京这个Region下有可用区A、可用区B、可用区C三个独立的可用区。

对于重要业务如果有需要可以把重要的数据从北京同步到上海。像物流很多库房是分布在全国各地的，资源部署上也会在就近的Region部署相应的服务。每个系统在同一个Region里部署的时候都需要考虑跨AZ的情况，比如应用实例部署到云主机的时候需要跨AZ部署，确保一个AZ异常时另一个AZ的应用可以正常对外服务。申请云数据库或者云缓存等其他资源时，选择跨AZ就可以直接创建出一个跨AZ的数据库或者缓存实例，当某个AZ异常时，可以平滑地切换到另一个AZ，确保业务尽量不受影响。服务高可用一般是靠主备或者无状态的服务部署多份（跨Region或者跨AZ）等来解决单点问题。根据场景不同，当出现异常时可以是自动切换的，也可以是人工在控制台进行切换。

除了服务高可用， 预案整理还有一个非常重要的部分是业务降级 。 所谓业务降级一般指当某个业务如果超过了其不能承受的范围时，可以进行限定保护，牺牲掉一部分业务流量从而保证至少有一部分是可以成功访问的。例如当某个用户访问请求非常大时，可以将用户做一定的限制，超过阈值时访问将会失败，从而确保在整体资源有限的情况下其他正常请求的用户可以访问成功。甚至当正常的流量大到一定程度以后也是需要有能力放弃一部分流量来保证其余大部分流量是正常的。

降级思路实际是贯穿在整个业务链路中的，比如当应用实例部署很多时，每个应用实例的数据库连接池也是需要做好控制的。如果连接池过大很可能造成数据库压力太大，而站在数据库的角度自然也是需要做好最大链接数限制，确保即使应用实例的连接池配置得过大造成有数据库压力大的时候，数据库自身还是有能力保护自己不被打趴下。这种贯穿整个链路的降级保护思路也可以理解为系统间不信任原则的体现，即任意的A服务（模块）去调用B服务（模块）时，虽然在内部实际开发的过程中，A服务会尽量的去保护B服务，但B永远是不信任A的，B需要根据自身的情况做好自己的保护工作。

除了降级保护以外，还有一类是弹性扩容预案， 一般资源扩容在大促之前就会全部扩容完毕，坐等流量洪峰的到来。但是也不排除在大促中会出现少量业务的流量超过了预想值，或者依赖的资源因为机器较老性能较差导致承接流量洪峰时压力较大的情况。尤其是当上游系统的生产流量已经往下游走的时候，下游压力比较大，此时除了降级保护以外还需要能快速在线上扩容来满足整个生产流量往下走。在大促业务压力高峰时间点进行扩容在工程实践上来讲实际是一把双刃剑，对各级系统的考验还是非常大的。大促这种有明确的时间点预期以及压力预期的业务场景中，如果可以提前在业务低峰期做好合适的扩容准备才是最理想的。

监控是我们看系统的眼睛，是线上系统的感知体系。如果监控没有做到位的话，整个系统就是两眼一抹黑的状态，线上运行是否正常就全靠人品和运气了，整个系统的运行就变成了玄学，所以做好系统监控是至关重要的。

监控和报警总是相辅相成的，监控是通过各种方式不断去观测整个系统的各种指标，报警则是发现指标有异常时可以及时通知到对应的值班人员及时介入处理。

监控可以分很多类别，最基本的是存活监控，我把它们称为如何活下来，也就是优先要保证能否活下来这个底线，存活监控一般包括 IP存活 、 端口存活 、 服务存活 等，一个服务是死是活是需要可以明确感知的，如果服务宕机了，需要第一时间可以检测到并发出报警，除了这些机器及服务层面的存活，还有整个AZ(机房)的存活，如果整个AZ出问题了，对整个业务的影响是什么，能否监控到能否发出报警等。

在活下来这个底线保住的情况下，第二类监控是解决如何活得更好的问题，比如TP99到了几秒，CPU使用率是不是过高，内存占用比例是不是过大，磁盘IO压力是不是过高等。这类监控一般可以帮助你快速发现系统压力，在系统真正故障或者不可用前及时介入处理，确保整个系统运行平稳。除了CPU、内存、磁盘等通用指标的监控，实际上还会有很多带有较强业务属性的监控。比如某个任务如果长期处于中间状态，很可能是某个环节出现了没有考虑到的异常，这种就需要有专门的监控用于发现这种长期处于中间状态的任务。

当业务评估、监控报警、预案整理都梳理完，下一步重要的事情就是将整个业务链路完整串起来。例如某个业务预估订单量是10w/s，那就需要采用压测机器人模拟相当的业务量从源头开始压测，观测整个链路在压测过程中的监控指标变化情况。如果有异常要能及时报警，并按预案进行处理。这种完整的业务链路压测代价其实是比较大的，各个上下游系统需要能够处理识别出模拟压测的订单，确保压测产生的订单不会影响到线上生产的订单。

除了业务全链路压测以外，各个系统还需要根据各自系统的特点进行演练，比如云数据库RDS，在大促之前会对线上核心业务构造主库宕机等异常情况，观测系统自动切换时间以及线上业务的表现等，保证即使数据库发生异常也可以秒级自动切换，确保业务表现平稳。此外，数据库还会单独演练数据一键恢复等功能，云数据库除了每天会做一个全量备份外，还会实时将增量备份上传到云存储(oss)，确保即使有异常，在云上也是可以一键将数据还原，解除上层应用的后顾之忧。

京东大促备战的绝大部分工作，不论是业务评估、预案整理、监控报警、业务压测还是预案演练都是前期准备工作，当这些前期准备工作做到位后，开门大促开始时反倒是从容的，需要做的就是做好值班工作。值班同学24小时无缝衔接，确保线上报警可以第一时间响应，如有异常按预案处理即可。

大促结束后，还有一个重要工作是大促复盘，团队一起回顾大促备战到大促结束的整个过程，审视哪些是后续需要改进完善的地方，哪些是未来需要进一步加强的，为下一次大促做更长远的准备。

介绍完经典的八步备战指南，再来看看这次11.11备战我们又遇到了哪些挑战？

第一个挑战是资源需求。 我们先思考一个问题，在云没有被广泛接受和应用之前，各个业务团队和技术团队是怎样的关系？之前京东的业务在没有上云之前，我们的业务部门要提前好几个月开始备战，因为有大量的扩容需求，各团队为了机器需要付出大量的精力去和大家争抢有限的资源，同时涉及机器采购，周期也会很长，备战周期长而且无法优化，陷入一个死结。

云可以解决这个问题吗？ 答案是yes， 这是因为云的背后有一套商业逻辑驱动，以前IT基础设施对于业务部门是成本中心，是辅助部门。但是云的世界里IT基础设施是商品，商品就有其商业行为去驱动，云按照商品去提供标准化的服务，获取对应的收入，业务按照自己的需求去购买对应的服务，同时通过账单和资源使用率严格控制成本，大家各取所需，形成良性循环。 所以第一点要和大家分享的是推荐大家上云。 同时我们利用云的规模效应，将空闲时间以便宜价格售卖给渲染和需要大量计算但是对成本敏感、时效性要求不高的资源提高价格，回收给大促使用，从而满足众多客户的需求的同时大大提高云资源的利用率，降低所有用户的成本。

第二点，我们要对业务系统梳理，识别出有风险的0级或者1级系统。 但是随着大家业务逐渐上云，资源使用也越来越多，从几百到几千、上万，每个都核对一遍基本不现实，我们快速利用Devops系统按照业务应用的角度快速导出所有业务系统的依赖项，根据系统的等级标识和业务部门核对黄金流程里的0级系统的需求和风险点，快速完成扩容和调整，这种将京东大促等众多业务场景的需求沉淀在我们的系统、流程和产品里的思维贯穿在我们所有产品的设计中。以此实现未来将备战逐渐淡化掉，我们的系统随时可以应对大促。

第三个优化项是我们近两年逐渐引入的开门红， 即6.1和11.1，提前为后面更高的大促高峰做一次真实的演练，这次我们的开门红已经超过了去年11.11大促的量，这对我们验证前期准备和为11.11的大促做了一次很好的实操，对于发现的问题要及时修复、超过预期峰值的要尽快扩容，以更好地护航11.11大促。

第四点，我们引入协同理念。 今年的黑天鹅疫情让大家越来越适应了远程沟通，协同办公的系统也被越来越多的公司引进，甚至催生了多家独角兽，京东智联云的协同办公系统，包括移动化、邮件、在线文档等等，大大提高了我们沟通和进度跟踪的效率。

大促备战是一个定频的行为，不能每次都从零开始，传承和积累，以及不断迭代优化是我们必须要坚持的，只有这样才能不断优化我们的流程和打造更符合用户实际需求的产品。