【摘要】目前集中式架构已越来越不适应业务以及转型的要求，需要对架构进行分布式改造，提升IT系统的承载能力。分布式数据库作为分布式架构的基石，其选型直接关系到分布式架构转型的成败。本文结合企业实际情况，为分布式数据库的选型提供了参考，可降低选型和复杂度及工作量。1.1 背景
随着科学技术的不断进步，计算机的计算及存储能力取得了实质性的发展，进而推动关系型数据库技术不断完善及发展。传统的集中式关系型数据库技术日趋成熟，在各行各业的核心业务系统中扮演举足轻重的作用。但我们也清楚的认识到，虽然底层硬件的能力在不断发展，数据层面却体现出“广、大、快、杂”的发展趋势，且发展速度远超底层硬件的增长速度。如何处理不断产生的大量的数据，将是摆在传统集中式关系型数据库面前的一个难题。为了解决这个难题，行业内大都采用将承载数据库的底层硬件替换成更稳定、更高计算能力的设备、分库分表、读写分离这些方案。这些技术方案虽然在一定时间内解决了部分问题，但终究只是过渡方案，且实施复杂，治标不治本，无法在数据库架构层面提供根本性的解决方案。
幸运的是，计算、存储和网络能力的快速发展，带来了高IO、低延迟的传输体验，分布式关系型数据库逐渐登上历史舞台。随着阿里、腾讯等互联网公司的高并发核心业务逐步搬移至分布式关系型数据库，分布式关系型数据库已经成了高并发业务系统的数据库重要解决方案。分布式关系型数据库系统是由若干个节点集合而成，它们通过网络联接在一起，每个节点都是一个独立的数据库系统，它们都拥有各自的数据库、中央处理机、存储，以及各自的局部数据库管理系统。因此分布式数据库系统可以看作是一系列集中式数据库系统的联合。它们在逻辑上属于同一系统，但在物理结构上是分布式的，“形散神聚”是对分布式数据库架构组织形式最恰当的描述！
1.2 业务需求
目前金融行业绝大多数核心系统的数据库依旧采用传统的集中式架构（高端小型机+集中式关系型数据库+集中式SAN存储）为主的实现方式。数据库作为IT建设必备的基础软件，集中式关系型数据库越来越不适应海量数据以及高并发环境下对数据处理能力的要求，成为整体IT建设的瓶颈。“业务+技术”双轮驱动公司发展的方式，会因为技术的滞后显得没那么协调，阻碍企业快速、健康可持续发展。随着国家战略的转变、业务规模的扩展以及IT技术水平的发展，对数据库提出了更高的要求：
1、安全可控：近年来，随着国际竞争格局的变化，国家提出了自主可控的战略要求，IT 基础设施及基础软件作为科技发展的基础构件，其自身的自主可控对国家整体自主可控战略的实施起着举足轻重的作用。随着国家技术能力的进步，在底层的基础设施层面大多已实现自主可控的解决方案，可使用X86+机内盘存储的方式来提供数据库运行的计算及存储能力。数据库作为基础软件，安全可控的数据库产品是必然要求。
2、多活容灾：企业对外提供的IT服务大都基于数据中心，数据中心一旦发生故障，将导致所有业务系统的中断，对企业发展造成难以挽回的损失。作为保障业务系统安全稳定运行的最后一道防线和风险集中点，我们的业务系统必须要考虑数据中心级别的容灾、多活方案，这要求数据库产品要支持多活及容灾能力。
3、提升业务承载能力：随着互联网、移动业务需求的爆发式增长，产生了大量的数据及高并发的访问需求，达到了集中式数据库单机处理的瓶颈，难以通过垂直扩展的方式来解决问题，极大的降低了用户体验。这要求我们的数据库产品要提供高并发、可水平扩展的能力，提升业务承载能力，提高企业核心竞争力。
4、高可用：现在的核心生产系统要求7*24小时不间断运行，给数据库产品的高可用提出了极高的要求。如果将数据库集中在一台服务器上运行，一旦该服务器发生故障，则整个系统将受到影响，可靠性不高。即便集中式数据库做了一定的高可用性设计，切换过程也可能会存在数据丢失、业务中断的情况，难以满足连续不间断运行的要求。
5、架构转型：随着互联网的深度应用和数字经济时代的到来，数字化接触渠道更加丰富，客户需求正在向定制化、碎片化、场景化转变，具有小额、高频、海量特点的互联网业务爆发式增长。这要求企业的产品和服务需要快速响应市场和用户需求的变化，持续交付新的功能，不断优化用户体验。此外，平台化战略、跨界融合趋势，也要求企业将内部能力进行开放，并具备与上下游主体的快速对接能力。面对上述挑战，企业需要积极采用新的技术，适时进行架构转型，构建领先的IT服务平台，在提升信息系统支撑能力、提高系统可用性和灵活性的同时合理控制IT成本，从而更好地支撑业务发展和快速创新，适应未来发展需要。显然我们的集中式数据库并不能应对架构转型的要求，需要重申审视并引入新的数据库产品。
1.3 为什么要选择分布式关系型数据库
传统的集中式关系型数据库在应对业务需求方面能力不足，选择分布式关系型数据库是大势所趋。各企业可根据自己的实际业务需要，决定是否对数据库进行分布式改造。下面从三方面来说明选择分布式关系型数据库的必要性，供大家参考：
1、可水平扩展
近些年，随着互联网经济的崛起，数据变得越来越重要，数据产生的速度越来越快，数据随时随地访问、分析的需求也越来越多，这给国家的整体经济结构以及各行各业都带来了前所未有的机遇与挑战。针对金融行业而言，单台数据库服务器的处理能力已经无法跟得上上述趋势的变化，必须引入可扩展的分布式架构，将多节点的处理能力聚合在一起来解决。而分布式关系型数据库可以提供这种水平扩展的能力，且技术成熟，商业应用比较广泛。
2、高可用
分布式关系型数据库可通过部署在不同区域的多副本来提供同机房高可用、同城双活、异地容灾、异地多活等多种高可用架构。当主节点发生故障后，能迅速将业务重导向到同机房的备节点上，应用层几乎无感知。即便发生一个数据中心的灾难，同城机房也可以在20秒内迅速接管业务，且数据不丢失，极大保障了业务的连续稳定运行能力。
3、高性能
“三个臭皮匠赛过诸葛亮”，集体的力量是强大的。分布式架构用性能稍差的多节点来替代性能高的单台服务器，增强了IO吞吐以及数据处理效率，尤其是面对业务爆发式增长的场景时，通过扩展节点，增加个体来近乎线性增加处理能力，这是集中式架构无法解决的。
综上，高可用、高可靠、可扩展的分布式数据库带来了极大的技术变革，给金融行业的业务发展起到了较大的促进作用，有助于金融企业在激烈的竞争中增强核心竞争力，加强技术储备能力，提升业务创新能力及用户体验，以更优雅的姿态迎接互联网时代的挑战。
1.4 分布式关系型数据库带来的挑战
任何事情都不是完美的，虽然分布式数据库能解决很多业务的问题，但对我们的开发以及运维工作带来了更多的挑战：
1、对开发的挑战：
（1） 库表结构设计：分布式关系型数据库下的库表结构设计有别于传统的集中式关系型数据库，要结合业务来重新规划分库分表的方案，采用单元化的思路来限制数据库的跨节点、跨域访问，提升处理效率。
（2） 开发思路转变：在传统数据库中常用的存储过程、触发器、外键以及序列等对象在分布式关系型数据库支持并不友好，需尽量规避。这对开发人员提出了更高的要求。以存储过程为例，开发人员应通过服务拆分及编排的方式来实现传统存储过程实现的功能，降低耦合度，便于系统移植并降低系统升级影响范围。
（3） 制定新的开发规范：为规范并提升代码质量，通常企业都会制定对应的数据库开发规划，原有的集中式数据库开发规范已经不适应分布式数据库，需要重新引入分布式关系型数据库开发规划并开发相应的脚本工具对代码进行检查来确保开发人员按照新的开发规范进行开发。
（4） 新技术学习成本：引入一个新的数据库产品，需要先了解其特点与优势，这需要开发人员持续不断的对新技术进行学习，才能充分发挥出产品优势，提升系统的运行效率。
2、对运维的挑战：
（1） 运维复杂度提升：分布式关系型数据库架构体系复杂，备份恢复技术也较集中式数据库难度更大，且分布式数据库运维标的数量远高于传统的集中式数据库。这样对于DBA而言，运维标的的运维难度和数量都有明显增加，给整体运维工作带来了更大的压力。
（2） 新技术引入及学习成本：DBA需要在实践中不断摸索并学习分布式数据库的运维技能，形成标准化运维手册，提升故障处理能力。这需要持续不断的培训投入，带来试错成本，在新架构转型的初始阶段，可能会对业务系统的稳定运行造成一定的影响。
2. 分布式关系型数据库技术路线选型
2.1 分布式关系型数据库选型原则
目前市场上有开源及商业分布式关系型数据库产品，因数据库承载着企业最为核心的数据资产，数据库的高效、稳定、安全运行至关重要，所以在进行分布式关系型数据库选型时，首要的原则就是不考虑开源产品，而选择成熟、稳定的商业产品。
针对商业产品，分布式数据库的选型还需要考虑其可靠性、稳定性、可扩展性、安全性以及服务能力等诸多因素，下面就这几个方面的选型原则简述如下：
（1） 可靠性：要确保数据库产品能够保证数据不丢失，可以进行正常的备份以及恢复，当某个节点发生故障时，对用户体验无明显影响等。
（2） 稳定性：数据库与底层硬件不存在兼容性问题，可基于底层物理环境稳定运行。具备高并发环境下的应用案例，能提供稳定的数据库服务能力，提供可在线升级的能力等。
（3） 可扩展性：可通过增加计算节点来提升事务处理能力，且支持计算节点线性扩展，数据可在各个节点间均衡分布等。
（4） 安全性：支持应用到数据库的访问加密，支持多种密码策略，支持数据脱敏，访问白名单、数据库审计等。
（5） 服务能力：数据库产品提供商具备极强的产品开发能力，有标准化、体系化的产品路线图以及服务支持能力等。
基于以上原则，通过市场深度调研及分析，最终确认了技术路线的选择范围为市场上技术能力雄厚的三家厂商提供的产品。
本文并不是对三家产品做谁好谁坏的论断，而是结合企业自身的实际，来对选型的思路及具体过程进行描述，希望能对目前正在进行分布式关系型数据库选型的企业提供参考，降低选型的复杂度和工作。
2.1.1 技术能力匹配度分析
市场上的分布式关系型数据库产品各有千秋，都有自己的核心技术优势，对于处于第一梯队的产品，没有最好，只有最合适。因分布式关系型数据库的选型最终是服务自身需求的，需要通过多轮的技术沟通、市场调研、用户需求讨论筛选出最适合自身需求的技术能力匹配度清单，然后按照清单对厂商的产品进行比较深入的了解及打分，以便对厂商产品有量化的评估依据。
下面为技术能力匹配度参考表单及样式（部分内容），具体内容请各企业根据自己实际情况定制：
技术能力匹配度得分计算采用加权计分法，计算公式如下：
S为总分
n为领域能力总数
P为能力的权值
V为能力分值
Bi用于表示当前能力具备情况。如果具备该能力则取1，反之取0。
2.1.2 实施难度分析
分布式关系型数据库选型必须考虑的一点是后续的实施难度，从传统的集中式数据库到分布式数据库，涉及到核心系统重新开发，工作量非常大。这时候企业可拿出急需改造的一个业务系统，针对入围产品来做一对一的改造测试，通过改造过程厂商的支持力度，改造后的功能满足情况以及系统性能来对厂商及其产品进行进一步的了解，进而对各家产品进行排序及分档。
2.1.3 成本分析
成本包括软件许可费用、原厂技术服务、软件维保服务及关联的硬件资源投入成本。不同企业引入分布式关系型数据库的目的不同，比如我们比较关注多中心多活的实现，因此对副本数量的多少、分级存储这些会直接影响硬件投入的因素十分敏感，也是我们在成本分析上需要重点考虑的。
2.1.4 产品成熟案例
一个成熟的商业产品，必须要有成熟案例的支撑，这方面我们主要考虑入围的厂商是否有在大型金融机构有成熟的支撑案例，相关案例的规模以及支撑的系统类型。
2.2 如何开展分布式关系型数据库POC测试
2.2.1 测试方案设计
为确保入围的分布式关系型数据库产品能满足企业的实际需求，POC测试是必不可少的一环，因此需要有针对性的对测试方案进行设计。测试方案的设计主要包括五大部分：
（1） 引言：对测试文档、测试背景以及测试目标进行说明。测试背景部分描述测试活动的背景，包括现状、未来预期，以及相关领域的背景信息，整理出原始需求和POC测试的对应关系；测试目标部分描述本次测试活动的测试目标，按照基本能力验证和其它特性验证的划分原则，将重要需求和一票否决项放入基本能力验证部分，优先进行测试。
（2） 测试策略：涵盖基本测试策略、人员及职责、测试时间安排及测试环境说明等内容。其中基本测试策略描述测试阶段的划分原则，以及每阶段的准入准出标准。
（3） 测试方案：包括基本能力验证及专项特性验证测试两部分及其具体的测试用例。
（4） 测试执行：按照测试方案进行测试，并记录相关测试结果。
（5） 测试结论：对测试过程中发现的问题及测试的结果进行总结说明。
2.2.2 测试内容
在POC整体测试中，最重要也是最耗时的并不是测试执行环节，而是确定测试方案，这个需要对测试的内容和测试用例进行详细设计。针对分布式关系型数据库而言，测试主要涉及了三个大的场景：
（1） 基本能力验证：包括功能性验证、语法、高可用、运维管理、数据安全、数据导入导出、多租户以及容灾等方面。
（2） 数据复制能力：测试从传统的集中式数据库中将数据取出来并迁移至分布式关系型数据库，这个场景直接关系到分布式改造能否顺利进行。
（3） 实际业务测试：选择至少2个业务系统，针对其中复杂的SQL和业务场景进行改写，然后在分布式数据库上进行功能及性能测试。
2.2.3 测试结论
经过详细的测试，最终针对入围产品的整体结果进行测试汇总，并看看是否有产品会触发一票否决事宜。从实践经验来看，在选定入围产品时，我们就已做了大量的技术摸排工作，因此POC测试的结论是全部通过。
2.3 结论
分布式关系型数据库选型是一个非常复杂的问题，除非有必要，不建议对数据库进行分布式改造。但一旦做了分布式改造的决定，就必须对技术路线的选型进行合理、充分的论证，以便保证分布式改造的目标顺利实现。企业在进行分布式改造的时候，一定要从内部梳理最真实、最迫切，最关注的需求，然后据此选型。目前不存在完美的产品可以解决所有需求，我们需要的仅仅是从众多的产品中选择最适合企业自身的产品然后应用它，快速有效的适应业务需求的变化，提升企业核心竞争力，在残酷的竞争中保持核心技术优势。
