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