一、业务背景

有赞连锁，定位为连锁品牌多门店管理、多渠道增长数智化经营系统。店铺结构上为多级结构，主要为：

• 管理单元MU（连锁总部、合伙人店铺）：无售卖能力
• 经营单元BU（网店、门店）：具备售卖能力

目前商品在连锁产品中采用的是复制方案，即总部新增编辑商品后，1：1全量复制到每一个分店。商品信息接受MU的强管控，同时也具备部分字段信息的自定义能力，如价格、库存、商品标题等。

商品在进行同步分店时，实际上我们在进行1*（分店数+合伙人店铺数）的商品创建请求。业务设计上，总部商品变更完成不依赖于分店同步。这里我们使用NSQ消息进行数据同步。以商品创建为例，

二、带来的稳定性挑战/问题

2.1 流量失控

• 面对突发的大流量，欠缺流量控制能力；
• 流量来源没有区分，大商家操作影响小商家；
• 无法支撑更大规模的连锁。

2.2 流量分布不均 

一次商品变更，流量被成千上万倍放大，因此连锁大商家占据大部分的机器资源、存储资源、流量资源。

2.3 流量水位变化感知缺失

欠缺流量水位业务操作级别监控，大流量来临，线上定位困难，强依赖于开发测试人员对业务的了解程度。

2.4 支撑更大规模连锁商家 

连锁产品设计之初，估计没有想到会在不久的将来就承接成千上万个网店数量的大型连锁商家，信息更新的时效性要求给我们带来了巨大的挑战。

三、设计思路 

在开始之前，我们先盘点现状、资源，明确行动方向和目标。我们本次行动第一要义并非提供商家非凡的用户体验，而是解连锁总部的操作打崩全站业务的风险。

3.1 目标 

• 连锁商家操作不对非连锁商家产生影响
• 连锁商家之间的操作相互之间不影响
• 具备支撑超大型连锁（*家分店）的能力

3.2 现状 

长链路操作，应用、接口、中间件、存储未隔离，存在突发流量占满资源打爆应用的风险。

3.3 思路 

【短期】 

1、在调用链路的放大节点卡点监控，设置限流。维度：渠道、店铺、商品等

2、在入口进行渠道限流，针对来源渠道设置限流

3、异步消息消费考虑消息合并，降消息数量

【长期】 

1、连锁非连锁资源隔离 

2、连锁vip资源隔离 3、热点商家检测、隔离机制系统化

3.4 成本 

需要输出放大场景链路的时序图，清晰放大节点和公式

四、应对机制-控制、预警、隔离、合并、演练

基于前文输出的链路梳理、链路应用依赖图，我们按照核心链路、非核心链路、高频操作、次高频操作、低频操作的优先级开始上手段。

4.1 流量发现-监控告警

【问题】

1、大流量预警时，只能通过日志系统的接口日志定位大流量商家，效率低下 

2、监控粒度较粗，无法快速对应大流量的业务场景

【思路】

1、流量来之前，具备预警能力。通过设置各业务场景流量和RT的波动阈值（90%&95%），设置监控告警。

2.流量冲击期间，通过各个细分场景的top-N监控，快速定位热点店铺、商品、分组等信息，进行后续的应急处置（如扩容、隔离、控流等） 

【效果】

1、大流量问题由外部上报全部转化为内部发现，问题感知时效提升半小时以上

2、问题定位不强依赖特定的人员，问题定位时长下降2/3。3、全盘呈现对业务影响范围

4.2 流量隔离-vip隔离 

【问题】

1、在应用接口、存储层，大商家和普通商家没有独立部署。目前的设计上，大流量商家操作会占据大部分资源，这对全站商家的体验极其糟糕。极端情况，甚至影响全站业务

【思路】

1、不同业务线之间的链路隔离或者接口独立；对于不能拆分的接口增加来源和店铺级别标签区分；简言之，非连锁业务的商品增删改和连锁商品的增删改业务链路拆分

2、基于总部做资源隔离（如店铺id、商品id），我们的流量翻倍发生在接受消息之后的数据同步阶段，消息真正消费之前拉取动态配置做消息通道隔离

【效果】

1、20+以上业务链路具备vip隔离能力，任何突发流量的连锁支持链路隔离，在分配的资源里面消费，其他店铺不受流量波动干扰

4.3 流量控制-链路限流、消息合并消费

4.3.1 链路限流 

前文我们提到了设置的两个关键节点：入口和流量放大点。与此而来的问题是，设置多少值相对合理？按照木桶定律，我们依据链路时序图，找到当前生产环境的最短木板，确认该接口可分配给连锁链路的流量资源值，按照调用的流量比例，倒推放大节点的限流阈值。

我们在设计流量控制能力，需要支持操作动作（比如商品新建和编辑在同步链路上有大量的接口是相同的）限流、流速控制、临时中断流量、强制跳过异常流量。

【效果】

高频操作如商品、分组关联关系增删改具备操作动作限流能力，20+业务链路具备流控能力，加上前文的vip的隔离，具备随时演练大连锁的能力。

  4.3.2 消息合并消费 

业务监听binlog进行业务逻辑处理，一些情况下不需要感知每一条binlog消息，可以按照固定时间窗口来对binlog消息进行合并，降低同步流量。以连锁c端库存扣减同步到分店的场景为例，我们在扣减上面使用的是引用模式即扣总部库存，查询上面采用查询分店。假定某连锁在进行活动推广期间，库存扣减平均一分钟100次，如果按照10s的时间窗口进行合并，压缩比为16.7:1左右。

4.4 应急预案 

4.4.1 预案目标 

让不熟悉相关业务的同学在值班的时候可以低门槛快速执行预案，恢复生产正常服务。

4.4.2 预案设计原则 

1、在哪里观察到什么指标可以判断，可以执行预案；

2、如果执行，预案的干系人是谁，在哪里操作，详细操作步骤 

4.4.3 设计模板

 

4.4.4 预案效果 

预案就位之后，连锁突发流量的止血时长由40mins收敛到5分钟内，期间影响范围从连锁缩小到特定的店铺或者商品、规格。

【不足之处】

1、目前我们的监控告警和预案之间没有打通，相互之间的关系通过业务表征由开发测试人员人为维护，机动性不强

2、限流阈值是固定值，目前没有根据集群的负载和rt来动态调控

3、业务场景预警能力覆盖待完善，目前仅具备高频操作场景的监控大盘 当然，好的预案应该在预案平台统一管理。针对不同程度的问题表现，值班同学一键执行预案，这一项目前正在建设中

4.5 生产演练 

按照以往经验，我们做秒杀或者活动大促的全链路压测，都会选择凌晨低流量时段。本次开工之前，我突然想起之前老板说过一句话，大意是国外用户达到一定量，凌晨也就不再是所谓的低峰时段。回看项目整体目标，我们完全可以在具备预案能力的条件上，随时演练。毕竟商家要做什么操作并不会挑选时间段，也不会报备。按照小店铺验证-大连锁试错的思路，我们演练计划设计如下：

4.5.1 目标 

当前性能数据采集 告警覆盖完整 预案有效，执行时长 

4.5.2 核心关注指标 

监控告警接口QPS、RT、机器cpu、集群水位、天网error日志，连锁监控大盘、消息堆积情况、中间件（存储、缓存、定时任务等） 

4.5.3 设计维度（多热点）

网店数量、商品数量、规格数量、并发操作店铺数 

4.5.4 演练效果 

演练目前正在实施中，从5月中旬至今，我们累计发现问题20+，其中有5次是阻塞性问题。业务链路优化20+，调整预案里面阈值近10次。在不间断的演练中，逐步完善监控告警覆盖面，最近2个月通过监控发现连锁热点操作、大盘定位业务场景、启动预案控制线上毛刺流量，真实商家带来的问题基本得到控制。

五、未来展望 

【短期】

连锁业务流量监控支持自动发现异常流量，自动上报热点（店铺、商品），流量尖峰之后，自动回退热点；

接入算法规则，推送开发人员适用的预案；

值班人员接收信息后，直接执行预案平台上的预案，通过大盘观察流量趋势趋于平稳

【长期】

复制方案存在两个劣势，随着连锁分店数目的扩大带来的影响直线上升。

首先，同样的商品信息占据大量的存储资源，前文所提在1k分店数的规模连锁中创建1个商品，在数据库以及其他存储组件中会插入1001条数据，其中八九成的字段信息完全一致；

其次，总部和分店数据一致性难以保障。在商家操作的体验上来说，操作完成之后数据即时生效是基本诉求。但在大量的分店同步请求下，我们采用削峰的方式优先保障稳定性，数据同步的时长会逐步拉长。

在稳定性差、资源浪费、扩展性差的前提下，引用方案呼之欲出。引用：在连锁模型中，总部存储共享数据，分店存储差异化数据。简单而言，在强管控的连锁模型中，复制是（1+分店数）个商品实体，引用是1个商品实体。从实现上消减分店同步流量，提升系统的稳定性。演化过程如下图：

连锁业务在稳定性实践中，遇到并解决了不少本文没有提及的问题和挑战，如数据库慢查打满连接、hbase数据热点等，欢迎更多的朋友加入我们一起攻克问题。