一文了解电商大促系统的高可用保障思路-献给技术伙伴们

电商大促是电商平台组织的一种大型销售推广活动，目的是通过提供各种优惠、折扣等方法，提高商品销售额和网站流量，增加消费者的购物欲望，以实现销售目标。电商大促活动通常会在一些特定的节点或者节日举行，比如“双11”、“618”、“黑色星期五”等，这些时期的电商大促极具吸引力，既有大量的商品打折优惠，又有丰富多样的活动供消费者参与，是电商平台提升销售业绩的重要手段。 电商大促活动期间，大家可以购买到平时心仪已久的商品，并且价格通常会远低于平时，而电商平台也会通过活动吸引更多的消费者流量和购买力，进一步提升其在电商行业的影响力。电商大促不仅仅是一种营销方式，也是电商平台和消费者互动、提高用户粘性的有效方式。

618大促：每年6月是京东的店庆月，也是京东的电商促销主战场，在店庆月京东都会推出一系列的大型促销活动，从6月1日延续至6月18日（近几年开始从5.20日左右开启预售模式，但是整体时间依然是以6月1日开门红为准）。从2010年开始，以满减、优惠券等活动的方式，通过单品类、跨店铺等方式逐步蔓延到23年的百亿补贴，历时已经13年之久为整个京东零售平台的GMV营收带来不小的贡献。

双十一&双十二: 双十一是指各网络购物平台在每年11月11日的大型促销活动，最早起源于中国阿里巴巴旗下购物网站在2009年11月11日举办的“淘宝商城促销日”，现已演变成全行业一年一度的购物活动，及影响全球零售业的消费现象。2012年11月11日网络购物全日销售额超过美国网路星期一，成为全球最大的互联网的购物节日。双十一购物节战场延伸进12月，即“双十二”。（备注：淘宝商城项目刚独立，后更名为天猫，该营销活动主打品牌商的商品，是想要模仿美国感恩节大促销这种活动，通过一个活动或一个事件，让消费者记住淘宝商城）。（参考维基百科）

黑色星期五：Black Friday最早于2005年美国网络shop.org创造的购物节日，与1111被电商炒成购物节原因相似。与之相对应的还有兴起于法国、葡萄牙与德国的Cyber Monday。关于黑色星期五这一叫法的起源，较普遍的一种认为看法是，由于这一天是感恩节（11月第四个星期四）后开业的第一天。再加上人们通常由此开始圣诞节大采购，很多商店都会顾客盈门从而有大额进帐。传统上商家会用不同颜色的墨水来记账：红色表示亏损即赤字；反之黑色则为有盈利。商家把这个星期五叫做黑色星期五，用以期待这一天过后，年度营收由负转正，由红字转为黑字。而商店的员工则使用黑色星期五这一名字来自嘲，表示这一天会非常忙碌。黑色星期五这一天一般都会是一个大的采购狂潮，销售额是一年中第二或第三高的一天，而通常一年中销售额最高潮是圣诞节前夜或之前的一个星期六。（参考维基百科）

除上述比较大型的电商促销活动外，其他零售电商平台比如苏宁818、国美418，以及其他电商平台也在自己造节日，而近几年的拼多多、抖音、快手等电商平台更多的是借势双11或者618来提升整个电商平台的GMV交易额。

经过上面电商大促简介，大家心里已经有一个简单的电商大促活动认识，对于电商行业从业者，电商大促活动是基本的知识，近几年随着“新零售”、“无界零售”、“全渠道”等新词的频出，给原本电商大促活动增加了更多的业务复杂性。这也是为甚么会在这里提下系统分类的原因。在整个零售业链路的节点上，刘总曾经提到过“十节甘蔗”理论，而我们致力于做的事是后5节甘蔗的内容，大家知道京东是以自建仓储物流打通供应链为核心驱动力，而淘宝天猫平台更多是聚集在平台交易环节通过营销和兼并购买生态产品带动流量增长为核心驱动力（近几年阿里也开始布局菜鸟平台开始衍生至其他节甘蔗）；拼多多商业模式更侧重于不同的营销模式，所以系统也聚焦在营销、交易侧，采用第三方商家和物流配送体系；抖音、快手直播电商本身是在构建一个流量场，从开始京东、淘宝天猫入驻流量场到现在独立发展电商，他们更多是希望搭建的平台场来实现交易额；



通过上面的讲述其实是想要说一件事，如果单纯字面上说电商大促备战是没有意义的，针对不同环节的"甘蔗",整个电商大促中重要性不同，所以电商大促备战中，需要明确自己的系统在整个业务链路中的位置，同时系统提供的核心功能，是否涉及资损、用户体验、阻碍交易行为或者影响公司名誉、品牌、集团战略、营销计划等内容。

基于上述内容，我们可以基于营销、交易、仓储、配送、售后来划分京东零售整个系统的业务链路环节初步划分，从大促活动来看营销是吸引流量、聚集流量、进行流量转化的手段，属于整个大促活动的核心环节；从我们的电商平台大促目的来说，大促活动更多的是希望带来交易订单的达成，促进交易额的提升，所以整个交易链路是真正目标核心链路，属于整个大促活动的最重要环节；从仓储、配送、售后来看更多的是交易后履约服务保障，这里面更多的是给电商平台带来的口碑影响，和用户的长期体验，对于电商平台长期发展来看也是非常重要，但是在电商大促的特定场景下可能相对前置的交易属于次重要核心环节。因为涉及业务知识比较庞大，以下我简要说明下链路作为大家一个参考（如有不对，可联系ERP：liuxiaocheng6反馈）

营销链路：营销策略方案制定->营销方案采销/商家宣讲->营销方案外部市场公关->营销活动创建->营销活动审核->营销活动投放->促销招商->商家报名->商家选品、发品->营销活动商品审核->营销活动、优惠券、商品的投放&推荐

交易链路：登陆（网站/APP/小程序/H5）->京东首页（搜索&推荐）->商详->购物车->结算页->收银台（支付）->订单(订单列表/订单详情页)->资金对账

履约链路：订单拆分、转移、下传、出管->POP商家(采销/供应商)接单->发货、拣货、打包、出库、打印面单->分拣、配送、自提->确认收货

售后链路：拒收/订单取消/售后退货、换货、退款->商家审核/快速退款/纠风判责->暂停修改订单、拦截物流返仓、原路（部分）退款、上门维修、换新单等->财务对账->客户满意度评价

上面提到的链路因为分叉分支很多，比如时效保证、开寄发票、预售先款/先货、商品评价、直播空间、店铺评价、客服处理等等内容未涉及，也从侧面想说明如果想要保障整个电商平台的大促稳定，如果不区分重点的话，那么眉毛胡子一把抓是肯定完不成好的效果，所以这一个环节主要想要阐述说明在特定场景下，电商大促更多的是保障重点在哪里。

大促备战目标的核心一个点：稳。在我们工作中，很多有经验的同学会发现，如何去设计一个良好的系统，大概会从如下几个要素考虑：功能性、可用性、性能效率、安全和扩展性，有些场景可能比如秒杀系统更多考率的是高并发因素。那么在整个大促备战过程中，基于场景不同，所以我们的大促备战目标也不可同述。但是整体的总目标来说，依然维持在可用性，如何保障交易核心链路更稳、更好的支撑用户购买下单，促成交易。

但是事与愿违，往往我们会发现管理者、项目、产品、研发、测试总是会面临同样的一个问题，资源不足，无论是人力、物力或者财力，永远资源不足的问题是我们要解决的一大核心问题。从古至今，上到将军打仗、皇帝恩济百姓，下到企业家创业，资源不足就决定了我们在做决策的时候，需要集中优势力量兵力结合正确的战略方针，攻击目标最薄弱的环节，保障方案正确落地，正所谓蛇打七寸。所以接下来就很明晰我们要做什么？如何做是我们要考虑的重点。

大促备战是一个完整的事件，具备着详细的故事线，这里面延展开说明下，在领域驱动设计的建模过程中有个事件建模其实就非常好的应证了这一个点，如果我们将人类文明的活动想要梳理清楚，其实很多时候会发现越理越乱，所谓的点-线-面-体，其中线是我们更好的中间表述环节。基于故事线来看的话，那么整体备战思路，我们拆解为事前-事中-事后来考虑，相对而言会比较全面的将大促备战体系针对特定场景下的备战尽可能全面。

（1）参与部门/集团大促启动会，及时获取最新集团备战导向和最新的战略内容，比如京东的三道防线战略。

（2）进行资源盘点梳理，包含人员、应用、上下游依赖、中间件、数据库，本次大促的SLA约定，值班上下游群，问题反馈群，大促备战手册等。

（3）针对可以降低发生概率的事项进行改造，比如梳理核心链路，针对链路上的薄弱点进行改造，并对于日志进行改造可以基于不同场景进行日志输出，规范整个大促备战的指南方案。

（4）宣讲仪式增强备战感知，比如基于大促封板需求开始，进行大促意识宣讲，同时完善监控大盘，补充关键日志，报警邮件短信治理，历届大促相关指标同环比数据对照分析数据表等。

（5）宣讲会后日检工作内容，比如成立应急故障虚拟小组，基于历史故障和常见问题形成故障手册，同时制定限流和降级预案等指南手册。

（1）业务目标的达成情况，比如某个营销活动的达成情况，做的好的，待改善的，可以萃取经验的内容。

（2）产研测团队的系统需求保障情况，比如大促前期和中间上线的需求，上线情况和需求收益达成情况。

（3）系统应用的指标、资源成本、人力成本投入情况，比如每年大促备战基于成熟化的工作流程、工具等内容，在业务变化不大的情况下，成本投入应该逐年下降等。

（4）备战沉淀的经验形成文档资产，每次大促都是系统历炼的一次非常好的机会，期间形成的文档资产都可以归档方便下次使用。

（5）大促备战中的待办工作内容和事项持续跟踪，很多时候团队部门缺少跟踪事项表，只是记录了时间和人但是持续跟踪的事情没有持续性。

因为上述战略中我们提到的内容比较多，我们这里以系统应用为切入点，开始进行系统评估是否属于良好的应用，如果特征因素中有不满足的我们进行薄弱挖掘，比如大促备战中，其实整个防护工作是以流量沙漏防护原理为核心的，从流量请求开始，CDN、Nginx、业务网关/前端应用直到后端应用（包含中后台系统）以及依赖的相关组件和其他应用，其实是在一个整个流量沙漏下，最复杂最核心的也是我们最常讲的就是后端应用故障稳定保障。



考虑因素特征措施功能/适用性合适原则系统需求的可理解性能效率全面性页面、接口、功能加载时间
时间性RT响应时间、吞吐量
资源利用率内存、磁盘空间、CPU使用率
可扩展性代码、架构设计可用性全面性平均无故障时间、平均修复时间、平均故障间隔时间
稳定性平均停机时间
容错性错误崩溃、代码覆盖率、多机房容灾、冗余备份等可维护性全面性应用维护人力投入情况
模块化结构清晰、边界清晰
可重复使用性代码、功能复用情况
可测试性代码覆盖率
可分析性复杂性、代码圈复杂度、服务之间交互耦合等
可变更性代码大小、变更、代码耦合、服务单一职责等成本全面性开发、测试、部署维护
基础设施云/本地基础设施成本

CDN动静分离：主要集中在我们的前后端分离场景下，但是据笔者了解因为历史、组织结构调整交接等各种原因依然有很多应用没完整彻底的前后端分离，界面还是以后端维护和编写；但是如果是核心应用的话基本上都完成了前后端分离，所以这块优化相对简单。

网关安全保障：通常我们的网关分为技术网关和业务网关，技术网关更多关注的是安全、鉴权、防刷、防攻击、限流和降级等功能，业务网关更多的是偏BFF层的业务接口适配、裁剪等能力。这块我们应该更多面对的是热点流量峰值的不确定性、用户行为的不确定性以及安全攻击等风控行为，需要结合风控团队对于黑产异常流量、异常IP、Cookie自动加入黑名单进行限流操作；同时结合大促压测进行压测指标评估，结合大促预期目标对于系统应用有个合理的阈值和水位管控。

后端应用：后端应用类型、功能、服务面向用户不同决定了高可用的保障手段不同，比如后端应用分类可以基于任务类、工具类、支撑业务类、核心业务类等划分；根据其应用分级的定义程度我们进行应用健康纬度的评估，评估基础硬件资源、容器资源、应用资源、监控报警、链路维度等明细情况，进行薄弱环节治理，比如公司平台的应用健康度能够合理的给应用进行画像，便于问题的诊断和定位。

类型检测指标基础资源应用跨集群应用跨机房应用跨POD应用POD分布JIMDB POD分布网络TCP重传应用容器CPUJIMDB CPUJMQ CPU数据库 CPUJIMDB分片拓扑JIMDB分片POD数据库主从数据库机房数据库规格JMQ PODVIP机房数量后端机房数量错误后端(ip)集群环境一致容器容器存活应用模块化GIT分支灰度更新超时CPU利用率内存使用率磁盘繁忙网络流入TCP连接数CPU利用率内存使用率Swap使用率磁盘繁忙磁盘使用率(根目录)磁盘使用率(export)网络连通性网络流入网络流出系统时间偏差应用JSF版本JMDB版本JMQ2版本JMQ4版本UMP版本DUCC版本LOG4J版本JVM版本Full GC/Young GCJVM_XMX最大堆内存JVM_XMS最小堆内存JVM_堆外内存JVM_ParallelGCThreadsJVM_GCConcGCThreadsJVM_CICompilerCountJVM_MetaspaceJVM_CMS回收阈值JVM_新生代大小JVM_HeapDumpJVM_Server模式JDOS_日志清理JSF_Timeout超时时间JSF_跨单元调用JSF_跨环境调用JSF_跨机房调用JSF_重试次数负载均衡JSF_限流JSF_动态别名JSF_设置黑名单JSF_同机房部署JSF_别名命名规范JSF_混合环境部署color网关timeout最大连接数初始连接数connectTimeoutSocketTimeoutmaxWait时区JIMDB FAILOVER状态JIMDB 热KEYJIMDB 大KEYJIMDB 慢日志JIMDB 扫描过期频率JIMDB 服务端版本一致JIMDB 服务端风险版本淘汰策略JIMDB_Swap交换区JIMDB_绑核JIMDB_CPU模式JIMDB_网卡软中断慢SQL优先治理慢SQL含外键表索引过多表自增溢出表大表接入方式最大线程数JIMDB读超时JIMDB跨单元调用JIMDB连接超时JIMDB等待超时JIMKV连接超时JIMKV读超时JMQ_sendTimeout空应用纯预发应用单实例应用预发流量过大预发资源过多不活跃预发分组应用_实例存活应用_Port存活应用_URL存活JSF_Provider接口存活JSF_Consumer接口存活依赖JIMDB集群异常Server_OPS次数Server_CPU利用率Server_内存使用率Server_内存RSSServer_网络流入Server_网络流出Server_连接数tp99异常次数积压broker 主机-负载broker 主机-磁盘繁忙JED QpsJED连接数JED主从延迟监控报警CPU利用率负载内存使用率Swap使用率磁盘繁忙磁盘使用率网络连通性TCP连接数TCP重传网络流入网络流出系统时间偏差JsfProvider组件报警JimDB组件报警JmqProducer组件报警Mysql组件报警SpringMVC组件报警UMP JVM监控UMP 方法监控JVM_CPU利用率JVM_内存使用率JVM_线程数FULLGC次数YONGGC次数方法TP99方法TP999方法可用率方法TP99配置合理性方法TP999配置合理性方法可用率配置合理性方法调用次数Port存活URL存活OPS次数连接数内存使用率主从断开主从复制延迟积压重试主从延迟Logbook关键字报警配置链路超时链路超时链路超时JIMDB组件

其他应用/中间件/数据库：我们会发现很多时间我们的问题引入集中在三方因素较多，也是在备战中需要关注的重点：

•- 接口定义不合理，业务周知不到位，新上的业务需求直接在某个时刻脉冲流量到达薄弱依赖将服务打挂；

•- 还有部分是因为上下游依赖不稳定，比如遇到性能瓶颈，业务系统强依赖无法作出降级操作，只能静静等待恢复故障；

•- 在机房方面没有容灾，可能因为通信机房网络问题，电缆被挖断或者信号中断等问题导致网络瘫痪故障不可用；

•- 中间件使用策略异常，比如没有做业务幂等性操作、重试策略未控制次数和时间导致依赖的业务系统无法承接脉冲流量从而服务不可用；

•- 还有依赖的中间件和数据库容量水位已到阈值，没有及时扩容，从而引发业务系统的不可用。

•- 应用操作数据库线程阻塞、死锁、慢SQL等造成数据库拖垮服务应用

•- 应用操作缓存/ES出现热点的商品造成的数据流量不均引发的服务不可用。

•- 应用内存泄漏、JVM配置不合理等等

通过上述的流量沙漏防护原理是希望帮助大家能够对于大促备战有个整体框架，从而更好的结合三道防线战略，以及考虑因素评估表和应用画像来决策如何治理整改应用不合理的内容，最终形成相对合理的应用架构。



电商大促相对每个人来说都是很好的成长机会，通过大促备战能够让你更好的补齐自身知识的不足，也能更深入的了解所在团队的核心业务，所以建议无论是业务运营、产品、研发、测试人员都可以简单了解下。

那么如何成为一个合格的团队大促备战师呢？笔者以自身当时经历来说，就是大促备战师要做到胸有成竹，在大促备战前应该充分了解核心链路业务，做好事前工作梳理，能够有着大促指南手册宣导给团队每一个人，做到精兵强将，人人互为备份，将监控报警可视化面板进行大屏展示，及时捕捉和观察业务变动情况。

那么如何成为一个事业部架构师或者集团架构师呢？笔者认为需要有严格清晰的备战路线和里程碑，关注的重点事项以及日例会进行事项跟进和同步，因为当人数超过几十人以后，大促备战更多的是管人、管流程，而不是管应用，所以需要责任到部门、到个人，紧抓流程，同时日例会及时信息沟通减少信息变更差。

关键词：电商,黑色星期五,链路