高可用防抖架构及其演进

原创云诚蚂蚁质量AnTest

2023年06月07日 02:00

作为高可用体系的一环，防抖架构通过业务的异构以及异步化处理，实现了对单笔失败请求的挽回，和对故障期间大量失败的兜底，为支付、商户订单等多个业务保驾护航。随着接入业务的增加，原近端防抖架构的弊端也逐渐凸显了出来，新版Mesh防抖架构通过MOSN引流+防抖基座+业务模块的方式，解决了老架构的诸多痛点，实现了对宿主应用的0侵入，以及业务的快速开发迭代。

一、背景

在分布式架构中，系统间的网络交互非常复杂。一个完整的业务流程可能需要几十甚至上百个应用的参与才能完成。任何一个强依赖节点出现问题，都会对链路的上下游产生影响，甚至导致整笔业务的失败。失败可能是网络、数据库等偶发性问题导致的短时间内抖动，也可能是由于系统故障导致的大量报错。

二、防抖思路

防抖属于纵向高可用体系中的一环，其能力依托于链路，尤其适用于核心且冗长的链路，其本质思想为在业务入口层，以最小化、最简化、异构化的实现，与原业务链路进行一定程度的故障隔离。在正常业务冗长链路发生抖动或不可用时，能够代为进行业务处理，从而可以微损甚至无损的保障业务。

防抖将业务流与信息流进行解耦处理。通俗来讲，信息流指业务自身在用户侧的强感知信息展示（如：支付结果页、商户通知等），而业务流指对用户弱感知且具体的业务处理逻辑（如交易中的资金流转）。当发生系统异常时，在用户可感知的实时阶段，对业务进行受理、记录，并mock成功的信息流从而实时返回给用户成功结果。而在下游抖动/故障恢复后，异步将请求记录回放调用下游，从而使整个业务真实执行完成。

三、近端防抖架构

3.1 近端防抖架构简介

近端防抖架构，是已经在支付链路中稳定运行的一种高可用方案。之所以叫做近端防抖，是因为防抖作为一个近端包被接入宿主应用中。宿主应用是需接入防抖的业务的上游应用，一般是网关层。防抖近端中的防抖切面会对调用下游的业务请求进行识别，当识别到接入防抖业务的请求返回了失败响应，会进入防抖流程。防抖近端会将这笔请求序列化落库，然后向上返回mock的成功响应。

可以进行防抖处理的失败请求要确保能够实现最终一致性，即防抖兜底的请求可恢复。我们通过接口返回的错误码来识别请求是否可进入防抖流程，比如网络抖动、数据库抖动这类系统失败可以进行防抖。每个业务方可根据自身需求配置接入防抖的错误码列表。

防抖近端会定期捞取待恢复的流水进行恢复操作。恢复处理流程由业务方编写，可以是简单的流量重放，也可以自定义恢复流程，来推进业务流，达到最终一致性。

3.2 经典防抖案例展示

3.2.1 盒马线下扫码支付防抖

3.2.1.1 业务背景

盒马属于线下支付场景中重度依赖支付宝的一家商户。若支付宝不可用，则在店内的买家无法付款，会导致用户排长队，容易引发重大舆情事件。同时，盒马也对支付宝提出了100%可用率的诉求。由此诞生了盒马防抖。

3.2.1.2 服务端盒马防抖方案介绍

支付宝网关应用A集成了防抖近端组件。当盒马通过网关应用A调用下游支付系统B进行下单和支付时，防抖组件会识别该请求，并对该请求的响应进行解析。如果发现响应失败，并通过响应中的错误码识别该笔请求为抖动时，会对抖动流量进行兜底处理。兜底逻辑中会进行详细的业务校验（包含金额、商户信息、限权等）。校验通过后，会将该笔支付请求记录为防抖流水，并返回成功响应给商户，同时构造成功结果页信息，使得在商户与用户视角看来，该笔交易均为成功。后续待下游业务链路恢复后，防抖会异步从DB捞取流水，调用下游系统进行恢复。恢复时先尝试追款（从买家账户进行扣钱），若尝试一定次数后依然无法成功，则会走防抖免单资金池垫资给商户，以确保该笔交易最终进入成功状态。

3.2.1.3 业务成果

2021年成功避免盒马一次较大故障。

3.2.2 订单同步防抖

3.2.2.1 业务背景

外部商户会通过支付宝网关向支付宝发送订单同步请求。若支付宝处理失败，可能导致客户端首页智能助理、账单、服务提醒等场景无法正常展示，影响使用体验；历史上出现过一次涉及百万数据的订正，导致运维成本太大。由此发展出了订单同步防抖。

3.2.2.2 订单同步防抖方案介绍

在支付宝网关集成防抖引流组件，在识别到订单处理失败后，会通过配置的错误码识别是否进入防抖。当进入防抖，会将该笔请求落库，并返回兜底成功，之后外部商户会收到成功响应。

防抖平台会定时对该笔请求进行重试，来对该笔订单进行恢复。

3.2.2.3 业务成果

22年累计兜底近2亿笔订单同步请求，防抖成功率接近100%；
22年避免一次因订单下游切库导致的请求大量失败故障。

四、Service Mesh时代下的防抖架构

4.1 近端防抖的不足

随着接入业务的增多，近端防抖遇到了一些问题：

侵入宿主应用：近端防抖架构需要上游系统引入防抖近端。防抖近端中除了包含防抖核心能力，还包含部分业务逻辑，比如兜底校验，这又可能为宿主应用引入业务依赖。防抖在提高下游业务可用率的同时，却为宿主应用（一般为入口网关层应用）引入了额外的风险；
开发进度受限：防抖迭代无法自由进行，需跟随宿主应用，无法适应快速迭代的业务需求；
业务逻辑与核心能力耦合，开发成本高：防抖的核心能力与业务逻辑全在防抖近端中，业务开发同学需要理解防抖架构和细节，开发复杂。多个业务团队之间，以及业务团队与防抖团队之间的开发运维可能互相干扰。

4.2 Mesh防抖架构

Service Mesh架构体系下，应用之间通过sidecar进行通信。sidecar实现了分布式系统中通用能力的下沉，使得业务系统更专注于自身逻辑的实现。MOSN作为蚂蚁sidecar的一种实现，覆盖了蚂蚁大部分应用，这使我们可以把防抖所依赖的异常识别和引流作为核心能力下沉到MOSN，来摆脱对宿主应用的侵入。

上图展示了Mesh防抖架构。在业务链路中，应用A调用应用B的服务并获取返回结果。mosn内嵌引流组件实现远程调用的接口识别以及参数解析。应用A的mosn识别指定接口的返回错误码，当判定为指定异常，即将流量转发到防抖中台进行兜底处理。在兜底方法中，可以将本次请求信息序列化落库，并向应用A的mosn返回mock的成功结果。应用A的mosn将用该兜底结果替换原有异常结果并返回给应用A。防抖中台会定期捞取数据库中的待恢复流水执行恢复操作，直到恢复成功，或者达到恢复次数上限。

4.2.1 MOSN引流

可以看到，通过MOSN引流能力，宿主应用无需感知防抖的存在，仅需要对宿主应用的MOSN进行配置即可。配置项包括：

业务识别：即哪些请求需要进行拦截处理。通过MOSN的解参能力，可以实现参数级的业务识别，即识别到某个参数为指定值时，才进行拦截，这样可以让我们方便地区分不同的商户，并针对性地制定不同的防抖策略；

判定请求抖动的规则：典型的抖动判定规则由错误码定义。mosn可以按设定的错误码解析规则提取响应的错误码，若在配置的错误码列表内，将进入防抖流程。此外，mosn还支持通过接口超时率、报错率等指标判定抖动；

请求抖动时调用的兜底服务：防抖中台提供的兜底方法。兜底方法与原始服务接口定义相同，通过uniqueId区分。

4.2.2 防抖中台

防抖中台建设在serverless架构之上，分为防抖基座与防抖模块两大部分。防抖基座抽象出防抖的通用核心能力，如流水服务、恢复调度、配置管控等。而每个业务方维护自己的专属防抖模块，对应一个独立的代码仓库。多个模块可以同时动态安装到防抖基座上。由于模块仅需实现业务逻辑，量级很轻，且支持动态安装和卸载，可以实现秒级部署，这就大大提高了开发和运维的效率，且各个业务团队的开发运维互相隔离。

在每个业务模块中可以包含多个业务场景。业务场景通过mosn的业务识别规则来进行定义，对一类特定的业务进行处理。每个业务场景可以有自己的配置，通过后台来维护。业务模块需依赖防抖SDK，防抖SDK以接口的方式将基座核心能力暴露给模块，实现基座和模块的交互。用户仅需为每个业务场景编写兜底方法和恢复处理器，清晰地划分了平台开发者与业务开发者的职责边界。

4.2.2.1 同步兜底

同步兜底流程中，业务仅需在模块中实现兜底方法。mosn转发的异常请求会被防抖切面拦截。防抖切面会从mosn透传的请求报文中解析出对应的业务场景，并构建该业务场景的配置信息，加载到防抖上下文，随后执行业务兜底方法。

典型的兜底方法首先进行业务校验，再次判断是否准入防抖。随后调用SDK提供的落流水接口，将请求信息序列化落库。最后，兜底方法mock一个成功的响应并返回。在方法内部，可通过配置key从防抖上下中获取具体的配置项。

最后，原始的失败响应会被替换为成功的响应，返回给上游业务。

防抖基座对流水服务进行包装，并提供接口供模块调用，模块仅需要构造对应的参数即可。支持多业务共用流水表，并可按自身需求将业务属性映射到通用索引字段。同时，业务也可以自定义流水表，此时需要业务按防抖规范接入DAO层SDK或服务。

仅同步兜底业务

对于风控等查询类业务，无需落流水，也无需执行恢复处理，当识别到业务失败，防抖将调用一段简化的异构链路，并将该结果返回给上游。这类业务被称为仅同步兜底业务。按触发条件来说，又可以具体划分为如下两类：

按单笔请求执行兜底，即对每一笔请求，如果原始链路失败，均由异构链路进行兜底，异构兜底结果将替换原始失败响应返回给上游；
大范围超时兜底，比如由于下游数据库故障，可能导致几秒至几分钟内大量请求超时或者耗时升高。mosn可以对请求超时（或耗时升高）进行感知，当超时（或耗时升高）请求比例和请求数量超过配置阈值，将把之后可配时间段内的所有流量降级到防抖异构链路。

4.2.2.2 异步恢复

异步恢复流程中，业务仅需在模块中实现恢复处理器：

基座将捞取流水表中的待恢复请求，构造参数调用该处理器执行恢复操作。恢复的频率、次数上限以及每次恢复的数量均可配置。基座将按照恢复结果把流水状态更新为恢复成功、需要继续恢复或者卡单。如果是卡单状态，则需要人工介入处理。

在基座内部，为充分利用机器资源，会通过多层分发来将恢复任务尽量均匀地划分到每台机器，并通过生产者-消费者线程池将恢复任务尽量平滑地划分到每个时间段。

4.2.3 防抖管控后台

防抖后台负责对接入防抖的业务进行维护管理，主要功能如下：

配置管控：维护每个业务场景的配置。配置分为基座部分和模块部分，基座配置与核心能力相关，包括异步恢复开关、重试间隔、最多重试次数、可配置的恢复处理器等等。而模块配置与业务相关，可由业务自行定义，支持多种数据类型，以及业务自定义类型，在推送时，将自动把配置字符串转化为业务定义的复杂配置对象，方便模块处理；
流水查询：查询防抖流水库中的原始异常请求；
手动恢复：可手动在后台触发恢复任务，也可对恢复失败的请求进行手动处理。

五、总结

防抖架构作为一种高可用方案，通过业务的异构以及异步化处理，不仅实现了对故障的兜底，还可以实现单笔失败挽回。新版Mesh防抖架构在此基础上将高可用轻量化，实现了业务的快速接入和迭代。相信在未来，防抖将发挥出更大的业务价值。

如对本文有任何建议或问题，请关注我们的微信公众号，我们将私信回复 ❤️

阅读原文

继续滑动看下一个