1。 背景
今年的818大促跟往年不太一样,在苏宁成立30周年之际,苏宁易购提出了"专注好服务"的全新品牌主张,在带来巨大流量的同时,也给我们中台系统的保障工作带来了更大的挑战。如何在818的大促过程中,更快的,更有效率,更智能的全面做好稳定性保障工作,是我们亟需解决的难题。
2。 大促保障的痛点
大促是考验电商后台系统能力的试金场,面对着成千上万的消费者抢购流量,系统压力瞬间增大,为了避免系统被流量冲垮,电商系统经历了从满足日常业务的系统设计模式到满足高并发的系统架构模式的转变,系统架构越来越复杂。大促过程中如何保障系统稳定、快速获取流量峰值和热点、快速获取和汇总相关业务数据便成了大促过程中新的痛点问题。
交易中台基于以上痛点,结合大数据技术,通过数据的挖掘和应用来保障818大促的稳定。
3。 数据组件支撑大促保障
3.1。 TPS采集组件
目前RSF平台(苏宁自研微服务框架)只有分钟级的调用量统计,无法精准统计到秒,且平台原始日志数据也为采样打印,无法直接使用。无论从容量规划角度,还是从实时监控,流控等角度去考虑,秒级监控需求都极为迫切。
基于以上情况,中台自研了TPS采集组件,截止目前已经接入近30个系统、200多个核心服务,通过统一的展示门户,接入服务的实时、历史调用量一览无余。大大提升了压测、大促时链路分析的效率及准确性。这些核心服务的数据落地,为性能分析、容量规划及储备,提供了最基础的不可缺少的原材料。也让业务系统能直观的看到自己系统的核心服务的压力。
方案:
1:利用SpringAOP织入切面,业务系统接入只需添加注解并配置SCM开关。每个jvm统计各自服务每秒的调用量并记录日志。
2:flume实时采集日志。
3:flink汇总每个服务单机房以及多机房的秒级调用量。
4:服务秒级调用量汇总入库。
5:门户实时展示调用量数据。
3.2。 流控组件
流控一直都是系统最重要的保障手段之一。流控从技术实现上分为两种。一种为并发流控,这种流控主要基于并发考虑,公司的RSF框架流控基于此原理,但是缺点也比较大。一般系统服务能力或者筹备目标都是用TPS去衡量,而从TPS很难精准的换算出单JVM能支撑的并发量。而另一种流控是通过控制QPS来拒绝流量,最终保护系统。也是我们弥补目前流控能力不足的方式。
因此,中台自研了流控组件,目前中台130多个核心接口已经全部接入。每个核心接口按照其使用的场景及需求接入了不同种类的流控组件。在接入流控之后,极大的降低了整个大促监控团队的运维压力,某种意义上实现了对服务的无人值守。
3.2.1。 分布式流控
分布式流控主要是针对每个JVM设定流控阈值,进行单JVM流量控制。因此需要计算整体的服务能力,然后除以应用数量,计算流控阈值。他的优点主要是完全基于JVM,损耗极小,几乎可以忽略不计。
1:控制平台将流控阈值下发到每个JVM。
2:对每次请求进行秒级调用量汇总,判断是否超过阈值。
3:如果超过阈值则将超过阈值的请求流控,并打印流控日志。
4:flume采集流控日志。
5:flink汇总单机房以及多机房流控值。
6:门户展示流控数据。
3.2.2。 分布式冷热桶流控
主要用来防止爆款抢购,系统秒杀等热品流量堵到正常系统的请求。如果直接使用普通流控进行拦截,会造成普通商品购买被拒绝。因此对于这种场景,在之前的流控组件的基础上增加冷热桶,系统自动识别热品,同时冷热流控阈值分离。
2:对每次请求进行冷热区分(自动判断、固定值判断)。
3:对冷热请求按秒级维度进行汇总,并按冷、热两个阈值进行判断。
4:如果超过阈值则将超过阈值的流控,并打印流控日志。
5:flume采集流控日志。
6:flink汇总单机房以及多机房流控数量并入库。
7:门户展示流控数据。
3.2.3。 全局流控
全局流控主要是针对流控要求比较精细的场景,希望能做到精准控制。例如提交订单场景。整体思路是设置全局流控阈值(可放入Redis中),由JVM进行阈值步长拉取,后在JVM中去扣减流控步长以达到流控目的。