国产数据库金融行业应用与技术论坛原创

尊敬的各位领导和来宾，欢迎大家来到由腾讯主办的数据库金融行业应用与技术论坛。在当前技术环境下，关键技术与信息基础设施的自主可控已经成为国家与行业的共识。这其中，数据库作为金融机构数字化的基础软件，承载着核心交易与关键业务数据。扩产数据库如何向下一代分布式金融数据库引进金融行业关键核心技术突破与创新重要课题。为此，我们今天有幸邀请到了来自银行、证券、保险行业以及行业分析机构和数据库厂商等领域的多位专家、学者、管理者、技术掌舵人，共同分享国产数据库在金融行业的最佳实践与观点。期待这次思想与时间的交流分享，为金融行业数据库的用语创新提供新的思碰，撞出新的火花。那么首先我们有请腾讯副总裁胡立明先生为此次论坛做开场致辞，有请胡总。

尊敬的各位领导，各位专家、媒体老师和线上的观众朋友们，大家下午好。呃，我是腾讯胡立明，很高兴和大家在云端相聚，共同探讨数据库在金融行业的这个技术发展趋势和实践案例。我仅代表腾讯欢迎各位嘉宾的这个参会。那么。2022年，关键核心技术的这个供应链安全已经成为大国战略。竞争的核心焦点，不论是人民银行还是银保监会等等这个监管机构发布的金融科技发展指引。还是近期我们国家的20大报告都强调了关键核心技术的自主可控和自主创新。那么对于金融行业来说，数据库其实是金融信息系统建设的这个核心基础设施。承载了核心的交易业务。关键的这个业务数据。在信息系统的这个软硬件之间，也起到了承上启下的这个核心的作用。

我们认为呢，数据库的国产化建设是目前这个科技公司和金融机构一定要打赢的攻坚战。这里我也向各位领导和嘉宾分享一下腾讯在这场数据库攻坚战方面的三点思考。第一呢，我们要做好长期的作战准备。全面完成国产化的这个数据库国产化的一个转型，它不是一蹴而就的。呃，在技术线，包括这个产品选的规，用的景的试，呃实这些呢，都离不开这个技术厂商和金融机构生态伙伴的这个充分的配合和耐心的打磨。那这里往往是几年甚至是十几年的一个技术的长跑。所以在加快产品和技术融合的同时，我们不但要重视研发的投入，也要不断的提升专业的这个服务的水平，重视实施和交付的这个能力的提升。

为这场持久战做好充分的准备。第二呢，要实现真正的自主可控，并建立强有力的这个国产化的技术的壁垒。那么金融行业是支持国民经济正常运行的关键的行业啊，金融数据库也支撑着大量的这个交易账户和这个金融的核心业务。啊，数据库的。据其实在保障业务的正确性，以及这个呃业续性，这个期国产化数据崛起之呢，之前是以这个L代表的海外的业产及的这种技术，国内这市场规模方是技方都有一定的性。那么呃，近年随着国产国产化的这个数据库厂家崛起和奋起直追哈，那么。

啊，国内的这个数据库技术也在蓬勃的发展，我们腾讯呢，在坚定不移的走这个可控的线期，我们T口的数据库也通过了安全部的这个中国信息安全检测中心的自主可控的测评。极致的性能。呃，高效的数据迁移以及高可用性，呃，这个保障的这个技术和能力。来满足金融机构对于核心国产数据库的这个建设的要求。呃，第三呢，是要通过大量的实践，为我们整个金融行业提供可落地的参考和路径。呃，当前国产数据库其实在国内啊，我认为整体还是在一个初步的阶段。陆续有不少的这个试点落地阶数据厂家是比较多的，传统的一些厂家，新兴的这个技术类的厂家，也有像腾讯这样的这个云厂家在参与，那么呃，我们的T目前之所以。

多家的国有大股份支行，还有交易，包括很多商的金融机构，主因为我们积累了大量的数据的实践的经验。那这些经验来自于说像腾讯在这个广泛的互联网场景当中的这个原生需求的积累。包括研发的积累，还有就是腾讯计费对于整个腾讯系的值兑换的场景的支持，也加了我们在海量呃当中的这个成熟度，以及支持微众银行核心全面应用的这个实践，那使得我们目前成为国产数据库的佼佼者之一。

上百家金融机构提供了这个数据库服务。啊，也让我们的数据库在多行业、多场景的金融领域应用当中得到大量的能力的提升和积累。那么今天的论坛呢，我们也邀请了各个金融领域和生态伙的和领家，他们国产这个实践的经验行带和启。最后呢啊，借着本次国产数据库技术论坛的这个机会，希望我们腾讯和线上的诸位一起来共同探索碰撞。

再次感谢大家，谢谢。好，谢谢胡总的这次，那么下面我们首先有请IDC企业级系统研究部研究经理王楠先生。腾讯金融数据库论坛的朋友们，大家下午好，我是IDC咨询的分析师王楠，我主要负责应用开发与部署领域的研究，那么数据库市场呢，也是我这边的核心的研究领域之一之一，那今天非常的荣幸在这里跟大家分享一下中国数据库市场的一些趋势，还有关于分布式数据库实践的挑战与建议。那大家都知道，呃，其实呃现在中国的数据库市场是非常火热的一个状态，那其实我们讲的话，嗯背后有大概三个原因啊，去驱动这个市场的热度，第一个是行业的数字化转型，那随着企业数字化转型的深入，企业对于呃数据的价值的这种。

嗯，认知程度是越来越高的，嗯，对于使用数据去分析数据的需求越来越强烈。对数据库也产生了更多的这样的需求，第二点呢，是资本的关注，那资本的入驻，呃，帮助这些数据库厂商有更多的资金去投入，在。产品研发，市场开拓，嗯，包括这种客户拓展层面是嗯，数据库厂商的这样的市场活动更加活跃。第三点呢，就是政策激励，呃这两年其实我们看到了，呃政府在呃基础软件层面，就包括数据库中件在的基础软件层面是有很大的这样的。利好政策也帮助本土的这些数据库厂商获得了前所未有的市场机会。呃，总体来看呢，这些呃驱动因素是中国数据库市场持续升温，也推动了中国数据库市场的一个高速增长。

那下面这张图呢，是IDC的一个预测数据。我们可以看到，在2021年，中国数据库管理系统的总规模是43亿美金，那到2026年呢，这个规模将大概翻3.5倍，达到了148亿美金。呃，从符合增长率来看，2021~2026的符合增长率，中国是27.9%。嗯，远远远高于美国，中国的这个增速还是非常快的。那呃，除了这这这些宏观因素以外，数据库是数据库所处的数据环境啊，包括呃企业的业务发展的这种嗯变化，以及基础设施的变化，其实都给数据库的部署使用，包括一些能力呃提出了更多的要求。首先我们看呃数据的企业的数据环境是日益复杂了，嗯，那企业的数据规模现在远超异往啊，并且是一个高速增长态势，那企业中的数据的类型也变得越来越多种多样，以前企业的内部呃主要的数据类型就是关系数据库啊，结构化数据可以说。

嗯，那现在呢，企业需要更多的去分析啊的一些数据啊，包括呃，用户的行为行为数据，呃，互联网的这种点击的这种数据啊等等等等，那需要管理和分析的数据类型越来越多了。呃，第三呢，就是我们看到数据的部署环境里的变化，那呃，在多运环境下，混合运营环境下，甚至边缘利的环境下，终端的里面数据企业都需要去管理。所以也要求呢，我们的数据库要有这种跨云的，呃，跨部署环境的这样的管理。呃，第二个呢，是我们看到企业的业务侧重在发生变化，那呃，移动互联网的业务在蓬勃发展。这回带来两点问题，首先业务的规模在快速扩张，那高并发的场景是越来越多了，那就要求我们的数据库要支撑这种高并发的场景，第二点是企业的业务发展越来越依赖。数据价价值的挖掘，呃，并且呢，对这种呃业务的分析的这种时效性要求越来越高，那需要我们的数据库这种支撑实时分析。

嗯，第三我们是看到新技术日新月异，包括云计算啊，物联网啊，人工智能啊，5G编计算等等等等啊，首先这些新技术也是带来了前面的数据规模和数据类型的这样的高速增长和多样化。其次呢，嗯，这些数据也催生了更多的细分类的专业的数据库场景，比如说呃，持续数据库，无数据库啊等等。嗯。总体来看呢？呃，以上这些，呃，技术变化，企业的业务的变化，是数据库的发展，发展方向产生了以下几点变化，首先呢，我们看到的是分布式的数据库。出现那分布式，它可以很好的解决呃，数据规模的这样的弹性扩展扩张的这样的。的能力，那使我们呃数据库可以支撑更多的呃海量的这样的数据规模的数据，那高速增长的同时，我们提供一些弹性的能力啊，我们可以快速的。

呃，弹出我们的数据库的指力啊，去管理这些高速增网数据，第二个呢，是我们看到呃云营商数据库的这个出现，那云生数据库里面其实也包含了一些呃分布式啊的技术，但是我们想营生它更多的是在利用云的一些技术去帮助我们。降低数据库的呃，管理的复杂度，嗯，可以。嗯，让我们的数据库更加应用啊，减少我们的数据库的日常运维动作。呃，第三个呢，我们看到的是AI使能啊，更多的其实是AI托底啊，利用AI的能力去减少对呃人工的这样的依赖，呃利用像智能调优，智能调餐等等，减少我们日常运维的一些工作。第四点是我们看到多某数据库的出现。

嗯。呃，过去呢，我们的。这个数据库呢，通常来说一个数据库是管理一种类型的数据，但是现在企业很多场上讲，特别是。比如说呃，工业互联网呃智能驾驶这类的场景，那它需要去综合的分析多种类型的数据啊，才能保证这个呃业务的连续性，或者是服务的连续性。可以满足我们的要求，嗯，所以如果在过去的话，那。多种类型的数据，它需要多种数据库的支撑，那如果需要统一分析的话，就涉及到数据的迁入迁迁出啊。无论是从这种工作量上还是时效性上，都是不能满足性的需求，所以现在出现了多模的数据库，用统一的这样的呃平台就可以管理多种模式的这样的数据的存储啊。大大简化了数据迁入迁出的这样的工作，也提高了这个数据使用和分析的实效性。

最后一点是我们看到混合事物与分析啊。呃，这样的需求，呃，HT数据库的出现，那过去呢？呃，我们做事物的负载和分析的负载通常需要两套数据库，那呃，利用这种行业混存的这种技术，实现HT这样的数据库，我们就解决了，呃，两数据库需要两个副本啊。这样的情况，我们用一套引擎，我们就可以支撑我们的事物和分析啊，同时也大大提高了实效性，满足一些数据的频繁变化，但是我们对呃数据分析的时效性要求有非常高的这种。IDC是怎么去呃划分数据库软件的呢？IDC总体上把数据库软件分成了六大类，首先也是最重要的就是我们的关系型数据库。呃，第二个呢，是nol数据库，这里面包含的呃，细分的子品类数据库就比较多，像序啊，图啊，值啊等等都在这里，这也是比较热的一个数据库类。

第三个是地点法数据库啊，指的是不依赖，嗯。图呃，指的是不依赖中页的DBA啊，可以部署在我们的桌面环境这类数据库啊，比如说微软的access，第四类是从呃导航式数据库，或者叫层状层次数据库。第五类是数据库管理系统，第六类是缓存数据库。那么我们看右边的图，在整个的中国数据库管理软件市场里面，其实呃，关系型数据库的占比还是最大最大的。它也是我们整个数据库市场里面最重要的一个数据库。当然关系型数据库里面，我们也包含了交易型的，也包含了分析型的数据库啊，都在这个品类。那从中国的这个专业型势库市场发呃发展趋势来看，我们总结了四点，第一个是呃，政策利好，本土的这个厂商啊，本土的品牌前面也提到了，那本土品牌在这个很多行业里面，特别是政府行业的份额大幅提升，那第二点呢，我们是看到云服务商，包括腾讯云啊在内的，以及阿里云啊，华为云啊。

啊，大家以前更多的是做公共理论上面的一些服务产品，那么现在大家在寻求传统部署市场啊，行业客户的一些拓展。第三点，我们看到了开源生态建设成为了很多厂商的重要战略，那开源生态建设可以帮助厂商快速的去获得用户场景啊，同时也能呃从用户那边得到产品的一些使用的反馈体验。呃，反过来帮助厂商去更好的去，呃优化啊，或者改造产品。呃，第四点是分布式数据库的快速发展，这个后在会在后面呢展开去讲。这里就不介绍。

嗯，我们其实已经看到了，呃，企业在应用传统的数据库，或者叫集中的数据库的时候，面临的已经面临的一些挑战。呃，IDC在去年做了一个调研，然后从用户的反馈中，我们梳理了几点比较集中的啊，这样的传统数据库目前面临的问题啊。首先是。传统数据库在管理，嗯，数据的容量上的一个瓶颈，那单机数据库其实已经不能很好的满足当前海量数据规模的这样的一个管理要求。第二个是，嗯，传统数据库。对高并发的支撑能力相对来说较弱，那面对高并发的场景，那传统数据的性能其实嗯，已经是很难支撑了。啊，第三点是备份效率啊，嗯，备份效数据的备份效率还是比较低，那业务稳定性可能性会。带来降低的这种风险啊。

呃，传统数据库的。由于在企业内部部署的这种数呃量是非常大的，并且种类也越来越多啊，运维的工作是越来越复杂，很多情况下去靠这种人工式的啊运维是带来很大的这样的日常工作的这样的繁重的挑战。啊，最后一点当然是安全风险的。所以我们已经看到一些领先的企业开始尝试去利用分布式数据库解决这些问题。啊，这同样是我们去年做的，呃，一个。调研，我们调研了包括政府行业、金融行业。啊，以及运营商行业在内的一些，呃。企业型的客户，那这里面金融行业其实是占了大头的，超过50%。嗯，调研结果看的话，目前有27%的呃用户已经部署了分布式数据库，那最终呢，呃超过呃大约是2/3的用户，66%的这种备访企业。

已经看到了啊，利用分布式数据库替换之后的性能的，并且改善啊，表现出呃，满意甚至非常满意的这样的一个态度。从嗯，分布式数据库替换啊，集中式数据库的驱动因素来看，我们把它总结成两个方面，一个是技术驱动，那啊企业需要提前布局，那分布式数据库是未来的技术啊，我们要拥抱未来，然后第二点呢，就是说提高数据库的稳定性和可能性。嗯，还有还有一个驱动因素就是业务驱动啊呃，分布式的这种性能更高啊，相对来说，呃与这种利用依靠硬件的高性能硬件的这种方案，成本相对来说更低啊，还有就是满足移动互联网业务的这种海量规模和高高品发展需求。那嗯，IDC是怎么嗯定义分布式数据库呢？IDC认为分布式数据库具有以下四点的基本特征，首先是逻辑的统一性，那分布式数据库呃在逻辑上应该是。

同一个数据库保持统一的系统逻辑，服务于统一的呃目标，第二是呃面对于应用和用户的这种投透明性，那用户和应用应该是使用分布式数据库的时候，是无需考虑部署架构的，那数据是怎么分布的，它的存储逻辑是是在哪，然后数据要怎么怎么分辨存存在哪里，不需要考虑这些问题，应该是与传统的。集中式数据库的使用体验是一样的。嗯。第三点是可以按需的灵活扩缩容。啊，还有第四点就是。分布式数据库可以实现高度的自啊，有很高的这样的安全性。那呃分布企业在分布式数据库中，呃通常会说会面对，呃面临哪些挑战呢？首先第一点我们看是保障数据的一致性，那呃或者说是从用户侧更多的是来自于数据一致性的顾虑，那保证数据。

的一致性，其实是由分布式数据库厂商已经把这个问题解决了，他提供这个数据一致性的能力，通过派source啊，Rap等等一些算法，那嗯，更多的是来自于呃，用户对分布式据库，因为它多多付款存储，那数据可就有可能产生产生这种不不一致的风险这种顾虑啊。呃，第二点是我们看到啊，数据迁移的难度太大啊，首先嗯。在做集中式到分布式替换的时候，会有海量的这种数据的迁移，那么如何保证在迁移的过程中我们的业务的稳定持续啊，不中断啊，这是很多用户的一个表达的一个顾虑。第三点是缺乏呃相应的运维工具和经验，呃不像呃成熟的这样的商业的产品和开源的产品，有大量的原厂的工具，呃第三方的工具啊可以使用，那在分布式数据库这一块，运维工具更多的是用原厂支撑的，并且很多的功能还不完善，是随着用户的实际的使用中，厂商在不断完善。

呃，第四点是需要对原有应用系统的升级的诊断啊，虽然现在很多的分布式数据库的产品，呃，厂商啊，他其实都有提到，我对某个开源产品和商业产品的兼容度很高啊，甚至达到了90%以上。但是在实际的迁移和替换当中，嗯，客户还是需要做大量的这样的，嗯应用层的改造，包括思考嗯这样的语语句的这样的优化。嗯，但是好，现在好的地方呢，是厂商已经开始提供这些评估工具，那让用户在迁移之前就有一个全量的这样的一个评估啊，减少在迁移过程中应用改造的一些风险。呃，最后一点是我们看到其实是缺乏相关的技术，现在呢，分分布式数据库的，呃。

嗯，优秀的技术人员基本上是在呃供应侧的，就是说在分布式厂商内部啊。在市场上比较难找到相应的这样的专业的技术人员。那总体来看，其实我们嗯，也想向企业去实施分布式数据库啊，去做这种分布式数据库迁移改造的这些用户啊，提个建议，那其实最主要的首先就是我们借鉴同行行业内的最佳的实践，那以及他们的经验教训。呃，在金融行业其实已经有很多分布式数据库实践的这样的先行者，那他们在嗯选对于分布式数据库产品的选型啊，包括整个的实时迁移过程，那他们遇到哪些问题啊，他们得到了哪些这种经验教训，我觉得啊，都是在呃，企业在做这个分布式改造的过程中，或者之前值得去学习和借鉴。

具体来看的话，我们把企业分布式数据库的实施策略分成了我们三点分讲，第一点是根据部署的难易程度，那对于那些比较容易部署数据容易迁移的，那我们先进行分布式尝试，较单，那么放在后面啊。第二点是根据业务发展的需要，那我们嗯一个互联网策略业务啊，比较容易出现高频发场景，对空中要求，嗯，比较频繁的，我们优先进行分布式进部的清理啊。嗯。第三点是根据数据安全的需求，那在金融行业啊，特别银行啊，保险啊，证券等等，对数据的安全等级普遍是比其他的一些行业的企业的要求高的，那出于安全啊，稳定啊，合规性啊，监管呢等等的这部分要求的考虑，那企业会将非核心系统的数据啊进行分布式改造，那核心系统我们就慢一些，然后轻则度啊，不去进行这种分布式查询。

以上就是我们对分布式数据库实施的一个建议。那好，我今天的分享就到此结束，谢谢大家。啊，好的，非常感谢来自IDC的王先生为我们带来的行业分析以及预测。那么下面呢，我们会有请中国银行技术平台产品架构师王先生为我们分享大型商业银行分布式数据库应用事件，有请王鑫先生。各位同仁，大家好。那个我是来自中国银行软件中心的王鑫，那个很高兴能够参加这次技术交流的这个活动啊。今天呢是由我呢分享我中行呢在这个分布式数据库应用的一个实践，希望呢能为大家在这个分式数据库应用过程中呢，起到一个参考的一个作用啊。那么本次呃，这个我主要的分享的主题呢，有三个方面，第一个方面是我一个应用系统的一个现状和这个一个我们实施的规划。

嗯，主要是主要是，嗯，我行，就是目前的这个数据库的一个应用的一个情况。第二个方面呢，是这个，呃应用分布数，呃，应用分布式数据库的一个实践，主要是介绍这个呃，我行在分布式数据库建设中的一些架构的一些设计和一些思考。第三个方面呢，是阐述一下数据库后续应用的一个情况。呃，首先呢，我先简单介绍一下我行现有数据库的一个应用情况，目前呢，中行应用系统呢，应用的产品呢，按照。渠道。呃，场景金融总线，还有外围核心进行一个划分。呃，按应用场景呢，分为这个交易服务类和分析服务。那我们在这个，呃，这个这个TP的交易中呢，核心类场景和柜面交易呢，交互类的这个场景呢，一般使用的是这个D和R。

呃，大部分传统的这个金融业务使用呢，是这个Oracle数据库。呃，我们还有一些新兴的这个场景啊，像我们的商啊，使用的是这个MY数据库。呃，在分析类的这个场景中呢，大部分产品使用的是Oracle作为这个后线数据处理。这个。部分产品呢，啊。是迁移到了MP，随着这个业务场景啊。呃。目前我行这个数据库的转型呢，主要有两方面的一个驱动啊，一个是在内部驱动上呢，我们主要是业务场景的一个需求。

那例如说我们有大量的这个海量数据的查询，还有高并发的需求，还有我们业务的一个这个活动啊，沟通的一些一些活动。那么都会对这个存储。啊，算力啊有很。企业及架构的一个建设，主要是在这个新流程和新工艺，还有我们技术平台支撑上，那么是做了很大的一个改造，从而快速了，快速推进了我们的一个技术转型。那外部驱动上呢，那一个就是我们监管的一个自主可控的一个要求。另外一方面呢，是目前的一个趋势啊，就是我们呃，国产国产的分布式数据库呢，目前在这个整体的这个能力上，性能还有运营服务上。都在逐渐完善啊。应用适配的这个场景呢，也逐步的这个在丰富。我。

我们行呢，这个13年14年呢，其实就开始向这个分布式数据库开源的这个数据库进行探索。呃，在商的系列产品里呢，我们都采用了MYND这个D。这个这个。呃，数据库。还有在我们的这个，呃，历史数据，历史数据查询的这个交易里呢，我们采用的是这个芒果DB。呃，在整体应用过程中啊，我们是积累了这个比较多的一个分布式数据库的一个应用经验。那么目前呢，随着我行这个信创几家建设呢，逐步我们目前呢，是逐步转向采用这个，呃，商用的这个工程数据库啊，进行一个替代。呃，我还在这个云原生数据库和大数据领域的这个数仓方面呢，目前也在进行这个研这个研究工作。

嗯，目前呢。目前呢，我们行呢，就是呃，整体业务应用的一个呃，一个迁移的策略是呃。呃，主要是在这个现在这个渠道非金融和非关键这个场景啊，进行这个分支数据库应用的这个积累。然后呢，会逐步这个推，推到我们的金融的外围啊，还有金融的核心。打造我们金融级的这个工作数据库的一个底座。嗯，目前我行这个已有的这个已有部分场景啊，在就是配了就是两种这个数据库的这个，呃，这个架构吧，一个是我行这个自主，呃自主研发的一个技术平台叫红平台。那么我们平台加上呃，目前腾讯的这个，呃，T这个的这个数据库。

呃，由这个应用完成这个路由的分发，读写分离，分布分表，还有分布式事物。另外一种呢是呃，我们会在这个应用层，也就是我们技术平台做适当的这个呃集群的拆分，那么由这个分支呃分支分布式数据库。完成整体的分布式事务，啊，数据的这个分发路由就是两，呃，目前就是两种这种技术架构。嗯，下面呢，我介绍一下就是应用分布式数据库的一个实践情况。呃，目前呢，呃，刚才介绍了，我们是用红平台加这个腾讯。呃，进行这个，呃，在一部分业务场景里啊，进行了这个数据库的这个分支数据库的一个国产化的一个，呃改造。那么在应用呢，那么我们主要呃，主要是呃，采用技术平台啊，去突破这个单机的这个一个存储和算力的一个上限。

满足这个可扩展、高存储还有高并发事物一致性的这些要求。呃，对于实时性要求比较高的这种，呃复杂的，然后聚合查询呢，我们现在趋向于是采用这个汇总库。就是我们的这个交易库。那么会我们的汇总库去同步数据，然后由汇总库进行一个数据的处理。那对于时效性比较低的T加一的这种呃数据的一些处理，那我们是目前是呃，由这个呃实时数据同步到我们的呃大数据平台进行这个数据的处理。呃。目前在现在我们这个架构下呢，其实我们主要是我们在连机这块呢，主要是需要解决呃三个问题吧，三类问题。一个是这个我们的数据怎么去拆，那么数据怎么去由，怎么去定位。

那另另外一个呢，就是因为数据拆分以后呢，我们需要解决这个事物的一致性，产品间的事物。第三个呢，是刚才说了，就是我们要解决。跨库的一些聚合呀，跨库的一些关联，还有批量的一些业务。那么后面呢，我就会那个针对性的呃，逐步展开做一个介绍。那目前我对于这个TD产品的整体的一个部署方式呢，其实呃。呃，跟铜业应该是比较相像的，我们是采用这个一组三重。那么跨机房呢，同城的跨机房节点呢，是一个这个同步的一个节点。呃，本机房和这个，本机房和这个，呃，跨机房各有一个这个异步的一个同步节点。那么在我们的，呃，异地，也就是说在我们的环境，我们是一的。呃，两个数据库实例，作为一个灾备的一个环境。

那么整体上呢，在环境这块呢，我们的应用呢，是要做这个数据的一个预热的。然后通过这通过整体的这个架构的这个设计呢，那么我们是实现了同城多活，异地可切的一个功能。满足r po和R的一个要求。呃。为满足这个我行这个一级规模的这个金融核心服务和这个多地多活高可用能力需求啊，我们也是借鉴了一些业界的单元化架构的一些实施的一些经验啊，还有结合五行的基础设施，基础环境的一个布局情况。那么我们设计了一个覆盖呃全领域的一个企业级的一个单元的一个架构。呃。通过这个综合考虑呢，数据库这个单机的这个TPS数据量，还有我们数据库的连接数，以及全局的一个业务的一个情况呢。

我们划分了十个单元，就是总共划分了十个这个这个服务单元。呃，每个单元呢，是有十个，每个单元是有十个这个数据库。呃，十个数据库实例，每个数据库呢？那么我们会在内部继续拆分十张表，十张表。也就是说我们每个单元呢，会有1000，每个单元会有1000张表，整体形成一个百度表的一个部署的一个形态。那么我们在单元间呢，是做了一个呃，对等的一个关系，就在单元间是有一个对等关系的，就是我们的这个副本啊，是有一个对等关系，那么可以实现这个同城的。时间。呃，同时呢，我们还做了一些单元化设计的一些原则的一些要求。那么要求呢，应用产品呢，尽量去遵守统一的一个规则。那么呃，总共有三个一个原则，一个是单元化流量封闭的一个原则，一个是数据拆分的一个原则，还有一个是单元化平台支撑的一个原则。

那么单元化流量封闭的这个原则呢？其实主要是实现渠道核心外围系统。一个端到端单元化的一个架构。要求单元内呢，业务要自包含。呃，服务调用链路呢，是封闭，封闭的流量是收敛的。那大概是什么意思呢？就是我们在单元内呢，要完成我们整体的一个业务。尽量避免呢，我们是跨单元的一个数据库的一个访问。尽量避免这个单元的事故的产生。那数据数据拆分呢，是这个，呃，我们觉得是单元化这个架构下，数据库比较重要的一个部分啊。呃，对应用系统，我们应用系统呢，改造呢，提出了一个四点，呃，提出了四点要求。

呃，一个是客户账户相关的关键系统是必须拆分的。另外呢，我们是可以拆分的，系统是要求尽量拆分。还有一个是在关键业务链上拆分的维度呢，是需要保持一致。第四点呢，就是在单元收敛，减少跨单元的一个访问。那么根据我们的这个业务的一个目标成本，还有容量的一些考虑呢，那么我们要求各产品这个在数据，呃，就是数据拆分的这个力度。要合适，要做，数据要足够平均，那么性能呢是优先考虑的，那么业务是需要解耦的。那么基于这些考虑呢，实际上我们的整体分析完了以后呢，我们的拆分原则呢，就是按照这个，呃，客户维度进行一个拆分。呃，有了这个单元的一个拆分的一个原则，数据拆分的原则，那么我们，呃，还有这个我们用技术平台支支撑的一个原则，我们各类应用系统啊，各类改造的应用系统都都需要使用我们的技术平台。

呃，我们技术平台呢，在这个运行呢，呃，大家可以看到，其实我们提供了很多这些，呃一些呃共性的一些非功能的一些呃处理啊。那么跟数据库这块呢，相关比较相关的呢，是这个我们的数据访问代理，分别是事物还有数据的一个同步，可观测性的一个平台。那么我们在运维态呢，其实我们还提供了这个路由一些一些路由规则的一些管理，还有监控的一些管控规则一些管理。那么我简单介绍一下这个相关的这些，呃，组件的一个一一个功能，那么首先呢，介绍一下这个数据访问代理的，呃，这个组件呢，我们的一个功能，这个组件呢，它主要提供表的读写。和这个数据访问的一个功能。还有单元化路由功能，支持这个流量切换时动态调整数据库，数据库的一个连接。

那么提供这个单元单元定位的一个功能，那么是在客户端呢？是通过采用分配哈希算法。去实现，那么在服务端呢，我们是实现相应的一个映射规则。同时呢，我们还提供了这个分库分表的这个功能实现，主要是实现数据库层面的请求到分库分表的一个路由及逻辑表明和物理表明的一个映射。呃，另外一个比较重要的分布式事物组件呢，是用于保障实现分布式架构下我们的一个跨库跨服的一个事务的一致性。呃，提供这个单元化架构下分布式事务的处理能力，能够按照单元路由规则和记录执行这个我们的分布式事务。另外一个是我们数据同步的一个建设，那么我们在分布式架构下呢，实现了这个实时的一个数据的一个传输服务。

那么我们可以将这个我们联机的这些数据库的数据啊，通过我们的这个实时同步工具，传到我们的汇总，传到我们的大数据平台。呃，另外在运维侧呢，我们实现了这个，呃呃，就是单元化的一个这个可观性，或者叫微服务下的一个可观测性。那么我们提供了这种多视角的这个监控能力，那包括整体的这个应用产品的一个监控。还有单微服务的监控链路的一个跟踪，还有实时报警。呃，通过这些呢，是保障了我们整体。呃，整体我们单元化的一个，呃，能够可靠的一个实现。那下面介绍一下，就是我们对于分布式事物的一些呃方案。那么数据库解决，数据库解决的是这个数据库存储层级的一个事物的一致性。那由于业务呢，业务是比较复杂的，那么对于有些产品呢，它确实是需要进行一些跨库跨产品的一些访问的的这类场景呢。

就需要呢，在应用侧完成事物的一致性的一个保障机制。呃。我们我们行呢，从这个应用整体上综合考虑呢，是采用这个的这个模式去解决分布式事务的这个问题啊。那么提供了三方面的一个功能。一个是这个分布式事务，那么提供各应用产品，我们由技术平台啊，提供给我们的应用产品，那么提供它一些分布式事务的这个这个。呃，SDK那主要包含呢，是事物的一个协调器和事物的一个管理器。那事务协调器呢，那主要负责呢，根据服务编排中配置的这个事物呢。进行这个事物的调取。那事务管理器呢，是主要负责事务流水信息的一个记录。另外呢，我们还提供了这个事物自检的一个服务，就是准实时的检查不一致的一个事物的一个状态。

进行自动的一个补偿，处理和发送事物的差错。第三个呢，是这个事物差错的一个批量的一个兜底机制。那么主要是提供。呃，差错的一个数据的存储查询，还有一个。还有一个告警。那在这个分支事务的实施过程中呢，我们嗯，也是有一些思考，嗯。也是给各应用产品呢，提供了一些呃考虑的一个整体的一些呃指南吧，算算做一个指南，那首先呢，在这个呃分析阶段，那么我们刚才说了选的是这个的一个事物模型。那在设计这个服务时呢，我们需要对子事物的一个拆分和边界呢，进行一个定义。另外呢，我们在使用分门事物时呢，是需要借助这个编程式的一些注解呀，还有我们的服务编排工具啊，进行整体这个事物的编排。

呃，其次呢，在这个开发阶段呢，呃，我们要求这个开发这个正反交易，也就是说类似于数据库的一个回滚的一个，呃，一个度的一个工作啊。那么另外还有我们要有交易状态的一个查询，也就是说这个对于未名交易我们都知道它的一个一一个状态。那由于这个卡的机制呢，那在交易过程中呢，它会某些服务呢，会执行重试，所以呢，我们还要保证这个交易的一个密等性。呃，最后呢，我们在运行阶段呢，在服务提供了这个实时服务监控和差错。的这种处理。呃。例如呢，就是我们在呃原子服务，我们在做某个原子服务时呢，那假如说机器出现某些问题，那需要做重试，那重试后呢，可能还是失败。

那这时呢，就需要由服务呢，发起这种自动的这种反向冲。呃，除了刚才了这些事务监控差错自动处理呢，那么我们呃，在账户余额角度，从账户余额角度呢，还进行了一个兜底的一个核对，那整体呢，就是从我们的运行运行态，还有这从我们的这个后边这个批量处理，那么整体上去保证我们最终的一个事物的这个。呃，一致性。呃，下面介绍一下，就是我们对于汇总和聚合库的一个一个思考啊，就是我们在这个呃数据库在做这个分库以后啊，分分以啊，那么在呃会导致某些这个场景下聚合查询啊，还有我们。一些关联查询啊，还有批量处理啊，那么这些这些呃场景呢，会涉及到多个这个数据库的一个一个一个读操作。

那应用层呢，我们需要考虑数据的一个聚合处理，那包括排序分组过滤啊这些功能。那么导致呢，应用呢复杂且性能其实不佳。嗯，实际上呢，就是在传统的这个数据库应用时啊，像我们用Oracle做的时候啊，就是遇到这个复杂的这个，呃，这种批量场景啊。呃，也是有相同的一个问题啊，只是在这个分布式数据库啊，由于数据库又进行了一个分片啊，那么问题呢，就会更加的这个突出。那我们大概的一个处理策略呢，是对于少量的这种简单的批量应用场景啊，就在某些产品里有少量简单的批量应用场景。我们目前呢，是由各数据库实例啊进行一个汇总。关联。然后呢，再进行。二次汇总。二次聚合。啊，这是在库里边儿去做这种操作的。那另外呢，我们在对于这种复杂的一个，呃，这种混合场景啊，那么我们行呢，就主要趋向于采用这种连接批量分离的这种方式啊。

呃，通过这个原表数据的一个异步的一个复制，也就是说采用这个CDC工具啊，那将这个我们的这个数据啊，同步到我们的汇总。呃，主要是有几点考虑吧，一个是这个，呃，我们批量业务的这个复杂度啊。呃是比呃其实还是比较高的，那么对于对于批量处理的这个吞吐量还有时效性，另外还有功能的一个扩展，灵活灵活啊。其实都是有比较高的一个要求的。另外一个呢，就是说我们在批，我们在使用批量库的时候啊，可定满足这个批量需求的这个数据的一个分规则和一个索引的一个规则。呃，这样的话呢，不会联想，呃，不会影响这个连机的这个这个。那第三点呢，是这个，呃，我们事务性的一些处理啊，和可以和这个查询进行一个分离，也就是说我们也可以由汇总库去提供一个查询服务。

嗯，上面呢，是对于呃，这种我们刚才红平台呢，加这个T单机单机模式的单单实力的这种架构下呢，我们整体的一个就是比较对于比较关键的一些呃，技术处理的一个介绍啊。另外呢，就是呃，我们还有另外一种就是集群拆分的一个设计啊。我们可以看啊，我们现在这个，呃，就是这个产品啊，它是一个这个高并发的一个产品，那么它也涉及到这个。也涉及到我们的汇总库，也涉及到我们的这个数据的一个同步。那么这个产品呢，它主要目前现状呢，它主要采用的是也是一个同城双活的一个架构啊，八个八个这个处理单元。

那么目前数据库呢，还是采用这个Oracle的一个的一个方式啊做这个。主要负责这个处理连接事务。呃，分库呢，是用各分库是用O去同步到这个我们的汇总的。嗯，那我们，那我们在这个这个产品改造的过程中啊，呃，我们的方案呢是呃，采用这个分布式数据库啊。是采用分门数据库做一个这个整体的一个替代。那我们。那我们选用的是这个代理模式的，这个数据库的模式，也就是说我们是由这个数据库做整体的集群的这个呃。数据的拆分，路由，还有负责整体的这个事物。嗯，我们可以看右边这张图啊，实际上我们我们是我们整体上是分了这个四个我们的国产数据库的一个分布式数据库的一个集群。

那么每一个集群里呢？每一个集群里呢，会有多个数据库的这个set去组成。那在每一个集内呢，再进行这个按客户号啊去进行一个分库分表，也就是说我在这一个集群内是由我们分支分支数据库是负责我们整体的这些。呃，路由。整体的这个事物。都是由数据库负责，那么在数据库在这个集群是由我们上一层的应用去负责这个，呃，数据的一些，呃，数据流量的一些分发，还有保证，保证这个跨库的一个事物的一个情况。那么这个这种设计呢，主要其实有两方面的一个考虑啊。呃，因为我们这种设计呢，呃。其实我们的数据的这个流啊，会应数据流，还有我们的应用部署啊，会更加的一个灵活。

我们不会因为一套集群。一套集群会就是一套集群会造成我们整体的一个切流的一个限制啊，我们多套集群。加上我们应用的整体的一个，呃。呃，一个部署方式啊，是可以，呃，部署到我们的同一地，或者部署到我们的4D。做这个整体的，呃，服务的一个接入。呃，还有一方面的一个考虑呢，是这个，呃，因为我们也是想，因为这这个产品是一个呃，并发量比较高的这么一个产品。那么我们我们也希望呢，降低这个集群的一个存储计算的一个整体压力啊，就是分散它的整体压力。那么更好的更安全的应用我们的这个国产国产分布数据库。目前呢，这套架构呢，已经完成了一个验验证的一个测试啊，已经完成验证测试。呃。

嗯，一个呢，就是说我们在这个嗯，建设这个就是分布数据这个替代的过程中啊，就是我们呃，也对整体数据库的这个呃。呃，问题啊，做了一个调研啊，就是我们也看了一下外部机构的这个统计啊，就是我们现在数据。呃大呃，大概有九成以上的这个数据库的这个问题是一个基础性的一个问题。那我们行呢，部分项目呢，其实是引入了这种呃后的一些检查工具啊，但是标准呢，其实不太统一，那数据库覆盖的这个范围呢，其实呃目前还比较少。那为此呢，这个那个我行呢，随着这个企业架构建设呢。逐步探索建设一个统一的一个SQL审核的一个工具，啊，建设一个审核工具。呃，目前呢，已经适配了这个Oracle等重要的一些数据啊。

呃，主要应用于我们的开发和测试阶段。通过这个工具啊，抓取动态静态这个破痕迹啊，并进行分析，协助我们这个开发人员在开发过程中啊，严格遵守这个开发规范。嗯，同时还提供了这些知识库啊，方便开发，呃，能够了解我们呃数据库应用的一些问题。呃，最后一部分呢，就是我们对数据库的一些，嗯。一些展望吧，或者一些应用的一些想法。嗯，这个当前呢，呃，面临着这个，我们都面临着这个技术转型啊，关键核心技术的一个创新和突破啊。呃，自主可控的这个数据库肯定是一个必然的一个发展方向。呃，在金融业就是在我们实践来看呢，目前数据呢，其实不不能是库这个打天下的这个这个形式啊，那么不同类型的这个数据库。

呃，不同类型数，呃，相同类型数据库，不同架构都会适配不同的这种应用场景。所以未来呢，我们将。呃，采取这种多元化的一个发展的一个策略啊。同时呢？呃，我们也看到这个就是目前分布数据库。嗯。这种规模呀，还有应用的这个时间啊，其实还是比较啊。在产品的这个成熟度，产品的稳定性，运营体系，还有配套的一些管理上。我们觉得还是需要有。有一些完善的，有一些提高的。呃，我们作为这个数据库的一个使用方呢，那么我们银行这块呢，其实在持续的梳理啊，这个行内数据应用的一个典型场景。因为毕竟我们用传统的这些，呃，数据库啊，已经很长时间了。

那么应用场景其实积累了很多，那么我们从呃，传统的这个数据库在向我分门数据库的搬迁过程中呢。肯定会有很多需要进行一些场景适配的地方。所以呢，我们在梳理的同时呢，也也也基于这些场景呢，呃，就是呃。建建建立了一些我们的应用专题吧，应用的一些研究专题，那么我们也形成了一些标准化的一些测试工具和测试方法案例及。并持续的开展。这些。这个呃，整体的一些测试工作啊。我们也希望这个数据库厂商呢，能够积极参与到我那个我们我们银行的数据库场景的一些研究中啊，获取我们一线的这个需求的一些关切。同时呢，希望同业间呢，也能够这个经常分享一些经验啊，希望整体上是希望我们能用好我们的数据库产品，同时呢也能用到这个更好的数据库产品。

呃，我今天的整体的这个分享呢，就到这儿，谢谢。好，感谢中国银行的王鑫先生为我们带来的分布式数据库在大庆商业银行的落地事件，谢谢。那么下面呢，我们有请秦皇岛数秦皇岛银行数据库技术首架构师进行先生为我们分享交易型分布式国产数据库在银行核心系统的应用都先进行签证。呃，尊敬的各位领导，同业的专家老师，大家下午好，我是秦皇岛银行秦皇岛银行科技部的纪宁，那非常高兴呢，有这个机会与大家做一起线上的交流，嗯，本次的分享呢，主要是针对秦皇岛银行在国产数据库上的实践的一点分享。那本次的分享呢，主要分成了四个部分，那第一部分我将简单的介绍一下，那在当前强调自主可控的基调一下国产软件的发展背景。

那第二部分呢，我将主要介绍一下在当前背景下，那秦皇岛银行是如何针对我们的实际需求去做国产数据库的选型的，那第三部分呢，主要是介绍一下在选型完成之后，我们整体的建设策略和我们的建设规划。那第四部分呢，主要是针对未来我们要做国产化的一点思考和建议，那接下来就进入我们的第一部分，国产软件的发展背景。那随着2008年的美国微软的黑屏事件，以及一三年的美国的棱镜门事件，以及零八年的中兴事件，以及一九年华为的断供事件，那这一次事件之后呢，美国的商务部又对611家中国的实体进行了管制，那其实质呢，也是美国利用国家安全的借口，对科技领域竞争对手的打压和限制。那这一系列重要的事件呢，也是给我们敲响了警钟，如果我国的网信产业命门继续掌握在别人手里，就好比在别人的基地，地基上盖房子，再大再漂亮也可能是不堪一击的，那特别是在美国的极限施压的情况下，那随之而来的后门啊，漏洞啊，断供的问题也是更加的突出。

那在此背景下呢，也是催发了以我国自主研发及生产的软硬件产品来构造网络及信息系统的，那与此同时呢，也为我国国产的it厂商提供了实践创新的沃土，从而逐步的建立自主的it底层架构和标准，来实现全it产业链的实力实力和结构的优化升级。那在当前的安信息安全下愈发重要的背景下呢，秦皇岛银行也是决定开始我们的国产化转型之路，那在数据库软件上呢，我们也是通过对我行的实际需求的分析，以及对未来技术的研判，开始了我们的国产数据库的选型，那接下来我将介绍一下选型的整个过程。

那当前的数据库呢，主要分成集中式数据库和分布式数据库两大类，那我们也是通过以下的对比，做出了我们对于集中式和分布式的选择，那从产品架构层面来说呢？那集中式数据库主要采用的是经典的单点集中式架构，就是二性的架构，那构建在高端的硬件基础之上，比如IBM的高端服务器和EMC的高端存储等设备。那对于分布式数据库呢，主要是基于业界最严格的或者是rap协议，那基于我们的普通的PC服务线。PG服务器是不需要高端硬件的。那在数据的可靠性和服务的高可用性方面来说呢？那集中式数据库主要是利用高端硬件来保证数据的可靠性。节点之间呢，采用的是主从复制，那在主节点故障的情况下呢，一般会有一定的数据丢失，并且呢，我们在自动恢复的时间通常也是以小时来计算的，那对于分布式数据库来说呢，那是以普通的PC硬件基础，那利用我们的分布式协议来保证我们数据的可靠性，那在主节点故障的情况下呢，可以保证数据的无损，并且呢，我们可以自动的选举并恢复服务，通常呢，恢复时间也是比较短的，一般可以控制在30秒以内。

那从扩展性来说呢？那集中是数据库的数据存储，只能是在单点内实现纵向的扩展，那最终呢，也会必然触达我们单点架构下的容量上限，计算节点呢，也是只有在少数的模式下，比如rank，我们才可以做计算节点的扩展。但是多个的计算节点之间呢，仍然需要访问单点的共享存储，并且呢，扩展的计算节点的数量是有一定的限制的。那在这一点方面呢，那分布式数据库就比较具有优势了，那在数据节点和计算节点呢，均可以在MPPT的架构下实现水平扩展，那数据节点和计算节点是没有任何的数量限制的。

那从使用成本方面来说呢？那集中式数据库由于需要采用高端的基础硬件，那整体来说这一部分的费用是比较高的，那分布式数据库呢？那由于采用的是PC的服务器，那相对来说整体上从使用成本上还是具有一定的优势的。那也是基于此呢，我们也是在集中式数据库和分布式数据库的选择中，我们是更于倾向于分布式数据库。那对于分布式数据库呢，那又主要分为中间件类的数据库和原生自研类的分布式数据库，那我们同样呢，也是做出了以下的一些对比。那么从产品架构层面来说呢，中间件类的数据库主要是基原基于开源的买或者PG加上中间件的架构来进行设计的，那原生的数据库呢，主要是基于独立的架构设计，或者是谷歌的spner架构设计。那从存储引擎方面呢？中间件类的数据库一般是基于加数，原生数据库主要是基于LM。那对于开源风险的角度来说呢，那PG的源码使用度的自由是比较友好的，那商业的应用也不会受到任何公司的实体控制，但是买的版权呢，目前是在甲骨文中，但可能会因为政治啊或者战争等因素存在一定的影响，但是目前呢，也有公司开发了独立于社区的数据库内核版本。

那在原生数据库呢，是目前是没有开源风险的，那对于开源风险这部分呢，我相信国家未来也会有相关部门牵头，那组织我们国内的分支版本，那这样的话也可以避免我们，嗯在在开源方面受人卡脖子的问题。呃，政策导向方面来说呢，那开源其实并不是问题，但是会与我们未来的政策以及我们自主的，呃，技术的自主可控程度是呈现的比较强相关的。那目前在原生的数据库呢，我们国家对于部分企业的政策还不是特别的明朗，那这也是需要我们考虑进来的。那从兼容性方面来说呢，那中间件类数据一般对或者PG的兼容性会比较好，原生的数据呢，一般会做MY和AC的兼容。

那在运维难度方面来说，中间件的数据库由于使用的开源组件比较多，那整体的运维难度会略高于原生的数据库。嗯，能力方面来说呢，能受到架构的限制呢，那中间件的数据库会略低于我们的原生资研类数据库，那从未来的发展空间层面来说呢，那整体中间件类数据库的起点是比较高的，那基于的开源技术也都是比较成熟，那长远来说呢，它的发展可能会受到我们的架构存在一定的限制。那对于原生的自然类数据库呢，相对来说起点是比较低，那整体的技术啊和生态也是在不断的完善的过程中，那整体呢，是不会受到我们未来不会受到我们的架构限制的。那对于以上的两种类型的数据库可能存在的问题呢，我们也是，嗯，在中间件类数据可以通过后期我们产品啊和架构的更新来提高我们的运维能力和high能力，那对于原生类的数据库呢，我们也会可以通过我们未来产品的迭代技术的升级来使我们的产品更加的可用。

那对于分布式数据库的选择呢，那除了以上的考量呢，那我们对于以下的四点也是我觉得也是非常需要关注的，那第一点呢，就是我们原有的技术路线。那对于我们需要改造的系统呢？那原有的技术路线是使用的是Oracle啊，还是my circle还是inform？那这对于我们未来在选择国产数据库上，我觉得是一个比较关键的因素，那国产数据库能做以上哪种数据库的兼容呢？会直接决定我们未来的改造难度，改造的工作量，以及要承担的改造风险。那第二点呢，就是技术人员的能力，那对现有的技术人员的能力呢，我们，嗯，对于未来的分布式数据库能力的储备，能否覆盖我们未来的开发运维以及相关能力的要求，也是我们需要着重考量的。

那第三点呢，就是我们的投入和风险，那我们想做国产化这个事儿，我们要去投入多大的成本去完成我们的任务，那我们是想选择快速的完成任务呢，还是说我们真用去积累经验，那为未来的技术架构以及我们的技术技术转型去做准备？那第四点呢，我觉得也是比较重要的，那就是谁会成为未来的主流，那这两部分呢，我觉得主要是从两方面来说，那第一个是技术层面，那第二个是厂商层面，那从技术层面呢，那到底未来是集中式啊，还是中间件类的数据库，还是我们原生自研类的数据库，那这需要我们来进行一定的判断，那对于未来厂商的选择呢，我们是选择大厂还是选择小厂，那选择大厂的好处来好处呢，就可能是技术能力比较强，版本迭代的也比较快，但是大厂的售后服务能否跟上，我们也需要进行一定的考量，那对于小厂来说呢，那通常的技术呃，通常的服务比较好，但是他的技术能力啊，以及未来它是否能够存活，也是需要我们嗯，着重的考虑在内的。

那以上呢，就是我们在国产数据库的选择，我们整体的一些考量点，那基于此呢，我们也是制定了我们国产数据库的详细的测试方案，目前我们的测试方案主要分成了四大类，那第一大类的话是我们数据库的功能测试，那主要是针对我们基础的搜Q语法啊，比如我们的DDL啊，DML啊，以及我们的scheme和表相关的操作。嗯，还有我们的常用功能，以及我们的数据库的运维管理能力，扩展性，高可用性和数据库的安全性等等的相关测试。那在数据库的性能测试方面呢，我们也主要是选取了分析类的场景和事务类的场景主要这两部分进行测试。那在业务的功能适配测试这一类呢，我们选取的是连接业务和批量业务，那主要是选取了核心的一些核心场景，比如我们的开立账户啊，我们活期的存入啊，转出等业务，来进行我们应用厂商和我们国产数据数据库的适配能力进行测试。

那第部分第四部分的测试呢，主要是我们的业务的性能测试，那也是选取了我们核心的业务场景，以及我们最终的日中批处理场景，来进行我们整体的耗时啊，性能啊，TPS的相关指标的测算。那对于所有的测试项呢，我们也是根据它的重要等级分成了一到五级，那从一到五级呢，也是非常重要到我们的不重要，那同时呢，每一个等级也是对应了不同的能力分值。那整体呢，对于我们测试案例呢，我们编写了五级的有七个，四级的有39个啊，三级的有45个，二级的有63个，一级的有29个，那整体的测试案例呢，我们合计超过了一百八一，183个，我们的测试功能点超过了700个，那我们的测试方案呢，也是可以覆盖到多种的场景，分别从不同的角度，不同的力度来去考核国产数据库厂商的综合能力，那也是为我行的国产数据库的选型把好了质量关。

那对于我们的测试项呢，我们是也是有不同的测试结果，那我们分别是由全部支持到我们的部分支持，再到我们的支持，那对应每一个测试结论呢，也会获得不同的得分比例。那对于结果评定呢，主要是分为单项得分和测试总分两部分，那单项得分呢，我们是得，呃，单项得分呢，是我们的重要性级别乘以我们的结果评定，那实际上来说就是我们的题目的分值乘以我们最终的得分比例，那在测试总分方面呢，我们采用的是加权计分法来进行评定的，来会求我们最终的总成绩，那最终的总成绩是1000分，采用的公式如下。S等于西格玛乘以PI乘以VI乘以BI除以西格玛乘以PI乘以VI乘以我们的1000，那S对应我们的是总分，N代表我们的测试项总数，P代表我们的重要性全值，V代表我们的能力分值，那B代表我们整体的能力具备的情况。

那接下来呢，就是我们的第三部分，在我们选定数据库之后呢，那我们也会针对我们的建设，制定我们整体的建设规划和建设方案，那对于建设策略方面呢，我们的对于存量系统来说呢，我们要制定自顶向下的嗯规划，那针对我们的存量系统，我们要按照我们的业务啊，以及科技的发展来制定整体的改造计划，来推动完成我们的信创改造。那对于新增类的系统呢，那我们明确的要求新增的系统需要优先的满足国产化的适配需求，那对不满足国产化适配需求的，嗯，系统呢，我们要实施准入的控制策略，我们需要由我们的高层领导进行审批。那同样呢，我们存量的产品呢，我们是会在其产品的生命周期。

当时我们进行替换，并且呢，我们要默认的选择信创类的产品。那对于新增的产品呢，我们首选国产化呢，一定要成为常态，当我们选择非国产化的产品的时候呢，我们也是需要由领导来进行批准的。那对于整体的建设规划呢，我们也是分成了四个阶段，那第一个阶段的话是我们的选型实践阶段，那主要是针对我们的业务需求，我们要梳理我们相关的需求以及数据库的功能需求，我们进行整体的数据库选型。那第二个阶段呢，我们是要进行我们总体的设计以及我们的开发适配阶段，那这一阶段呢，我们主要是做我们一些应用和我们数据库的兼容适配，那包括我们要同时进行我们的功能测试、业务测试、高可用测试等等，以及压力测试等等，我们同时要进行多轮的验证，来保证我们在本阶段的适配可用性。

那第三阶段呢，主要就是我们的投产和我们经验积累的阶段，那这一步这一阶段呢，我们主要是选取我们第一次第一批次的业务模块进行投产，那与此同时呢，我们也要对我们的高可用啊，故障切换等能力进行我们的实践和验证，那同时呢，我们要在建设中呢，去积累我们相关的经验，将我们经验进行梳理归档。那第四阶段呢，就是我们持续迭代建设阶段，那基于我们前期的经验，我们还有积累的知识，我们的知识库，以及我们建设方案，我们持续的进行我们后续的系统的迭代升级。那对于我们国产数据库的建设呢，我们也是与TT来共同制定了三方面的，呃，储备计划，那第一个是我的专业培训，那我们要进行t t circle的运维交付专家工程师的培训，那同时呢，我们行内的技术人员呢，也要进行相关的认证。那第二部分呢，就是我们的实操练习，我们会准备专业的操作环境，那秦皇岛银行这边会成立我们相关的技术小组，那同时呢，也是由我们T的相关人员来共同嗯，指导我们进行产品的安装啊，配置啊，运维啊，调优啊的相关练习，来夯实我们对于国产数据库的掌控能力。

那第三部分呢，就是我们的人员支持，那无论是业务系统呢，还是我们的数据库系统呢，我们会在我们建设的全周期，我们的所有的相关的厂商人员会对我们进行相关的技术支持。那经过以上的三种方式呢，我们也是要完成我们的技术积累，以及我们的人才储备，以及我们实施经验积累，来确保我们分布式数据库的知识可以进行有效的转移和落地的应用，同时呢，也积累和储备相关的信创的项目经验的人才。那接下来呢，就是我的最后一部分，那就是关于信创呢，我们未来国产化建设的一点的思考和建议。

那第一点建议呢，就是更多的测试，那对于分布式数据库呢，我们在金融行业的应用实际上目前仍然处在一个快速发展和快速迭代的阶段，那我们呢，为了保证我们的安全性，我们需要我们通过我们覆盖全业务场景的测试以及压力测试来进行我们的验证，来保证我们业务的安全可靠。那第二点呢，就是更高的要求，那对于分布式数据库的使用呢，那对我们的技术团队也是提出了更高的要求，技术人员呢，也必须要掌握我们分布式数据库与传统的集中式数据库的差异，还有差别。那开发人员呢，要严格的遵守分布式数据库的开发限制规范，严禁编写不合格的SQL语句，那这一部分如果说胡乱的编写分库语句将会产生比较大的影响，那对于运维人员来说呢，我们要严格的按照我们分布式数据库运维的管理标准来建立配套的运维服务管理机制。那第三点呢，就是更多的投入。

那数据库的安全可控呢？是一个复杂的生态建设工程，工程并不仅仅是一次商业采购的产品替换，那在整个的实施过程中呢？我们要下定更大的决心，投入更多的力量和资源，在应用的集成、性能的测试、运维的支撑等方面，才能把这项工作做得更好。那第二点建议呢，就是我们可以考虑引入赛马街制，那就是引入不同的产品，多线来共同的发展。那最后一点呢，想说的就是更加的坚定，那我们在做，呃，国产化这条呢，我们可能会选错数据库，但是国产化的道路是不会走错的，我们需要在不断的纠偏的过程中来不断完善我们的方案，为未来不断积累我们的经验和人才。那最后一点想说的就是早做是成绩，那晚做是问题。那以上呢，就是我关于秦皇岛银行在国产数据库选型和实践的方面的一些简单的分享，那也是非常各位感谢各位专家老师的聆听啊，谢谢大家好，非常感谢来自秦皇岛银行的进营先生的分享，还有我们带来的是交易性分布式扩数据库在银行核心系统的应务事件，谢谢。

那么下面这个环节呢，我们有请银河证券信创项目负责人刘海伟先生为我们分享西证券行业信创数据库的探索，有请刘海伟先生。很荣幸能够受邀在此和大家分享一下银河证券在信创数据库选型和国产化建设的一些心得体会。嗯，目前证券行业的大部证券行业应用呢，大部分选取的是集中式数据库，是典型的ARP在线交易型业务，具有低延时、高可靠、数据丢失等硬性要求。至于国产化建设过程中到底是选择集中式数据库还是分布式数据库，我相信这个问题到现在依然是一个选择难题。

集中式和分布式这块都各有千秋，需要结合具体做的业务系统和未来远期的建设方案来进行规划。数据这一块呢，它目前是不支横向扩容，性能和容量取决于物理硬件上分布数据可以向扩容，但是这个给应运维和应用系统开发以及技术人员带来一定的挑战。那国产服务器的性能呢？目前是普遍弱于国外服务器的，那采取分布式的架构也许可以弥补一部分性能上的一个劣势。嗯，除了数据库到底是选择集中式还是分布式之外。那么我们国内的数据库呢？现在是处于一个百花齐放的状态，如何选择一个良好、长期稳定的数据厂家？进行合作。我们分别从知识产权技术线前移无忧。追根溯源、业务保障、人才培养等全方面进行考察。

由于证券系统这个系统特别多，业务形态呢也是各有所长，结合上述的多因素应用，我们应用系统对TDB、达梦、base等国产数据库做了适配，这个图里面呢，就是列举了国产数据库一些典型的国产数据库与国外数据库的一些技术上的一些。差一些，对比吧。嗯，结合部分系统的这个数据库的适配和使用情况，我们在资金中台接网关OT cotc系统在国产化适配过程中选用了TC。除了TCL本身的一些技术优势之外，我们还看中了其他方面。比如像数据库的。自制运营管理平台扁鹊。这个它可以协助DBA进行诊断，优化数据库性能问题。还有像自动化运维度平台，它可以提供T的全部运维管理功能。

因为后续国产数据库呢，肯定是一个集群的一个批量的一个处理，如何有一个良好的运维管理功能和一个诊断，这个是一个比较，这是我们看的比较看重的一个特性指标之一。在这个赤兔管理平台上，可以有上百项数据库状态的一个监控指示，让数据库管理员在日常操作的90%以上的都可以通过这个界面图形化来进行完成，同时呢，也可以更方便的去排查一些定位一些问题。除了这两方面之外。由于国产化是对原有系统的一个数据迁移，对原有系统的一个适配改造，对原有系统的一个技术架构升级，所以在数据迁移方面我们也是依然是非常看重的，因为金融行业最重要的就是一个数据的一个完整性和一致性。那么，如何从国外？成熟的数据库当中，把成千上万，成千上万的数据，甚至是上T的数据迁移到国产数据库这块呢，摆在摆在我面前，是进行国产化适配的一个重要的一个障碍物，那T这边呢，提供了一个数据迁移的一个方案。

可以兼容主流数据库的一个数据迁移来从数据迁移评估到数到改造，数据正反向同步，一个平台可以搞定。呃，那我们现在针对我们现在是公司的一些创系统呢，是采取了是T呢，目前主要是有，比如像集中交易接网关这个图中蓝色的部分，集中交易网关呢，采取的是TD的一个分布式，一个集中式的一个部署，呃，数据库采取的是一两层的数据库架构，来保证业务的稳定和安全，为什么采取的是集中式呢？是因为集中交易接网关它主要是存储的是一些网关路由和一些一些路由策略，所以说它在未来几年的这个数据量级完全是可以用集中式就可以去搞定的。

那么一个项目呢，就是资金中，资金中台呢，主要是及客户数据。这个数据库是整合我客户在相关系统所有的资金管理功能。它主要是构建统一的服务客户资金的一个中台系统。未来将承载5000万的客户资金量。查询响应时间呢小于100毫秒，业务处理响应时间要求小于500毫秒，并逐步的完成两地三中性的一个部署。在证券行业当中。选择分布式，我们经过综合的考量和实践发现，如果数据量大于1T的话，那是不是可以跟开发商和和数据库厂商三方会诊来来进行项目分布式的一个可行性分析，并在系统在测试环境中进行全方位的一个数据迁移，验证到业务的一个连贯性。

嗯，通过做这些项目的一些来看的话，我们在信创系统的这个改造过程中啊，主要有这么几个难点，第一个呢，是产品的一个持续完善，因为国产化从2020年开始才算是一个产品落地逐渐开放的，或者是大家竞相竞争，大家提的一个。一个阶段，那么新创产品目前对标国外成熟的厂商产品呢，不管是从功能、性能还是稳定性上都是有一定差距，但是这个差距随着时间的推移呢，这个已经是逐渐的缩小。第二个呢，是说是信需要保障原有的功能和性能，需要有大量的工作，这个原除除了业务系统去保障原有的功能之外，那么我们还需要做大量的数据库调优。

应用的应用的功能拆解来保证原来的性能不会弱于。迁移之前的性能。这个呢，就需要不仅仅是需要从。公司。从公司本身自己。应到应用开发商，再到数据库厂商，这三方是一个紧密联合、互相配合、持续攻坚的。一个过程。那第三呢，就是保障业务的正常过渡。在证券行业。在证券行业当中，这个业务的连续性，数据的一致性是一个非常关键的一个地方。那么我们在业务在进行过渡的时候，一定要经过分的验证，充分的业务测试和长时间的一个业务验证，甚至在甚至是要配合交，甚至是在生产系统大量的进行通关测试。从各个方面，从不管是从业务上，从技术上，甚至从网络上。

包括其他的一些切换上来，反复的验证这个可行性，保证正常业务的正常正常迁移，保证核心系统。非信创迁移到信创这个呢，必然是一个复杂漫长的过程，而且这里面会带来很大的技术风险，所以说一定，所以说这一块呢，也是一个技术改造的一个非常难的一个点。当然在这个推进项目国产化的过程中呢，我们也积累了一定的数据库改造经验，可以简单的和大家分享一下啊，比如把因为集中，因为像集中交易这边，或者是其他的系统这边，很多的一些过程，很多的一些运算过程是依赖于存储存储过程的，那么。那么我们可以把这个存储过程。复杂的存储过程。把它分解为应用，承担一部分逻辑处理，那么还有另外就是简单的去简化这个思考，这样的话可以把复杂的存储过程拆解开，拆解开这样的话，等这样的话就可以高效的完成这个数据迁移，业务验证啊一些其他的一些一些事物。

除此之外呢，还有从把表字关联较多的改为表，减少表字关联查询。优化多层嵌套逻辑查询。如果采取的是分布式数据库，那么要合理的设计这个分字。比如说。从证券业来说，最主要的是一个客户号。那么把客户号。进行哈希，然后再取模，然后再进行，然后这样的话是不是可以去均匀的分布到几分片上。除了除此之外呢，是还要梳理的这个改造和业务系统之间的一个职责划分。呃，因为数据库，因为数据，国产数据库现在性能上，尤其是在处理一些复杂的存储过程中，或者是在数据量超过一定级别之后，它的性能较国外成熟的产品这一块呢，尚有差距，但是我们相信随着多方合作，一起去推动完善这个数据库之后是。

之外。那随着这个用的产品越来越多，分泌越来越广。这个国内国外的数据库差距一定会，差距之间呢，一定会越拉越小。所以最后呢，我们在总结一下我们当前在国产国产系统建设遇到的一些困难，挑战和风。呃，第一个呢，是主要是信创项目要尽早的开始，然后。在项目实施过程中呢，要按照it审计的这个标准进行项目过程管理。重点环节呢，一定要留痕。在功能测试，性能测试呢，要全面覆盖，并且测试一定要充分。

在推进国产化系统替代过程中呢，我们是不断的去积累相关的这个信创建设经验。在选型方面。在软硬件供应商方面，要充分考虑软厂商的自身的一个风险，包括使用这些开源产品的一些安全授权问题。除此之外，我们还要联合厂商在产品的性能、功能、稳定性。再进行全面证，如果有必要的话，我们甚至是可以委托第三方机构来进行这个。国产系统替代的一个功能性的一个稳定性，从各个环节来确保这个业务系统的连续性和稳定性。当然国产化替代完，国产化替代过程中增加了很多一些第三方组件，或者是或者是厂商提供的一些运维管理工具，那么在这个过程中呢，系统运维的压力比较大，因为它是要双线作战，在原系，在原系统没有下线之前，它要并行运行多套系统，甚至是双轨运行。

那么所以在这方面系统的运维压力也比较大，要及时的储备相关的一些运维人才，信创DBA人才，包括项目管理人才，软硬件相关的都要做一个及时的储备，及时的储备。为后续信创系统建设积累工作经验。嗯，感谢大家，我今天的分享就到这儿。好的，非常感谢银河证券的刘海伟先生为我们分享了信创数据库在证券行业的探索与实践，谢谢。那么下面我们有请阳光保险集团数据库团队负责人车东兴先生为我们分享保险行业国产数据库应用实践，有请车东西先生。我来做阳光保险啊，是车东兴。下面呢，就我们这个。一个OA系统啊，在这个去年做的这个。

国产化数据库替换的这个整个项目。跟各位做一个汇报和分享。那么去年实际上我们是在。年初的时候，也也就前年年底啊，完成这个这个项目整个的这个。工作。因为这是我们。在我们公司内的第一批的这个国产国产化的替换的事儿啊，然后它涉及到的这个。方面比较多，从操作系统中间件数据库啊，整个全部都替换了。那历时大概半年的时间。然后我们也是布局的也也比较早。从一开始的这个国产化的和。现在的和之前的这个外部这个Oracle啊，然后咱们一起并用，到最后全部采用国产化的这个软硬件。

在二一年的这个年底。整个全部完成了。那这里边的话，呃，涉及到的这个。我们开发团队的小伙伴啊，这个也付出不少努力，还有我们这个。T，这个厂家。一起共同协作，把这事做成了这个。中间过程还是比较艰辛的。然后下面我主要说说这个我们在这个项目过程当中啊，呃，相关的这个T这块方面的一些考量啊，和我们的一些这个经验吧啊。嗯，首先呢，我说说这个T这个数据库。这个数据库的话，我相信嗯，大家也都有有一定的了解啊，那它那个腾讯接口比较好，因为它是基于这个，那我们用这个版本啊，是这个TPG版，那PG版是基于这个po circle。那首先这个PG本身，它对奥的这个语法接种就。

很好。那和相对比于我们这个目前市面上的一些云原生的啊，这些数据库可能将性更好一点，尤其是对我们现在。这个项目当中这个系统啊，就是就是这个OA系统，那我们用的是一套比较老的系统，大概是有了呃七八年以前的一套系统。因为是采购的这个第三方的系统有一些这个嗯。商用的这个这个模块啊，我们。没有云代码啊，在我们迁移过程当中，嗯，碰到的绝大部分问题都是因为这个问题造成造成的，还好在我们这个开发人员使用的比较长了啊，有也基于这个系统做一些二次开发，有一定的了解。那后续的话，经过我们一一系列的调整啊，那规避了一些这个这个问题。啊，那由于这个这个源代码的不开放，那就造成这个我们在替换这个数据库的时候啊，需要选一款对Oracle这个语法高度兼容的这么一个数据库才能够完成这个。

地方工作啊。那么经过我们。分别测试了几款这个集中式数据库和分布式数据库之后。最后选择了这个我们的TTQ的这个PG版。并且成功上线了啊。那审过程当中啊。我们这个发现这个。数据库的这个。分布式，分布式这个事物啊和这个。呃，安全级别啊，完全满足我们这个日常使用和这个监管要求。另外的话，他有这个双引擎啊，所谓双引擎就是我们这个AP和TP的事物都可在这跑，然后他有目前据据我这个了解啊，而且我们也也进行过测试啊，有它有两个这个优化器的一个选择，一个是TP的优化器，一个是AP优化器选择啊。

然后呢，呃，目前我们正在做的一个一个一个事儿，就是对这个我们使用的这个。这套OA的系统的数据库进行扩展。打算做一个在备项目啊，目前看的话，我测试阶段还比较顺利啊，而且相对来说可能还比较灵活。那至于这个。在这个监控啊，备份啊，这些这这些管理方面来看的话，这个页面也也比较友好啊，那个在这个我们出现问题的时候。从从这个页面上都能看到啊，能够发起报警，而且处理一般一般的问题在页面上都可以通过这个。呃，集成功能进行。进行处理啊。那下面说说我们这个具体的迁移情况啊，迁移情况的话，大家可以看到片子上啊，这个数据类型函数啊。

以及存储过程啊一些包。这些在我们迁移的过程当中都碰到过，也就是我们的原系统当中啊，会使到会使用的这个存储过程啊，这些函数啊，有一些这个过程的语言，包括数据类型啊，我们在使用过程中一些常见数据类型啊，包括这里面写到的这个二进制啊，B涝吧，C涝吧，这些都有啊嗯。具体的迁移，迁移过程过程当中啊，都没有什么报错啊。那有一些在我们这个迁移成功啊，在使用使用的时候有些问题啊，后边我我们也都解决了，而且后边片子呢啊，大家可能会看到。下面说说我们这个关键点啊。这个我们公司这个OA系统啊。是你八年多了啊，是八年多了，然后在原有的这个EEK p2的这个。代码之上啊，我们进行了很多的这个这个二次开发。

加了我们自己后续的一些功能啊。基本上我们的研发人员对这个EK这个。整个的OA系统啊。非常熟练的啊，这也为我们这次这个迁移啊，能够顺利的完成啊，奠定了一个基础啊，那我们迁移过程当中啊。主要了碰到了这么几个问题啊。第一个是。在目前啊，在这个我们使用的这个集中数据库。这个时候那个我们数据库的服务器。CPU使用率就很高。因为原来使用的是这个两节点的一套这个集群。啊，也是口地区。那么两个节点呢？在高峰时段。一个在使用率的一个CPU使用率在60%啊，另外一个CPU的使用率达到30%。那可想而知啊。在。

迁移迁移迁移到了我们国产数据库之后啊。肯定也会面临一样的问题啊，就是CPU率会高啊。这样我们在测试这个。集中式数据库的时候啊，就是国产化的集中数据库啊。果然啊，就碰到这个问题了。疾病使用率非常高。因为我们这个公司的OA啊，是集中集中集中式的，就所有的这个办公人员，所有的人员都在以。一套这个OA系统的办公啊，不像有些公司可能分省分分区域。那就造成这个问题。另外一个问题呢，是这个在我们使这个T的时候。那个有些这个大表。在这个。我们查询的时候啊，因为会会写到这个哦，啊这个这个关键字。那发现它这个效率比较低啊。那在并发量大的时候啊，就是业务高峰的时候。出现性能瓶颈啊，导致这个业务系统响应缓慢，这是第二个问题，另外一个问题呢。

嗯，我们的OA系统啊，因为以前那个使用的这个Oracle集群的时候，采用的是这个直连的方式啊。然后这个在这个上线之后啊，上线呃，上线我们这个TQ这个PC版之后啊，在这个我们预生产的时候啊。就发现在高峰时段啊。会出现性的问题。那么下面针对我们这几个问题啊。我们怎么解决的啊？那个为了满足OA系统啊，这个性能要求。那个我们就放弃了这个原来的这个集中式数据库啊，就是我们国产的啊集中式数据库。想找一款分布式数据库啊，那在我们经过这个一系列的这个比例选项之后啊，嗯，觉得这个TDSQL这个PG版啊，适配度比较高啊。而且这个。

相对来说性能好啊，然后。经过测试啊，上线之后，我们这个这个也确实啊，我们这个因为这个系统它有一些自动的更新这个数据表结构的这么一些这个。功能啊，发现这个效率提升到50%了啊。同时这个相对于原来的这个数据库架构啊，新的这个TPG上线之后，扩展性明显会比我们以前的这个呃。入口集群啊，要好很多。第二点是这个我们对这个现有的系统啊进行优化啊，就是这主要针对上边我们的这个这个性能问题啊，这个奥的那个性能问题。重新改口啊，把奥改成UN解决这个。病房大的时候这个瓶颈问题。第三个是我们这个直连啊。

然后这个那天也是。呃，搞了好晚啊，解决这个问题。把我们这个在这个原来的EKP12这个OA系统的这个后后台啊，找到它的那个这个连接池啊。啊，不是找到找到连数据库这个方式啊，然后把它这个连连这个连接方式啊，改成连接池啊。另外一个方式啊，另外一个就是针对我们这个高峰时压力大的一个情况啊，我们有一些这个模块，呃，为了安全起见啊，把它做了这个这个这个隔离啊，如果发现情况之后，我们可以可以切换啊。那下面这张这张图是我们现在的这个。系统的一个数据库架构图。没看到我们是。一组一倍啊，就是数据呢，是一组一倍。然后，呃。

CNCN也是一组预备啊，CN是我们这个这个协调节点，然后然后我们这个GCM啊，也是三台主机啊，上面也是挑选两台啊，做了个主备配置，另外那个三台主机上呢，每一台都部署了我们的这个管控的这个服务。然后我说一下这个架构啊，这个架构的话，我们是这个首先啊，这个我们是物理机啊，采用的是全过程化的物理机啊。啊，操作系统呢，也是这个公众号操作系统啊，加上我们这个现在这个。呃，这个TSQ这个数据库啊，那就是整套全是国产化啊，那么我们部署的这这三台机器啊，呃，是部署在同一个机房。然后呢，呃，各个各个组件啊，就是刚才提到的这个CNDNGTM，以及这个管控系统，各个组件都是这个高可用的配置。

然后我们配置的这个数据节点啊，那其他的还都好说啊，都是一些无状态的，那我们这个。这个数据节点啊，是这个同步复制的，这么相同步复制的这么这么这么一个这么一个配置方式啊，出现问题的时候会这个自动切换。然后那个oss呢，这个就也就是管控节点啊，在这个我们三个主机上都配置了啊，那如果有任何的一台出问题啊，剩下的两台能够。保障集群能够正常的对外提供服务。那么。这张片子啊，就是我们正在做的一这个事儿了啊，目前我们正在做的就是这个。对，现有的这个这套这套TT配G版啊做这个备。看到左边这半，这半边图是我们，嗯。原来的这个数据库的这个架构，可以看到下边这个这个管控节点啊，以及嗯，右边的这个这个新出新多少这部分啊是有改变的。

可以看到我们这个。在原来的这个。数据节点和CN啊，啊数据节点就是DN啊，就是CNDN在原来的这个，呃。一主一备的基础之上啊。那在我们的备机房呢啊，有添置了两两台物理机。那么两台物理机啊，就部署了这个，呃，一个CN的被节点，另外把三个DN的这个配节点啊，又都部部署了一套啊最后呃，造成的结果就是我们这个数据节点啊，会变成一组两倍啊一组两倍。啊CN呢，然后我们为了这个节省资源啊，就在这个不节点啊，就部署了一个这样。如果出现紧急切换的情况啊，那个被节点呃，被机房啊也有这个啊CN啊可以可以使用。

那那我们看到这个管控节点啊，我们也在这个备机房啊，也也也布了一个啊，如果真的出现紧急情况切换的时候，那么通过备机房的这一个管控节点啊，我们也可以重新重新搭建这个管控的集群。啊。那么我们配置这个这个主备切换啊，就是呃，在当主机房不可用的时候，要启用这个备机房，紧急的紧急情况下是呃和这个同机房切换是不一样的了啊，同机房我们配置的是这个这个同步复制，然后自动切换啊，那备机房我们配置的是这个手动切换。手动切换，这也也说我们需要我们这个DB人员接入啊，才能这个。完成切换动作。大家好啊，那我我的这个分享就到这。非常感谢来自阳光保险的车东先生为我们分享了国产数据库在保险行业的应用时间，谢谢。那么下面我们有请。腾讯数据库总经理王毅成先生为我们带来金融级分布式数据库解决方案与技术前瞻，有请王毅成先生，呃，各位先生的朋友大家下午好呃，首先非常感谢前面几位嘉宾啊，然后包括我们的客户使用T售后的这些呃过程啊，包括做了一些相应的分享，但今天呢，我代表腾讯数据库团队呢，然后也给各位分享一下，就是我们的整个金融级的分布数据库解决方案，首先做个自我介绍，我来自腾讯云数据库团队啊，目前在腾讯云数据库团队负责整个关系型数据库的啊，产品设计研发啊，包括售前售中后POC啊，相关整体工作的技术管理的工作啊，然后呃，今天呢，我的分享大概会分为以下四个部分啊，然后从分别来给各位做一个呃，我们自己的一个理解吧，首先来给大家介绍一下腾讯云数据库的整体的一个解决方案，其实腾讯云整个呃，在云上提供服务呢，是从零九年开始啊，整个腾讯云数据库就跟着腾讯。

去一起来为用户提供了整体的这个呃数据库解决方案，目前经过了十年的发展呢，其实我们已经演变了将近29款呃数据库的产品啊，那今天我我罗列了四类啊，主要我们的一些重点或者明星的产品啊，首先在我们这个关系型数据库的大类上，我们有这种MYCQL、买瑞、DB、搜PD啊这样的一些，这个我们可以理解为叫托管类的云上的云数据库啊，还有一些非关性的数据库，比如现在用的比较多的red啊，Mango啊，Cash t卡plus t卡plus啊，包括CB啊这种都是在公上卖比较多的这种云数据库，然后我们现在其实在今天金融行业也好，政行业也好，我们推的比较多的这种国产分布式数据库，包括我们之前啊，很多嘉宾在分享的像T的啊，买S版本啊，包括像阳光老师讲的TP版本，包括我们的杠A的分析，以及在TSO-C啊，这种这种我们的自研的分布式数据库系列啊，现在目前有四款这种明星的产品，另外在这个数据库的。

Saras类啊，就是在数据库之上，我们构建了一些客户使用起来相对比较便捷的一些相应的SS类的服务啊，包括我们的数据库迁移的工具啊，数据库的智能管家工具啊，DB还有这种管的平台啊，以及可视化的云图啊，红色部分可能就今天我们在政企跟金融行业的这种呃，使用比较多，或者说独立部署比较多的这几款明星的产品啊，这个是整个数据库的前站的这个呃解决方案，那今天呢，其实刚才几位嘉宾都分享了，就是呃利用使用了TSO购啊，在构建了呃行里的一些相应的一些应用啊，核心系统也好，或者说这种新创系统也好，都用了很多，那其实我在这一页上也分享一下整个腾讯云的国产T的一个发展的历程，那整个我们的这个TSO的团队呢，是在零二年团队成立啊，那其实成立团队的初衷呢，其实当时是腾讯的自有业务的发展，包括财付通业务，包括后续的这种广告业务啊，包括现在的我们像腾讯音乐啊，腾讯视频啊，以及像腾讯会议。

啊，其实这种底层的这个这个数据库系统啊，都是我们这个团队，包括我们开发的产品来去做支撑的，那逐步的我们的第一个转折点呢，其实是开始我们做这个，呃，T搜口开始走向线下啊，然后支持了中国的第一个互联网银行啊，然后整个微众银行的扣bank啊，或者现在所有的核心业务系统都是基于T搜口来去搭载的这种线上银行的一个一个一个一个核心的系统，那后呢，下一个转折点其实在一八年，其实1514年的时候呢，其实微众银行呢，更多是呃，这种偏互联网类的银行，那我们真正开始走到传统行业，或者走到传统银行的Co bank呢，其实是张家港银行啊，我们当时是在一七年的时候开始做相应的接触，也历经了POC，然后系统测试啊，暴力测试啊，相应的选型的这种呃，这种这种PK，那最终呢，我们在一八年呢，是帮助张家港银行啊，顺利的把扣业务系统构建在之上啊，当时替换了，那我们在下一个其实重大的转折点。

在2020年，其实我们在走到了真正的大型的股份制银行，我们替了这个中国第一个这种DB two的主机，DB two的主机下移，那平安的信用卡核心是构建了，这个构建在了T之上啊，然后实现了我觉得是在整个中国的国产数据库发展史上一个比较重要的一个里程碑，那我们觉得下一个爆发期呢，其实在2021年开始啊，也就是疫情之后的这个这段时间啊，包括整个政策的推动，那我们其实截止到现在呢，其实我们在整个的国有大行啊，然后包括我们重要的股份制银行，还有一些核心的这种，呃，这个这个这个呃，农信社呀，然后这个城商行啊，包括保险公司啊，其实都做了大型的这种这种核心系统，或者新上系统的突破啊，这个也是我们简要的一个，呃，腾讯数据库啊，TS的这个啊，这几年的一个发展的情况，那为什么，嗯，为什么有这么多的客户啊，会在这种独立部署的模式上选择了这个T测库呢？我觉得政策推动的是一个，或者说今天信创的一个替换。

是一个比较大的这个这个这个推动，那核心商还是我们来看到今天金融也好，保险也好，其实也是存在了一个整个呃这个呃这个核心替换，或者说应用系统替换的一个一个契机，那两个契机可能发展迈射到了一起，也是今天整个电信跟金融也是在整个数据库替换，或者说新酬行业的替换也走的最快的两个行业，那客户为什么在这么多的国产数据库中选择TSO后呢？啊，我们觉得呃产品优势是有几点，第一点呢，其实还是在我们的这个呃融合策略上啊，其实第一点融合呢，我们觉得还是要想让客户可以便捷的使用呢，还是要去兼容我们的业内的通用的协议啊，那我们现在提供的这些产品呢，其实能够完美的去做my circle的兼容啊，包括post gray的兼容，那我们也在坚定不移的或者持续的来去做啊。

帮助客户做欧货的替换，我们在欧兼容性上啊，也是基于霹雳的版本啊，霹雳这个这个版本已经做到了一个90%的一个兼容度啊，那可能在特定行业我们能做到98%，那这个可能也要再看啊，客户对于欧po的重载业务的一个使用情况，那另外一种融合的模式呢，其实我们也是要提供多种的产品形态的交互方式，那今天呢，腾讯在整个数据库呢，提供公有云的部署模式，那客户可以用相对比较好的少的资源，或者利用便捷的这个弹性资源选择公有云部署，那也有一些大型客户呢，要要要将整个腾讯的公有云全部搬到自己的机房去，那我们也可以支持这种大型的私有云的建设，就是把腾讯的计算网络，数据库，存储、安全几大件产品全部一站式的啊，搬到客户的那个那个私有的机房，那可能在一些大型的这个这个金融机构啊，会选择这种模式来去部署，那同时呢，今天我们用推广的最多的可能还是这种纯软件的独立部署啊，那客户客户的选择就是我一个数据库的替换，那我们也可以。

从T会变成一个软件啊，独立的部署到客户的自己的机房，自己的啊硬件啊，自己的操作系统之上，我们也支持多种现在业内主流的操作系统和芯片，那同时可能还会有一些用户呢，他会觉得我买一个数据库，我不想针对一个数据库，又去接触balance的厂商，又去接触数据的厂商，还要去找操作系统跟跟硬件不同的厂商，那我们在一些呃小型的银行或者中型的银行，我们也会推动了呃，推进了几个数据库一体机的采购啊，那就客户选用一个整体的机柜啊，我们将TSOHO构建在ten森的OS之上，然后再加上整个的这个，呃，这个这个这个国产的硬件，或者说这种英特尔的硬件之上，为用户构建一个整体一体的方案，那其实这也是一种多种的融合方式，然后呃，驱动很多用户选择TSO的原因，那另外呢，就是还是产品还要自身应就是本身啊，作为一个数据库的通用的产品能力啊，我们一直在这六点上持续不移的来去做相应的产品跟技术的开发啊，首先要保证。

这种数据的强制性，要确保多副本的架构下啊来去保持这种数据错乱啊，那个那个避免的集群的数据错乱，保持数据的强一致，另外我们提供两地三中心跟啊3D5中心的这种金融级别的高可用啊，最低能够保证用户五和九的一个高口的方案，那目前在这种大型的呃。

大型的工业银行中啊，其实这种两地三证方案也得到了一个广泛的一个验证啊，包括这种这个上线的这个体验，那另外呢，在这个架构的开放性上啊，我们在买思接口啊，包括PD接口上能做到一个完美的兼容，那整个分布式数据库客户的考量，还是说今天在整个大的薪酬背景下，其实我们的硬件的发展还是很难。短期内追上这种传统啊，国外厂商的这个硬件的这种小机跟大机的发展的，那利用叉八六或者利用R的这种单机的能力啊，来去提供一个整体数据库性能不低于Oracle跟DB two的这个点呢，也是至关关键的，所以TQ一直在这种线性水平扩展上啊，持续了投入很多的研发跟产品设计的能力，来保证我们平滑的这个数据的线性水平扩展跟缩拢。那第二那后边呢，就是这个企业的安全性，不管是在公务云跟私有化部署啊，其实对对于整个的这个企业安全性也是非常至关供应至关重要的，我们提供这种事前事中事后啊，针对啊不同的这种安全策略来去保证这个数据库的这个这个数据安全，那最后呢，其实呃，由于这个这个国产化的替换的这个过程中呢，其实啊，我们利用分布式数据库啊，其实这种这种数据的节点多了啊，或者说管理的资源多了，那这个数据库的便捷的运维也是至关不重要的啊，所以我们在这种智能化的这个运维的扁鹊呀，包括自动化的运维工具上啊，也是持时的来去投入相应的资源啊，这个也是我们主打的这个产品特点，那下面几页我们来来去给大家分享一下，就是产品的架构，刚才说这个以及这六点中的一些，呃，明星的这个这个模块，首先这个是整个T的产品架构啊，底层是我们可以支持物理机，虚拟机的部署啊，然后在上层来去构建啊，No，就是单，就是这单的节点我们也可以提供。

分布式的集群，然后在上层的存算分离之后，我们提供这种计算节点，现在支持TP的引擎跟AP的引擎来去在两种不同的这个呃，数据的压力负载情况下，来去做相应的分流，那在上层呢，就是我们那种吃醋的运营管理平台来帮助DBA做日常的这种操作啊，然后还有这种扁鹊的DBA的分析平台啊，包括高口音的分析啊，性能分析啊思分析来去助力啊DBA来去优化相应的这个数据库的部署，那在呃在这个整体的部署架构之这之外，这这这边缘呢，就是有相应的调度系统啊，包括备份系统，来去为这个数据库的本身的pass能力来提供保证。另外呢，就是我们对外来去暴露相应的服务模块啊，客户也可以通用，通过open派的方式来去做相应构建自己跟自己内部系统啊，来去做相应的对接啊，包括审计啊，迁移校验，订阅啊，来去跟内部的一些运维系统来去做相应的对接，那这个就是整体的一个呃，TSO的产品架构，那下面呢，就针对于我们两个呃，用户其实好评度非常高。

或者说对他们的运维过程中呢，非常重要的两个本身的模块啊，因为数据库这个东西呢，其实10%是在开发的引入，那90%还是在后续的运维，那提供这种运维的便捷性工具啊，是我们认为构建这款产品最重要的核心点，那其实这个赤柱呢，就是我们其实也是从啊之前团队成立时候在内部持续的去打磨啊，腾讯用集相应比较少的人力能够维护啊，这么大腾讯内部的集群也是靠赤住这样的一个管理系统，那这在这个管理系统之上呢，其实我们可以去做帮助DBA种白屏化的进行日常类的事务操作啊，包括创建实例啊，啊扩容啊，参数调整啊等等，都不用通过命令牌来去做操作啊，这个东西也是输出到线下，然后客户买用T息搜购之后就能做相应的操作，那另外他就故障类的这些事物啊，我们可以提供这种问题的整断啊，包括异常的监控的报警啊，日常的巡检啊，都是在这个啊附属的T搜的运维平台上啊，客户可以自己的D别页来去做相应的操作。

那在日常操作之外呢，其实呃，数据库很关键的一个点呢，就是怎么去解决这种啊，突然的卡顿，或者突然的性能性能下降，然后来去诊断相应的问题，到底是部署架构的问题，还是性能so后的问题，还是说这个这个建表索引的问题啊，基于这些点呢，其实腾讯的内部投入了大量的这个研发资源来去建立的这么一个自动化的这种智能分析平台啊，我们通过在底层去做SQ日志审计的抽取啊，包括DB系统的信息快照啊，还有历史监控库跟OS监控来去做相应的上层抽取，然后我们再用中下层这个相应的这个呃，提取相应的so后啊执行诊断啊，包括1NO DB本身内部的一些相应的数据来去做上层的抽据，跟整个的数据的聚合跟分析，最终能够提供四大板块给用户来去使用啊，包括这种啊性能的分析啊，来去提供这种热点表啊，大事物的分析，然后还有这种整体的可靠性分析，我们为用户可以每天产出体检报告啊，告诉这个表哪块不健康，哪个表应该修改，哪个表有。

磁索啊等等，然后另外还有一种相应的可用性分析，还有一些其他的这种数据分析，能够提供一个在用用户应用DBA的角度，能够更好的，呃，来去针对于T搜啊，现有的一些性能问题来去做相应的一个本身部署啊，或者说这个架构层面的一个优化，那下一部分就是我们来去讲一讲，就是我们做了这么多金融行业的客户啊，啊我们也想，呃，通过我们的角度来去理解，就金融行业啊，数据库现在的一个现状，首先呢，这个当前的金融行业的技术现状呢，我们觉得是只是两块吧，一个就是传统技术架构其实也是遇到瓶颈啊，我们觉得不光是整个政策的推动，那本身其实啊，这个这个其实摩尔定律呢，呃，这个这个这个它本身可能也是18个月这个性能才去增上一倍，那其实我们现在发现很多这个这个银行的系统呢，应用系统呢，其实它的这个这个这个业务的增长还是非常快啊，那包括现在摩尔经力也是逐渐失效的一个情况下呢，其实垂直扩展呢，可能也会存在。

一个相应的瓶颈，那其实就是以以以前啊，以国外大级主机和数据库为核心，这种集中式架构呢啊，在一定场景下已经无法满足大规模交易和处理的需求啊，另外呢，可能是价格也非常懊悔啊，导致这种维护成本居高不下，那其实新技术呢，会带来持续的，另外这个新技术会带来持续的这个科技创新啊，促使可能金融行业啊，这个这个技术上可能也要做一些变化，就是随着互联网的到来呢，可能手机银行啊，网上银行，包括互联网保险这类业务的业务增长期可能远远的超过了技术硬件的这个这个这这个这个成长的阶段啊，所以也是需要啊这个这个金融行业要向数字化啊，包括分布式来去转型啊，来去更快的是底层的技术系统，能够支持好业务前端的这个这个这个快速的成倍数的一个发展。

那目前技术的一个演进趋势呢，我们觉得过去至少在呃这个这个2021年之前啊，其实核心系统还是对国外厂商依赖度很高的啊，首先是在这个这个这个硬件上还是依赖于小机或者大级啊，然后软件呢，其实是在应用系统上可以做到自主研发啊，但是啊，然后会提供一些国外的这个这个厂商的基础支持跟资源啊，另外技术上呢，会就是技术架构跟硬件的耦合性会非常强啊，包括oraco和这个这个这个呃，小机跟大机的这个这个这个融合，包括一些DB two要跟大机一起绑定啊这类的，其实还是有一些技术架构和硬件的耦合性，那现在呢，其实整个的金融行业的趋势我们发现就是呃，硬件呢会逐渐的去云化啊，包括呃虚拟化跟国产化来去演进，那可能有一些大型的，呃，这个这个这个国有大行或者是保险公司已经开始啊购基于腾讯云也好，来去或者阿里也好，来去构建整个云化的系统啊，包括虚拟化啊，然后另外呢，就是软件这块区，就是呃利用开源软件来去部署一些应用，然后也去做相应的自主研发。

发啊，那在技术上呢，可能更加去看重整个的自主可控啊，数据库层面来去选用国产数据库的厂商来去提供国产数据库，然后大家加上层的微服务架构啊，这是我们看到金融行业的一个技术演进的趋势，那为什么呃，在这个这个这么几个趋势下呢，要选择国产数据库呢？啊，我觉得还是几点吧，一个是经营环境的变化，整体的降本增效啊，包括这个这个这个移动互联网的发展啊，软硬件的，软硬件的维护费用逐渐变高，那也实现了这种分布式的，整个应用的分布式，或者说数据库的分布式的转型，那业务上确实也存在创新啊，那数字化的转型呢，我们刚才说了会催生大量的业务创新，那这种业务创新的啊，可能增长的倍数啊，它可能远远超过呃，某尔定律这种18个月增长一倍的这种这种这种效应，那移动互联网也会带来这种海量的初击啊，包括未来的5G到底能够对应用产生什么样的一个变革，其实都是我们现阶段我们无法去去去去考量的啊，这还有一点呢，其实不得不提的就是今天整个的这个。

呃，信创的这个这个这个这个推动啊，整个保持呃基础基础软硬件的一个，呃核心的或设施设施的扩产化，那可能这是也是为什么现在呃大型的这个金融机构选择扩展分布式的原因，那选择数据库呢，我们认为呃厂商就是客户呢，应该要从几点来去考核考量吧，也是我们跟很多客户交流的点，那首先技术的考考量维度呢，就是我们要看客户会看业务迁移能力啊，你的数据啊是否能能否平化迁移，尽量少给应用的情况下把数据迁过来，那另外就是安全合规，首先要满足金金融的这种监管先监管的要求啊，然后实现这种数据库的，呃金融级别的这个这个安全啊，包括你的事前始中事后的这能能力，那第三点呢，其实很重，就是这是数据库的基本功啊，你的可靠性和可用性怎么保证，你的技术原理如何实现，那另外就是兼容性啊，就是在Oracle兼容性也好，或者TB two兼容性也好，能够做到什么程度啊，保证客户的应用尽量做少的这种开发成本的这个转移。那另外就是。

运营的风险，就刚才说的10%在开发啊，数据库90%是在运营啊，就到底你的故障的自动定位的能力怎么样，你的系统或者你的自动化工具会做成什么样的，那这个可能也是客户选择，呃，一家国产数据库厂商提供的产品的核心能力，那另外呢，可能考核厂商的这个角度，除了技术能力之外，可能要看厂商的这个综合能力，第一个就是产品层面啊，就是你的产品是没是有明确的演进方向啊，然后这种是不是啊满足业务销业务要求啊，包括新创的要求，那生态层面呢，就是整个这个公司的生态怎么样啊，数据库的啊啊啊那个周边的生态，包括SV的生态，服务的生态，软硬件的生态，产用产学的生态啊，是否这个产这个这个这个公司的产品是能够做到跟跟这个生态能够完美的结合，并不是孤立自己的发展，那技术层面呢，可能会看产品研发团队的规模，包括很重要的就是这个交付实施团队的规模，以及服务团队的规模，那另外可能我们现在看到越来越多客户会选择公有云。

在私有云一起用啊，就是呃，闽泰业务可能一部分会放在公有云上，因为它的这个呃，这个增长周期不太好预测啊，然后这个这个稳态业务可能在在在独立部署在私有云上去构建，那这个可能也是客户选择厂商的一个比较大的原因，那最后可能是在一些企业层面啊，包括股东结构啊，或者说这个这个做数据部的决心啊，包括企业整体的稳定性啊，和这个可持续性啊，这个也是我们针对于这个金融行业啊，这个这个这个技术现状的一个前线的思考，那另外一看就是我们介绍一下，就是核心系统下移，在最近做了这么多客户之后，我们的一个呃一个总结吧，其实我们觉得现在核心系统的下移呢。

主地下移或者说小地下移，其实有两个主流的技术架构，一个是用单元化的数据库核心架构，那我们其实也做了很多客户啊，包括微众啊，平安啊，还有很多大行的国产化，其实都是在做这种单元化的数据库架构，那上层是用这种这种分布式应用的角度来去处理，那还有一些这个这个银行，包括张家港啊，昆山啊，海峡啊这类银行呢，都是选择这种啊分布式数据库的架构，由分布式层面来去执行，执行分布式事务啊，其实这种两个不同的架构其实各有优劣性，后边我会简单再去介绍一下，那其实呢，就是我们看到可能现在目前大行或者说一些呃，这个这个研发能力相对呃呃储备比较比较比较丰富的一些大行或者股份制银行会选择这种，呃，这个单元化的架构啊，它会上层用全局路由来去定位，然后将数将应用来去分为多个库，或者说多个小的单元，然后再去做横向单元的扩展啊，最终再用一个T，再就是先用T的集中式，然后底层再用一个T分布式来去做整体的汇总，然后做相应的跑批啊，或者说日结啊，这个这个。

的这个相应的模式，那还有一类呢，就是呃，这个中小银行我们看到会用分布式加微服务架构更多，那在上层的微服务啊，会拆分出不同的业务模块啊，都包括我这张图上写的像库存的凭证啊，库存的现金，那底层会用一套分布式数据库，比如四个节点八个节点啊，然后来去支撑所有的这个这个这个他银行所支撑的业务啊，各有优劣性啊，另外呢，其实我们再讲一下这个这个这个典型的分布式的这个单业化架构啊，就这个我们画了一个简，首先呢，其实要做的底点就是数据的切分策略啊，或者按客户度分，或者说按这个这一定的维度来去分，然后来去部署单元的相应的划分，来去制定数据路由的策略啊，最终来去做数据库的这个部署，然后分布式事物呢，可能会用这种现在业内比较多的这种撒这种方式啊，来去在上层应用层面来去做这种分布式相应的事物啊。

然后底层在用这种，呃，可能要用这种易云多新的方式来去跑啊，或者说用英特尔和这个新创的环境来去同时并跑，那这个也是我们看到的这个架构，那下面这块呢，就是我们来再去讲解一下这个这个这个这个单元化架构跟微复架构再细拆分，那其实单元化架构现在也有两种，第一种呢，就是啊，上层的分布式事务啊，中间电实现这种三个这种方式，然后呢，底层它就一就是一个一个单元啊，单元之间呢，不涉及相应的这种分布式的事物，那还有一类呢，就是它也做了单元化拆分，但是有一类大的应用它还是要用分布式啊，那其实上层也用这种S来去做分布式协调，那底层也用到相应的分布式事物啊，就在这种大的应用下来去做分布式物拆分，那其实这个第二种呢，就跟呃，这个边上这种这种这种微服务架构呢，其实就有点相像，那我们可能看到一种就更纯粹的分布式使用分布式数据库的使用方式啊，就是微服务架构啊，用微服务来去拆分应用啊，拆到相对来说比较细，然后底层用一套分布的事物来去分布数据库来去实现那整个分布式，分布式是那个数据之间的这个调。

或者数据之间的这种事物呢，是完全由数据库层面来去提供这种呃，两阶段提交的方式来去实现分布式事务。那下边呢，就是最后呢，我再去跟大家分享一下，就是呃目前呃我们呃这个这个这个简单的几个例子吧，啊首先呢，就是这个是国有大行，我们在做这种信创的核心的数据库啊，当时这个信创的业务呢，选择相对来说比较重要的一个业务啊，我们是在呃这个这个构建了这种两地三中心的啊解决方案啊，数据主中心在上海啊，然后是用这种数据库的强通步的机制来去保证，然后背机呢，就用我们的内部的DCN的方式来去做异步同步到一地的灾备机房啊，实现一种两地三中心的方案，当时这套系统呢，其实也是频繁的来去做这种呃两地三中心的这种这种暴力的测试跟跟跟切换啊，其实也是完美的达到了这个业务的要求啊，所以这个呢，其实就是用t soco的这个部署在呃这个Linux之上啊，然后呢，这个这个这个用这种一云多新的方式并轨啊，然后来去一套跑在那个呃英特尔的这叉八六上啊，一套跑在新创之上，来去实现这种这个这个大这个新创相对核心的一个数据库的切换，那这个也是一个。

呃，比较典型的案例，那另外一块呢，这个也是某商业银行的一些，呃核心分布式啊加微服务的这个架构，就是他自己上层呢去做相应的这个呃微服务的拆分啊，按照这个公共微服务组啊，包括账户维护务组来去做微服务的拆分之后呢，然后上层的业务请求来去按比例进行负载的调优，调调流，那底层你看到数据库这个层面，其实它是呃这个这个每个主实力啊三个，这个我简要化了一个三个分片啊，其实它主备实力之间是可以跨，就两个主实力是在这个这个这个机数据中心一，一个主持力的数据中心二啊，其实也是做到了流量的一个相应的分配，那其实保证了这个三三分片的一个，呃，主备架构的一个一个一个分布式的架构。

这个就是，呃，在一个现在这个这个小型的中小型银行可能运用比较多的一个案例，那最后一个案例呢，就是。我们一个商业银行的核心系统啊，选择这种一体机的架构，那这个客户的考量呢，就是刚前面我说的，其实他不希望一个数据库的系统呢啊，针对数据库呢，要去找多家厂商来去做相应的这个啊问题排查跟解决啊，他就用腾讯的这种一体机的方案啊，全站的为客户来去解决这个点，那我们呢，其实就是将呃做了一个这个腾讯的机柜，然后再加上这个相应的这个这个存储节点啊，跟那个这个load balance，其实我们这块呢，提供在这个一体机之内啊，提供这种存储的节点，包括管控跟备份节点，以及这种万兆监换机来提供一个啊三个一体机来去构建它整个银行的这个核心系统的一个一个一个架构啊，目前也是实实实现了一种两地三中心的架构啊，用于这种新核心的一个投产。

所以以上呢就是啊，因为以上呢就是说啊，我们这么多，呃，这个这个这个实践啊，所以我觉得综合下来呢，呃，客户选择分布式数据库的这个综合的收益跟价值呢，首先就是降本增效啊，就是在硬件层面呢，采用叉八六服务器之后啊，可以取代大型机小型机，呃硬件成本呢，其实是可以做到之前的这个1/5啊，但是可能综合综合起来这个这个硬件变多之后呢，呃，可能会存在这个运维便捷性的一些相应的困难，但好在就是腾讯提供了像持醋跟扁鹊这样的一个运维平台，能够实现这种啊这个白平判的操作啊，就能在这个点上做一个相应的中和，那另外呢，性能呢，能够得到一个一个一个可以预期的一个提升啊，就是我们在发现啊，这个这个性能不能提验提升要求的时候，可以快速的采购叉八六，或者或者那个信创的机器能够做平化的扩投种啊，那第三点呢，就是可以实现这种同城双核的高可用啊，真正在数据库层面能够实现这种这种机房机房级别的这种灾难的故障啊，包括整个瑞盾级别的一个灾难故障能够做到一个。

灵活的一个相应的切换，能够保证业务的连续性，可以完美的支持这种大型银行系统的A级应用，或者或者是五级应用的一个支撑，所以以上呢，就是我对于腾讯数据库的一个呃，简要的一个一个概括性的分享啊，也该再次感谢啊各位线上的朋友们的倾听，谢谢大家。非常感谢来自腾讯数据库完成总经理为我们分享的TC数据库的整体方案与技术前瞻，谢谢。那么下面我们有请神州信息金融技术部总经理张进先生，为我们带来浅西银行核心业务国产改造方案，有请张静先生。今天也是很幸受那个腾讯的邀请，和大家就那个银行的核心业务的这种国产化改造做一个分享。那其实这个呃，作为一个从业这个这个一直在金融行业啊，尤其是在2020年开始，呃，深度的参与那个信创的这样的一个工作，尤其是金融信创，那我我认为就是说随着呃过去两年的，尤其是在银行金融信创的探索过程，那我们今天终于开始对银行的这个核心业务系统，也就是我们通常意义上所讲的存代购业务系统进行这种国产化的这样的一个改造或者是升级，那么从今天我跟大家分享的这个话题，主要分为三个内容，第一块呢，就是说对于目前的整体的金融行业在核心的这样的一个替代方面的一些要求和我们的一些理解，第二块呢，就是结合神州信息在过去20年在核心业务系统的这个经验，以及在最近三年我们深度参与金融信创，尤其是金融信创核心改造，我们提出了一些想法，最后一块跟大家也分享一下一些典型的一些案例。

那从政策要求的角度来讲的话，其实呃，核心业务系统的改造和原有的我们讲的一般业务系统，包括关键业务系统，包括OA业务系统的改造，其实还有非常大的一个差别，那从我们看到的就是说今年包括我们信创的一批用户，二批用户，三批用户，在进行核心业务系统的这样的一个新创改造的过程中，其实会发现，嗯，比过去我们的这个难度要大很多，大家都在讲IOE的三座大商嘛，就是IOE这三座，其实对于我们今天的核心业务系统改造都有非常大的难度，包括前面包括我们看到的一些大行的客户啊，包括一些这个城商行的客户，包括保险和呃，这个这个基金客户，其实证券客户，我们看到的就是说对于整体的核心业务系统替代讲的话，我们全会有三个层面，实际上是非常困难。

第一个层面就是说在基础软硬件方面，核心业务系统对于不管是国产的服务器，包括国产的操作系统，包括国产中心件和国产的数据库，在整个的稳定性和高性能方面都有了更高的要求，尤其是大量的银行原有的核心业务系统是构建在国外的小型机加上国外的操作系统，加上国外的存储乃至国外的数据库这样一个环境下，那大家怎么能够在今天放心的把我们的核心业务系统放到我们的整个的国产化的环境。第二块就是说从监管的要求来讲的话，就是说其实对于整个信创的这样的一个核心系统的改造，提出了不同的路径，这里面路径包括呃，生产环境、塞位环境和测试环境，那在呃，今年我们看到绝大部分的用户在2022年的时候开始针对核心业务系统的替代进行方案的规划设计，乃至在年底的时候要去上报整个的可实现的这样一个路径，那在2023年时候要初步实现在生产。

环境，栽培环境，并那个测试环境，三个环境中的一个环境，还有一点就是说在于整个的这个核心业务系统过程中，其实针对开源，针对第三方的组件要去做相关的这样的一些管理，因为核心业务系统它的业务等级非常高，而且它对于业务联系性的要求也非常高，那这个时候就是说在一些。核心业务过程中使用开源的这样的一些情况，如何去做有效的管理，甚至说要及时的去修复，在核心业务系统中是使用开源及第三方的一些相关的一些漏洞。

那第二块就是说，我们看到的就是说在整个的核心业务系统的这个替代过程中，我们也经常在讲所谓的单轨和所谓的这个双轨两种模式，但是我们看到的说，不管我们今天采用单轨和双轨的模式，那在整个的这个两种模式的改造下，其实都有非常多的一些难点和非常多的一个重点，那我认为其实有三块是值得大家更多的去关注的。第一块就是说在整个的核心业务系统的构建过程中，那我们一定会有一朵所谓的信创云平台，这个信创云平台是要做整个信创资源的聚合与复用，包括说后续的相关的组建的一些迁移和管理，以及说整个资源环境的运维和运营的这样一个管理。所以呢，这块来讲的话，就是说我们过去在党政信创，包括在做金融信创的一些OA系统的时候，其实不需要过多的去考虑云的一个环境，但是不管是物理服务器，甚至说一些裸金属，就能够呃更快速的去构建一个相对呃小短小精悍的这样的一个呃。

呃，信创的一个环境，第二块就是说我们再去谈整个的这个核心业务系统的时候，其实我们会谈到一个话题，就是说我们谈的我们的核心业务系统在未来一定是构建在一个分布式技术平台的基础上的这样的一个核心业务系统，那这个里面就是说我们其实一定要很重要的去把分布式技术平台引入到我们的信创的核心的这样的一个改造的过程中，这里面包括一些多活数据中心的一些需要，包括说这里面大量的这个服务的组件如何实现服务化，包括说对于核心业务系统里面的非常多的这样一些分布式事务的这样一些管理。第三块就是我们今天其实讨论的一个重点，就是说绝大部分今天金融行业的核心业务系统数据库其实都是构建在Oracle的，但是有一些这个大型金融机构，比如说用这个OS390的这样的一个大G用户，比如现在今天还是用DB two的环境，但是我们看到的就绝大部分金融的银行客户其实使用的是Oracle的这个数据库，那这里面来讲的话就是说，嗯，我们要根据这个数据库的这样一个类。

还行，根据它整个的这个核心改造的这样一个模式来去根据规模和需求合理的去选择集中式或分布式，但是今天我们看到的很多的金融用户都在去选择采用这种分布式啊，采用这种微服务啊，采用这种分布式数据库的方式来去做整个的这个数据库的这样一个改造和替换。第三块就是说数据库其实也是影响核心性能的这样一个重要的一个资源，就不是说我们买了很多的物理服务器，然后上面跑了很多的SSD的硬盘，然后有一些这个啊高端的这样的一些计算和存储的资源，就能够保障我们的核心性能的这样的一个快速稳定的运行，那这里面一个数据库的这样的一个选择和合理的配置调优，乃至说后面的这个运行维护都是影响核心性能的一个重要的这样一个。要素，那第二块跟大家去简单的分享一下，就是结合呃，2022年的这样的一些包括监管的要求，包括众多银行在自身发展的这样的一个考量，那神州信息作为一个已经拥有了20年核心业务系统的这样的一个建设的这样的一个呃厂商，那我们怎么去考虑如何将我们的软的能力和我们的硬的能力，也就是说我们核心系统的这个能力和我们的信创的这样的一个改造能力进行这种结合，那在最近的这个呃，三四个月里面，我也参与了多家这个银行，其实在针对核心业务系统改造的一些方案，那下面我跟大家做一下简要的一个介绍。

那我们可以看到前面也提到了，整个的信创改造，其实从目前的主流的这样的一个环境里面，其实啊是有三种场境，一种场景叫并行环境，第二种环境叫测试环境，第三种场境叫灾备环境，那这三种环境其实各有一定的优缺点，那我们可以看到，对于并行环境来讲的话，是说与现有的生产环境组成AB角，然后区分业务场景或采用双写的方式共同组成核心系统，那当然对于并行环境它是有一定的优势，有一定的劣势，它的优势呢就是说对于现有的这个生产其实没有什么一样的影响，但是它的劣势就是说它的投资和维护的成本其实相对比较高。

第二块来讲的话，也是我们看到最近很多客户呃，为了快速的能够推进核心信创的改造来选择的一个测试环境，那这里面就是说通过搭建信创的这样的一个核心的一个测试开发环境，然后新上的业务系统，经过新环境那验证以后再拆线，它的优点呢，就是投资比较小，不影响现有的政策，它的劣势呢，就是它毕竟还是一个测试环境，并没有把我们真正的生产啊去承载起来，所以它对于未来监管的一些进一步的要求，可能存在一些不确定性。第三块就是栽培环境，那我们看到的就是不改变我们现有的这个生产环境的前提下，我们构建信创的这样一个灾备的这样的一个核心的一个系统，能够实现对主中心的这个容灾，那那优点就是跟那个并行环境一样的，就是不影响现有的这个生产，缺点呢，就是说它的这个数据同步的r po r po需要做仔细的考量，可能这里面对于很多的技术实现来讲，数据库的，尤其是数据库的同步来讲的话，可能会有一定的这样的一些技术上的难点，或者会存在一定的这个风险，那但是我们觉得就是不管我们今天选择并行环境，还是选择测试环境，还是选择栽培环境，那相关的这个。

整个的架构的设计，以及相关的这个数据库的选型，都是我们后面要去关注的一个重点，那从整个的信创改造的这个最佳实践呢，也可以看到，就是说我们其实结合这个过去啊，包括一般业务系统，包括关键业务系统这个选型，那我们实际上在终端，在服务器，在操作系统，在服务数据库，在这个分布式平台，在云平台方面，我们也积累了很多的一些经验呢，这里面其实也给大家看一些这个主流的相关的一些厂商呢，包括从这个啊服务器端目前在国内其实啊主要还是以鲲鹏和海关为主，在操作系统这一块来讲的话，麒麟在服务器端可能会使用的更多一点，在那个终端方面可能是同性会多一点，数据库方面，这个尤其是分布式数据库也是百花齐放的，就是包括啊TDSO口，还包括OB啊高斯，DB啊golden tab，各有优缺点，但是我觉得最终还是要结合刚才其实各位这个，呃，我们的这个那个专家分享的话，要结合他的这个实际情况，通过POC，通过这个整个的这个结合改造的一个验证。

及后面运维的这样一个掌握来去看，那当然这里面也有一些传统的这个集中式数据库啊，当然这里面有一块非常重要的点，就是我在讲核心业务系统的替代时候，这里面一定是引入了分布式的这样一个技术平台，这个分布式技术平台能够实现应用跟数据库之间的这样的一个。结合，能够更好的去构建一个面向未来的分布式和微服务的这样的一个核心业务系统，当然私有云这块也有很多的厂商呢，包括像腾讯呢，包括像华为啊，包括像阿里这样的一些主流厂商，所以呢，我们可以看到一个核心业务系统的信创改造，会涉及到从整个的从操作系统到服务器到数据库，到中间到分布式平台到云平台的完整的这个过程，这个核心业务系统的替代的时间可能长达三年，甚至长达五年的这样一个时间。

那从整个核心业务系统的替代的角度来讲，我们也把它分成五个层面，那第一个层面呢，就是我们的硬件层面，这里面包括这个我们讲的基础架构里面，不管是我们的呃，信创服务器，包括我们原有的这个叉八六服务器，我们的分布式存储，我们的集中式存储，我们的相关的信创网络和信创的安全设备，那这块构成我们的整个的基础架构的环境。第二块就是我们的统一技术平台，这里面包括我们的裸金属，我们的虚拟机，快存储，文件存储，相关的网络资源，相关的安全资源已经在被那往上的三层，其实就是我们的这个数据库服务的一层，这里面不管是我们构建的这样的一个分布式数据库的这样的一个整个的集群，包括我们去做异构这个数据同步的CDC的这样的一个环境，再往上就是我们提到的就是说我们的技术平台，这里面尤其是以分布式技术平台为架构的主导的这样的一个技术平台，这里面包括我们的业务处理的框架，包括我们的开发平台，尤其现在大家提的比较热的低代码开发平台，包括我们整个的核心业务系统的这样的一个运维监控平台。再往上就是我们的真正的。

核心业务系统的应用，那通常意义上我们理解的存在会，其实这里面主要会包括一些相互相应这个会计核算的一些模型呢，包括我们的产品的工厂呢，包括我们的查询的一些服务啊，包括我们的客户信息的相关内容，那通过我们对于这五层架构的逐步的按计划的这样的一些改造，包括这样一个升级，才能够真正完成我们核心业务系统的这样的一个替换工作。那从核心业务系统的这个新创改造里面，其实也有两个核心的，第一个核心就是说去欧，我们认为在目前的整个核心业务系统替代过程中是一个最大的一个难点，那我们如何选择合适的数据库能够替代现有的主流的阿的一个环境，那刚才刚才看到就是包括中行的客户啊，包括我们的秦皇岛银行的客户，其实包括其他的客户都给到我们一些非常有利的这样的一些启示。另外一块就是说我们可能要针对我们整个的这个核心数据库，要去进行他的拆表拆库的这样一个拆分，能够将相关的功能进行下移到我们的国产数据库环境，来完成我们信创改造的一个目标。

这里面前面正好跟呃，王总提到的也有一些这个结合啊，就是我们可以看到，确实在目前我们做过的大行，包括股份制银行和一些中小城商农信行，再去做核心数据库的这样的一个架构中，确实现在有两种不同的这样一个选择路线呢，那大行的这个客户更多的会采用这种单元化的方式来去进行它的核心数据库的这个构建，那中小行的客户呢，其实更多的会采用这种分布式和微服务的方式来去构建它的这样的一个核心数据库的这个构建，这里面其实嗯，我觉得各有优缺点呢，那比如说对于单元化的方式来讲的话，它的呃优点其实也非常的明显的，它的高效的扩容，它的灰复的发布，包括它的整个的数据库的这个应用无迁入是它的优点，但是它的缺点其实就是对于这个资源的这个利用率可能不是那么高，然后对于运维的自动化要求也比较高，然后应用层要做跨单元事务的这样一个分布分表，这对甲方本身科技条件，尤其是软件开发条件的要求会更高一点。

那对于采用分布式加微服务的方式来进行核心数据库的这个改造来讲的话，它的优点就是说它的服务的这个服务级的扩容是比较方便的，然后呢，数据库已经实现了这种分布式的这种事物应用相对更加简单，但是它的缺点就是可能在极端环境下，它可能故障的影响面稍微会大一点，然后呢，应用需要做一些这种相关的改造，设为这个分布式数据库，这里面也提到了，就是说包括神州信息在我们的这个上一个版本的这个核心业务系统里面，其实大量的会呃利用这个Oracle的这个这个，比如说一些呃存储过程来去做它的整个的呃核心数据库的一个加速，但是到了我们今天这个这个分布式环境里面，那我们可能要做一些对于核心业务系统的这个改造，来完成对于国产分布式数据库的这样的一些这个适配，那这里面其实在过去的两年里面，我们也是跟呃，腾讯这个TTSO狗做了大量的这样的一个适配，来满足我们的业务系统对于数据库的相相关的一些要求。

那这里面其实在这个呃，数据库的这个核心的这个拆库的时候，其实我们也给到一个最佳的一些实践呢，那从整个的这个业务系统里面的模块非常之多啊，那这里面我们可以看到就是说前面我们提到的这个各种各样的模块，那我们其实在整个的这个数据库拆分的时候，我们建议优先的可以拆分，包括像参数工厂，像数据管理，像会计核算，像产品工厂，像代中管理这样的一些业务模块，真正的账务的话，我觉得它的这个整个拆分的这个顺序可以稍微的往后一点，这样呢，也是为了更加有效的去验证和使用我们国产化的整个的这样的一个环境，这样的一个架构，来满足我们整个核心业务系统的相关的这样的一个要求。那针对数据库这一块儿的话，我还提一个这个点，也是供大家去参考，就是说那我们认为在核心系统的这个数据那个信号的改造过程中，关于数据库的这个安全管控，我觉得一定是我们在整个的这个呃，数据库的管理里面一个非常重要的一个点，这里面其实包括我们的整个的事前的管理，包括我们的事中的管理，包括我们的事后的管理，这里面其实包括我们的数据库的权限管理啊，包括数据库的开发安全规范呢，包括数据库的安全审计，一方面我觉得要结合腾讯的这个，刚才我们看到的这个赤兔啊，包括这个呃扁鹊啊来去做这个相关的这样的一些呃管理，另外一方面就是我觉得从金融机构的角度来讲的话，也是要建立一个非常完善的这样的一个流程和制度，这里面比如说我们的整个数据库的变更审批的一些授权，包括多种用户的这个限制的策略，包括说在中里面的危险的这个操作的阻断，包括实时报警，包括在事后的非应用端的操作审计和问题追溯我个人的一个认知是这样子的，就是说阿他的呃。

这个生态其实是非常完备的，我觉得有的时候我们客户在选择阿，不仅仅因为阿acle本身做得好，而是因为阿acle已经构建出一套非常完善的针对数据库的这样一个完整生态，这也是我们国内主流的这样一个数据库厂商再去呃不断努力，我们大家共同去追求的一个点，就是来形成整个面对数据库的这样一个完整的一个生态。

那这里面其实我们也是在这个最近的这个几个月里面，结合客户的一个实际的核心的这样的一个改造，我们其实有了一套完整的这样的一个核心，信创的这个改造方案，包括从现状的分析，包括从核心系统的需求的分析，包括从建设的方案，包括从运维的那个保障，包括从投资的概算这块来讲的话，那我们也是有非常多的经验，可以后面我们很多的这个客户进行进一步的这样一个分享。那我们希望的核心的改造的最终目标实现是什么样？就原有的神马的这样的一个神州信息的这样的一个分布式核心，这里面是构建在啊集中存储的，构建在叉八六或小机的，构建到v email，构建在R或数据库上面的这样的一个分值平台，那我们希望通过我们的核心的这个信创的电源改造，最终可以跑在比如说信创的服务器上面，跑在我们的分布式存储的基础上，跑在一个信创的网络上，基于这个信创云的这样一个艾环境上面是那个TT搜狗，然后最终通过我们的分式技术平台来完成客户的包括存贷会的业务，包括这个相关的总站呢，包括支付的一个相关的业务来完成真正监管，包括国家对于金融行业最最嗯，风险最高，难度最大的这样的一个改造的任务的达成。

那这里面我也给到大家一个信创的这个核心适配改造的一个大概的一个计划，这里面包括从这个信创的技术站，包括从技术平台，包括从核心业务系统呢，一般情况下，我们是建议至少要通过呃六到六，呃六加62个月的这样一个实施的一个环境，来初步去搭建这个，比如说一些相关的开发测试环境，或者并行环境，通过业务的测试，逐步的完成这个业务系统的一个并行运行，乃至说最终的这样的一个业务的这样的切换，刚才前面我觉得那个呃，我们的很多客户都在讲，就是说这个工程其实对于每一家银行来讲的话，都是一个任重道远的这样一个事儿，可能我个人的一个感觉，可能到2025年的这样一个阶段，可能很多客户真正可以讲，哎，它的核心业务系统实现了初步的这样的一个国产化的一个单轨的全站的这样一个完成。

最后跟大家也分享一下，就是神州信息在呃过去的一两年里面，我们参与到呃金融行业，尤其是银行的这样一个核心业务系统，这样一个替代的这样一个相关的工作，这里面包括这个前前前四个都是我们和腾讯一起合携手的，包括像重庆银行，包括像秦皇岛银行，刚才那个我们秦皇岛的客户也讲了，其实昨天秦皇岛银行我们也恭喜啊，秦皇银行，银行的核心业务系统正式的上线，包括像浦发硅谷银行，包括像我们也参与了呃中国银行的这样的一些这个。那分布式数据库的这样的一些建设过程中，当然其他的还包括像百信银行，北京银行，台州银行，平安一通，天津浦发，邮储，常熟农商，梅州客山，一林银行，那我们可以看到随着整个监管的对于金融信创的这个替代的要求愈加的这个呃明确，那我们也相信越来越多的金融客户啊，包括和神州信息一起，包括和我们信创的相关的主流的基础软硬件的厂商一起，我们希望通过三年到五年的一个工作来最终实现啊，我们核心核心业务系统的这样的一个新创替代，那我今天的分享就到这啊，谢谢主持人和谢谢线上的同事。

好的，非常感谢神州，谢谢张先生给我们带来的分享，我分享了银行核心业务过程改造方案，谢谢。那么下面我们有请金正股份证券市场高级产品经理杨若凯先生为我们带来金正国产整体解决方案与实践分享，有请杨若凯先生。各位参会的领导、老师，大家下午好啊，我是金正股份的杨凯，很荣幸呢可以代表金正参加本次腾讯的技术论坛，下面呢将由我为大家分享金正关于信创条化的整体解决方案以及一些项目实践。我的分享呢，主要也是分为四方面的内容，首先呢是行业内，特别是金融证券行业关于创的一些背景。是正。这些年在一些实践及我们。

第三部分呢，是信是金目前正在推广的一个宣传方案，那么最后呢，也会介绍一些典型案例。人的背景上。然后众所周知，在过去，中国的it标准是厂商制定。存在创。而国内呢，特别是聚焦到证券行业。信创呢，其实已经是在全面加速的一个状态。首先从监管侧，咱们信通院呢，目前呢是在八暂启动了信创的一个公安基地，九月呢，上交所呢，也是通过了系列的走访，展开了对于就是这些证券公司核心系统的调研活动。那么在上游监管上就是要去不断加速推进。券行创。那么第二个呢是产业，产业呢，像咱们腾讯，然后以及华为欧等些厂商呢，也都是纷纷发布了新的产品以及的产品决方案，在技术上呢，进行了再次的升级。

而银河证券、华信证券、中金等等更是已经加快了脚步，让核心交易系统创已经成为了一个进行时。下面讲一下我们正之前的一个信创历程，以及一些落地的结果。针对信创呢，也是顺应整体的一个发展，要成立由集团的一公司专项小组，并遵循的一个推进战略。第一步呢，是从2018年到一九年，我们已经启动了关于信创基础底座的一些适配验证。第三步呢，是从2022年到二五年，我们完成了信创方案的，我们将会进行信创方案的一个全面推广，并且更多的参与到上下游多层次的一些多领域合作之中。

同时呢，我们也是积极响应了国家的信创产业战略，积极制定信创行业标准，并且积极加入了一些信创的组织以及联盟等等信创单位。那么我们目前呢，已经是在国家层面，行业层面以及生态层面深度耕耘，共同的推进的证券行业的一个市场发展。此外呢，我们也是践行的政府目标，积极的项目落到实处。首先在行生态上呢，金正股份呢，是与腾讯签订了战略协议，并且与浪潮设立联合创新实验室。而项目申报上呢，我们已经向信通院、交所以及深圳创新委员会等等一些机构联合申报了一些创新项目，完成了一些政府的信创课题。

未来正也将持续展开其他一些主流产品互联工作。经过这一系列的实践呢，金正呢，目前也是最终形成了我们的信创方案，那就是将金正所拥有的系统的新创技术以及业务理解，与国产硬件厂商所提供的一些信创做技术相融合，打造出真正符合行业需要的信创方案以及应用。那么下面呢，就讲一下我们正目前提出的一套方案。案心目是实现业适主创技术提方。目前呢，我们已经实现了包括经济、资管、投行在内的一个金融全业务系统的系统改造。在前端层面呢，我们也是基于BS框架提供外设支持，配到不同的操作系统。比如像麒麟和信。底座层面呢，我们已经完成了服务器、操作系统、数据库、中间件的主流产品适配。在基础设施层面呢，我们也是支持了物理部署、虚拟部署，并且应用在了公有云、私有云和行业云等层面。

整体的系统呢，会基于金正资研的Co卡云原生技术平台，以及传统的叉PBP平台平台来提供技术支持，实现我们的啊证券业务与基础底座关券商多元策略。前品呢，已经是保证了证券资和银行所有产品全个支持。下一个推荐策，推荐策略。具体来看呢，分为两种，一种是升级换代，一种呢是迁移适配。首先呢，对于现有技术难以满足未来主流发展趋势的产品，以及说这个系统本身就面临着升级换代问题的产品，我们都是在将它升级到最新版本产品的同时，米信创做信创化的设计。

而第二呢，就是对于目前的技术仍然能够满足未来一段时间业务需求。我们就是在现有的产品上呢，直接进行信创做一个迁移适配改造，就可实现信创。那么这里呢，具体几个例子，就是关于教育系统的一个系统改造。我们呢，是将现有的交易系统，两融系统和系统，以及相应的一些网全部级为正的系统。那么原有的这些涉及到股票的系统呢，都会变成未来这个F的一个业务模块，然后逐步去上线。关于这套的一个新创建设模式呢，也是有三种类型。第一种就是固件接管我们稳步目前各个系统的一个功能，然后逐步建设信创。比如说我们先建设一个A后台业务系统，将会逐步接管目前系统的所有的算功能。那么通过这样的模式呢，可以实现各个系统的一个稳定切换了。第一种推进模式呢，是旁试点，也就是先建设一个F系统信创版本的一个全链路。

然后接着呢，券商这边以少量可控的一些试点客户做迁移，接着呢，后续呢，在分批次，分业务维度去进行迁移，直到最终完成全部迁移。第三种模式呢是交易灾备交易呢，其实也是旁试点的一个小的分支，它也是说建设一个完整的AC0系统，但是呢，会作为同城灾备的一个应急方案。通过实现一个准实时的备份，逐步的为他提供一些面服务，最后呢，会通过灰度接管来完成一个整体的一个系统切换。那么A这里呢，它本身呢，就是有一个原生的设计的，因为它是基于卡原生平台提供了技术支撑而开发出来的。而卡呢，在各个组件上呢，包括像交易业务、清算业务、运营业务、数据服务、消息中心、运维平台等等，所有的卡组件都是已经进行了市上工作，满足上要求。我是可以到基于平台，它可以去协同不同一些国产化的实。

那么数据知有两方面。首存。内证数据库呢，我们是采用了啊Q卡MDV这样一个精正自研的一个基于C加加自主研发的产品，符合了线创要求。而在磁盘数据库层面呢，我们则是基于业务场景数据请求，考虑了数据库的部署模式。比如说对于订单证系统据要实较层级成个满不场景不需，并且实现由控扩充。然后在部署上会采用集中的一个数据库部署。其他的系统，比如像接入系统，资金系统，计算系统等等，他们在日常的数据请求呢，是比较低频，但是数据量会比较大。他们呢，就会用数据库部署呢，实现一个分布式部署，这样支持未来一个平行扩充，支持未来的一个大数据量的形式。

那关于数据库的平台工作呢，关键点之一呢，是进行了一个数据库的封装。那么我们呢，是通过数据库的一个差异适配器，屏蔽了数据库差异对于业务代码的一个影响。对于数据库的封装工作呢，涉及到三点，一个是函数抽象，第个是序列器适配，第三个是特殊查询的语句适配。通过这样一个一个的数据库封装步骤呢，我们就已经实现了将业务功能数据库的一个无感知对接，这样呢，我们的系统呢，是可以灵活适配任何一款国产的一个数据库。在数据库的部署层面呢，我们仍然是采了一个两中心的一个部署方式。在同城的中心呢，通过异步同步的模式，采用流复制工具，可以实现同步。而异地的灾备呢？可以通过DSG来实现同步。这两种方式呢，其实都是适用于集中式、分布式部署。而相比于前的一些物理部署，我们还额外测试了基于腾讯云的云化部署模式。

在我们的测试数据中，单节点的性能呢，可以达到单节点每秒一万两千三百零五笔的一个成绩。而多节维性能呢，可以达到50个节点下每秒48米的一个成绩。以上部分呢，就是正信方案的一个介绍，这套方案推出之后呢，也是实实在在的到了行的支持和。那么下面呢，我们就分享一下真正与行业内各个券商合作信创的一些案例。目前呢，金正已经是与包括像国信证券，华盛证券，中金建投证券，银河证券，华证券等等在内的诸多券商就很多的系统啊产生了，呃，各种各样的一些创一些推进项目。他们的整体要求呢，都是秉持着信创，信创双轨并行，以及逐步推进核心交易信的这样一个要求。目前呢，我们已经是签约了20家客户，目前正在实施中的项目呢，也是有十几个，后续正在沟通和撮合中的项目呢，也有30多。

那首先详细分享的呢，是一家头部券商的一个O系统改造案例。那么目前呢，这个OTC系统呢，它是基于现有的原有的一个非国产的个OC系统进行一个迁移改造，这些目标呢，是打造一个全站的创的一个技术平台，实现OC业务单轨目标。那么这个项目呢，是从21年9月开始的，在九月到十月呢，就完成了基于国产化的改造版本的相关组件，十月开始呢，就进行了系统测试和对接联调，最后在11月底就已经上线，整体的电池周期呢是三个月。那它的切换原则呢，是双轨并行的情况下呢，进行了一个全部切换，一次性整体切换，那么现在呢，是一个信创的单轨运行模式。那么在这个项目中呢，其实有几个关键的改造方案，首先是服务器的替换，将原有的服务器换成了泰山。操作系统呢，也是从Windows换成了启的操作系统数据也从Oracle换成了的。

前端的部服务呢，是从换成了我们国产的一个德。那么在这之后呢，也进行了一系列技术改造。在整体的一个迁移过程中呢，也是浮现出了两个突出的技术难点。的是开发平台迁移的过程中，由于技术框架的差异产生了问题。这问题是通过语法规则的差异调整A替换。这个技术问题呢，在于数据库的，数据库适配过程中呢，啊，传统的AC口，它与咱们腾讯的T有一些预差异。那么我们在分析它的相关差异问题之后，通过口口语句适配，然后优化以及自动化测试回归测试，然后此外呢，还有一些腾讯技术专家的支持，解决了这个券商在设备过程中面临的诸多难题。第二个案例呢，是另外一家头部券商关于资金中台新创的一个项目。那么这券上，它在系统的要求呢，同时呢，是增添了一个功能需求，就是要支持数字币支付，实现5000万家客户的一个资金管理。

那么这个项目呢，是从21年10月开始，整体的建设周期呢，也是三个月完成，则呢也是啊，进行双轨并行，然后进行一个整体的一个次换，然后在项目二期呢，会有一个分批的一个切换。它的适配难点呢，同样的是存在一些数据库的性能啊，数据库的语句兼容性，服务器性能。以及居住的角色上，然后这些呢，呃，这里呢，就不太详细展开了。最后呢，我们目前的一些新创的客户案例与保障服务。在宣传的保障服务上呢，我们是承诺了团队保障，我们啊新生提供的服务呢，是会有具有信创项目经验的一些资深团队，然后人员去带队的。那在项目实施上呢，我们会保证对于整体的一些服务器的参数、运维、交易链路全方面进行全方位的一个风控。而对数据提供人工复核啊，以及功能验证，还有数据质量保障等等。在项目上线首日呢，我们会提供专门的一个专家组进行现场保驾护航。

最后呢，我们也会提供对于业务和系统的一些培训服务，来保障券商这边系统的一个完美运行。那么以上呢，就是我关于啊的一个整体宣传项目的一些分享介绍。好的，非常感谢来自金正股份杨文凯先生为我们分享的金正国产整体解决方案与事件，谢谢。那么以上是此次国产数据库金融行业应用与技术论坛的全部嘉宾分享内容，再次感谢参会的各位领导和来宾，谢谢大家对国产数据库的关注与支持，期待着后续能与大家进行进一步的交流与探讨，那么今天我们就到这里，谢谢大家，再见。