大型电商如何做双11/618的稳定性保障？

系统稳定性对于一个互联网线上系统至关重要，俗话说的好攻城容易守城难，一个好的系统不光是用户体验好，能赚钱，还要保证线上不出问题，平时要保证系统不会经常宕机，大促期间还要能抗住流量洪峰并且在高并发场景下，业务不出问题。要做到这些其实并不容易，我们不但要从平时的发布流程来保障，还有底层的中间件，业务层的压测，运维侧的监控告警和紧急预案，这些都是稳定性保障需要做的工作。

那大型互联网公司到底是怎么做大促备战的？大促备战有哪些重点工作？还需要哪些中间件和基础平台来做保障？

今天我就来给你分享一下，大型互联网公司是怎么做双11/618大促之前的稳定性备战的。

关于稳定性保障主要需要做这几大类的工作，容量规划、风险识别、预防监控和检验测试。

其中，容量规划，是指应用的机器要根据大促和业务的需要进行扩容、缩容。风险识别指的是针对架构或者软件硬件，中间件等风险点还有可能的资损点进行评估。运维监控要做到就是梳理需要监控的指标和日志还有告警。检验测试，主要是针对应用进行压测，还有一些故障演练。

下面，我们详细聊聊具体需要做哪些工作，怎么做。

先说说容量规划，现在大部分系统都是基于服务或者微服务架构 每个服务或者微服务都是一个应用，应用都要运行在线上环境的机器上，这些机器可能平时足够支撑应用的正常运行，但双11或者大促期间流量会成倍增长，这时候我们就需要对应用进行扩容，但是问题是扩多少合适呢？这时候要参考3个主要的指标。

业务的增长指标是指，今年业务量大增可能导致系统流量大增，这时候就要和业务方确认业务具体增长量，并且评估业务增长可能会给系统带来的流量增长的量。

往年大促指标是指，如果有往年数据，需要知道往年大促应用峰值的QPS，但是需要注意的是应用的峰值QPS是集群的QPS需要除以机器数才是单台节点的平均QPS。

压测数据指标是指，我们要根据上面的两个指标来获得单台压测数据指标，计算公式是这样的。

再根据压测结果得到单机能够承受最大的QPS，通过单机能够承受最大的QPS乘以目前机器数 是否大于 去年峰值 来决定是否需要扩容。

再来讲讲风险识别，风险识别就是通过各种梳理，沉淀出业务的上下游依赖和整体链路的图，再通过评审的方式，来发现应用架构和依赖下游接口存在的潜在风险，可以参考我提供的这张图，图片部分内容我做了脱敏处理，

从图中我们可以看到要把系统所依赖的所有应用和接口，还有调用的下游接口和中间件全部梳理出来， 然后通过评审的方式，来确定风险点和需要改造的地方。其中，需要注意业务中的架构风险，服务间依赖风险，中间件的风险，物理部署风险，资损风险和舆情风险。

然后是预防监控，需要把业务中关键的链路和关键的功能配置日志，配置告警，设置一些开关和制定紧急预案还要做一些针对大促的架构重构。

风险识别和预防监控只是进行了梳理和评审，发现的问题还需要通过专项治理来进行加固，确保大促不出问题。下面就来讲讲专项治理具体需要做哪些事。

专项治理和大促改造

专项治理主要包括，依赖中间件保障专项，依赖下游服务保障专项，代码改造专项，日志和监控指标专项，以及开关和紧急预案专项。

依赖中间件保障专项，指的是要确保依赖的中间件，在大促期间不对部门内的核心业务降级，比如说消息中间件不延时或者不丢，如果发生丢消息或者消息超时重试，要有相应的补偿幂等机制，保障程序正常不出现故障或者资损的问题。

依赖下游服务保障专项，指的是对于下游的服务可能出现的问题，比如超时或者抛异常，都要有降级或者监控并且打印日志，当发生问题的时候能够快速定位，快速响应，并且能够返回错误给上游，不会造成雪崩影响全链路。

接下来是代码改造专项。大促当天凌晨是流量最高的时候，任何不必要的影响程序性能和数据库性能的操作，都需要停止或者错峰，这时候往往需要改造代码。比如说定时任务错开零点高峰执行，一些数据拉取的任务调整成从备库拉取，针对慢SQL进行优化或者SQL语句的调整等。

日志和监控指标专项，说的是针对关键功能，关键链路，可能涉及到资损和影响主链路的地方，都需要打印关键日志，然后针对日志的关键字或者指标，进行监控和告警，配置监控实时大盘，可以在大促期间实时发现数据异常。

比如，我给你展示的这张图就是针对Nginx日志配置的流量大盘，我们能实时观察到请求流量的变化。

开关和紧急预案专项是指应用要支持一些动态的配置，这些配置像开关一样，可以打开或者关闭某些功能，大促的时候一旦发生资损或者故障，有些开关可以打开，某些功能会立即停止，从而防止造成更大的损失。这些开关需要被录入预案平台，大促期间这些开关只能通过预案来执行。这个专项有两个关键动作，一是应用中所有必要的开关都要录入预案平台，二是需要提前测试执行，确保它们没问题。

我给大家展示一段实现动态开关降级的伪代码。

public ServiceResponse msgPush(String content)
{
    //isAvailable 为动态推送的变量，当服务需要手工降级时，比如下游接口不可用或者可能出一些资损问题这里直接止损，推送为false， 
    
    if(!isAvailable)
    {
        return ServiceResponse.toError("service is unavailable");
    }
    
    //dosomething   这里执行正常的业务逻辑取数据


    return ServiceResponse.success(data);
}

这些工作都做完之后，最重要的就是检验测试环节了，这里主要就是对所有的业务链路以及所有接口，进行压力测试，还有针对于紧急故障的故障演练，断网演练，切留容灾演练等，这里我就不详细展开了。

最后我们总结一下。整个大促稳定性保障工作，其实分为三个方面和四个类，三个方面包括梳理、治理和验证，四个类型包括容量规划、风险识别、预防监控和检验测试。我总结了张思维导图，你们可以看一看。

今天的分享就到这里，希望我的分享可以帮助到你，如果你对视频中的任何环节有疑问，都可以留言和我讨论。