20150211支付清算协会分布式架构研究与设计参考 v1.0.0211
- 1.
- 2. 中国支付清算协会 ii 目录 1. 前言.......................................................................................................................................................... 1 2.对比分析.................................................................................................................................................. 2 2.1. 成本分析 ..................................................................................................................................................2 2.2. 安全性分析 ..............................................................................................................................................3 2.3. 项目管理模式分析 ..................................................................................................................................4 2.4. 工作难点 ..................................................................................................................................................4 2.5. 实施路径 ..................................................................................................................................................5 2.6. 相关政策建议 ..........................................................................................................................................7 3. 分布式系统架构概述............................................................................................................................... 8 3.1. 分布式架构的层次 ..................................................................................................................................8 3.2. 分布式架构的应用 ..................................................................................................................................9 3.2.1. 高可用架构......................................................................................................................................9 3.2.2. 多中心部署架构 ............................................................................................................................10 3.3. 关键技术 ................................................................................................................................................11 3.3.1. 分布式服务集成框架 ....................................................................................................................11 3.3.2. 分布式消息中间件 ........................................................................................................................12 3.3.3. 自主研发的 CDN............................................................................................................................13 3.3.4. 分布式数据库(Sharding) ...............................................................................................................14 3.3.5. 分布式缓存....................................................................................................................................15 3.3.6. 分布式文件存储 ............................................................................................................................15 4. 分布式系统架构最佳实践 ......................................................................................................................16 4.1. 用户交互层 ............................................................................................................................................16 4.1.1. 负载均衡........................................................................................................................................16 4.1.2. 反向代理........................................................................................................................................19 4.1.3. 页面片段缓存................................................................................................................................20 4.1.4. 访问控制........................................................................................................................................23
- 3. 中国支付清算协会 iii 4.1.5. 网络流量控制................................................................................................................................24 4.2. 业务逻辑层............................................................................................................................................28 4.2.1. 高可用消息队列 ............................................................................................................................28 4.2.2. 分布式任务调度 ............................................................................................................................32 4.2.3. 分布式服务监控 ............................................................................................................................33 4.2.4. 服务配置管理................................................................................................................................38 4.2.5. 服务流量控制................................................................................................................................41 4.3. 数据持久层 ............................................................................................................................................43 4.3.1. 分布式文件系统 ............................................................................................................................43 4.3.2. 分布式键值存储库（K-V）...........................................................................................................45 4.3.3. 高可用关系数据库 ........................................................................................................................49 4.3.4. 分布式数据访问层（DAL 服务）.................................................................................................53 4.3.5. 分布式事务协调（DTC 服务）.....................................................................................................60 4.3.6. 数据库复制工具 ............................................................................................................................63 5. 结束语.....................................................................................................................................................70
- 4. 中国支付清算协会 1 1. 前言 金融业包括支付清算行业是我国最早引入信息技术且应用领域最为广泛深入的行业 之一。经过多年发展，业内已形成了较为成熟的以商业化软硬件产品（包括 IBM、ORACLE、 EMC等大型外资企业）为主导的集中式架构技术体系，即以高可靠高性能服务器、高端存 储设备以及成熟操作系统、数据库、中间件等构建起符合 RAS 特性（即可靠性、可用性、 可扩展性）的集中式架构，以满足在海量客户数、账户数、交易量的情况下对业务处理的 实时性、一致性、稳定性、安全性要求。 在集中式技术架构及商用产品体系成熟并广泛应用的同时，业界领先的互联网企业面 对商用闭源企业级软硬件平台成本较高、扩展性难以满足互联网应用灵活要求等弊端，投 入大量研发力量探索出一套基于低成本 PC 服务器（X86 平台）的分布式架构技术体系（主 要涵盖操作系统、云平台管理、数据库及服务治理等通用中间件），基本摆脱了对商用闭 源软硬件厂商的依赖，并不断推进自有 IT 平台向云计算化、大数据化发展，其技术成熟度 在实践检验中持续提升，并为第三方支付、互联网金融等具有金融属性的业务快速发展提 供了重要支撑。尤其是支付宝、财付通等具有互联网基因的非金融支付机构快速壮大，并 以分布式技术架构构建了完整的技术支撑平台和业务系统，其客户数、交易量均已达到甚 至超过传统金融业水平。实践证明，分布式架构技术体系可满足电商、网络金融、第三方 支付等互联网应用模式的大规模发展及弹性应变要求，同时已在一定程度上具备满足传统 金融企业级应用可用性、稳定性要求的技术能力。 统筹考虑新兴技术发展趋势、互联网实践及信息科技自主可控的发展要求，中国支付 清算协会有必要跟进研究在支付企业已广泛采用的分布式架构技术体系，分享支付机构实 践经验，探索现有以集中式架构为主的信息系统向分布式架构的转型之路，为支付清算行 业以及金融业的技术发展贡献一份力量。
- 5. 中国支付清算协会 2 2. 对比分析 随着分布式架构技术体系在电子商务、网络金融等领域的广泛应用，传统的集中式架 构的不足逐步显现。一是集中式架构不能很好适应业务量突发和快速的增长，为了应对最 高业务量，集中式架构不得不按照最大的预估业务量来准备计算资源。二是集中式架构缺 乏弹性，线性的业务量增长会引发指数级增长的 IT投入，一旦系统的容量规划确定，改造 升级的成本高昂，对于业务快速变化的网络时代，被迫三年就得一小改，五年就得一大改。 但技术路线的变化，需仔细研究、深入分析，从成本、管理、安全、人才基础等多个 方面进行比较，衡量优劣和可行性，设计可行的实施方案，应慎之又慎。 2.1. 成本分析 集中式架构的计算平台可以选主机、小型机、也可能是 PC 服务器，分布式架构是以 基于 PC 服务器、甚至是以普通 PC 机为基本计算单元。从比较精确的软硬件投入比对的角 度，从集中式转到分布式后进行后评价才能得到相对准确的结果，因为需要在功能、性能 基线相同的情况下的比对软硬件投入水平。但目前尚缺乏权威机构给出的可信评估结论。 一是成本的比较不仅涉及到软硬件投入，还涉及组织管理、人员结构、运营模式等方 方面面改变带来的成本，即使学术界也缺乏对转变过程中的成本进行评估的评估模型。实 际上，将成本划分为组织正常开销和转换过程带来的开销本身就是一件非常模糊的事情。 二是目前由集中式系统架构转变为分布式系统架构的成功案例仅有支付宝一家，即使 是支付宝也只是从小型的集中式系统架构向 3. 分布式系统架构进行迁移，而其它相关机 构都是从零开始，在没有历史负担的情况下采用分布式系统架构。定量评估集中式系统架 构与分布式系统架构的成本是一件十分耗费财力物力的事情，而且在缺乏可靠评估模型的 情况下其结果也不准确。本节主要从定性的角度比较分析集中式系统架构与分布式系统架 构的成本。 将应用系统从主机平台、小型机平台迁移到 PC 平台，硬件成本会无疑会大幅下降。 从金融应用最广泛的小型机平台看，一套系统使用小型机进行投入预估与使用 X86 服务器
- 6. 中国支付清算协会 3 相比，在同样性能的情况下，软硬件投入多一个数量级。据公开信息，天弘基金推出余额 宝后一开始使用的是小型机，随业务爆发增长，预计要投入 7000-8000 万进行扩容，后来 迁移到了阿里云上，迁移后4 年的云服务费用是 2000-3000 万左右。对于采用主机系统的 大型金融机构而言，采用分布式系统架构的硬件成本优势更加明显。 同时，分布式系统架构中以开源软件为主，则软件成本也会大幅下降。集中式系统架 构使用的商业软件的需要支付高昂的使用费，且商业软件一般将底层功能进行了封装，上 层开发人员无法对其进行修改，因此很多情况下，为实现业务上需求，开发人员不得不寻 求厂商的技术支持才能实现开发目的，这往往也需要支付昂贵的技术支持费用和沟通成 本。而使用开源软件，一般都是免费的，且开发人员可以对软件进行定制修改。 从集中式向分布式转型，软硬件成本一定会大幅降低，但另一方面开发、运维所需的 人力成本也一定会大幅提高。架构转型需要首先进行开发、运维人员知识结构、技能体系 的转型，涉及人员增编、技能培训等等一系列投入。分布式架构系统组件复杂，硬件规模 庞大，需要通过开发、运维摸索一系列自动化管理运维体系，也必定需要大量的人力投入。 综合来看，从集中式转向分布式总体综合成本未必会大幅降低，但是从企业角度来说， 成功完成分布式架构转变的话，企业自身的信息化能力会能够得到显著提升，有利于大型 企业的长期发展。 2.2. 安全性分析 从操作系统或主机本身提供的安全机制上看，分布式架构下一般使用 PC 服务器、Linux 系统、MySql 数据库等软硬件产品，集中式架构则使用主机/小型机、存储设备、Unix、 Oracle/DB2、WAS/MQ 等软硬件产品。从主机安全层次考虑，集中式技术和分布式技术都 是使用类 Linux 系统作为操作系统，在单机的安全性上，两种方式应该有着近似的安全性。 但是，分布式架构是使用大量廉价的机器来替代大中型机器，根据木桶原理，安全性取决 于安全性最差的那台机器，因此在分布式模式下，一组机器中只要有一台出现安全漏洞， 则整个系统的安全性就会遭到破坏。因此，分布式架构下的系统运维工作将更复杂和繁重； 而在集中式方式下，运维人员只需要集中精力关注主机系统的安全即可。
- 7. 中国支付清算协会 4 从数据库和中间件层来看，分布式系统安全方面还没有特别成熟的企业级产品，分布 式架构下的这些组件的安全机制还显得非常不足。例如，Oracle 或 DB2都具备多层级的授 权访问体系，但 MySql 的安全机制明显粗糙，只能控制到 DB 级的读写权限，还需要从系 统软硬件之上的中间件层、应用层面等增加安全监测、防控的配套机制。为了解决分布式 架构下的安全问题，阿里云单独开发和部署了用于整体安全管理的“云盾”系统。相比之 下，集中式技术的数据库和中间件都已经发展得非常成熟。 从网络层考虑，分布式架构下的网络部署较集中式更为复杂，合理的网络部署能够降 低网络安全风险，但是这对运营人员的技能水平以及运维管理水平都有着更高的要求。 综合来看，分布式架构比集中式架构带来了更多的安全风险和挑战，需要更加强大的 自身运维团队以及外部安全支持。 2.3. 项目管理模式分析 集中式架构下，硬件、数据、中间件、应用之间界限分明，在项目组织上开发、测试、 运维、质量保障等团队界限也比较明确。同时，系统变更频度相对固定，可通过周期性的 集中变更窗口进行项目发布及实施，通常以“季度”或“年”为同周期实施变更，进行集 中发布。但分布式系统开发运维特性与传统集中式系统迥异，一是技术上软硬件、中间件、 应用关联密切，二是系统组件庞杂，变更频繁，通常以“天”或“周”为单位实施变更， 且每次发布包含的变化更少。由于部署经常进行，因此系统发布可采用“灰度发布”，逐 步变更到所有的服务器，对生产系统影响较小，应用程序会以平滑的速率逐渐生长。由此， 分布式架构下，开发与运维界限不再明显，部门之间需要十分紧密的合作，以加速交付、 反馈以及创新周期。并往往以产品为单位，组织包括业务、开发、测试、运维人员、质量 保障一体的专项小组，融合开发和运维资源，加速产品发布。 2.4. 工作难点 技术上，根据 CAP 理论1，在分布式系统环境中，数据库的一致性和可用性不能同时 1 分布式系统的 CAP 理论，把分布式系统中的三个特性进行了如下归纳。一致性（C）：在分布式系统中的所有数据备份，
- 8. 中国支付清算协会 5 得到满足，而这两点对于银行业务都至关重要。业界实践是通过在分布式系统中进行部分 功能集中处理、SOA 化、服务治理等进行优化，获得较好的最终一致性。如果银行业务采 用这种方式是否合适，一致性要牺牲到什么程度，需针对业务需求及特性进行详细评估。 实际上，金融业务的不同，在一致性、可用性方面也是有不同要求的，哪些业务系统可以 在牺牲一定的一致性或可用性的情况下转到分布式架构需要摸着石头过河，这也是银行业 从集中式向分布式架构转化的最大技术难点。 对于银行的 IT团队来说，采用分布式架构，首要任务是建立从开发、测试、发布到运 维的快速、集约化流程，通过自动化的交付管理，缩短 IT 交付周期，并从技术与管理上实 现开发与运维的紧密契合。在架构层面，银行需要打破当前内部孤立竖井式的系统，实现 架构上的集成，使分布式真正成为面向客户服务、业务流程驱动的平台。这种改变对银行 的 IT 团队的人员知识结构、技能结构、管理结构以及银行系统整体架构带来巨大的变化， 受到冲击的不仅仅是科技部门，而且要从公司治理、人员安置、资金成本等多方面统筹考 虑。 从银行整体战略考虑，基于分布式技术的信息化架构，能够为银行业务提供可以灵活 扩展的信息化支持，使得信息化能力不再是制约银行业务开展的瓶颈。但这种转换涉及到 对银行的经营管理体制进行全面的转型，这往往需要对企业组织架构进行调整，并通过一 定的流程、考核与激励机制的优化，员工技能的培养，不同产品线的资源整合，最终实现 以客户为中心的金融服务。 2.5. 实施路径 银行业从集中式架构向分布式架构转化可以根据业务系统对数据一致性要求由弱至 强的顺序进行尝试和探索，实施路径可参考下表。 在同一时刻是否同样的值；可用性（A），在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求；分 区容忍性（P）：集群中的某些节点在无法联系后，集群整体是否还能继续进行服务。CAP 理论就是说在分布式存储系统 中，最多只能实现上面的两点。
- 9. 中国支付清算协会 6 系统 起步 后续 网络银行系统可部署在分布式平台 大数据分析系统 可部署在分布式平台 基于 WEB 的渠道类系 统（如网银等） 启动并分步骤推进分布式平台架构 转型 传统渠道系统（如 ATM 等） 分析评估现有分布式平台架构转型 可行性并进行相应尝试 产品类系统 新项目结合业务特性尽量选择分布 式平台部署，分析评估现有系统分 布式平台架构转型可行性并进行相 应尝试 核心系统 对于以客户体验类为代表的部分非 金融交易功能进行下移，剥离至分 布式平台处理，保证核心系统资源 相对稳定或有所缩减，避免容量需 求持续高速增长
- 10.
- 11. 中国支付清算协会 8 3. 分布式系统架构概述 3.1. 分布式架构的层次 表示层 业务1接入服务业务2接入服务 业务n接入服务 数据缓存层 业务逻辑层 数据访问层 数据存储层 消 息 总 线 系 统 集成服务1 集成服务2 集成服务n 基础服务1 集成服务2 集成服务n 用户资料缓存 商户资料缓存 其它信息缓存 用户资料类 DB 订单类 DB 其它资料 DB 外围业务系统1 外围业务系统2 外围业务系统n 三 层 体 系 架 构 图2-1. 三层体系分布式系统架构 图 3-1 所示的一个典型的分布式服务系统是以三层体系结构的设计思想为基础，通过 对数据缓存层和消息总线系统的引入，以达到进一步提高系统性能的目的。各个系统层次 作用如下： 1. 表示层：主要对用户的请求接受以及数据的返回，为客户端提供应用程序的访问。 2. 业务逻辑层：主要是针对具体的问题的操作，也可以理解为对数据层的操作。业务逻 辑层通过对数据层的访问，实现指定的业务逻辑。 3. 数据访问层：主要是对原始数据（数据库或数据缓存）的操作访问层，而不是指原始 数据，也就是说，是对数据的操作，而不是数据库，具体为业务逻辑层或表示层提供 数据服务。 4. 数据缓存层：在一般的三层体系结构中，数据访问层一般直接访问数据库或文件系 统。在分布式服务系统中，由于底层数据库服务器存在性能瓶颈问题，为了降低数据
- 12. 中国支付清算协会 9 访问的延时，可以增加一个数据缓存层，通过内存缓存数据，提高系统整体性能。 5. 消息总线系统：通过消息的订阅和分发，实现部分业务逻辑的异步化处理，以减少实 时联机交易的处理工作量，提高系统响应性能。 3.2. 分布式架构的应用 3.2.1.高可用架构 图2-2. 分布式数据架构拆分方式示意图 分布式数据架构可伸缩策略可以按照三个维度进行设计：按照业务类型进行垂直拆 分；按照客户请求进行水平拆分；对于读远远大于写的数据进行数据复制和读写分离处理。 交易系统的数据主要分为三大数据库集群： 1. 主交易数据库集群，每一笔交易创建和状态的修改首先在这里完成，产生的变更再通 过可靠数据复制中心复制到其他两个数据库集群：消费记录数据库集群、商户查询数 据库集群。该数据库集群的数据被水平拆分成多分，为了既保证可伸缩性和高可靠 性，每一个节点都会与之对应的备用节点和 failover 节点，在出现故障的时候可以在 秒级内切换到 failover 节点。
- 13. 中国支付清算协会 10 2. 消费记录数据库集群，提供消费者更好的用户体验和需求。 3. 商户查询数据库集群，提供商户更好的用户体验和需求。 3.2.2.多中心部署架构 多中心部署架构，可以解决如下几个关键问题： 1. 跨单元交互异步化和尽量的少，让异地部署成为可能。整个系统的水平可伸缩性大大 提高，不再依赖同城 IDC； 2. 灾备成本和可用性问题，可以实现 N+1 的异地灾备策略，让灾备的成本变小同时一定 是确保灾备可用的； 3. 整个系统的稳定性提升，这个架构的形成证明了整个系统已经无单点，同城部署多个 单元可以互相切换，有机会做到 100%的可用率； 4. 整体系统的可管控能力提升，这个架构让线上压测，流量管控，整体灰度发布等以前 难以实现的需求变的简单。主要因为这套架构的形成让我们在业务级别的流量入口， 出口形成了统一的可管控，可路由的控制点。 架构如下图所示： 图2-3. 多中心部署方式示意图
- 14. 中国支付清算协会 11 3.3. 关键技术 同传统企业级应用相比，大型互联网企业在应对业务弹性大，峰值业务是平时数倍、 可用性要求高，能随时支持业务需要、数据存储量大和降低 IT成本的压力，在架构中选用 面向服务、高性能可弹性架构成为应对这些挑战的利器。下图为分布式架构总体框架，后 续就相关内容进行逐一阐述。 图2-4. 分布式架构总体框架 3.3.1. 分布式服务集成框架 使用分布式服务集成框架支持服务水平伸缩是实现弹性计算的重要内容，能够实现软 负载均衡、无单点瓶颈、支持水平伸缩等功能。下图为服务集成框架图：
- 15. 中国支付清算协会 12 图2-5. 分布式服务集成框架 3.3.2. 分布式消息中间件 使用分布式消息中间件保证异步消息可靠，最终保证事务的一致性。在机制上采用写 双份MySql、MySql Replication、基于文件和内存的消息落地机制，保证消息可靠，支持消 息广播，订阅等；支持分布式部署，采用分布式部署，支持软负载均衡和水平伸缩。下图 为分布式消息中间件工作流程图：
- 16. 中国支付清算协会 13 图2-6. 分布式消息中间件工作流程图 3.3.3. 自主研发的CDN CDN 很早就被应用于大规模网站中，作为用户访问跨 ISP、跨地域、跨国家的解决方 案，商用产品有 NetScaler、ChinaCache 等，这些商用的 CDN 产品早期也被互联网企业使用 过，但随着访问量增大，发现商业产品存在性能瓶颈、功能欠缺、成本高、不稳定等问题； 因此互联网企业开始基于开源软件自主研发 CDN 框架，例如淘宝基于 LVS 与 Haproxy 开发 的 CDN 系统，其特点为流量分布更均匀、扩展能力更强、增删服务器更灵活。其异同如下 图所示：
- 17. 中国支付清算协会 14 图2-7. 自主研发 CDN与商用 CDN 对比图 3.3.4. 分布式数据库(Sharding) 单台 Oracle 数据库的处理能力是有上限的，它的连接池有数量限制，查询速度和容量 成反比。在数据量上亿，查询量上亿时，就会遇到性能极限。要突破这种极限，需要对 Oracle 数据库进行扩展，而 Oracle 本身是一个封闭系统，扩展的方法就是增加数据库数量，将数 据分库分表存放。 数据分库后，上层应用还必须像查询一个数据库一样来查询数据，性能也要像查询一 个数据库一样快，所以需要使用分布式数据访问层对数据库进行封装。下图说明了分布式 数据库的工作原理：
- 18. 中国支付清算协会 15 图2-8. 分布式数据库工作原理示意图 数据库 sharding后，能够解决读写性能问题，但并不能应对单点故障及容灾要求，要 通过同城异地建立两套 sharding 数据库，通过专线同步数据，同时解决单点和容灾问题。 3.3.5. 分布式缓存 当交易流量增大的时候，页面信息如果每次都从数据库中读取，显然不划算，要是把 这些信息放在内存中，每次从内存里取，性能要好很多。 由于要同时对页面的静态内容与动态内容作缓存，互联网企业采用了 Key-Value 缓存机 制的系统。这种缓存系统由一个中心控制节点（Config Server）和一系列服务节点（Data Server）组成，Data Server 对外提供各种数据服务，并以心跳的方式将自身的状况汇报给 Config Server，Config Server 是单点提供服务，采用一主一备的方式保证可靠性，Data Server 是分布式部署，所有的 Data Server 地位均等价。如下图所示： 图2-9. 分布式缓存架构原理图 3.3.6. 分布式文件存储 文件存储从企业级应用系统开始就早已广泛应用，对于银行和保险行业而言，客户身 份证件的影像扫描文件、业务单据扫描文件等都需要存储在文件系统中，但是商用存储软 件存在未有针对性优化、文件数据量大导致网络设备无法支撑、扩容成本高等局限性。
- 19. 中国支付清算协会 16 4. 分布式系统架构最佳实践 4.1. 用户交互层 4.1.1.负载均衡 4.1.1.1. 负载均衡概述 负载均衡（Load Balancing）是一种计算机网络技术，用来在多个计算机或计算机集群、 网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到最佳化资源使用、最大化吞 吐率、最小化响应时间、同时避免过载的目的。使用带有负载平衡的多个服务器组件，取 代单一的组件，可以通过冗余提高整个系统的可靠性。而负载均衡器（Load Balancer）就 是完成此功能的一个专用软件或硬件设备。 可以采用两大模式，在不同层面、使用不同技术来实现负载均衡功能。 模式 1：代理中转方式 IP 层软件负载均衡。如 Linux 下的 LVS 软件。特点是内核级操作，负载能力较强， 但不检测后端服务器状态，需要结合一些脚本，才能避免将请求转发到已停机的 服务器上。 TCP 层软件负载均衡。如开源 HA-Proxy 软件。特点是能够智能检测服务器状态， 缺点是负载能力较差。 HTTP 层软件负载均衡。如开源的 Apache 和 Nginx 等软件。特点是解析 HTTP 报文， 从而能基于某些策略，实现服务器粘连性，确保同一个用户的请求，都转发到同 一个后台服务器上。 硬件负载均衡器，基于 IP/TCP/HTTP 等多个层次和网络协议，完成负载均衡。特点 是负载能力强，功能丰富；缺点是成本较高。 模式 2：服务查找方式
- 20. 中国支付清算协会 17 使用智能 DNS域名解析服务器。缺点是修改 DNS 后，生效时间较长，不适合用于 支付清算相关业务。 使用自定义名字服务或配置中心。需要结合前端应用软件，来完成负载均衡。 4.1.1.2. 案例：使用 LVS 负载均衡 LVS 是全球最流行的四层负载均衡开源软件，由章文嵩博士（当前阿里云产品技术负 责人）在 1998 年 5 月创立，可以实现 LINUX 平台下的负载均衡。基于 linux netfilter 框架实现（同 iptables）的一个内核模块，名称为 ipvs。 1、需求及问题：用户接入层需要进行负载均衡，接入层为用户访问网站的入口；内 部系统需要负载均衡，管理多台应用服务器；跨物理 IDC 连接需要收敛和负载均衡。 2、设计思路及架构说明 充分利用 4 层设备性能高的特性在外部入口，内部 vip 以及跨机房互联上使用。如图 所示： 图3-1. 多中心部署方式示意图 LVS 主要技术特点： 内核实现确保了高性能。
- 21. 中国支付清算协会 18 转发模式 FULLNAT，实现LVS-RealServer 间跨 vlan 通讯。 防御 TCP 标志位 DDOS 攻击。 支持集群部署确保高可用性；主要思想：LVS 和上联交换机间运行 OSPF 协议，上 联交换机通过 ECMP 等价路由，将数据流分发给 LVS 集群，LVS 集群再转发给业务 服务器。 高性能的健康检查。 3、实施效果 在支付宝全站部署，多年运行下来稳定可靠。 4.1.1.3. 案例：使用名字服务负载均衡 财付通名字服务案例。负载均衡、故障容灾是分布式系统的共性问题。对于传统的 LVS、 Nginx、HAProxy 等负载均衡服务，存在故障影响大、成本较高、无法从最终业务层次来判 断后端服务的质量等问题。 CL5（Cloud Load Balancer， 5 指代 99.999%的可用性）针对上述问题应运而生。如图 所示： 图3-2. 使用名字服务器进行负载均衡示意图 CL5 基本原理如下：
- 22. 中国支付清算协会 19 1. L5 agent部署在业务机器上，业务使用 L5 API 从 L5 agent 获取后端服务的访问地址。 2. 业务直接访问后端服务。 3. 业务程序使用 L5 API 把后端服务的访问质量上报给 L5 agent。 4. L5 API 和 L5 agent 通过智能的负载均衡和路由算法，决定下一次业务访问哪个后端 服务。例如业务访问后端服务 1 失败的次数超过阈值，那么 L5 将后端服务 1 屏蔽 一段时间，不会提供给业务使用。 4.1.2. 反向代理 4.1.2.1. 反向代理概述 反向代理（Reverse Proxy）是指以代理服务器来接受互联网上的连接请求，然后 将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回客户端，此时代 理服务器对外就表现为一个服务器。 通过使用反向代理，可提高内部服务器安全性，降低内部服务器负载。大多数 Web 服务器都具备反向代理功能，如 Apache 和 Nginx 等。反向代理通常和 HTTP 层负 载均衡结合使用。其结构如图所示： 图3-3. 使用名字服务器进行负载均衡示意图
- 23. 中国支付清算协会 20 4.1.3. 页面片段缓存 4.1.3.1. 页面片段缓存概述 页面片段缓存是大型系统里经常采用的一种数据缓存技术。通过将页面中的静态和动 态片段进行区分，避免由于页面中这些少量的动态内容而无法将整个页面进行缓存。 当前业界已有成熟的解决方案，并且有一个W3C 标准：ESI（Edge Side Include）。它是 一种简单的页面标识语言，开发人员可以使用它标志各种内容片断，方便缓存服务器识别， 并提高缓存效果，从而有效降低原服务器的负载，同时提高用户访问的响应时间。开源代 理软件 Squid 和 Varnish 都有支持 ESI 的响应模块。CDN 网络也可以利用在分布全国各地的 节点中安装支持 ESI 的 Cache 服务器来提供对网站动态内容提供 CDN 服务。 4.1.3.2. 案例 CDN 1. 需求以及问题 收银台在支付宝中作为门面系统，负责复杂的支付工具使用规则，以及和用户的交互， 用户访问量大，计算复杂，是支付宝的最大应用集群。 随着访问量的增加，对集群的机器数量需求很大，机器成本，维护成本都很高，未了 减少单个应用集群的机器数，降低成本，减少日常维护发布时间。特对收银台的部分页面 做静态化的改造。 2. 设计思路及架构说明 总体分析：收银台主界面如图所示：
- 24. 中国支付清算协会 21 图3-4. 收银台主页面示意图 如上图所示，收银台的主页面，目前分成 3个请求，主框架，银行的 2 个异步区域（快 捷部分，和网银部分）。 主框架包含支付宝内部账户部分，包含余额，积分，红包之类，这个内容变化比较频 繁。另外有一个可以使用的支付工具类型的 tab 页面，这个部分对于淘宝交易来说，基本 不变。 快捷部分异步区域，表示一个用户已经签约的银行卡，基本不会变化。 网银部分异步区域，表示一个用户用过的网银，基本也不会变化。 静态化主要真对几个不会变化的地方。 业务流程变成如下图所示：
- 25. 中国支付清算协会 22 图3-5. 静态化后的支付流程图 静态化内容的录制： 通过开关控制录制内容，在 servlet输出的时候，直接保存页面的内容到 tair，同时保 存这个页面创建的时间戳在另一个 key 中。如果需要使用缓存的时候，就直接从 tair 获取。 缓存使用： 在使用缓存的时候，如果发现 tair 中有存在的内容，并且没有过期，就使用缓存的内 容直接返回。因为保存的内容中有部分字符是需要替换的，我们在后端把部分字符串内容 更新掉，但是这个过程就需要经历，从 tair 的字节流转化到字符串，然后替换完成之后， 又转化成字节流的一个过程。 方案改进： 考虑到纯粹 javascript 的执行，在浏览器端，还是比较可靠，就确定使用浏览器端来做 内容替换，这样就消除了后端字节流和字符串的转换。另外考虑到现代浏览器都有部分缓 存可用，最少的 ie6 也有每个域名 64k 左右。我们就把页面的缓存也做到了前端。而前端 的缓存是否需要更新的判断依据也来自于动态请求的主框架页面带上的一些元数据信息。 前端发现需要录制的时候，也把通过 ajax 请求获取的数据，通过前端缓存组件缓存起来。 前端使用的时候，先根据元数据信息判断缓存是否过时，如果过时就访问后端，否则，就 直接使用前端缓存结果，替换必要的字符，然后展现给用户。 业务流程变成如图所示： 图3-6. 方案改进后的支付流程图
- 26. 中国支付清算协会 23 3. 最终效果 收银台整体性能提升 70%，页面请求数量减少20%。 4.1.4. 访问控制 4.1.4.1. 访问控制概述 4.1.4.2. 财付通案例 财付通多联单对账系统主要使命是保护用户敏感数据不泄露，即便泄露，也要及时发 现。当前多联单对账使用场景是依赖财付通的鉴权中心，访问流程如图所示： 图3-7. 财付通多联单对账系统访问流程图 多联单系统架构如下图所示。基本原理是如果黑客攻破 CGI 机器，通过后台服务拉取 敏感数据，多联单对账系统通过对账发现只有后台服务的访问日志而没有前端必经的 CGI 或者服务的访问日志，那么就会告警或者联动打击系统阻断黑客访问。
- 27. 中国支付清算协会 24 图3-8. 财付通多联单系统架构图 目前多联单系统应该应用到财付通 5个关键的业务中。 4.1.5. 网络流量控制 4.1.5.1. 流量控制概述 流量控制可以有效的防止由于网络中瞬间的大量数据对网络和服务器带来的冲击，保 证网络和服务器系统高效而稳定的运行。网络流量控制针对在单位时间内的网络带宽、被 发送到网络中的数据量，或者是最大速率的数据流量发送；服务流量控制则针对单位时间 内的服务请求数量进行控制，及时分流或限流，防止后台某单一服务器的过载，而无法响 应用户请求，甚至导致整个服务器集群的“雪崩”。 4.1.5.2. 财付通案例 财付通流量控制概述。流量控制要尽量靠前，在前端对流量进行限制，防止瞬间流量 太大对后台进行冲击，系统一般在 CGI 接入层来实现。 流量控制的粒度要尽量细，一般根 据业务来划分。实现方案分成两级：全局的流量控制和单机的流量控制。 1. 单机的流量控制
- 28. 中国支付清算协会 25 单机的流量控制比较简单，在共享内存中存放"Key-Value"对。一个"Key-Value"对就是 一种业务的流量控制参数。key 对应业务类型，value 中涉及三个主要数据： 时间段长度：单机一般配置成1s， 在同一个时间段的请求量不能超过分配的配额。 超过这个时间段，重新分配配额。 当前时间段的剩余配额：当前时间段内，这台机器还可以接收多少请求。当时间段到 期以后，重新分配初始配额。每个请求来的时候，当前剩余配额会减 1。如果剩余配额为 0，而且当前时间段还没有超时，则不能再处理请求，直接抛弃，一直等到当前时间段超 时以后，重新初始化配额，才能再处理请求。 当前时间段的超时时间：超时的绝对时间点。当到这个时间点以后，就重新分配配额。 这三个参数都放在配置文件中，可以灵活配置调整。 2. 全局的流量控制 全局的流量控制，涉及到所有机器的总体流量控制，会稍微麻烦一些。我们采用的是 两级流量控制机制。 CKV (tencent的nosql) 全局配额分配 CGI 业务接入机 共享 内存 CGI CGI CGI 业务接入机 共享 内存 CGI CGI 图3-9. 全局流量控制分配示意图 全局的配额存放在腾讯的 CKV 中，这是一个 NO SQL 产品，里面的数据也是 Key-Value 对。跟单机的流量控制类似，一个 Key 对应的一个业务，Value 里面的数据也主要是三个：
- 29. 中国支付清算协会 26 时间段长度、剩余配额和超时时间。为了减少对全局配额的请求量，在本地会在共享内存 中缓存一个小的配额。 当一个请求到来时，每台业务接入机的 CGI 首先会请求本地共享内存的配额，每个请 求都会使配额减1。当本地配额消耗完，再去全局配额中申请新的配额，申请的时候一次 会申请多个，剩余的配额存放在本地共享内存中，全局配额则会减少对应的请求量。例如 全局配额中剩下 100 个配额，某个 CGI 处理请求发现本地共享内存的配额没有了，则去全 局申请了 10 个配额， 那么全局配额就只剩下 90 个。CGI 自己的请求消耗了 1 个，剩下的 9 个则存放在本机的共享内存中。 如果 CKV 的配额消耗完了，而时间段还没有过期，则后继来请求配额将返回频率超过 限制的错误码和剩余超时时间（因为各个机器时间不同步，这里是剩余时间而非绝对时间 点），在剩余这段时间内 CGI 从而不能再处理请求。CKV 在每个时间段超时以后，自动重新 分配初始配额。 全局的流量控制中，如果涉及到网络故障或者全局配额分配出错，那么无法获取配额。 那么 CGI 会自动降级成单机的流量控制机制。 4.1.5.3. 支付宝案例 1. 需求及问题 业务上希望实现各种粒度的限流，比如收银台主页面展现限流，单个服务 QPS 限流。 2. 设计思路及架构说明 流量控制对于系统的稳定性非常关键。主要起到保护后端系统不被流量冲跨的作 用。应用上的解决方案主要可以在 7 层 http server 和应用层代码上，解决不同粒度的 流量控制需求和性能消耗。 7 层 http 这块我们主要有 TMD 产品，应用层主要是 SLA。 整体结构如图所示：
- 30. 中国支付清算协会 27 图3-10. 支付宝系统架构限流分配图 TMD 流量管控是部署在Tengine Web server 上的一个模块。主要功能为防止因请求超 载而做的 QPS 流控功能。可针对特定的 URL（支持正则表达式）进行保护，并且流控的阈 值也可灵活调整，同时，对于超出阈值的访问，也提供两种策略进行响应：等待（等待时 间可配）或拒绝；不但支持全局限流，而且还支持对指定的 URL 进行限流；并且可以根据 权重进行区域限流，保证优质地区客户的访问。在限流方式上，对于瞬间突增的大流量， 可采用延期服务或直接拒绝服务两种方法，以适应不同的应用场景。 SLA 模块是部署在 APP JAVA 容器中。基于拦截器思想，根据规则对请求做不同指标数 值的统计，当一段时间内数值大于用户定义的阈值将触发限流。目前支持的统计指标有单 位时间访问次数，单机并发数，集群并发数，平均访问时间，匹配次数，成功率等，同时 也支持业务维度的细粒度统计和限流。输出模型可使业务系统能够灵活配置业务输出指 标，与弹性计算平台和业务决策系统配合，提升业务的动态管控能力和业务决策的准确性 和实时性。 3. 实施效果 tmd 和 sla 在支付宝全站都有部署，很好的解决了大促过程中页面，服务，业务的限 流需求。
- 31. 中国支付清算协会 28 4.2. 业务逻辑层 4.2.1. 高可用消息队列 4.2.1.1.高可用消息队列概述 消息队列（Message Queue）是一种进程间通信或同一进程的不同线程间的通信方式。 消息队列提供了异步的通信协议，消息的发送者和接收者不需要同时与消息队列互交。消 息会保存在队列中，直到接收者取回它。 在一个大型系统中，通过引入“消息队列”组件，可实现如下一些目标： 1. 解耦子系统：1）各子系统作为队列消息的“生产者”或“消费者”，都能独立地扩展 升级。2）消费者进程异常中断，还可在恢复后继续处理队列消息。3）通过简单增加 “生产者”或“消费者”进程，就可提高消息入队频率或消息处理能力，而不需修改 代码或调解参数。 2. 提升可靠性：1）可靠传输消息：每个消息可靠送达，且只送达一次。2）可靠处理消 息：通过持久化和"插入-获取-删除"范式，确保每阶段的数据都能被正确处理，每一个 消息只能被处理一次。3）顺序处理消息：通过设定，可以能保证数据会按照 FIFO（先 进先出）的顺序来处理。4）性能削峰填谷：使用消息队列能够使关键组件顶住增长的 访问压力，而不是因为超出负荷的请求而完全崩溃。5）优化处理过程：通过消息被处 理的频率和延时，快速确定那些表现不佳的处理环节，为进一步优化系统提供依据。 3. 实现异步通信：消息队列提供了异步处理机制，使得发送方和接收方都不用等待对方 返回成功消息，就可以继续执行后续任务，从而提高了系统的整体处理能力。 4. 然而，随着业务的发展，对消息队列的依赖越来越大，对消息队列的性能和可靠性要 求也越来越高，此时需要一个高可用的分布式消息队列集群。 5. 主备模式（Active/Passive）：例如，高可用 ActiveMQ 架构，提供了基于共享存储、基 于 JDBC、基于 Zookeeper 的复制 LevelDB 存储等多种主从实现机制，从而实现高可用
- 32. 中国支付清算协会 29 性。 6. 多主模式（Active/Active）：例如，分布式消息队列 Kafka，通过ZooKeeper 管理和协调 Kafka 代理，可以在集群中动态地增加或减少 Kafka 代理，从而实现高可用性，具体架 构见下图： 图3-11. 分布式消息队列集群架构图 4.2.1.2. 案例：ZQ 队列 金融信息系统通常需要与上游系统、下游系统协作，完成资金流转和调配，形成一条 资金流转业务链。而在很多场景中，业务链中两个相邻的上下游信息系统，二者的处理能 力是不匹配的，表现为两种形式： 上游系统能力小于下游系统，此时下游系统的能力得不到充分利用 上游系统能力大于下游系统，此时为了保证整个业务链健康，上游系统必须限制 业务请求速度 这其中，第一种情况对于上下游系统来说影响可控，而第二种情况如果不妥善处理， 可能会导致下游系统崩溃，从而使得整个业务链瘫痪。 信息系统的流量控制技术，就是为了解决此类问题诞生的，目的是使用一些方法和手 段控制系统间业务请求流动速度，以保护业务链中的任何一个节点不会因压力过大而被冲 垮，从而保证整个业务链可用。
- 33. 中国支付清算协会 30 1. 需求及问题 作为第三方支付系统，支付宝系统的上游是终端用户，下游是各资金渠道，这些资金 渠道大部分是银行系统。由于支付宝是互联网系统，相较于大多数银行系统，它面对的业 务量要大的多，因此其处理能力要比银行高很多。 在日常时，这种处理能力差异带来的影响并不明显，而在双 11这样的大促活动中， 影响就比较显著了。为了最大化促销活动效果，支付宝系统一定是尽自己最大能力接收用 户请求，流入系统的请求量就必然比下游的银行系统处理能力高出许多，此时整个系统就 会面临一些问题： 银行系统一旦遭受冲击瘫痪，短时间内难以恢复，严重的会导致整个促销活动失 败，因此不能无限制的把请求量下泄给银行系统，必须保护银行。 为了保护银行，最直接的做法就是限制用户发起请求的速度，减少流入支付宝系 统的请求量，但这样一来支付宝系统自身的能力就得不到充分利用。 由于受到限制，用户有一定概率不能顺利发起请求，用户的使用体验很差。 2. 设计思路与架构说明 为了解决上面的问题，首先需要改造支付宝系统主业务，使之支持异步化；然后，在 用户与支付宝核心系统之间，设置一个请求蓄水池，用户发起的请求将首先进入这个池中， 再从池里限速下泄给银行系统。请求池由请求队列、请求派发引擎、流控阀 3 部分组成， 如图所示：
- 34. 中国支付清算协会 31 图3-12. 支付宝系统请求资源架构图 流控阀实际上是一个令牌桶，控制桶中的令牌数量，就可以控制请求下泄的并发量； 如果需要控制的不是下泄并发，而是单位时间内下泄的请求数量（一般用 TPS作为单位）， 那么流控阀中的令牌桶需要再配合一个漏桶使用，漏桶以指定的速度向令牌桶中漏出令 牌，通过设置漏桶单位时间内漏出的令牌数量，就可以控制请求下泄的速度。流控阀结构 如图所示： 图3-13. 流控阀结构图 3. 实施效果 在实施了以上方案后的首次双 11 大促，相较于实施前一年，所有银行系统保持高水 位稳定运行，没有因流量冲击而崩溃；支付宝自身核心系统资源利用率提升 14%，支付宝 银行卡类支付成功率提升 7.1%，约 8 亿原本会支付失败的资金成功支付。 4.2.1.3. 案例：Active MQ 队列 Activemq 是 Apache 研发的开放源码消息中间件，实现了 Java Message Service（JMS） 规范，支持多种语言（Java、C、C++、C# 、Python、PHP …），支持多种通讯协议（OpenWire、 Stomp REST、AMQP …）。架构图如图所示：
- 35. 中国支付清算协会 32 middle adaptor-in active mq mqagent cgirelay 活动 mysql split adaptor-out 风控 图3-14. 财付通消息队列架构图 财付通引入 Activemq 后，为避免业务逻辑层增加一种新的通讯协议，决定在 Activemq 前面增加了一个 adaptor-in 模块。adaptor-in 代理业务逻辑层模块，实现了对 Activemq 读 写操作逻辑。业务逻辑层通过财付通已有的内部通讯协议调 adaptor-in 写入 Activemq。另 外，为及时消费 Activemq 消息，新增加 adaptor-out 模块，将 adaptor-in 写入 Activemq 的 消息转发给相关订阅者。 4.2.2. 分布式任务调度 4.2.2.1. 概述 分布式系统中必然会存在大量的任务触发的调度。采用单机调度的模式主要问题是无 法管控和利用集群的分布式能力。 4.2.2.2. 案例：支付宝 业务需求：交易自动确认收货超时，和各机构对账文件生成，每日日切任务触发 。 技术上需要对全站任务做管控，让开发方便使用，支撑单业务日亿级别业务的调度。运维 上希望灵活对任务做机房的调度和启动停止。 1. 实现方案 分布式任务调度架构如图所示：
- 36. 中国支付清算协会 33 图3-15. 分布式任务调度架构图 调度中心分为管控和实时调度，旨在为业务系统提供通用的任务调度服务，调度服务 将定时任务抽象成任务模型，提供基于任务模型的统一编程模式。同时通过定时任务管理 平台为定时任务的提供实时状态监控和集中控制。针对每个调度场景对任务设置策略模 式，通过任务拆分和负载均衡等方案提升大数据量任务的性能。通过异步消息的可靠性给 业务提供了一定调度到的能力。 2. 实施效果 这套架构在支付宝系统中大量部署，业务上比如淘宝交易超时支持单个业务亿级别的 任务调度和管控。 4.2.3.分布式服务监控 4.2.3.1. 分布式监控概述 1. 监控的维度（做什么）： 按目标和操作这两个维度，监控可分为四个象限：系统监视、系统控制、应用监视、
- 37. 中国支付清算协会 34 应用控制。不同的技术工具，所覆盖的象限范围是不同的。 2. 监控的模式（怎么做）： 系统和应用监控，一般分两种模式：Agent 模式和Agentless 模式。前者对于 Agent 实 现，要求具有高性能、高靠性、占用资源低、采集数据大。而后者，则依赖多种不同方式 来获取数据，SNMP，Telnet，SSH，WMI，JMX，JDBC，ODBC 等。两者比较如表 1 所示： 表-1 Agent 模式与 Agentless 模式对比 监控方式 Agent Agentless 对被监控资源的影响 占用一定的 CPU 和内存运行 Agent 代理软件本身。 对 CPU和内存的影响，除了对 telnet/SSH/ wmi 的影响，其它几乎可忽略。 对监控服务器的影响 大部分工作通过监控资源端的 Agent 代理软件完成，对监控服务 器的影响相对较小 所有工作通过监控服务器远程连接监控 资源端实现，对监控服务器的影响相对较 大 对网络带宽的影响 在监控资源端采集的数据，经过压 缩处理后，传输给监控服务器，故 对网络带宽的占用较低。 监控服务器采集的信息直接传输给监控 服务器，数据都未经压缩和汇总，故数据 量相对较大。 监控指标 Agent 代理监控方式一般都支持 二次开发，监控用户关心的独特的 指标。 受实现方式所限，一般监控指标相对固定 ，不支持二次开发。 部署方式 部署相对麻烦，需要每台主机部署 安装 只需要开通相应的协议和端口，几乎不需 要部署 功能特性 即可监视，也可控制 控制能力有限 3. 监控的模块（怎么分） 一个典型 Agent 模式的监控系统，包含三个子系统。 （1）监控代理 Agent：包括定时调度引擎、脚本执行引擎、自动更新引擎等。 （2）数据采集中心：包括告警规则引擎、数据存储引擎（DB 或 Rrdtool）、图形/报表 引擎等。 （3）告警通知中心：支持日志、邮件、短信、IM 等多种通知方式。 4. 推和拉模式（数据流向） （1）推模式：由 Agent 将采集到的数据，定时上传到“数据采集中心”。由于 Agent
- 38. 中国支付清算协会 35 不保留数据，上传的总数据量较大，且“数据采集中心”时，数据有丢失。 （2）拉模式：由“数据采集中心”定时主动请求 Agent 索取所需的监控数据。Agent 有一定计算能力，可以对原始数据进行精简，从而减小上传的数据总量。但是Agnet 需要 开启服务端口，提供远程服务，会带来一定的安全隐患。 （3）推拉结合：以推方式实现拉的功能。 Agent 主动通过脚本获取采样数据保存到 本地。Agent 定期根据指令向 Server 上传统计数据。避免开启额外端口，安全性更好。但 对 Agent 要求更高，开发难度大。 4.2.3.2. 案例：支付宝监控架构 1. 需求及问题 对于一个能够快速故障恢复的架构体系来说，问题发现的及时性非常重要，这时候能 够迅速发现问题的监控系统非常重要，监控的数据和计算量要能达到每秒 GB 级的秒级计 算能力。解决如下问题： （1）希望用最小成本来实现最大价值，并且监控对于数据一致性和可靠性的要求不 是非常高，可以对监控内容做等级划分，在一段时期内可以接受 99.9x%的可用率。 （2）业务监控类型繁多，对定制化能力要求很高，我们急需一套通用的可配置化平 台。 （3） 整个监控架构的可扩展性，必须支持随时随地的横向扩展以支撑日益增长的数 据量。 2. 设计思路及架构说明 支付宝监控架构如图所示：
- 39. 中国支付清算协会 36 图3-16. 支付宝监控架构图 3. 实施效果 （1）能够做到增量计算，监控数据延迟率降低到10 秒之内，保证了监控时效性，快 速的发现线上故障。 （2）能够做到架构的可扩展，计算逻辑的可扩展，自动化的运维能力，需求的可配 置化能力，提供给上层二次开发的接口，以实现功能的扩展。 （3）低成本的控制，整个监控系统的规模在 100 台服务器左右，实现了⼀一套实时 ⽇日志分析平台监控系统处理的数据峰值在 130GB/分钟左右。 4.2.3.3. 案例：财付通 财付通监控架构如图所示：
- 40. 中国支付清算协会 37 图3-17. 财付通监控架构图 财付通监控架构需要考虑解决一个难题是，业务 1倍增长量，会带来 N 倍（在财付通 大约是 N=40 倍左右）日志增长量；为了解决这个问题，有以下三个方式： A、接入部分、统计计算部分能够平滑的扩容；财付通的扩容是用过“lvs+set”化的方 式来解决的，但是这个不能解决本质问题，监控平台不可能需要 N 倍业务的机器量，这种 增长是无法接受的，例如：业务机器增长 10%，那么监控的机器增需要增长 400%；所以， 在这个平滑扩容之后，还增加了下述解决的办法。 B、在接入 agent 部分，通过“统计+错误日志”的方式； 日志分布在业务机器上，并 不需要每一条日志都集中在一个地方，实际的需求是使用错误日志来定位问题，正常的日 志基本不查询，所以日志采集仅仅采集了错误日志；对于正常日志的需求是，看到业务各 种指标的量来观察业务的正确性；解决了日志量 N 倍增长的问题，大约压缩了 95%的数据。
- 41. 中国支付清算协会 38 C、在统计方面，提供差异化的配置。解决日志接入之后，发现另一个问题：由于统 计的维度很多，针对统计和 db 的压力也会成几何级数增长。于是，在依据针对时间粒度 不同，用不同的时间粒度进行统计数据，减少1 分钟统计粒度的数据量的同时，针对不同 业务以及业务统计的维度，要按需配置，减少不必要的统计项。采用本方案后，减少了大 约 90%的计算量和存储量。 4.2.4. 服务配置管理 4.2.4.1. 概述 蚂蚁金服部署了上万台应用服务器。在这个数量级下，保证所有应用系统之间 P2P 服 务调用的高可伸缩性、高容错性的特性比较困难，通过软负载和配置中心技术为所有的应 用提供了对上述特性的支持。这些技术保证了蚂蚁金服每天数以百亿的 P2P 服务调用在上 千个应用中正常、有序、稳定的运行，它是蚂蚁金服分布式系统中最普遍也是最重要的技 术之一。 在蚂蚁金服的分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提 供方都会部署多份，以达到对等服务的目标。而软负载则是对等服务调用的调度器，它会 帮助服务的消费方在这些对等的服务提供方中合理地选择一个的来执行相关的业务逻辑。 为了保证应用的高容错性，则需要消费方能够感知服务提供方的异常，并做出相应的 处理，以减少应用出错后导致的服务调用抖动。我们能做到几乎无需应用系统感知，一切 服务调用的容错机制均由软负载和配置中心控制，帮助服务调用方正确选择健康的服务提 供方，保障全站的稳定性。 4.2.4.2. 配置中心 配置中心主要提供了非持久化数据的发布与订阅，如果软负载是对等服务调用的调度 器，那么配置中心则存储了所有服务的调度信息，具体来说就是所有应用的服务地址列表。 在应用服务器启动时，会向配置中心发布自身的服务，并订阅所需的服务。当服务提 供方变动时，配置中心会实时向订阅方推送最新的服务地址列表。该项功能看似简单，但
- 42. 中国支付清算协会 39 是随着业务的飞速发展，蚂蚁金服的服务器集群规模迅速增长，传统的单机架构很快就会 面临容量瓶颈和单点故障两大问题。 由于瓶颈在客户端连接数和内存数据量两方面，很难靠单一的水平拆分来解决。于是 配置中心垂直拆分成两种角色：Session 服务器（客户端连接）、Data 服务器（存储数据）， 每种角色都可以水平拆分成多个集群。 财付通配置中心架构如图所示： 图3-18.财付通配置中心架构图 Session 服务器是一个对等的集群，各台之间可以互相代替。一旦单台 Session 服务 器宕机，Data 服务器上立即会把来自该 Session 的数据销毁，同时订阅方会立即重新选择 一台 Session 服务器建立连接、重新发送数据，新 Session 服务器会通过负载规则将数据 重发到 Data 服务器上。也就是说，Session 服务器单机故障后，它的负载会立即被其他服 务器近似均匀地分担，和普通的无状态应用集群一样，既分担了压力，又增强了稳定性。 Data 服务器则采用主备同步的机制消除服务器的单点故障。 通过这样的方式，解决了配置中心容量瓶颈以及单点故障两个问题，可支持业务继续 向前高速发展。 1. 软负载架构
- 43. 中国支付清算协会 40 软负载架构如图所示： 图3-19. 财付通配置软负载架构图 如上图单个部署单元所示，服务提供方会将地址发布到当前单元的配置中心，而服务 消费方启动时，则会订阅当前单元配置中心的相关服务地址，待获取服务地址后，会通过 一定的负载均衡策略调用服务。由于配置中心的存在，服务提供方和服务消费方可以实现 任意扩容和下线。 单个部署单元是传统的软负载部署结构，蚂蚁金服在这个基础上进行了深入实践—— 应用系统的单元化部署（后续会有文章讨论应用单元化部署技术），在这样的单元化的前 提下，软负载能够优先调用当前单元的应用，如当前单元没有被调服务，会选择其它单元 进行调用。 在单元化的部署架构下，通过优化机器网络部署拓扑，可以让大多数 P2P服务调用 都落在了物理上相近的机器，这样不仅可以减少服务调用的网络延迟，也会极大的减少交 换机以及路由器的网络流量，提高应用性能的同时也可提升全站网络的稳定性。
- 44. 中国支付清算协会 41 随着业务的扩张以及网站架构的变化，应用之间的服务调用结构也变得十分复杂，为 了更好的梳理应用之间的服务调用，软负载中提供了一种叫 Tracer 的机制。Tracer通过在 服务调用中传输应用的上下文信息，可以将所有的服务调用梳理清楚，在方便业务开发人 员定位问题的同时，也方便架构设计人员了解整个分布式系统的调用链路图。 软负载及配置中心技术引导着蚂蚁金服的全站分布式请求，控制着全站的分布式调用 链路，是分布式系统中网络、服务资源合理使用的保证。 4.2.5. 服务流量控制 4.2.5.1. 服务流量控制概述 流量控制可以有效的防止由于网络中瞬间的大量数据对网络和服务器带来的冲击，保 证网络和服务器系统高效而稳定的运行。 与“网络流量控制”不同的是，服务流量控制，主要是针对单位时间内的服务请求数 量进行控制，及时分流或限流，防止后台某单一服务器的过载，而无法响应用户请求，甚 至导致整个服务器集群的“雪崩”。 4.2.5.2. 案例：财付通 1. 银行渠道分派与流控机制基本概念 渠道 渠道指的是同一类功能或者服务通过不同方式实现的后端系统。一般情况一个渠道对 应一组完全相同的后端服务系统。用于容灾，一个渠道会在不同区、专线等环境下部署相 同的后端系统。 健康度 健康度是指能反映后端系统的健康度的情况。主要包括系统错误数量，处理请求过慢 的数量以及成功率。系统错误指的是调用后端系统超时拒绝以及后端系统自身内部超时等 位置错误，主要以配置错误码为主；处理请求过慢指的是超过了预期处理一笔请求的时间
- 45.
- 46. 中国支付清算协会 43 于设定的阈值时，则告诉前端系统使用其他的渠道。并在指定的周期内对渠道进行自动打 开试探，如果试探的请求完全正常则恢复其使用，否则继续维护该渠道。 4.3. 数据持久层 4.3.1. 分布式文件系统 4.3.1.1.概述 在存储文件的方案上主要由外部厂商提供的 NAS 方案和利用 x86 架构和本地磁盘的分 布式文件系统。NAS 方案主要存在容量扩展难、容灾切换时间长、细碎文件存储升本高等 不足。而 NAS 方案的优势在于使用简单，可靠性方面可以得到很好的保证。 4.3.1.2. 支付宝案例 1. 需求及问题 支付宝应用中图片作为一个基础业务，需求上需要存储几亿规模的大小文件，比 如：头像，各种对账文件等， 业务对图片服务的性能和可用性要求都非常高。 2. 设计思路及架构说明 从需求中分析首先确定了走分布式文件系统的方案，产品选型上选择了阿里成熟的自 研产品 tfs（后面发展为云存储 OSS）。整体结构如图所示：
- 47. 中国支付清算协会 44 图3-21. TFS 系统整体结构图 各模块说明如下： （1）web层的实现使用 tengine 上的 tfs 模块安全高速的访问 tfs 集群做查询并且可以 给 CDN 缓存做回源使用。 （2）在图片应用上主要封装图片业务服务提供给各个业务使用；保证 DB 中存储的图 片地址和 tfs 集群中图片的一致性；安全上确保图片的访问权限； （3）tfs 集群根据业务的容量和可用性要求采用多机房结构并且做异地灾备。 多个备 份的集群都可以提供读服务。读的可扩展性问题只需要增加备集群就可以完成。每个图片 集群里都保存 3 份图片数据，保证数据的可靠性。 （4）图片 DB 集群里主要存储业务类型，用户，图片地址，图片权限等关键的图片相 关元数据。 3. 实施效果 图片服务对各个业务使用方提供了方便、安全的图片服务。利用 tfs 分布式特性给业 务提供了读写高可扩展性、稳定性和数据安全性。同时带来了运维上扩容，缩容，机房容 灾演练上的便利。
- 48. 中国支付清算协会 45 4.3.2. 分布式键值存储库（K-V） 4.3.2.1. 分布式键值存储库概述 键值存储库是一种采用采用Key-Value 模型的 NoSQL 数据库，它放弃了传统数据库的 结构化和关系型，以支持各种非结构化和半结构化的数据；放弃了 ACID 强一致性事务，代 之以 BASE（基本可用，柔性状态，最终一致性）；放弃了 SQL 访问方式，代之以 K-V 方式， 追求高扩展和高性能。通过分布式部署键值存储库，可以支持海量非结构化数据的高并发 读写访问。对于金融行业来说，也适合将其作为高可用数据缓存系统。常见的键值存储库 有 Memcached、Redis、Dynamo、LevelDB 等。 4.3.2.2. 案例：支付宝 基于 KV 的分布式缓存,它弹性的管理多台存储服务器提供缓存服务。 基于 KV 的分布 式缓存提供功能包括：基于对象的数据访问服务和弹性调整集群和扩充容量。 基于 KV 的 分布式缓存,相对仅使用数据库的数据架构有下列优势: 高性能：基于内存的访问速度比持久化存储的访问速度快一个数量级；分布缓存 集群可提供线性扩容内存存储空间，内存数据命中率比数据库高；一般用户数据 在数据库上拆分为多条记录需多次访问，分布式缓存聚集了大部分数据，一般仅 需一次访问，响应时间更短。 低成本：相同 QPS 下，内存的成本小于数据库使用的存储成本；分布式缓存的使 用,可减少各类数据库附带的费用；可进一步演化⾄至近端数据访问方案,大规模减 少应用服务器成本。 高可用：基于一致性哈希算法，分布式集群可动态剔除异常的存储服务器，服务 持续可用、可动态的扩充存储服务器，提升集群容量。 1. 需求及问题 账户访问模块提供账户信息修改和账户信息查询 2 大基础功能。基于概述中分布式缓
- 49. 中国支付清算协会 46 存带来的优势，会员系统的账户访问模块需要加入缓存。相对仅使用数据库的访问方案， 引入新的一层缓存将带来的 ACID 方面的问题。 2.设计思路及架构说明 业务上，账户信息在剥离了资金金额等少数强一致性数据后，在大部分业务场景下采 用 BASE（Basically Available, Soft state, Eventual consistency）策略，通过系统+分布式缓存的 封装，为账户信息查询服务提供业务所需的一致性： Basically Available：会员核心系统的服务器仅访问同 IDC 全量数据的分布式缓存，当缓 存服务器不可用，影响范围有限，且可以将影响到的系统临时切换到其他 IDC 的分布式缓 存集群上； Soft state：账户信息的变更量小，将变更集中在一个逻辑应用集群访问单点数据主库， 变更数据库主库记录。事务提交后同步数据到各 IDC&城市的分布式缓存集群中，同城 IDC 的数据时效性延迟在 3ms 左右，异地 IDC 的数据时效性延迟在 30ms 左右，因账户信息不 涉及资金金额，业务可接收该延迟。 Eventual consistency：通过在账户信息变更时在数据库同事务中保留一致性流水记录， 基于时间版本规避数据乱序，应用层通过异步复制和定时调度 2 种机制驱动账户信息在各 IDC、各城市的数据版本最终一致。 方案如图所示：
- 50. 中国支付清算协会 47 图3-22. 分布式键值存储库方案示意图 3. 实施效果 该架构的实施，提升了账户信息查询的性能，每次在数据库（FIO配置）中访问账户 信息需要 10ms，而分布式缓存访问仅需 2ms，仅为数据库平均相应时间的 20%；减少了服 务器成本，2012 年到 2014 年 11.11 大促对账户信息访问峰值上升了 900%，未新增数据库 预算，应用服务器预算仅新增 200%；保障了账户信息查询的高可用，基于该架构支持了 2013 年到 2014 期间 4 次 11.11 活动对账户信息访问，查询服务连续 2 年可用率 100%。 4.3.2.3. 案例：财付通 腾讯 CKV（Cloud KeyValue），是腾讯自主研发的高性能、低延时、持久化、分布式 Key-Value 存储服务。 与 Memcached，Redis 等开源 NoSQL 相比，CKV 具有以下优点： 1. 低成本 CKV 利用数据冷热自动分离技术，将热数据存储在内存，冷数据存储在 SSD 中，从而大幅度降低成本，且保证 99%以上的访问命中内存。 Memcached 和 Redis 的数据 都存储在内存中，成本是 CKV 的 3 倍。 2. 可扩展性强 CKV 单表存储空间可以在 1GB 到 1PB 之间在线自动无损伸缩，业务基 本无感知，适合各种规模的业务，和业务的各个生命周期。 Memcached 和 Redis 本身是
- 51. 中国支付清算协会 48 单机的，受限于单机的性能和内存容量。虽然可以通过客户端或者 Twemproxy 等构建分布 式集群，但是不能做到完全无损扩容，伸缩修改配置比较麻烦。 3.高性能 CKV 单表最大支持千万次/秒的访问。通过网络访问的延时 1ms 左右。单台 Cache 服务器千兆网络环境支持 50 万/秒的访问，万兆网络环境支持超过 100 万/秒的访问。 Memcached 采用多线程，但性能比 CKV Cache 略低。而 Redis 是单线程的，性能垂直扩展 性差。 4. 可用性超过 99.95% CKV 软硬件全冗余设计，双机热备，主备切换对业务透明，跨 机架跨交换机部署。 Memcached 机器死机后，部分 key 访问就会 miss。Redis 有双机方案， 但是还不成熟。 5. 数据持久性超过 8 个 9 CKV 数据落磁盘存储，多内存和磁盘副本，具有灾难时回档 能力。 Memcached 机器死机后，数据就丢失了。Redis 虽然数据可以落盘，有双机方案， 但是还不成熟。 6. 完善的运维体系 CKV 能够预防和及时发现处理故障，自动化运营。 Memcached 和 Redis 缺乏专门的运维系统。 CKV 架构如图所示： 图3-23. CKV 架构图
- 52. 中国支付清算协会 49 4.3.3. 高可用关系数据库 4.3.3.1. 高可用关系数据库概述 为了解决数据库的单点故障，提高系统的整体可用性，有两条技术路线。 技术路线1：基于传统关系型数据库的高可用集群。主要包括共享存储（Share-Storage）、 全共享（Share-Everything）、无共享（Share-Nothing）三类。 技术路线 2：基于 NewSQL 数据库的高可用架构。如谷歌的 Spanner/F1 数据库，阿里 的 OceanBase 分布式数据库。 目前，中小银行的核心系统，对事务一致性要求高，主要采用下面两种集中式方案。 基于“Share-Storage 架构”的主备数据库集群：双机主备，但由于主库和备库共享了 一个磁盘阵列，导致主备切换时间较长。 基于“Share-Everything 架构”的数据库集群：此时不仅共享存储，同时还共享缓存。 典型案例为 Oracle RAC 数据库集群，由于过度依赖其一致性缓存技术，导致其扩展能力不 足，一般只能扩展到 4～10 台左右。 更好的方式是采用基于数据库复制的“Share-Nothing 架构”，具备数据冗余，能快速 实现主备切换，具有更高的可用性。针对不同场景，有“主主”、“双主多从”、“分片只读”、 “分片读写”4 种方案。前两个方案的数据未做水平拆分，写扩展能力有限。后两个方案 的数据已做水平拆分，但是分布式一致性问题难以解决。要解决分布式一致性，一种方案 是结合应用端，按照某种分布式一致性算法，来实现轻量级的事务一致性；另一方案则是 引入全新架构的 NewSQL 数据库，由 NewSQL 数据库来保证分布式事务一致性。 以上各方案模式如图所示：
- 53. 中国支付清算协会 50 1.主主方式 2.双主多从+VIP（或：双主多从+DAL） 3.分片只读+DAL 4.分片读写+DAL 图3-24.Share-Nothing 架构方案分类示意图 几种方案的简要对比如表所示： 表-2 Share-Nothing 架构方案对比表 特性×∨√ SSQQLL++集集群群 SSQQLL++分分片片++集集群群 NNeewwSSQQLL R 关系型 √ ∨弱关系 √弱关系 Q 支持 SQL √ ∨不支持跨库 √精简 SQL C 索引 √ ∨无全局索引 √ 关联 √ ∨无跨库 JOIN √ 事务/ACID √ ∨无跨库事务 √ 同 DC 一致性 √ ∨可调整 ∨可调整 跨 DC 一致性 × × √ 高扩展容量 × √ √ 高扩展写 × ∨分片+写 √写延时较大 高扩展读 √读写分离 ∨分片+读写分离 √ 实时性/内存 × × √
- 54. 中国支付清算协会 51 A P 数据分片 ×∨无跨库写 √ 分片方式 × ∨应用分片 √自动分布 案 例 1．主主方式 3.分片只读+DAL 5.OceanBase 数据库 2．双主多从 4.分片读写+DAL 4.3.3.2. 案例：MySql 财付通高可用数据库架构主要分为以下几个部分： 1. 容灾使用典型的两地三中心数据存储方案，只有一个写入点，数据同步的方案有： 对于同构的数据，使用数据库的复制技术同步数据到本地和异地备机。 对于异构数据，使用拆分程序，通过解析 mysql 的日志，再经过一定的业务逻辑转 换，生成业务需要的最终的数据。这些最终的数据可以是相同的但是以其他维度 存储的数据，也可以是汇总的数据。 使用 MQ 等技术实现数据的异步订阅和分发。 高可用方案架构如图所示：
- 55. 中国支付清算协会 52 图3-25. 财付通高可用方案架构示意图 2. LoadBalance和 Failover 对于读应用，使用 LVS 或域名等技术实现负载均衡、动态扩缩容以及失败节点的自 动切换。 对于写应用，使用 keepalived+仲裁机制来实现安全的数据库失败切换。 主 DB 高可用主要架构如图所示：
- 56. 中国支付清算协会 53 图3-26. LoadBalance 和Failover 原理示意图 财付通的 mysql 自动切换主要基于 mysql 半同步技术与 keepalived 来做的。其中半同 步解决数据实时安全同步的问题，它确保了至少有一台备机成功接收到 binlog 事务才算成 功；keepalived 通过虚 IP 漂移来解决应用透明切换问题。为了防止脑裂问题，还引入第三 方仲裁服务。主机、备机和仲裁服务器都定期探测各方的状态信息并保存下来，如果主机 或备机探测到对方有异常了，会让仲裁服务器参与投票，超过半票才会执行接管切换。 4.3.4. 分布式数据访问层（DAL 服务） 4.3.4.1. 分布式数据访问层概述 随着业务量不断增长，传统的三层架构已经无法满足需求，需要进行进一步横向扩展， 变集中式为分布式。而这三层当中，主要包括三类服务器：处理静态页面的 Web 服务器、 处理动态逻辑的 APP 服务器、存储数据的 DB 数据库服务器。对于 WEB 和 APP 层，都比较 容易实现多机部署和负载均衡，从而消除单点故障，提高系统的可用性。而 DB 则是最后 一个，也是最难解决的单点故障环节。 分布式数据访问层的结构如图所示：
- 57. 中国支付清算协会 54 图3-27. 分布式数据访问层架构图 1 当传统Web 应用面对高并发数据访问需求时，原底层单数据库设计难以有效支撑上层 应用的数据访问。此时一般通过如下几种方式对 DB 减负，从而提高系统的整体可用性。 1) 按应用拆分：不同业务系统使用不同的数据库（即垂直分区）。 2) 按操作拆分：增加多个全量数据镜像，提供数据冗余，实现“读写分离”访问。 3) 按数据拆分：相同业务系统根据某种分片策略（时间、ID、HASH 等）使用不同的数 据库和表（即水平分区）。 4) 按类型拆分：将部分数据从关系数据库迁移到 NOSQL 数据库中，减少对前者的依赖。 其中 1）无需改造业务系统，比较容易实现。而 2）3）4）则需要对业务系统做一定 改造。尤其对于 3）而言，经常需要根据不同场景下、不同数据量来调整分片策略。在当 DB 较少，而应用很多时，需要同时修改多个应用系统，实施起来很困难。此时，需要引入 一个独立的数据访问层（DAL），来屏蔽因为各种拆分而导致的复杂性，简化 APP 层开发的 难度。 维基百科上，将数据访问层（DAL）定义为一种计算机程序层，它提供对存储在某种 类型的，持久存储数据的简单访问，如关系型数据库。其他应用程序模块通过 DAL 来访问
- 58. 中国支付清算协会 55 和操纵各种数据存储中的数据，而不必处理这种访问方式固有的复杂性。简单来说，DAL 是一系列服务的集合，是 DAO 在大型系统中的自然延伸，是SOA 的具体实现。 通过引入独立的数据访问中间层（DAL），可以达到如下一些目标： 1) 简化客户端接口，规范数据操作，以便实现“透明性”分片。 2) 保持客户端接口，动态升级服务端实现，实现 SOA 架构。 3) 支持访问海量数据，包括分布式缓存、读写分离、数据分片（分库/分表）等。 4) 支持对服务的治理，实现各种认证、管理、权限、监控、分析、优化等。 目前数据访问层 DAL（Data Access Layer）有三种实现方式： 客户端端封装方式：针对特定接口封装自定义 SDK 包，供前端业务系统端调用。 服务端封装 RDS 中间层（Relational-Database-Service）。完全针对关系型数据服务，应 用端 SQL 和 JDBC 驱动完成和中间层的交互。已有的淘宝 TDDL，Amoeba，Cobar，阿里 DRDS、 奇虎 Atlas，网易 DDB、腾讯云数据库、百度 DDBS、亚马逊 RDS、微软 AzureSQL、谷歌 Cloud SQL 等系统或服务，都是采用这种方式。其中部分实现完全兼容 MySQL 网络协议，应用端 无需修改任何代码或驱动库，即可完成数据库访问操作。 服务端封装 DaaS 中间层（Data-as-a-Service）将数据及对数据的访问视为一种服务， 此时不限于访问关系型数据库，还能访问各种非关系型数据库，甚至是 Tuxedo 中间件之类 的在线服务。此时，需要放弃 JDBC 网络接口，甚至放弃 SQL 语法，而改用自定义接口提 供给 APP 端来访问。如 SUN 的 JPA 规范，Amazon 的 S3/SimpleDB/DynamoDB 等，Google 的 CloudDataStore 和 BigTable 等。其中，3）也可和 1）2）结合使用。 其层次关系如图所示：
- 59. 中国支付清算协会 56 图3-28. 分布式数据访问层架构图 2 4.3.4.2.案例：典型 DaaS 实现（联动 UDAL） 联动优势的 UDAL 方案，主要采用 DaaS 方式进行设计和实现，同时也在客户端封装了 自定义 SDK 和 JDBC 驱动，方便业务系统调用。其架构如图所示： 图3-29. UDAL DaaS 架构图 联动优势 UDAL 的具体实现过程，分为四个阶段： 第一阶段（Udal-Server）：实现 DaaS 中间层基础架构，完成 UDAL 服务器，代理各种 数据库和在线服务的访问。
- 60. 中国支付清算协会 57 第二阶段（Udal-Client）：为方便业务应用端使用，封装了远程和本地两种接口。前者 通过 Udal-Server 访问所需数据，后者则直接访问后台数据库和在线服务。 第三阶段（Udal-Shards）：在上述基础上，实现对分片数据（分库和分表）的访问。支 持“分库+分表”访问方式，读写分离、单列/多列分片、全局/单条/范围查询、结果集合 并/二次排序、多表分页查询等高级特性。 第四阶段（Udal-Jdbc）：在上述基础上，实现对SQL 的解析。同时通过定制 JDBC 驱动 器（Udal-Jdbc）与 UDAL 服务器相连，使用 iBatis 测试用例完成相关测试。此时应用端直接 用 Udal-Jdbc 驱动，替代原有的 DB2 或 MySql 数据库的 JDBC 驱动，而无需修改业务代码， 就可完成对分库分表的统一访问。 首先，UDAL 满足如下一些功能性需求： 服务代理：提供独立的数据访问中间层，代理完成所有的数据访问操作。 资源共享：a）共享数据库连接池，降低核心 DB 的并发连接总数；b）共享缓存， 提高多机部署时的缓存命中率； 读写分离：识别并区分数据库的读和写操作，根据读写类型访问不同的数据库。 数据分片：有两种实现方式：a）根据自定义协议实现分片数据访问；b）根据动 态 SQL 语句实现分片数据访问。 同时，UDAL 还满足如下一些非功能性需求： 无状态性：方便进行多机部署和负载均衡。 平台中立：支持将 DAL 服务器部署在多种操作系统上。 前端语言中立：支持多种 DAL 客户端，支持 Java、C/C++、PHP、Flex 等多种语言。 后端数据库中立：支持多个厂商的关系型数据库（如 DB2、MySQL 等），以及混搭 使用；支持多种 NOSQL 数据库（如 MemCached、MongoDB 等），以及混搭使用； 支持 Tuxedo 中间件等在线服务。
- 61. 中国支付清算协会 58 数据访问安全性增强（访问控制）：用户认证：单认证策略；多认证策略；连接管 理：限制用户连接数；限制 IP连接数；权限控制：基于角色的授权；精确控制到 SQL 语句级，而不是库/表/字段级。 4.3.4.3. 案例：支付宝 ZDAL 支付宝 ZDAL 系统核心架构如图所示： 图3-30. 支付宝 ZDAL 系统核心架构图 zdal 采用标准的 JDBC 规范，可以在分布式环境下看上去像传统数据库一样提供海量数 据服务，是一种通用的分库分表数据库访问框架，解决单库单表数据库访问压力，Zdal 主 要提供分库分表，结果集合并，sql 解析，数据库 failover 动态切换等功能。 4.3.4.4. 典型 RDS 实现 国内已有的中间层方案，主要采用 RDS 方式实现，包括： 方案 1：DAL@手机之家（许超前）——非开源，主要针对 PHP 应用。 方案 2：Mysql-Proxy@MySQL——支持读写分离，不支持分库分表，且性能较差。
- 62. 中国支付清算协会 59 方案 3：Atlas@Qihoo360（王超）——基于mysql-proxy-0.8.2 版，将 lua 脚本改为 配置方式。 方案 4：Amoeba@盛大（陈思儒）——包括 Amoeba for Mysql/Aladdin/MongoDB 三个版本，不支持事务/存储过程/分库分表/输出大结果集。 方案 5：Cobar@阿里巴巴（贺贤懋）——基于 amoeba-0.34 版。开源版只支持 mysql， 不支持读写分离。 以 COBAR 为例，包括五大模块： 1）协议解析器：解析数据库底层网络协议，实现编码解码。 2）SQL 解析器：解析 SQL 语句，识别用于 SQL 路由的参数：读写类型、表名、分片 字段值等。 3）SQL 路由器：根据 SQL 解析结果，选择不同的分库和分片。 4）SQL 执行器：在不同的分库和分表上，执行相关 SQL 语句。 5）结果集合并：针对多个库/表的 SQL 执行结果，完成合并、二次排序，二次分组 等操作。 注：如能抛弃 SQL 方式，则能进一步简化服务端的处理逻辑，提升处理效率。 其内部架构如图所示：
- 63. 中国支付清算协会 60 图3-31. COBAR 系统内部架构图 4.3.5.分布式事务协调（DTC 服务） 4.3.5.1. 分布式事务协调概述 对于一个“高可用关系型数据库”而言，为了支持海量数据和高可用性，其数据分布 和系统分布都在所难免。如何确保一致性，这就牵涉到分布式事务一致性的问题，即在一 个分布式系统中实现事务的 ACID（Atomic，Consistent，Isolated 与 Durable）属性。 实现分布式一致性有两类架构： 对称的无主架构（Leader-Less）：所有 Server 都是对等的，Client 可以和任意 Server 进行交互。 非对称有主架构（Leader-Based）：任意时刻，有且仅有 1 台 Server 拥有决策权， Client 仅和该 Leader 交互。 实现分布式一致性有两类技术： 1 2 3 4 5
- 64. 中国支付清算协会 61 基于协议广播（Agreement-Based）； 基于仲裁协调（Quorum-Based）：在没有并发写冲突时，性能更优。 在具体实践中，考虑系统性能和延迟，通常结合上面两种架构和技术来实现。 在准备阶段，为对称架构，通过广播方式完成投票并选定 Leader。 在提交阶段，非对称架构，通过 Leander 完成分布式事务的最后提交。 常见的分布式一致性算法有： 2PC 算法（Two Phase Commit protocol），分准备阶段和提交阶段。以阻塞方式完成， 性能差；无容错机制，无法处理协调者宕机问题。 3PC 算法（Three Phase Commit protocol）。在 2PC 基础上引入超时机制，将准备阶 段分解为两个阶段：在超时发生以前，系统处于不确定阶段；在超时发生以后， 系统则转入确定阶段。 Paxos 算法：包括 Classic Paxos（1990/1998），以及 Fast Paxos（2005）等改进方案。 基于分布式选举原理，具有高度容错特性，且唯一被证明的一种一致性算法。 Raft 算法：基于复制状态机的原理，将问题分解为选主算法，日志复制，安全性等 子问题，更容易理解和实现。 几种一致性方案的初步比较如表 4-3 所示： 表-3 一致性方案对比表 方案/算法 备份 主/从 主/主 2PC 3PC Paxos Raft 一致性 弱一致性 最终一致性 强一致性 事务 无 全 本地 完全事务性 延迟 低 低 低 高 高 高 低 性能 高 高 高 低 低+ 中 高 数据丢失 大量 少量 少量 无 无 无 无 失败转移 无 读 读&写 读&写 读&写 读&写 读&写 复杂性 低 低 低 中 中 高 中
- 65. 中国支付清算协会 62 4.3.5.2. 案例 1：支付宝 在分布式数据架构下，保证事务的原有的ACID（原子性（Atomicity）、一致性 （Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability））特性，还要保证 高可用和可伸缩性是非常具有挑战性的，试想你同时支付了两笔资金，这两笔资金的事务 如果在分布式环境下相互影响，在其中一个笔交易资金回滚的情况下，还会影响另外一笔 是多么不能接受的情况。根据 CAP 和 BASE 原则，再结合分布式系统的特点，需要一套基 于服务层面的分布式事务框架，支持两阶段提交协议，在保证事务的 ACID 原则的前提下， 确保事务的最终的一致性。支付宝分布式事务框架流程如图所示： 图3-32. 支付宝分布式事务框架流程图 实施效果上这套分布式事务系统在线上交易、支付、账务场景可以支撑每秒十万级别 的分布式事务。 4.3.5.3. 案例 2：财付通 财付通多机事务，顾名思义，就是要在不同机器上实现交易的原子化，例如，一笔交 易涉及到三个用户，这三个用户加上交易单，逻辑上分布在四台数据库机器上，要保持 4 台机器上的账户和交易的事务一致性，这无疑是个挑战，我们参考了 X/Open 分布式事务 的一些规范，但开发这样一套独立的系统，时间上成了不可能完成的任务。目标似乎遥不 可及，但是，如果直面问题，事情有时候就变得简单了，回过头看下我们交易体系的业务
- 66. 中国支付清算协会 63 模型，答案就在其中。业务模型里边，只有简单的三个逻辑：减钱、生成交易单、加钱。 这个模型以交易单为中准线，只要交易单成功，则表示交易成功，此时业务逻辑必须往前 走，将加钱操作做成功，若交易单未成功，则将减钱操作进行回滚（把减的钱给用户补上）。 所以财付通 3.0 只需要实现一套能完成上述三个步骤的业务控制系统就可以。 在财付通3.0 的设计中，提供了两类资源管理器：用户类、单类，每个资源管理器负 责管理一台数据库机器（用户类或单类），在资源管理器上搭建一个事务管理器，负责将 一个交易拆分成多个原子交易（只操作单个用户账户或交易单），事务管理器负责将交易 分拆成上述三个逻辑步骤，依次执行减钱、生成交易单、加钱的步骤即可。考虑到事务管 理器的实时性能问题，事务管理器不负责回滚和补偿操作，一旦出错，事务管理器将事务 的上下文发送给差错处理器，由差错处理器接管该事务，对事务进行回滚或补偿。 财付通分布式事务框架流程如图所示： 数据库1 事务管理器 资源管理器1 差错服务器 数据库2 资源管理器2 核心服务 middle 数据库3 资源管理器3 RELAY 图3-33. 财付通分布式事务框架流程图 4.3.6. 数据库复制工具 4.3.6.1. 数据库复制技术概述 为了实现 Share-Nothing 架构的高可用关系型数据库集群，在引入数据库访问层（DAL）、 分布式事务协调器（DTC）的同时，还需要一个重要的技术组件——数据库复制工具 （Database-Replicator），来将单一数据库的数据内容，复制到备份数据库或从属数据库上，
- 67. 中国支付清算协会 64 增加数据冗余，提高数据可靠型和系统可用性。 按数据库复制机制分类，可分为： 同步复制方式：复制时需要等待目标库的应答，实现最大保护，但性能较低。 异步复制方式：复制时无需等待目标库的应答，实现最大性能，但数据可能不一 致。 混合复制方式（半同步）：在“最高性能”和“最大保护”中权衡。当同步复制超 时或失败时，自动转为异步复制，确保复制的“最大可用性”。其缺点是，在网络 连接中断后，主库又发生故障，此时会导致数据丢失，造成备库数据不一致。 按数据源和目标库的个数，可分为： 一对一复制：数据源为单一数据库，目标也是单一数据库。 一对多复制：数据源为单一数据库，目标为多个数据库。 多对多复制：数据源有多个数据库，目标为多个数据库。 按数据库类型不同，可分为： 同类库复制：如从 DB2 复制到 DB2 数据库。 同构库复制：如从 DB2 复制到 MySql 数据库。 异构库复制：如从 DB2 复制到 NoSql 数据库。 按复制工具的实现架构，可分为： 集中式复制模式：单一模块部署在源端，通过远程接口写入目标端。一般为一对 一模式。 客户/服务器模式：源端部署“服务器”，多个目标端部署“客户端”。一般为一对 多模式。 发布/订阅模式：多个源端部署“生产者”，多个目标端部署“消费者”。支持多对
- 68. 中国支付清算协会 65 多模式。 4.3.6.2. 案例：联动优势 DB2复制工具 1. 需求及问题 将联动的 DB2 在线交易库复制到 DB2 离线数据库，将 DB2 离线数据库复制并归档到 MySql 读库集群，用于完成一些统计查询，以及一些大范围历史数据的查询处理。 公司已购的商业复制工具 IBM-CDC 价格不菲，操作不便，不支持复制到 MySql 中，经 常因数据库结构变更等原因导致复制中止，其可用性不可控。 基于以上原因，公司开发了 DBRep 复制工具。 2. 设计思路及架构说明 联动的 DBRep 复制工具，采用客服/服务器模式，实现了异构数据库的异步复制。联 动优势 DBRep 复制工具架构如图所示： 图3-34. 联动优势 DBRep 复制工具架构图 3. 实施效果 联动的 DBRep 复制工具，已完成如下特性： 支持 DB2 到 DB2 和 DB2 到 MySql 的复制，并可扩展复制到 MongoDB 数据库。 支持一对多库的复制；
- 69. 中国支付清算协会 66 支持表名过滤和映射（单表对多表，多表对单表）； 支持字段过滤和映射； 其关键技术已获发明专利授权（200910241240.X 数据同步方法及装置）。 目前已经用于联动优势话费读库、第三方支付读库、用户管理等多个系统中。 4.3.6.3. 案例：支付宝 1. 需求及问题 银行核心系统的容灾能力通常通过两个指标来衡量，RTO（Recovery Time Objective）： 业务功能恢复正常的时间，RPO（Recovery Point Objective）：业务恢复正常时丢失的数据量。 业务系统的容灾能力通常取决于数据库采用的主备同步方案，以 Oracle 为例，支持 MA（max available）和 MP（max protection）两种模式。MA 模式下采用异步同步的方式， 主库故障时备库延迟可能很大，导致 RPO 时间不可控，在实际应用时，通常部署共享存储 减少 MA 模式下的 RPO 时间；MP 模式下，只有主备库都写入成功时，事务才成功提交， 但 MP 模式会造成 Oracle 性能有约 70%左右的损耗。以支付宝交易系统为例，采用 Oracle+ 共享存储架构下的 RTO 以及 RPO 时间分析如下所示: RPO：主备库和共享存储分别部署在两个机房，主备库通过 DATAGUARD 同步。故障通 常分为两种情况：1）Oracle 主库宕机（单机故障），此时备库能够访问共享存储，可以通 过原来主库的存储恢复数据，此时 RPO 时间为 0；2）如主库所在的 IDC 发生故障，此时备 库无法访问到原来主库的存储，主备切换时会造成约分钟级别的数据丢失，既 RPO 小于 1 分钟。 RTO：Oracle DATAGUARD 高可用方案的主备切换时间约为 5 分钟，既 RTO 为 5 分钟，5 分钟不可用对于支付宝的交易系统是无法接受的。因此为了缩短 RTO 时间，交易采用了创 新的 Failover 方案进行故障转移，当交易主库发生故障时，通过中间件迅速的切到 Failover 库，保证交易的持续推进。采用 Failover 方案后，RTO 时间缩短到 1 分钟 与 Oracle 的共享存储方案不同，OceanBase 采用 share nothing 的架构，通过 Paxos 协
- 70. 中国支付清算协会 67 议保证主备库之间的一致性，交易系统在成本和可靠性获得进一步的提升。 2. 设计思路及架构说明 从本质上看，银行业务的 RPO和 RTO 时间主要取决于主备同步技术和存储架构 RTO 时间主要取决于主备切换时间，如 Oracle 主备切换时间约为 5 分钟 RPO 时间主要取决于主备延迟，如 Oracle 的主备延迟通常小于 1 分钟 为了能够去除传统金融数据库对共享存储的依赖，OceanBase 采用了 Paxos 协议，通 过 3 个节点（或者更多节点）投票保证数据的强一致性，当有多数派节点提交成功时事务 才提交成功，在保证一致性的同时兼顾了可用性，既少数派节点故障时系统依然可用 （Oracle 的 MP 方案，主备库任何一个点故障则不可用）。 OceanBase 在交易系统的部署方案如图所示： 图3-35. OceanBase 在交易系统中部署图 OceanBase 的 3 个集群分别部署在同一个机房的 3 个 IDC 事务提交给“紫色”的主集群，主集群通过并发机制将 Redo Log 同步给 2 个备 集群，有 2 个以上（包含主集群自己）提交成功则事务提交成功 当主集群故障时，通过 Paxos 协议选举一个新的主集群，选举时间约为 35 秒， 既 RTO 时间小于 35 秒
- 71. 中国支付清算协会 68 3 集群部署架构下，容忍最多1 个集群或机房故障（Oracle 的 MP 方案，主备 任何一个故障时系统不可用），单机房故障时仍然满足多数派协议 RPO 为 0； 当大于 1 个机房故障时，系统不可用 由于 OceanBase 引入了强同步的方案，对事务的提交时间有微小的影响，以交易为例 一个 150ms 的事务，在提交时会增加 0.7ms 左右的时间。3 IDC 强同步只导致事务增加 0.7ms 的主要原因如下：采用并发机制将 Redo Log 同步到备集群，因此网络上的消耗约为 1 个备 集群同步时间；只有主集群收到“commit”请求时，才将 Redo Log 同步给 2 个备集群，对 于一个执行时间很长的事务来说，0.7ms（双 11 期间数据同步的消耗）是能够接受的。 3. 实施效果 交易库迁移到 OceanBase 后，系统的容灾能力如表所示： 表-4 交易系统迁移到 OceanBase 后的系统容灾能力对比表 指标 OceanBase Oracle RTO 35 秒 Failover 1 分钟 RPO 0 小于 1 分钟 另外，交易迁移到 OceanBase 以后，由于去掉了对于存储和 Oracle 的依赖在成本上也 有所减低。 4.3.6.4. 案例：财付通 财付通核心数据水平拆分后，分布在多台机器的多个表里面，这给统计、监控、排序 带来了很大的问题。业务需要有个统一的数据源满足不同纬度的查询需求。监控系统需要 实时监听关键表的数据变化。 财付通是通过数据合并方式，将多个表的数据合并到一张表。数据合并还解决了多对 多数据异构数据复制问题，在数据变化之后触发外部事件，为检索系统更新数据。财付通 合并系统还支持开发人员通过插件实现数据格式快速转换。 数据合并的优势: 不影响现有业务，业务不需要改变代码，开发工作量少，保障数据
- 72. 中国支付清算协会 69 一致性，足够安全可靠。财付通 MySQL 数据处理流程图如图所示： MySQL binlog 数据读取 模块 数据包处 理模块 binlog解析 模块 数据过滤 模块 数据分发 模块 数据消息队列 数据消息队列 数据消息队列 数据消息队列 MySQL MySQL MySQL MySQL Hash Hash Hash Hash 图3-36.财付通 MySQL 数据处理流程图 数据分发模块会根据指定字段做 hash(比如 uid)，发送到固定线程中，来规避并发数据 对单个用户造成的数据顺序错乱问题，从而达到并发且对单个用户无影响，在对性能提升 的基础上做到对数据顺序播放。
- 73.