20141208内刊投稿（刘胜）支付清算行业分布式架构的探索v1.2.doc

《联动风采》内刊投稿
支付清算行业分布式架构的探索
刘胜（liusheng@umpay.com）
注：本文内容，改编自联动优势UPTC 2014大会上同名主题演讲，和支付清算行业协会“支付清
算行业分布式系统架构设计”研究报告，并有所节选。
0 背景
2014年10月24日，阿里上市仅一月，就已取代中国移动，成为中概念股中市值第一的企
业，这也标志着中国的互联网经济时代已经来临。
过去的2013年，已被称之为“互联网金融元年”，在这一年里，我们见证了第三方支付热度
不减、余额宝的火爆和P2P的喧嚣。而今的2014年，则被称之为互联网金融的井喷年和监管元年。
传统金融行业对互联网金融的态度，也发生了巨大的转变：从担心被颠覆，到各种打压，再到
加强监管和相互合作。
是什么原因引起了这些转变呢？
从内因来看，传统金融企业，技术相对保守，大多采用外购方式，使用集中式架构，导致
规模受限，而不得已放弃一些利润较低的业务。而互联网企业，追求技术可控，一般使用自研技
术，倾向于分布式架构，确保规模可扩，从而可以不断地抢夺一些传统金融企业放弃的业务。包
括我司在内的第三方支付公司的兴起，也源于此。
从外因来看，2013年6月的“棱镜门事件”，成为了其中的导火索，触发了中国“No ICE 策略”。
中国政府开始限制采购IBM，Cisco，EMC等国外厂商的软硬件产品。2014年2月，国家成立了
以习主席为组长的中央网络安全和信息化领导小组。5月，中央国家机关采购计算机禁止安装
Windows 8操作系统。9月，银监会下发[2014]39号文《关于应用安全可控信息技术加强银行业网
络安全和信息化建设的指导意见》，要求“从2015年起，各银行业金融机构对安全可控信息技术
的应用以不低于15％的比例逐年增加，直至2019年达到不低于75％的总体占比。”
在这些背景下，今年3月，工商银行软件开发中心北京研发部，邀请我司做了“UDAL技术
介绍”的交流。今年9月，中国支付清算行业协会的技术标准部，也邀请我司技术人员，与支付宝、
财付通、中国银行、光大银行等企业的技术专家一起，进行“支付清算行业分布式系统架构”的课题
研究，俗称 “去IOE研究”。
1 什么是IOE
一般来说，IOE是指IBM主机、Oracle数据库、EMC2存储，这也是大多数传统金融银行在
其核心系统中所采用的黄金组合，是“集中式架构”的典型代表。
在《淘宝技术十年》中有一张关于自研和外购的投入趋势对比图，其中用了两条直线。而我觉
得，应该是两条曲线：1）达到一定规模后，自研成本远低于外购；而且随着规模的进一步扩大，
自研投入的增长还会趋减。2）在某个时间点上，外购所能支持的业务规模有限；超过此规模后，
即使再多的钱也买不到相应的技术或产品。
正是由于在集中式架构下，这些顶级厂商的顶级产品也无法解决阿里日益增长的巨大容量
数据、巨大并发的处理难题，所以阿里集团首先发起了“去IOE”运动，将其IT系统逐步改造为“分
布式架构”，同时消除对IBM主机、Oracle数据库和EMC2存储的依赖。
Copyright © 2014 liusheng@umpay.com All rights reserved.

在2013年阿里技术嘉年华ADC大会上，阿里巴巴副总裁章文嵩曾将去IOE的原因总结为
三点：一是成本，二是响应速度，原有集中式架构对互联网大规模应用扩展的严重制约，三是
对技术的把控力不够。阿里巴巴首席技术官王坚则更进一步，将上述三点的重要性进行排序，即
“1.技术领先；2.响应速度；3.成本”。成本因素只是最表面的原因，而最深层的原因是在互联网时
代，包括互联网企业在内的绝大部分企业，都难以通过IOE提供的技术，来满足其对计算的需
求了。
2 如何去IOE
目前国内实施“去IOE”最早而且最成功的，是阿里巴巴集团。
阿里的“去IOE”实施，从2010年1月三淘（淘宝网、淘宝商城、一淘网）的核心系统正式启动
“去IOE”，到2013年6月支付宝最大、最复杂的现金流结算系统完成“去O”，基本实现“去IOE”既
定目标。整个实施过程，前后历时三年半，涉及1.7万名技术人员的参与。为了提高协同效率，在
2011年，阿里集团还将所有的技术后台运维和运营部门都集中在首席技术官下面，成立统一的
技术保障部，协同调度技术、产品和业务等各个团队。
对于“去IOE”的技术方向，阿里实际上在多条技术路径上进行了探索和实践。根据阿里技术
保障部DBA负责人周宝方在SACC 2013大会上透露出来的信息可以看到，阿里集团在2010～
2013这四年的“去IOE”整体预算，其重点各不相同。
 2010年，重点是商用技术，如Oracle RAC集群。
 2011年，重点是开源技术，如结合FlashCache和PCIe-SSD等硬件技术的高可用MySql
集群方案。
 2012年，重点是自主技术，如OceanBase分布式数据库，DRDS中间层。
 2013年，重点是云计算，包括一系列的“阿里云”服务，如RDS、ODPS等。
总结起来，“去IOE”有三条技术路径：
 技术路径1：用自主化和国产化的产品替代。然而，在IOE三者中，“I”和“E”是比较容易
被替换的，比如用浪潮小机替代IBM小机，用华为存储替代EMC2存储。但要替换“O”
则比较困难，国内尚无一个商业数据库能够达到Oracle同等级别的成熟度。
 技术路径2：用自主可控的分布式架构来替代。例如，最近中国银行正在借助“阿里技
术”来重建其内部核心系统。

 技术路径3：用自主可控的云服务来替代。这也是阿里首席技术官王坚所推崇的方案，
也是“去IOE”的终极方案。
3 数据云概念
随着业务量不断增长，传统的三层架构已经无法满足需求，需要进行进一步横向扩展，变
集中式为分布式。而这三层当中，主要包括三类服务器：处理静态页面的Web服务器、处理动态
逻辑的APP服务器、存储数据的DB数据库服务器。对于WEB和APP层，都比较容易实现多机
部署和负载均衡，从而消除单点故障，提高系统的可用性。而DB则是最后一个，也是最难解决
的单点故障环节。
当传统Web应用面对高并发数据访问需求时，原底层单数据库设计难以有效支撑上层应用
的数据访问。此时一般通过如下几种方式对DB减负，从而提高系统的整体可用性。
1）按应用拆分——不同业务系统使用不同的数据库（即垂直分区）。
2）按操作拆分——增加多个全量数据镜像，提供数据冗余，实现“读写分离”访问。
3）按数据拆分——相同业务系统根据某种分片策略（时间、ID、HASH等）使用不同的数据
库和表（即水平分区）。
4）按类型拆分——将部分数据从关系数据库迁移到NOSQL数据库中，减少对前者的依赖。
数据持久层在经历上述拆分后，会变得非常复杂；而业务逻辑层与之的交互也随之变得很
复杂。业务系统所需要的，是如何存数据、如何取数据，而并不关心真正的数据是具体存在哪种
数据库、哪个数据库、以及哪种存储介质上。在此场景下，“数据云”应运而生。
什么是数据云（Data-as-a-Service）？
数据云不是“云存储”，后者如百度云网盘、七牛云存储等，仅仅是“云”上的数据文件。
数据云也不是“云数据库”（Database-as-a-Service），后者仅仅是结构化的关系型数据库在

“云”上的表现。
从“云”角度来看，数据云DaaS实际上横跨了基础架构云（IaaS）、平台云（PaaS）和应用软
件云（SaaS）三个层次，以“云”的方式提供无所不在的数据访问服务。
从实现的角度来看，数据云包含了三个方面的技术：数据库，数据库集群架构、数据访问层
服务。
4 数据库类型和CAP+理论
按照Brewer的CAP理论（Consistency，Availability，Partition tolerance），传统SQL数
据库更关注一致性和可用性，而放弃了分布性。而在互联网和大数据背景下，分布性是必不
可少的，只有通过放弃一致性，才能获得高可用性和高扩展性，NoSQL数据库由此而来。
但后来随着进一步的研究，我发现，CAP 理论并不是简简单单的“三选二”，或者说，
CAP三个特性也不是三角形的三个顶点，而是三角形三条边，每个特性不是“有和无”的选择，
而是“多和少”的选择，这也就是我所描述的“CAP+”理论。三角形三条边长的大小，代表着对

该特性的重视程度。在同等周长下，你最多可以增加其中的两条边，与此同时，第三条边的
边长会相应缩小。
那么，有没有办法让这三条边的边长同时增加呢？答案是“有”，但前提条件式是：三角
形的面积需要有指数级的增长，而这面积所代表的意义就是“成本”，这些成本包括人员成本、
研究成本、部署成本等等。新型的NewSQL数据库就是这样产生的，它通过一些全新架构来
实现了高可用和高扩展，同时还保留了NoSQL所放弃的ACID一致性和SQL查询功能。
5 高可用数据库集群
为了解决数据库的单点故障，提高系统的整体可用性，有两条技术路线。
 技术路线1：基于传统关系型数据库的高可用集群。主要包括共享存储（Share-
Storage）、全共享（Share-Everything）、无共享（Share-Nothing）三类。
 技术路线2：基于新型NewSQL数据库的高可用架构。如谷歌的Spanner和F1数据库，
阿里的OceanBase分布式数据库。
目前，中小银行的核心系统，对事务一致性要求高，主要采用下面两种集中式方案。
 基于“Share-Storage架构”的主备数据库集群：双机主备，但由于主库和备库共享了一个
磁盘阵列，导致主备切换时间较长。
 基于“Share-Everything架构”的数据库集群：此时不仅共享存储，同时还共享缓存。典型
案例为Oracle RAC数据库集群，由于过度依赖其一致性缓存技术（Cache Fusion），导致其扩展
能力不足，一般只能扩展到4～20台左右。
更好的方式，是采用基于数据库复制的“Share-Nothing 架构”，具备数据冗余，能快速实现主
备切换，具有更高的可用性。针对不同场景，有如下几种方案：
 方案1.主主方式
 方案2.双主多从
 方案3.分片只读
 方案4.分片读写

前两个方案，数据未做水平拆分，写扩展能力有限。后两个方案，数据已做水平拆分，但是
分布式强一致性问题难以解决。要解决分布式一致性，一种方案是结合应用端，按照某种分布式
一致性算法，来实现轻量级的事务一致性；另一方案则是引入全新架构的NewSQL数据库，由
NewSQL数据库来保证分布式事务一致性。
1.主主方式2.双主多从+VIP（或：双主多从+DAL）
3.分片只读+DAL 4.分片读写+DAL
几种方案的简要对比如下：
特性×∨√ SSQQLL++集群 SSQQLL++分片++集
群
NoSQL NNeewwSSQQLL
R 关系型 √ ∨弱关系× √弱关系
Q 支持SQL √ ∨不支持跨库 × √精简SQL
C
索引 √ ∨无全局索引 × √
关联 √ ∨无跨库JOIN × √
事务/ACID √ ∨无跨库事务 × √
同DC一致性 √ ∨可调整∨可调整∨可调整
跨DC一致性 × × × √
A
高扩展容量× √ √ √
高扩展写 × ∨分片+写√ √写延时较大
高扩展读√读写分离∨分片+读写分离√ √
实时性/内存 × × √ √
P 数据分片× ∨无跨库写√ √
分片方式 × ∨应用分片√ √自动分布
案
例
1.主主方式3.分片只读+DAL 5.OceanBase
2.双主多从4.分片读写+DAL

6 分布式数据访问层
维基百科上，将数据访问层（DAL）定义为一种计算机程序层，它提供对存储在某种类型
的，持久存储数据的简单访问，如关系型数据库。其他应用程序模块通过DAL来访问和操纵各
种数据存储中的数据，而不必处理这种访问方式固有的复杂性。简单来说，DAL是一系列服务的
集合，是DAO在大型系统中的自然延伸，是SOA的具体实现。
通过引入独立的数据访问中间层（DAL），可以达到如下一些目标：
1）简化客户端接口，规范数据操作，以便实现“透明性”分片。
2）保持客户端接口，动态升级服务端实现，实现SOA架构。
3）支持访问海量数据，包括分布式缓存、读写分离、数据分片（分库/分表）等。
4）支持对服务的治理，实现各种认证、管理、权限、监控、分析、优化等。
目前的数据访问层DAL（Data Access Layer）有三种实现方式：
1）客户端端封装方式：针对特定接口封装自定义SDK包，供前端业务系统端调用。
a) 采用自定义接口或SDK开发包。
b) 实现自定义JDBC驱动，访问多个分库和分表。
c) 实现自定义DataSource数据源，从数据源获取相关DB连接完成操作。，
2）服务端封装RDS中间层（Relational-Database-Service）：完全针对关系型数据服务，应
用端SQL和JDBC驱动完成和中间层的交互。已有的淘宝TDDL，Amoeba，Cobar，阿里
DRDS、奇虎Atlas，网易DDB、腾讯云数据库、百度DDBS、亚马逊RDS、微软AzureSQL、
谷歌Cloud SQL等系统或服务，都是采用这种方式。其中部分实现完全兼容MySQL网络
协议，应用端无需修改任何代码或驱动库，即可完成数据库访问操作。
3）服务端封装DaaS中间层（Data-as-a-Service）：将数据及对数据的访问视为一种服务，
此时不限于访问关系型数据库，还能访问各种非关系型数据库，甚至是Tuxedo中间件
之类的在线服务。此时，需要放弃JDBC网络接口，甚至放弃SQL语法，而改用自定义
接口提供给APP端来访问。如SUN的JPA规范，Amazon的S3 /SimpleDB/DynamoDB等，
Google的CloudDataStore和BigTable等。

我司的UDAL方案，主要采用DaaS方式进行设计和实现，同时也在客户端封装了自定义
SDK和JDBC驱动，方便业务系统调用。具体实现过程，分为四个阶段：
 第一阶段（Udal-Server）：实现DaaS中间层基础架构，完成UDAL服务器，代理各种
数据库和在线服务的访问。
 第二阶段（Udal-Client）：为方便业务应用端使用，封装了远程和本地两种接口。前者
通过Udal-Server访问所需数据，后者则直接访问后台数据库和在线服务。
 第三阶段（Udal-Shards）：在Udal-Server的基础上，实现对分片数据的访问：支持“分
库+分表”访问方式，读写分离、单列/多列分片、全局/单条/范围查询、结果集合并/二次排
序、多表分页查询等高级特性。
 第四阶段（Udal-Jdbc）：在Udal-Server的基础上，实现对SQL的解析。同时通过定制
JDBC驱动器（Udal-Jdbc）与UDAL服务器相连，使用iBatis测试用例完成相关测试。
此时应用端直接用Udal-Jdbc驱动，替代原有的DB2或MySql数据库的JDBC驱动，而
无需修改业务代码，就可完成对分库分表的统一访问。
7 我司数据云下一步方向
我司目前已经在技术路径1（基于传统关系型数据库的高可用集群）上，做了很多研究和实
践，实现了数据量、读性能、写性能三个方面的高扩展能力。而下一步的目标，则是进一步解决“一
致性问题”，提高系统的事务一致性能力：
 不限于集中式事务，而是提供分布式事务能力。
 不限于超强一致性，而是实现可调整的一致性。
 不限于单数据中心，而是提供跨数据中心的一致性。
跨数据中心（跨区）的分布式事务一致性是一个世界性难题。在技术路径2（基于NewSQL

的高可用数据库）上，谷歌从GFS、MapReduce、BigTable 等原始云计算技术开始，到
Colossus/CFS和Megastore等技术，最后进化为覆盖全球数百个数据中心、数百万主机的超级分
布式数据库Spanner 和F1，前后花了10年时间。而@阿里正祥（阳振坤）所率领的团队，将
OceanBase从原型设计，发展到目前的0.6版基本可用的状态，也花了4年多时间。
这条道路艰辛而且漫长，需要更多的同学们一起戮力前行。

20141208内刊投稿（刘胜）支付清算行业分布式架构的探索v1.2.doc

Recomendados

Recomendados

Mais conteúdo relacionado

Mais de liu sheng

Mais de liu sheng (11)

20141208内刊投稿（刘胜）支付清算行业分布式架构的探索v1.2.doc