1.数据库架构搭建的基本方法和流程2.核心系统从大型机系统迁移到分布式架构3.Redis异地容灾架构搭建1.数据库架构搭建的基本方法和流程1.数据库架构组成1）数据库架构在日常工作中，如果谈到数据库架构，一般指的是网络、主机、存储以及运行在其上的数据库实例。数据库架构工作是指如何评估和组合这些组件，为业务提供满足运营需求的数据库服务。2）数据库访问组件当数据库架构向分布式架构演进时，如何让应用（服务）快速确认数据的位置成为一个核心问题，这就是数据库访问组件的工作。3）数据库运维平台对于一个大型组织来说，运维上千甚至上万个数据库实例是家常便饭，这也给运维团队的日常管理带来了一定的挑战。各个公司和组织都搭建了告警监控、故障处理、变更、版本发布等操作平台，在设计和构建数据库架构的同时，搭建数据库操作平台已经成为一种标准操作。2、可操作性和需求的构成1）业务需求数据库架构首先要匹配组织的业务流程，满足组织的业务需求，这是所有从业者的共识。2）运行需求设计和构建数据库架构的最终目的是获得一个能够提供持续稳定服务的数据库集群。从设计之初就充分理解并满足操作需求是数据库架构设计成功的关键因素。3）监管要求对于高度监管的行业，如果不满足监管要求，项目将无法启动。因此，监管要求可以说关系到监管行业的生死存亡，在设计之初就必须充分考虑。3、架构设计1）行业生态“不重复造轮子”。在设计数据库架构之前，调研行业的技术生态非常重要。同时要看到，我们机构的技术生态也是行业生态中很重要的一部分。2）架构设计初稿通过调研行业生态，获取数据库架构所需的模块，然后根据项目实际情况对所需模块进行组合、完善，即可得到初稿数据库架构草案。4.架构构建1)数据库选择和测试架构设计后数据库选择的一个重要考虑因素是保证数据库架构设计的客观性。如果在数据库架构设计之前选择数据库，则架构设计不可避免地会受到数据库功能特性的影响。2)数据库架构原型在完成数据库架构设计和数据库选型的前提下，我们可以在测试或开发环境中搭建数据库架构原型，作为我们下一步工作的基础。5.架构迭代1)数据库原型构建完成后，可以对数据库原型进行测试验证，验证指标要回归到最初的需求、业务目标、运营目标和监管目标。2）每一轮的测试和验证都会产生架构的优化项。结合项目的需求和目标，不断迭代数据库架构。一般经过3~5次迭代，就可以得到一个比较稳定可靠的数据库架构。二、核心系统从大型机系统向分布式架构的迁移1、项目研究迁移项目的第一步是对系统现状进行深入调查。1）容量和性能指标系统指标分为多个方面。对于数据库架构，首先要考虑的是性能和容量指标。2）业务特点本项目有一个明显的特点——实时在线业务一次只处理一个客户，而会计结算和报表模块需要一次处理大量的客户数据。3）数据访问与处理通常意义上的计算与存储分离，是指数据存储在主机文件中，业务逻辑完全在应用层实现。4）项目人员的能力项目人员的能力主要集中在JAVA的开发上。他们对Oracle、MySQL比较熟悉，但是对其他关系型数据库的开发比较陌生。项目人员的能力对数据库的选择有重大影响。2.数据库架构原型设计1)按客户切分数据，数据路由在应用层处理。每个分片由一个数据处理模块和一组数据库实例组成。不同分片完全独立，跨分片的聚合计算在业务层处理。2）从数据库本身来看，不同分片之间的数据库实例是完全独立的，不存在数据交互。从业务的角度来看，所有的数据库实例组成了一个统一的数据库集群。3）这种架构的优点是单分片处理逻辑简单，对实时在线业务非常友好；缺点是跨分片处理逻辑复杂，报表结算业务难度大。3、数据库选择1）Oracle和MySQL对比测试Oracle在性能和故障自动恢复方面有一定的优势，但是在分布式应用架构中数据库实例较多，Oracle的成本远高于MySQL。MySQL在技术生态上更兼容应用分布式架构，但需要解决半同步不退化的问题。2）经过架构师团队的讨论和权衡，最终决定使用MySQL派生的数据库。性能接近原来的MySQL，同时半同步不降级，满足RPO=04。运营平台建设1）配置管理：为每个数据库实例分片属性和业务属性加分。2）端到端交付：为满足数据库实例的动态横向扩缩容，增加拉入节点、拉出节点和资源池功能。3）监控排查：在原有数据库监控平台的基础上，增加了业务视角和分片视角。当数据库实例发生故障时，可以更准确地定位受影响的客户。4）数据库变更：为满足24小时不间断业务需求，增加了业务降级、流量控制、滚动处理、变更日历等功能。5）版本发布：在分布式架构下，为应对呈指数级增长的复杂性和风险，增加了灰度发布、并行发布、分片适配和版本编排的功能。5、数据库架构的迭代1）为了满足监管要求，需要在现有架构上增加容灾架构。在生产数据中心和灾备数据中心构建相同的数据路由、数据处理模块和对应的数据库实例，并在对应的数据库实例之间进行数据同步。每个分片可以独立地在不同的数据中心之间自由切换。添加全局数据路由确保事务被路由到正确的数据中心进行处理。2）利用业界现有技术，通过binlog实时同步数据到大数据平台进行报表分析。3）利用业界现有技术，通过binlog（整体导入）将数据实时同步到分片数据库，降低了账务结算流程的复杂度。三、Redis异地容灾架构搭建1、需求梳理1）所有Redis只作为缓存使用，不需要进行数据同步。2）95%以上的Redis是Cluster架构，不到5%的Redis是Sentinel架构。本次设计的架构侧重于Cluster架构。3）95%以上的RedisClusters对容量和性能没有要求。准确的说，所有的RedisClusters都可以标准化，只要提供后续的扩容/缩容功能即可。4）RedisCluster的生产变化较大，异地容灾生产要求必须同时上线下线。5)最小化DBA和应用开发团队的人力成本。2、架构实现1）搭建K8S集群承载所有Redis集群。2）搭建Redis集群同步平台，从已有的CMDB中读取生产Redis集群的信息，将创建的异地容灾Redis集群的信息更新到CMDB中。3）同步过程根据CMDB生成生产Redis集群集和异地容灾集。生产集减去异地灾备集，即需要搭建的异地灾备集，平台会自动创建异地灾备集群，并更新信息到CMDB。异地灾备集减去生产集，即需要下线的异地灾备集，平台会自动下线异地灾备集群，并将这些集群从CMDB中删除。4）每天执行以上步骤，保证移动容灾集群和生产集群的同步。5）K8S集群可以自动拉起down掉的节点，结合Redis集群本身的高可用，可以保证异地容灾集群的高可用。6）K8S集群自身的告警监控可以满足异地容灾的告警和故障处理需求。7)设计自助服务平台，应用开发和运维团队可以进行自助查询、自助修改参数、自助扩容、自助域名申请等操作，最大限度降低DBA和人力成本应用开发和运营。王顺平安银行数据库运维团队上海分组组长专注数据库领域20余年，目前专注于数据库运维和数据库架构。
