网易宝系统架构之我见：高可用篇

此文已由作者王文学授权网易云社区发布。

欢迎访问网易云社区，了解更多网易技术产品运营经验。

网易宝支撑了整个集团业务绝大部分的支付场景，平均每天的支付订单有100万单，接近1亿的交易额。对系统的可用性要求极高。下面就从我的理解上说说网易宝的系统是如何实现高可用的。

1. 网易宝系统的整体架构

先看看网易宝的系统整体架构(16年初的架构)

网易宝目前系统整体架构图

中间大的浅蓝色的部分为网易宝系统的整个体系。按照从下到上的层次关系分为存储层、技术组件、服务层、接入层。每个层都有系统监控来监控系统的状态。服务层和接入层有风控系统来监控风险行为，保障用户资金的安全。

存储层：数据库主要使用Oracle。网易宝的核心支付服务是基于本地事务去保证数据强一致性的。用户支付完成，订单状态修改为成功，扣除余额，产生资金流水，需要强一致性的保证。订单和流水的数据占了网易宝数据库业务数据的绝大部分。Oracle在单机大表的性能上是非常高的。所以数据库采用的Oracle。文件存储主要使用的FTP。用于存放银行清算文件、对账文件、结算文件。

技术组件层：包括dubbo分布式远程调用中间件、消息队列中间件kafka、分布式应用程序协调服务Zookeeper、分布式缓存存储memcached、杭研调度系统、linux-crontab（逐步迁移到杭研调度系统上，后续废弃）

服务层：为网易宝的核心层，提供高内聚的服务。网易宝支持多样化的支付需求是通过组装服务层的服务来完成业务流程的。包括用户账户服务，订单查询服务，支付核心服务（实现了实名，绑卡，充值，支付，提现，退款的核心流程）；网关服务payments-trans接入了几十家银行和其他支付通道；积分服务提供积分红包的充值、提现、发放和消费服务；网关路由服务gate-service提供支付时路由到具体的支付通道的服务；sign-service提供签名服务，保证内部系统之间和外部系统的调用请求的安全性；pay-gate提供第三方支付通道的对接服务；platform-module提供商户数据的查询服务。接入服务层的服务的方式包括dubbo,http,依赖jar组件。对账中心和结算中心不参与用户支付的流程，对账中心支持所有银行通道的对账，核对我们的备付金和用户商户的账户资金完全无误，对网易宝的资金流水按会计分录做到日切，符合人行的监管要求。结算中心给商户提供人民币结算服务和外币结算服务。

接入层: 分为前台系统（界面交互，后台API接口）和管理后台系统。前台系统包括用户前台epay-web、收银台cashier(从epay-web拆分出来，正在开发中)、网易宝用户端APP、可嵌入第三方APP的支付SDK组件、活动系统promotion、商户前台系统platform-web。管理后台系统包括后台管理epay-admin、网关管理payments-admin、商户后台管理platform-boss（正在开发中）。

风控：对用户在网易宝的整个行为做风险控制，保障用户账号和资金的安全。风控通过kafka异步方式同步网易宝的业务数据，运用大数据处理技术做分析。

与网易宝接入层人机交互的有用户、商户、后台管理人员（技术支持&客服&财务），商户的应用（游戏、考拉、一元夺宝、邮箱、理财等）。

网关系统和对账中心后台依赖几十家银行的网关。

以上对网易宝的整个体系架构按照层次做了个简单的介绍，下面进入主题，网易宝系统是怎么实现整体系统的高可用性的。

2. 系统高可用性的分析

2.1 集群部署、负载均衡、备份(消除单点问题)

网易宝的所有核心应用和中间件都是集群部署的，通过负载均衡，平均分配流量。

对于业务系统，在nginx服务器(nginx集群部署，负载均衡使用LVS)上配置了负载均衡策略，路由请求到后端的应用服务器resin。如果web应用集群某台机器挂了，nginx通过心跳健康检查，3秒内能检测到，把这台机器从可用列表中剔除出去。

中间件dubbo的consumer基于负载均衡算法，获取zookeeper上统计的provider的负载情况，决定请求哪台provider。Kafka也是类似的原理。如果dubbo服务的某台provider挂了，与provider维持长连接的zookeeper心跳线程会检测到，把provider从服务的可用provider列表中剔除，并快速通知到所有依赖该服务的consumer(也是维持的TCP长连接)，consumer更新本地缓存的provider列表。

对于有状态的服务器，都有数据备份机制。

数据库主库会异步同步数据到备库。数据库主库挂了，如果切到备库，可能会丢失部分业务数据(异步复制，网络稳定情况下10ms以内的延迟，不是同步写多份的)。Kafka每条消息都会复制到不同的机器(broker)上。Zookeeper上的数据也是多写的。Kafka的主broker挂了或者zookeeper的主服务器挂了，通过选举算法选举出新的leader。Leader用于读写，slavers用于备份。Leader挂了，从slavers中选举出新的leader快速恢复服务。Kafka和zookeeper是做了数据高可靠性保证的，极小概率会出现丢失数据的情况。

多机房部署上，网易宝有杭州、北京两地机房。杭州是主机房，北京是备，不是多活的。北京的机房服务器数量较少，数据库服务器性能较差，数据复制也有秒级的延迟。所以不到万不得已，是不会切到备用机房的。目前网易支付已经在搭建义桥的机房，2017年实现滨江机房和义桥机房的双活,解决机房的单点问题。

综上所述，在同一个机房，网易宝无论是无状态的服务器，还是有状态的服务器，从存储层，到中间件层，到应用层，都不存在单点问题。机房的单点问题也会在不久后解决。

2.2 缓存：空间换时间

更新不频繁的基础热点数据，如配置项、所有商户信息、网关数据，在应用启动时，加载到本地缓存。减少对数据库的频繁调用。

2.3 应用无状态化，支持横向扩展

网易宝的session管理使用中心化的memcached集群，业务流程中的一些状态数据，也是存放到memcached。系统之间使用文件数据交互的，文件保存到FTP。需要持久化的业务数据保存到中心化的数据库。不管是业务数据，还是非业务数据，都不会保存到本地应用服务器，保证应用无状态化，使得应用集群可以快速的横向扩展。

2.4 读写分离

为了保证核心支付服务的稳定性，数据库上做了读写分离。核心业务的读写走主库。对于读实时性要求不高的查询场景，查询备库。如商户系统订单的查询请求。对于耗时长的sql的查询场景，查询异构库，如商户的对账单下载。

2.5 异步化

热点账户处理异步化

为了避免热点账户上的行锁的激烈竞争影响系统吞吐，网易宝对热点账户的余额更新和资金流水生成，做了异步处理。业务完成后如果需要变动热点账户的金额，先生成缓冲流水，然后由调度任务异步去消费缓冲流水去更新余额、生成资金流水。使热点账户的并发锁竞争变成了串行处理，大大降低了行锁竞争导致的线程阻塞，提高了系统的吞吐。