一 背景
往年的 618 大促曾经如期而至，接下来我会从技术的角度，跟大家聊聊大促备战的底层逻辑和实战计划，心愿可能解答大家心中的一些纳闷。
首先，618 大促为什么如此重要呢？先从数据的角度简略做一下剖析，以下表格列举了咱们历年大促 GMV 成绩单：
| 年份 | 618 销售额（亿元） | 年销售额（亿元） | 618 销售额占比 |
|---|---|---|---|
| 2022 | 3793 | 33155 | 11.4% |
| 2021 | 3439 | 32970 | 10.4% |
| 2020 | 2694 | 26125 | 10.3% |
| 2019 | 2017 | 20854 | 9.7% |
| 2018 | 1592 | 16769 | 9.5% |
依据以上数据统计，咱们能够得出结论：每年的 618 大促销售额约占全年销售额的 10% 左右。以 2022 年 618 大促销售额为例，大促期间，每分钟的销售额均匀高达 1463 万元。因而，从技术角度来看，保障服务的稳定性是至关重要的。置信这些数据能够为您在大促期间制订工作优先级和做出决策提供有价值的参考。
二 挑战
大促期间零碎的稳定性对于业务的失常经营如此重要，咱们须要探讨以下问题：
• 影响零碎稳定性的因素都有哪些？
• 稳定性要求与日常对系统的高可用要求有哪些不同之处？
• 面对各种不稳固因素，咱们应该如何应答？
上面咱们一起来剖析和探讨这些问题。
1. 影响零碎稳定性的因素有以下几个方面：
• 流量大小 ：大促期间，流量往往是平时的几倍甚至几十倍，这对系统的稳定性提出了极高的要求，一个小问题，在流量放大后，往往调演变成大问题；
• 数据量大 ：以 2022 年的订单为例，订单额达到了 3.4 万亿，在海量订单数据的场景下，一个简略的查问，都会变得十分具备挑战；
• 场景简单 ：各类促销优惠、平台、商家、经营等各种营销玩法的叠加，使订单生产链路始终处于高负荷运算状态；
• 交付链路长 ：各端的流量散发、促销计算、加车、结算、提单、领取、物流配送、客服、售后等各个流程节点都须要保持稳定。如果一个服务 99.9% 的可用率，那么 100 个相干服务节点组合起来，可用率就只能达到 99.5% 了，而那 0.5% 的不可用，对应的都是大量的订单散失；
• 容忍度低 ：消费者要求良好的用户体验，商家须要促销疾速失效，平台则要缩小谬误和资损，爱护消费者和商家的利益。更高的冀望和关注，带来的是更低的急躁和容忍度；
2. 在大促期间，对系统的稳定性要求更高，但与平时对系统的高可用性要求不同。这次要体现在以下几个方面：
• 工夫紧迫 ：大促期间须要在短时间内保障服务的稳定性，通常没有工夫深刻技术细节；
• 视角不同 ：稳定性重视整体业务成果，而高可用性重视服务响应后果；
• 维度不同 ：实现业务稳定性保障通常是建设在零碎高可用性的根底之上，并配合相干的服务经营策略，以实现更高维度的业务稳定性。
3. 接下来将重点围绕备战大促的相干思路和教训进行开展，以帮忙您应答挑战并确保零碎的稳定性。
三 稳定性保障
以下列举了往年大促备战的局部措施：
上图里展现的各种备战我的项目，有方向性的领导，有流程上的标准，有落地层面的要求。上面我将从更细粒度的零碎执行层面登程，提供一些备战策略。
正如前文提到的，大促期间的稳定性保障个别属于应急策略。目标是在保证系统稳定性的前提下，对问题的疾速响应。咱们将从利用、存储、经营三个视角，来探讨零碎稳定性保障的应急措施。
3.1 利用视角
3.1.1 单元化
单元化部署是将利用拆分成多个独立的单元进行独立部署，有以下益处：
• 升高整个利用因某个单元故障而导致服务中断的危险；
• 升高故障排查的难度，因为能够疾速定位出问题的单元并进行修复；
• 每个单元都能够独立保护和降级，这样能够升高整个利用因某个单元降级或保护而导致服务中断的危险；
• 每个单元都能够独立扩大和缩减，这样能够依据理论需要动静调整利用的规模。
为了保障服务的可靠性，咱们须要在备战层面实现异地多活的能力，即要求服务进行异地多机房部署。思考到异地跨机房调用的网络延时问题（例如北京到上海的往返网络延时大概为 12 毫秒），黄金交易链路的所有服务都须要本地单元化部署。因而，倡议采纳本地单元化优先的部署架构，并与其余异地单元化互为灾备。
另外，也要留神流量负载平衡策略，防止出现分组的调用流量不平衡，造成局部分组因流量歪斜，导致性能体现不佳的状况呈现；
3.1.2 监控预警
预防和发现问题的最间接形式，须要关注以下几个方面：
• 监控粒度方面：监控依照层级分为底层中间件监控、依赖 RPC 监控、办法监控、机器监控、系统监控、业务监控、流程监控、整体的大盘监控；
• 监控的灵敏度问题。灵敏度过低会导致局部问题被延时裸露甚至被暗藏，而灵敏度过高则会造成信息爆炸，难以分辨信息的主次。因而，在施行监控前须要提前做好功课，确定适合的灵敏度；
• 监控的覆盖度方面：关注监控服务单元、监控指标梳理、监控触达办法。比方：监控须要笼罩容器数、资源指标、运行环境（JVM、线程池）、流量大小、限流值、上下游依赖、超时时长、异样日志、数据容量、模型规模、特色数量等，并能够进行工夫维度的纵向比照；
• 监控的准确性方面：看可用率，须要看上游调用方的，可能 200ms 响应时长，对与调用方来说，曾经属于不可用的区间了。看 CPU 忙碌水平，不能只盯着利用率，还要联合容器核数和 CPU 负载来剖析；
• 预警解除方面：接到预警音讯，及时排查并解决危险，切不可将小问题演变成大问题。先确认是单机硬件或网络问题，还是集群通用问题，如果是通用问题，是否通过服务调用链追踪技术疾速定位问题点，确认好问题起因，能力做好应答预案；
3.1.3 日志打印
日志格局、日志级别、输入形式，归档策略，序列化形式，traceId 策略等都须要进行正当设置，特地要限度反复日志和有效日志的输入，缩小日志对机器资源的占用。比方：业务异样堆栈日志不倡议间接打印，通过状态码统计后果就能够了；
3.1.4 疾速失败
可能疾速地检测和响应故障，帮忙服务更快地恢复正常状态，从而进步零碎的可用性和稳定性。实现疾速失败，常见的技术手段如下：
• 线程池超时工夫的设置，要害零碎要领有动静调整线程池运行参数的能力；
• 利用好工具已有的能力，比方：JSF，JimDB，JMQ 等中间件也都反对超时失败的动静调整能力；
• 服务限流也是疾速失败的一种实现策略，常见的微服务框架和物理网关个别也都反对相似性能；
总之，疾速失败能够爱护系统资源的正当调配，避免出现资源调度阻塞甚至全盘解体状况产生，是稳定性保障的重要伎俩。
3.1.5 服务限流
限流肯定是基于零碎的承载能力来进行的，整个服务调用链路上，遵循木桶原理，上面给出一些倡议：
• 限流形式和阈值须要通过零碎多轮压测验证，以确保数据指标的准确性。
• 对于业务聚合零碎，次要依赖于第三方服务，通常没有存储层，瓶颈往往呈现在应用服务自身。这种状况下，单机限流是比拟好的形式，因为这种形式对于服务扩容或缩容十分敌对。只需保障扩容的容器硬件配置与线上容器保持一致即可。
• 对于底层根底服务，瓶颈点往往在数据存储层，而存储层的扩容老本绝对较高，实现起来也比拟艰难。在这种状况下，全局集中式限流是一个很好的抉择，其目标是优先保障存储层的稳定性。
• 倡议依据调用方的重要水平进行精细化限流经营，确保在极其状况下，具备优先保障外围业务可用性的能力；
3.1.6 业务降级
通常状况下，降级策略是一种防御性的应答措施，用于应答可预感的危险。这种策略可能会就义局部非核心能力，以确保业务的根本可用性。随着业务一直迭代，须要时刻关注之前的降级策略是否依然实用，特地是在多人合作的零碎中。
3.2 存储视角
上面从存储视角来看看稳定性保障方面的一些思路。
3.2.1 数据库
主从架构 ：这是最常见的数据库实例部署架构模式，目标是保障外围数据的高可用，防止出现单机故障，导致数据失落的状况产生；
读写拆散 ：对于大部分实时性要求不高的场景，能够将从库资源充分利用起来的，依照业务场景，实现写主库，读从库的架构模式；
事务隔离 ：MySQL 默认的事务隔离级别是 RR，但对于大部分利用场景，特地切实写频繁的场景，将隔离级别设置为 RC 级别，也可能进步数据库吞吐量；
分库分表 ：这里不是要求大促前进行数据库架构降级，而是说在大促期间，能够进一步将数据进行更细粒度的迁徙，比方启动冷热数据的迁徙工作；
慢查问 ：提前做好索引优化，比拟重的查问，提前进行降级屏蔽，做好监控预警；
3.2.2 缓存
一主多从 ：外围数据须要关注部署架构的合理性，目标是保障外围数据的高可用，防止出现单机故障，导致数据失落的状况产生；
能力扩容 ：缓存是否须要扩容，次要思考两个因素，存储空间下限和 IO 流量下限。在达到下限之前，及时减少分片来进步容量下限；
主从双读 ：缓存主从部署架构的模式下，从分片也能够用来承接局部业务压力；
热点数据 ：热点数据须要及时毁灭，否则容易引起节点性能的急剧下降，高版本的缓存客户端曾经反对了热点数据的辨认，并实现了热点数据进行本地缓存的优化；
大 key 问题 ：大 key 同样会导致集群性能的稳定性问题，外围业务须要思考危险隔离，防止多条业务线专用一个缓存集群，尽量做到集群隔离；
3.2.3 Elasticsearch
双集群 ：ES 尽管领有数据容灾的能力，但在压力大的状况下，可能优化的空间无限，另一方面，集群节点故障的时候，分片再均衡也可能会影响可用率，所以重要的业务倡议做双集群进行能力冗余互备；
慢申请 ：有时候慢申请会导致整个集群卡住，相似关系型数据库中呈现锁库的场景。那么咱们能够通过查问集群中的慢申请工作，若有必要可勾销，以开释资源；
写控速 ：大量的写申请会比拟影响查问性能，有时候能够适当的限度写速度，来保障集群查问的稳定性；
存储容量 ：集群对存储容量默认有依据不同的水位线进行爱护，若超过水位线则无奈再提供写入个性。须要监督集群存储占用状况，亦可依据理论服务器存储配置调高水位线；
3.3 经营视角
千里之行始于足下，再好的预案都须要贯彻执行到位，否则只能事倍功半。上面给出一些经营保障措施。
3.3.1 备战小组
站在零碎或团队内看问题往往是有视线盲区的，还须要有站在更高维度看问题的视角，这就是备战小组。准则就是：及时响应、效率第一。从问题的发现、影响范畴的管制、解决方案的推动到流程标准的执行，备战小组都扮演着不可或缺的角色。
3.3.2 军演压测
这须要协调上下游相干部门，组织协调老本很高，旨在模仿实在线上流量，以进行零碎稳定性的压力测试。这是利用维度，稳定性保障预案的数据指标根底，如：监控指标，熔点阈值、限流阈值和机器扩容数等。
3.3.3 技术封版
上线封版，听起来往往让人难以了解，难道大促期间咱们就不上线了吗？据统计，70% 的线上问题是因为改变发版导致，大促期间，业务需要退让于零碎稳定性保障，也是再三衡量的后果。
3.3.4 每日巡检 / 假期值班
作为零碎主动巡检的补充，对系统定时定点的进行可用性查看。其目标是及时发现问题，升高异样影响范畴。
3.3.5 应急预案
这是呈现问题后的备用打算，备战是为了防止问题的产生，但如果问题真的呈现了，应急预案将成为咱们最初一道防线。对于应急预案相干的要求和操作，参照下图：
四 总结
本文从技术角度深入分析了大促备战的背景和重要性，重点介绍了备战期间稳定性保障的相干措施，包含具体的领导方向和落地细节。本文旨在回顾和梳理备战期间的关键步骤，以帮忙咱们更加从容的应答零碎稳定性的挑战。尽管大促备战是一场紧急行动，但备战的成果离不开平时的合作共识和技术积攒，过往的教训和教训，在此刻将失去充沛验证。
作者：京东批发 刘慧卿
内容起源：京东云开发者社区