演讲者 | 曾明富

规划| 冬雨

编辑| 冬梅

中国已成为全球最大的联通支付市场，联通支付用户规模、交易规模、渗透率均遥遥领先。 网上购物已成为常态。 尤其是2020年以后，受疫情影响，线上经济发挥了重要作用。 订餐、看病、网上购物等都属于网络经济的范畴。 支付是在线经济不可或缺的一部分。

联通支付就像人们生活中的水和电，陌陌支付是国民支付工具，支付系统的可用性非常重要。 网银基础支付团队不断对系统架构进行升级和演进，总结出一套保证系统高可用性的方法，解决系统在不同阶段面临的可用性问题。

本文整理自网银中级开发工程师曾明福分享的主题为《微信支付后台系统高可用性保障体系的演进》的演讲。 分享主要分为三个部分：

1、面向PC的支付框架；

2、移动支付框架；

3.思考与进化。

面向PC的支付框架

基础支付平台演进史

基础支付平台的演进历史主要分为三个阶段：

支付系统的三个重要作用

支付系统涉及三个重要角色：用户、商户、平台。 为了便于理解，我们首先简要介绍这三个角色之间的一些重要交互。 这里以网上购物为例。 首先，用户在商家的系统下订单，同时商家也在我们的支付平台下订单。 下单后，收银机就会被拉起。 平台具有支付查询交互功能，展示订单及用户相关信息。 用户输入密码后，支付完成。 今后平台将向商家发送通知，由商家进行发货操作。

网上银行基础支付平台及其发展历程

这是我们平台的全景图。 走在前面的是陌陌支付和QQ钱包两大品牌。 底层大致分为如图所示的几大系统。 下层是接入网段，负责所有业务的接入，以及路由分发、过载保护机制等。 下面两层是订单和清算系统，底层是分布式账户系统和建行接入系统，后面是贯穿整个交易流程的风控和反洗钱系统，为您提供安全保障。

我们先来说说这个平台的开发过程。

网上银行创立于2005年，2005年到2013年主要是PC时代，有一点通、快捷支付等，这个系统的完善为联通支付的正式到来奠定了坚实的基础。

中国联通支付起源于2011年，从央行发放第一批支付牌照开始，网上银行是第一批支付牌照。 2013年，陌陌支付发布首个版本，从此开启了联通支付网上银行的建设之路。 事实上，联通支付和PC确实有很大的区别。 遇到节日或者疯狂的购物活动，流量高峰就会立刻过来。 我们面临的一个大问题是系统需要建设和优化，我们的性能必须有很大的提高。

2014年，我们搭建了整个订单系统，并采取了缓存、异步等措施。 2015年至2016年，线下支付场景逐渐丰富，人们逐渐进入无现金生活阶段。 用户对于易用性的要求非常高。 我们提出了同城多项活动的框架。

从2016年到2017年，业务发展规模已经非常大了。 我们在安全和灾备方面做了更长远的考虑，提出了两地四中心、跨城市多活跃核心的架构。 2017年至2018年，为了更好的提升用户体验，进行了跨城市多活动条带化访问。 2019年后，我们将继续优化可用性，确保整个系统在出现故障时仍然有效。

架构进化之路

说完流程，我们再来看看我们的架构是如何演化来支持业务量的。

从2015年开始，我们总结为五代架构。 第一代架构是一个非常基础的架构，是一个中心化的系统。 在这个系统中，它基本上是一个单一的数据服务，并且应用程序是无状态的。 所有状态都在数据库上。 在这些系统下，没有很强的灾难恢复要求。

随着业务的发展，我们逐渐发现这些架构有很多缺点，并发展到第二代架构，将集中式系统拆分为几个主要子系统，并进行垂直经度拆分。

去同城建空活系统之后，横向拆分，就是我们的第三代系统。 在此期间，我们完善了分布式账户体系，提供了分布式能力。

第四代系统以后，有几大需求，就是支持快速扩展，要做一些标准化、快速扩展和容灾等。我们提出了基于Set的架构，它就像一个容器单元。 快速部署到您需要的可用区域。

到了第五代，系统的容量不再是核心问题，可能会更加关注可操作性、可维护性、快速扩展等。 以下是基础支付平台可用性保障的全局看法。

联通支付框架

接下来我们就从刚才提到的联通支付的三个阶段中选取一些技术来给大家分享一下。 首先我们来看1.0阶段。

1.0时代

1.0时代我们面临哪些问题？ 系统架构不足以支撑业务快速发展。 我们想快速扩张，但我们做不到。

我们的想法是先持有软件高可用性，然后优化。 有熔断、降级、限流。 如何优化此类措施？ 欧姆普。 哪些称为OMP？ 就是在一台机器上完成所有的支付流程，或者说支付的关键流程。 由于调用分散在各种服务之间，再加上网络费用，所以不好评估。 OMP相当于在顶部有一个路由总线。 进入公交车后，路由到那台机器，整个机器完成支付的关键能力。 这种支付方式尽可能减少了依赖，不仅是网络调用，还大大减少了网络流量。 同时，如果任何一台机器出现故障，都可以直接停电。 此外，服务的比例可以优化，并且每个单机都易于评估和调整。 更重要的是，能力评估有一个基准。 以后扩展时，只需将当前单机数乘以一个系数即可，大大简化了流程。

熔断、降级、接口限流是常用的方法。 熔断主要有三种应用场景：访问非关键资源、访问有冗余链路的资源（异步）、保护下游服务（特别是没有自我保护能力的服务）。 它有几个状态：

关闭：继电器关闭，调用失败次数累加，达到阈值时激活熔断机制；

开路：继电器处于开路状态。 此时下游的调用会直接返回错误； 同时设计了时钟选项。 默认达到一定时间会进入半熔断状态；

Half-Open：半熔断状态，允许一定量的服务请求，如果调用成功（或者一定比例），就会感觉已经恢复，关闭继电器，否则返回继电器打开状态状态;

从部署阶段来看软件高可用性，有单机限流和全局限流。 常见的限流算法有计数器算法、漏桶算法（leakybucket）、令牌桶算法（tokenbucket）等。 在实现socket限流时，要注意两大问题：流量突发（阈值问题）和流量不均匀。

2.0时代

2.0时代，线下场景逐渐丰富，人们已经开始过上无现金的生活。 用户对于单笔支付的可用性更加敏感。

这就是我们同城2.0多元居住的结构。 我们来分层看看。 第一层是接入层，它是无状态的。 我们可以直接将CGI连接到云平台，实现手动运维。

第二层是农业银行的接入。 我们还可以短接交通银行的专线来测量健康度。 如果A专线出现问题，转至B专线。

第三层是订单，也是最复杂的一层，因为涉及很多资源的基础服务都在这一层。 多Set排序系统需要解决Set之间相关性弱甚至无相关性的问题。 如果Set1层出现故障，用户重试时可以直接切换到对应的Set完成交易。

最后是账户层。 通过DB部署，实现多套核心账户。 现阶段我们的实现仍然是手动切换。

我们先来看看健康平台。 双方都是实时流程，分为网段订单和CCB接入账户系统。 在这一层，每一层上报自己的健康度，健康度平台逐层收集健康度，通过健康度平台进行策略分析。 最后形成动作，将差评发送至实时环节。 这样做的好处是，首先基于主中介的健康度，可以实现整个平台的负反馈机制，对实时流程的影响相对较小，可以实现平台化和业务前馈。

这里我们再看一下，多个Set是如何切换的？ 当发现订单Set1层出现故障时，两个Set上报健康状况，健康平台根据阈值进行流控仲裁判断。 确定Set1出现故障，需要进行切换，下发路由阻塞Set1。 所有流量被切断，交换机成功切换到Set2。 这是全链路手动切换的视图。

例如，网段的层是无状态的。 如果有问题可以直接测量健康度然后切换。 如果专线接入出现问题，可以在专线层进行阻断。 去屏蔽，通过这样的系统来保证整个链路的多集多效。

3.0时代

进入3.0阶段，业务突飞猛进，陌陌支付早已像人们生活中的水和电一样。 我们要考虑到一些自然的洪水、地震等情况可能会对整个中心造成严重的破坏。 这个时候我们如何保证我们系统的可用性呢？

当时我们提出了跨城市多活系统方案。 跨城市的国家标准有一些要求。 要求两个城市之间的距离不能太近，但满足距离要求会给系统带来很大的挑战。 那就是网络的延迟。 以北京到天津为例，一个ping包需要40纳秒，也就是说一个请求来回，网络上什么也没做。 它可能已经消耗了 40 纳秒。 例如，如果上海的中心真的坏了，如果你想切换到北京，你需要考虑上海的所有账户数据是否已经在广州收到，以及在上海完成的交易是否已经完成。广州是否收到。 少了多少个单词以及如何解决。

当时我们把一个城市的多活系统做成两个城市的时候，我们看到城市之间有大量的流量穿插。 这时候我们发现系统已经没有以前那么强大了。

我们该怎么做呢？ 首先，进行条带访问。 条带化的一个关键点是在帐户级别对齐路线。 也就是说，当将此类用户划分到两个城市时，应尽可能根据用户的归因级别来进行。 使用权。 举个反例，上海的用户要从上海出发，通过路由总线访问上海设置的订单和上海的账户系统，完成整个交互。 需要对这一层进行梳理，做好账户体系和订单层的规划，通过最外层的路由将用户引导到正确的位置。

你可能会问，我原来的业务这么复杂，我能整理一下吗？ 都能满足您的要求吗？ 当我们实在不满意的时候，我们该怎么办？ 这时候我们就需要区分快慢。 属于城市2的用户，从城市1访问，需要通过最外层的转发代理路由到对应的账户中心完成交易。 同时，这条链路是独立的，不会影响原来的快链路，保证原来99%以上的请求都经过快链路，最大限度地减少慢链路的影响。

上图展示了读写分离，实现数据的一致访问。 首先，用户层面的数据有一个特点。 读的多，写的少，变化也不是很频繁。 对于这类数据，主DB建在其中一个城市，并且只在这里更新。 城市数据的构建是通过用户的Cache完成的，所有可能的变化都通过消息总线发送到其他中心的Cache，以获得快速、准确的实时数据。 数据同步，同时通过DB的异步复制链路，保证其他中心DB的数据一致性，最后通过审计系统保证各个Cache数据的一致性。 通过这种方法，即使在跨城系统下，也可以访问本地资源，提高性能。

思考与进化

后来我们分几个阶段介绍了我们的系统。 在这个演变过程中，我们也做了很多思考，总结如下：

明天好文章推荐