民生银行数据库开源可控实践.doc

? ? ? ? ? ? ? ? 民生银行数据库开源可控实践 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 民生银行分布式核心开源实践 民生银行在 2018 年就上线了直销银行分布式核心系统。这套分布式核心架构也成为了金融行业的一个标杆。整个分布式技术平台包括的功能有分布式数据库访问、分布式事务、分布式服务框架与服务管控以及第四分布式批量作业调度，还有分布式配置管理、消息中心、分布式缓存，交易幂等性、统一冲正，全局系列的核心功能，这些所有的核心因素集在一起，构建了分布式的技术核心平台。 在这套分布式核心系统里通过分库分表和读写分离实现资源水平扩展，从容应对高并发加海量数据的 OLTP 应用场景。其中分布式数据访问（ CDAL ）层实现分库分表和数据访问，而底层采用了开源数据库。这是开源数据库在银行核心重要系统应用的经典案例，也是开源数据库在企业级应用的最佳实践。 民生银行的开源策略 为什么民生银行有信心在核心系统使用开源数据库？其实自 2015 年起，民生银行就已经在开始使用开源数据库 MySQL ，并在使用开源数据库的过程中总结出使用开源数据库作为企业级应用的经验，同时也收获了使用开源的信心。 民生银行不仅仅是在使用开源数据库，事实上民生银行的开源策略是全面拥抱开源技术，当前已经使用的开源产品覆盖所有基础软件领域。民生银行也不仅仅是作为开源的使用者，系统管理中心专门设置了开源软件支持组研究开源软件源码，分析和解决开源软件使用中的问题，同时和开源社区积极保持互动，不仅提交发现的问题，同时也提交问题修复代码贡献和回馈社区，参与开源软件生态建设良性发展。 数据库选型思考 民生银行当前存量的数据库系统大多数是运行在国外厂商的商业数据库上。因为一些众所周知的原因，数据库的可控性也成为当前最重要的课题。民生银行也一直在做新的数据库选型工作。我们认为可控性其实不仅仅体现在选型的产品是国产或者开源，可以避免使用当前商用数据库的政治不确定性，而且还要体现在我们最终选择的数据库产品使用可控性，也就是迁移和使用所造成的风险是否可控。 开源 VS 国产 作为可控数据库选型，我们把目光看向了国产数据库和开源数据库，并且考虑到选型的产品对国产系统和服务器的支持。当前国产芯片主要有国产 X86 芯片和国产 ARM 芯片， 而国产操作系统有麒麟，国产开源操作系统有 openEuler 等。因为暂时并不确定最终的硬件和系统方案，所以当前选择可控数据库，也是要求数据库支持这些国产平台。从民生银行的解读思路，开源数据库和国产数据库都是可选的。 作为国产数据库，为了使用风险的可控，我们需要考察产品的成熟度和厂商能力两个方面。产品成熟度包括产品功能，性能，周边工具支持等能力，而厂商的能力主要体现在研发能力、交付能力、支持能力和发展预期等。 作为开源数据库，为了使用风险的可控，我们需要考察产品的掌控力和开源生态这两个方面。产品掌控力包括自身的代码研究能力和开源贡献者的参与支持能力。开源生态包括产品成熟度、活跃度和周边厂商支持力。 如果上述的思考点满足我们的需求，那么这个数据库产品就具备使用可控性。 集中式 VS 分布式 在可控数据库的选型过程中，我们遇到了另外一个可能性。当前国内数据库在分布式领域实现了弯道超车，出现了很多不错的分布式数据库产品，并且性能和可用性超出了国外的商业数据库。这些分布式数据库的厂商也为国内企业提出了使用数据库更新的理念，那就是采用分布式数据库作为资源池，通过整合数据库资源和多租户的方式实现新的数据库使用方案。到底选择集中式数据库还是分布式数据库作为可控数据库的选型呢？我们需要分析下这两种数据库的特点和当前的实际需求痛点。 集中式 分布式 部署特点 部署场景简单，当前两地三中心部署方案比较成熟。 技术复杂，组件较多，多中心部署方案不成熟。 技术特点 产品性能足以应付大多数应用需求。存在资源纵向扩展上限。 通过资源横向扩展，应对高并发和海量数据场景。 运维特点 周边工具丰富，易于融入当前运维体系。 集群运维复杂性高，与当前运维体系需要改造。 需求 存量多，迁移需求更为迫切。 当前需要通过横向扩展解决瓶颈的系统少。 在这个总结的表格里，我们还是将分布式数据库的初衷作为是否需要分布式数据库的理由，那就是应用是否存在高并发和海量数据，需要通过横向扩展资源来解决性能瓶颈。而当前大量的集中式数据库需要做迁移，从迁移风险和运维风险的角度来说，我们还是偏向于传统的运维模式，采用集中式数据库。这是当前民生银行对于数据库选型的定位。民生银行不仅在考察可控的集中式数据库，也在考察当前的分布式数据库产品以应对性能扩展需求。 OLTP VS OLAP VS HTAP 为什么要单独列出来这个思考点，是因为我们认为这个真的很重