作者| 吴丰科 供职于中国银联技术开发中心

责任编辑| 杨琪

制图| 吴丰科

编者按：作为中国银联C端业务的主入口，“云闪付”这一面向C端用户的系统在多活建设中由于内部子系统众多，受时延影响明显，容易产生数据错乱、交易失败等问题，为了进一步增强业务高可用性、提升系统容量和优化用户体验，“云闪付”基础团队针对多活遇到的问题与挑战提出了三大解决方案。本文由浅入深地介绍了团队在“云闪付”多活建设中遇到的挑战、应对方案及其实施进展，最后展望了“云闪付”多活建设未来发展方向。

“云闪付”多活的背景

子系统众多。一方面，“云闪付”子系统众多，约逾40个（图1），其内部的子系统可简单理解为粒度稍大的“微服务”，这些“微服务”随着业务的增加也在持续增加；另一方面，App与后台子系统调用频繁，子系统之间调用关系频繁。以转账应用系统为例，一次转账操作前后台需请求交互9次，开始转账依赖于基础核心系统的session服务、卡服务；进行交易时则依赖于通用支付系统的转账交易服务；在转账过程中对用户进行身份验证时又依赖于身份核验系统；转账完成后需要向用户发送相关消息，这依赖于消息推送系统；此外，其余系统也与转账系统有着类似的依赖关系。子系统间的依赖关系增多后，若不同的系统都各有中心分流规则，那么中心间的请求访问势必会非常多。

图1 “云闪付”子系统

时延影响。此外，还有一个关键影响因素是时延的影响，尤其是异地时延。原先单机房的网络时延是0.5毫秒，扩大到北京和上海这种长距离的时延是30毫秒，增加到60倍。单次请求30毫秒的时间似乎并不长，但是叠加多次请求之后会产生时延叠加效应（图2）将会非常明显。

这里以一个简单的场景作说明，打开“云闪付”App涉及到App初始化、获取中心标识、用户信息和首页内容等4步内容。以第一步初始化的请求为例，首先要从外网进来到接入服务这一层，在外部网络上假设请求来回消耗40毫秒（相对理想的时间），从接入服务到业务服务，一次调用耗时35毫秒，从业务服务调用基础服务3次，基础服务再调用至分布式存储服务是2次，这样一次http请求从进来到返回总共时长消耗大约是250毫秒，如此一来，同样一次http请求异地耗时相对同中心时延达到了7倍量级。这仅是初始化中的一个请求，假设每一步都有1～2个请求，时延就会扩大到一秒至两秒，此时用户的感知会非常明显，而这些都是正常情况下的时延，若网络上再出现一些异常延时与抖动，从终端用户角度看，显然会使业务操作耗时变得更加长，用户将难以忍受。

图2 时延叠加效应

“云闪付”多活的问题与挑战

其一，C端跨中心访问问题。“云闪付”App一个用户的多笔操作被送往了不同的中心，在此过程中导致发生用户体验问题（图3）。问题发生的条件是从用户App侧发起请求（C端访问），但两笔请求发送到了不同中心，而请求2依赖于请求1写入的数据。

图3 C端跨中心访问问题场景

假设在同一个会话里，第一批请求发到A中心做“写”的请求，第二批请求为“读”的请求，随机分发到了B中心，此时若是读的请求，则正好“读”刚才从A中心“写”的信息。但过程中若有网络延时，没有来得及同步，那将读不到正确数据，这时用户交易会受到影响；另外一种情况是一个会话内所有请求都在一个中心，会话结束后立即重启App，请求恰好发到另一个中心，此时，同样存在着依赖于数据同步的问题。

其二，C端并发访问问题。“云闪付”App业务功能上要求一个用户同一时间只能在一台设备进行请求与交互，从业务安全角度限制同一用户的并发操作。多中心后带来的第二类挑战是一个用户若有多台设备，若用户在多台设备上使用同一个账号同时登录，同时操作，即两边都在“读”和“写”数据，导致的后果就是无论从用户体验上还是系统数据上，都会发生严重错乱（图4）。

图4 C端并发访问问题场景

其三，BC端跨中心访问问题。C端是从互联网进来的访问请求，B端主要是“云闪付”相关的银联内各子系统间或是与银联外系统间的交互。若一次完整的业务操作需要C端和B端请求配合完成，而B、C端请求恰巧发生在不同中心，数据同步时延可能会导致业务操作失败（图5）。

图5 BC端跨中心访问问题场景

以用户身份核验交易为例，接入方在A中心调用后台系统写入验证信息，获取到验证流水号，随后用户在B中心发起C端身份验证，如果数据同步延迟或中断，在B中心接收到C端请求根据验证流水号未查到核验数据，则会导致核验交易中断失败。

应对“云闪付”多活挑战的解决方案

一是互联网入口分流。这是针对互联网入口分流问题提出的解决方案，采用基于CDN（Content Delivery Network，内容分发网络）的分流模式。具体来讲，当用户的第一笔请求进入某个中心后，由中心分流系统根据分流规则进行判断，若用户已登录，中心分流系统会根据用户的一些规则信息，返回中心标识（dctag）；若用户未登录，会根据设备信息返回中心标识。客户端收到中心标识后，后续的所有的请求都会在http头上携带中心标识。当这些业务请求送到CDN后，CDN会根据头信息上中心标识决定将流量分发到对应中心。这个分流方案的特点是CDN和应用改造都相对比较少，此外，分流规则由APP后台分流系统控制，更为灵活，风险也更低。

二是C+C多中心方案。这是针对上文提到的C端并发访问问题提出的解决方案。基于同一个用户的请求能稳定分发在一个中心，方案提出增加预处理的操作步骤，即通过预处理请求的应答信息将同一用户的后续请求都调整到一个中心，避免依赖中心间数据同步。举例来说，若用户登录时输入了手机号，这时会发送一笔预处理请求到后台，后台会根据手机号找到用户信息，然后由中心分流系统判断该用户的请求应该是在哪个中心处理，将中心标识返回，继而后续的用户登录及其他业务请求都会发送到对应中心去处理。有了预处理操作后，若同一账户在两个设备同时登录，后续请求也会分发到同一个中心，在同一个中心控制用户的并发操作将会比较容易，可以采用传统的锁机制、事务机制进行控制（图6）。

图6 C+C多中心方案示意图

事实上，针对C端跨中心访问问题，还有一个延伸扩展问题——单用户跨中心登录（中心流量调整）问题，即App的一次会话完成后，立即重启App（进程被操作系统回收或用户主动结束App），假设此时中心分流规则发生了变化，原先一个用户的请求是在A中心处理的，规则变了，转到了B中心处理，在短时间内规则变化过程中，用户请求到B中心处理可能会有交易失败的情况发生。

为解决上述问题，提出了中心标识粘滞增强机制，即降低中心流量比例调整过程中对用户操作的影响。具体来说，“云闪付”App在启动时，通过比对上次最后操作时间与当前时间，来决定直接沿用原中心标识还是采用新的中心标识。通过中心标识粘滞增强，短时间内交易继续发送到原中心，这就解决了数据同步延迟带来的影响。

三是B+C多中心方案。针对BC端跨中心访问问题，提出了这一方案，即在原先的服务前加入微服务网关，如此，服务提供方的改造对调用方是透明的，因为原先的“微服务”提供的服务由微服务网关继续提供，微服务网关所做的操作是对接中心分流服务，判断用户的标识（图7），由微服务网关进行中心间的分流。

仍以用户身份核验交易为例，B端系统的请求会把核验信息发送至微服务网关以生成验证流水Id，微服务网关先至中心分流服务查询当前用户应该在哪个中心处理，若是在B中心处理，那就将请求转发至B中心处理，在B中心处理完成后生成流水Id，然后C端的核验请求从互联网入口进入，请求流经B中心的微服务网关时，有两种处理逻辑：若已有中心标识或基因，则优先送往对应中心的服务进行处理；若没有中心标识或基因，微服务网关仍需访问中心分流服务来获取这笔请求的处理中心，然后再进行业务处理。

图7 B+C多中心方案示意图

该方案的好处在于无论是从B端系统间进入的请求还是C端用户发起的请求，都是通过统一的中心分流服务进行BC端流量的协同，能够很好地解决云闪付众多子系统间流量协同的难题。

四是中心切换。中心切换主要有两个维度，一个是切换判断依据，另一个是切换对象。切换判断依据包括交易成功率、CDN中心告警、请求延时、系统告警频次、多维度监控系统告警频次与信息等，根据这些信息综合判断是否切换，然后通过调用切换调度中心（SDP），再调用关联的子系统应用、文件系统、消息中间件、中心分流服务、CDN、Nginx入口等完成中心的切换。

针对“云闪付”内部子系统多的特点，中心切换也将切换的粒度划分为3个粒度，最小粒度是单个子系统的切换，多个子系统都在同一个域名上提供服务，更大粒度的切换就是域名切换，多个域名组成了“云闪付”的整体，最大粒度就是整个“云闪付”中心切换（图8）。

图8 中心切换示意图

实施与推进情况

其一，“云闪付”北京异地中心基础框架已经搭建完成。其正常业务服务已经提供，包括基础系统、支付系统、内容展示系统，以及一些基础服务，如：统一服务注册发现、监控归集、日志归集等都已经完成。

其二，上海B中心生产流量已提升至30%（共27个子系统），双活比例已达85%。“云闪付”上海两个中心同时对外提供服务，其中上海B中心承担生产30%流量。2021年新增双活域名6个，其中4个域名有效，包括基础条线、交易条线、广告条线和账户条线。四个业务条线上的生产流量趋势与和占比与分流比例预计是完全相符的。

其三，产出可复用多活基础组件，形成了开发与运维的多活操作指引。基于“云闪付”App子系统众多，产生了一些可复用的基础组件，形成了开发和运维的规范。一是多活基础组件，包括微服务网关、平滑分流组件、消息消费组件。形成标准组件后，后续系统开发改造，可节省这部分的开发时间与成本。二是开发规范指引，包括大前端开发指引、域名使用指引、微服务网关开发指引。三是运维操作规范，包括多活系统变更流程、多活切换标准方案、多活系统监控方案优化、事件应急流程优化。

未来展望

从六个维度与业界公司进行对比，“云闪付”App在部署架构、数据同步、入口流量分流、应用多活等方面与业界水平持平，尤其在入口流量分流方面有着“云闪付”的特色，而在数据强一致性、中心智能切换方面还有进一步优化提升空间。接下来，团队首先将在中心自动与智能切换方面，结合多个监控因子的智能分析判断，配合CN域名改造事项，进一步优化提升系统的中心智能切换；另外也会在多活与灰度深度融合进行持续探索；最后，为了降低应用多活改造的成本，基于已有的基础多活组件能力持续向应用的跨中心弹性扩缩容目标探索。

（本文系《金卡生活》编辑部根据2022年5月27日中国银联技术开发中心吴丰科，做客中国银联支付学院2022年中国银联科技活动周“金融数字化线上论坛”内容整理而成，已经授课人审阅。）