腾讯数字政务云端系列直播 | 第一期：TDSQL助力建设数字政务原创

大家下午好。欢迎观看腾讯数字政务云端系列直播活动。我是腾讯云国产数据库产品中心的于超，目前我主要负责政务行业、国大行等重大项目的数据库方案设计和产品交付工作。今天我要分享的主题是助力建设数字政务。整个分享过程如果有任何疑问，可以通过评论区留言。在最后的环节哈，我会做出解答，欢迎各位交流哈。在接下来的一小时间里面，我将分为四个小节来探讨这个话题啊。首先。我们先分析一下政务行业的发展趋势。然后在这个趋势下，政务行业都有哪些业务的需求？为了满足这些需求。我们都对术挑。

而面对这些挑战。我们腾讯的T数据都有哪些？解决方案，在最后的时间里面，我会分享数据在政务行业的几个典型案例啊。首先我们来聊一下数字政务行业目前的发展趋势啊。我们先看一组这个统计数据。2019年。在各种审计行政许可事项中，哈。百分之八九十八已经实现在网上可查，82%的事项已经是在网上受理，然后线下办理，最多跑一次。另外，有35%的事项已经实现了网上审批。所有的流程啊。真正的实现了跑动啊，另外截止到2019年的12月，有31个省政府。已经覆盖，已经构建了。

呃，政务服务平台，其中有29个政务服务平台里面已经开通了一件的集成服务专区。但是我国在线政务服务的规模，用户规模已经达到了6.96.96亿，占整个网民比例的百分之七十六七十六点八哈。面的据，表明全面心个心民幸福。另外就是效率，加快我们这个建设服务型政府，提高政府的办事效率哈。那我们就是要运用这个信息化的手段来解决。企业和群遇到的一些办事难办慢办一问题啊，所以我们部采取了一系列的措，这些问题啊。我们在一在十四五的那个规划里面，现在可以看到这些关键字，比如说像一网通办，异地通，异地可办，跨区通办呀，还有那个全国转账。

另外是。技术可控。像以往我们不管是个人还是还是企业，在办理一些证明和审批的时候，需要多个部门之间来回的跑。效率很低啊，那一网通就是希望打破这个部门之间的壁垒，通过一套系统来处理所有的流程。另外，通过地可我理人员无我户口档案所在地就近办理相关手续哈。像这种医保啊，社保啊，纳税啊，以前是需要到这种企业注册地或者是个人的户口所在地去办理，现在是通过这个跨区通办，我们就可以在省内的任何一个地方都可以办理。另外全国一本站就是要站在全国的这个高度哈，全局的高度来统筹规划这个全国这种资源，来提高这个资源的那个使用效率。

自主可控呢，我们政府行业对业务系统的一个最基本的要求啊。像政务行业。国际民生的行业，那关键技术必须要掌握在自己的手里哈。那为了实现这些目标呢，我们政府部门呢，就提出了一些新的业务需求，我们通过建设一体化的政务平台哈，从角合部门的。呃，业务流程、数据连同不同的应用系统，实现一网通办。另外通过提供这种线上的政务服务哈，那可能把线下的这种服务都搬到线上，让企业和个人户就可以通过啊一系列的这种线上服务来办理各种手续哈。另外通过业务像这种呃，省啊市或者部级集中的方式来实现这种跨区域的办理啊。通过建设全国性的。这种。或者是部级的这种统筹平台覆盖建立覆盖全啊，然后。

城乡统筹、公平高效的志愿规划体系哈。最后是采用这个国产化的个国产化软件来替换核心的应用方式，来实现业务系统的可控。为了满足这些业务需求，对于我们的信息系统提出了更高的技术要求。那不管是一体化平台，还是说这个业务集中，都需要把我们的业务进行整合，把数据进行集中，那带来的结果就是的数据。和业务压力哈，那传统的集中式架构在应对这些高并发的数据场景的时候，要么采用这种比较昂贵些封闭的这种小机哈，要么是垂直扩容，扩CPU扩内存哈，但是我们的单机的那个扩能力是有限的哈，所以我们的选择就是说采用分布式技术，通过水扩展这个PC服务器。还有这种低端的这种数量。

来提高这个处理能力哈。相对于这种集中式架构来说，分布式数据库它是一个比较新的技术。他是专门运运的这种高并发海量的数据的场景哈。所以我们在做架构设计和系统开发的时候会遇到一些挑战。比如说我们现在有几个。这个分布式数据库产品，那我们怎么去选择适合我们自己的数据库？另外相比这个集中式数据来说，分布数据在使用啊。都哪些最佳实践？嗯，包括我们这个。在什么情况下，我们要采用这个分布式数据库，那每个分能放多少数据，能处理多少业务啊，这都是我们啊需要面对的一些一些一些问题啊，另外我们这种线上的政服务面要是七二十时在线，而且我们这种性的这个统平台面向的用更。一旦我们的系统故障导致这个业务中断时，它的影响范围就更大了，所以我们的对系统的可控提出了更高的要求。

那作为系统核心的数据。另外在做系统和数据整合的过程啊，还会涉及到数据的迁移，数据的同步，那如何在业影响最小的情况下。更加安全的去迁移数据，迁移应用。同时，如何保证我们数据同步的这个实时性，以及异构系统之间怎么去迁移应用和数据，这都是我们需要考量的地方。另外，在国产化替换过程间，我们有哪些需要考虑的地方？如何去控制这个替换过程产生的一些风险？首先我们在。在国产化的一个大趋势下面。涌现很多国产产，包括们务样去选择一款属于自己的数据库产品呢？

首先，我认为。这个产品，这个数据库要技术开放。我们之所以要替换大鸡，小鸡，要替换unix。最重要的原因是因为这些技术都是封闭的。被易卡。因为它，因为它不明所以有可能会有。或者是有一些不为人知的一些缺陷。那对此那T我们选择了开源的和P核，这是一个开源的架构，经过了几十年的那个发展，它已经是很成熟的那个技术了，有个非常良好的生态哈。另外就是有一些产品就自称是自研。完全自己哈，但是外界对他的那个架构一无所知哈。

那对于这种这种产品的话，就相当于从一个的体系入了另外一个的体系。嗯，另外我们基于。基于这种开源这种架构的话，我们。个厂家都应该具的力，核心代能要大的不是的，做一个装。那只有当我们自研的代码量达到一定的比例啊，我们才能是自由版权，自主可控，腾讯我们的我们。有自己的那个分支T，我们那个动的那个什么码。占占整个代保50%以上。所以我们的产品是。自主可控的。另外。相对于我们，我们以往的这种传统的集中式数据库，它都是。呃，技术来支撑我们的业务，所以往是有一些传统的厂商来引领这个技术方向，但是互联网时代。

这个海量数据高的这种访问需求。其中是已经无法满足这个需求了，所以往往是因为这种业务驱动了我们这个分布式数据库的这个需求。所以你会发现分布式技术用的最好的地方往往是一些互联网企业，尤其是我们中国这种互联网发展，呃，发展比较好的地方。那在分布式技术领域啊，首先腾讯我们首先是一个用户，早期我们的这个社交通讯业务啊，包括像腾讯充值啊，还有微信这业务啊，就是因为这种集中式的和PG无法满足我们的，满足我们需要，我们才有的这个什么。布需打把我们这产品对外去，在213年开始正式用，所以我们的产品是经过了业务的。

驱动适当的考验哈。他需要对这种主流的硬件，包括这种操作系统啊要做适配，而且还要有这种这种的这个应用厂商的一些支持。特别像我们这。行业的客户，他不像这种互联网大厂，像这种银行啊，像这种电信运营商啊，他有很专业的这种这种研发和运营团队。所以，对于。行业的客户，他们。要求我们要求我们的这个。产品厂商的差。能力和这个后续的那个运维是至关重要，那腾讯我们在全国有四个区域中心哈，在各市各市都有地的队时，我的发我们的这个这个伙伴，我们可以通过我望通过原厂加这个合作伙伴的模式哈，来提供这个交付和运维的支持能力啊。

那关于一个对于一个这种呃，分布式，一个新建的一个分布式数据库来说哈，那。我们。有。有哪些开发实践呢？所以我们要明确一点，就是说分布数据的目的是因为我集成数据。他无法支撑这种高并发的这种。这种海量数据的这种，它是一种选择，所以为了应对这种严的，相比这种数据库来说，分布式数据库它有它特的一些规则哈，需要我们去遵循哈，首先那我们需要就是说一般这种分布式架构的话，它希望就是说通过啊，一般需要通过选取一个这种分区件。然后让我们这个数据量的达在多个分片或者多个分区里面。因为这个分区它是，呃，这个要调整我们的这个分区，它其实会有一定的成本的，所以我们在选取这个分区的时候一定要谨慎。

第二就是说分布式数据库。他是处理这个分布式是没有任何问题，但是我们这里面我们讲就是说。分配数据后，它其实的些场景是应该就是高的场景哈。我们应该遵循另外一层，就是说我们应该尽量让我们的事物能够集中在一个分片里面完成，这是分布数据的一个一个最优的场景你的处理，所以我们在做设计，做开发的时候，我们应该就是考虑到，就是说尽量让一个这种小事物要。这种呃，高标的小事物能够在一个这个那个图片里面能完成啊。

那对于一些这种，呃。这种比较复杂，这种海量数据，这种这种查询这种报表啊什么的，那我们可能就是我们要希望就是说在设计过程中间哈，我们要最大的那个病。实这种并行操作，我们分片能并行的去完成我们这个这个任务样的话，通过呃，最大化的一个并操作，能够处理我们这个大事误哈，这种含量，这种这种比较复杂比较含量的这种事物的一个处理能力哈，它的吞吐能力哈。还有就是说我们应该把这个应用的那个业务逻辑哈。简单的在在在应用层里面去实现，而不是把这些逻辑放在数据库里面，比如说像这种以数库里面，可能放在这过程里面，或者放在触发器里面哈，这样做的有两个好处，一个就是说让我们的应用跟我们的那个数据库之间结耦那。对于对于我们的客户来说，应用应用层来说啊，那即便是以后要换数据库，或者是我们都是应用的，不需调整。另外一个很重要一点就是说我们。

把这个业务跟跟数据库结有之后，那我们的数据库在做那个横向扩展的时候就做的很容易哈。另外就是分布式数据库，它会有一些最优的场景啊。还有也会有一些呃，不适合的一些这种操作啊，那我们在做做应用开发的过程间，我们应该去遵循这个分布式的，它那个什么，它的一个聚焦，聚焦实践。我们要去，我们一般这种数据库都会有这种分布式的这个开发规范，那我们在做开发的过程中，我们要尽量去遵循这个啊规范，然后最大化我们这个分布式数据库的这个优点。这是关于就是一个新的系统里面，我们在做分布式开发的一个最佳时间啊。另外就是我们像我们很多这，我们这里面很多这种呃，应用都是在已有的这种老系统里面做一个分布式的改造，那在做改造的过程中间啊，我们要考虑就是说呃，首先第一个我们要考虑到。

啊，这是一个循序进的过程啊，我们首先第一个应该遵循。去集中去解决一些高频的一些交易哈，这些高频的交易，它可能会占我们业务的90%以上的这种交易哈，也都是一些比较简单的一些这种社会语句哈，那如果我们要是说解决这些高频问题的话，那基本上我们整个这个这个这个兼容性的问题基本上就解决了。然后呃，是先考虑的就是我们这些跑的业务，这跑业务它会比较复杂，而且他可能那个，但是他但是他的那什么那个。总那个数量，那个总量是相对于那个高频来说，它会比较低啊，那我们解决了一个这个高频的交易之后，我们再去考虑这个跑步的业务啊。然后在解决这个功能那个问题之后，我们还要再去考虑这个性能问题。

那。这个系统中，因为首先第一个我们从一个集中式的数据库到一个分配数据库，所以它会有一些区别啊，所以我们即便是功能满的情况下，我们还是应该做一些调整去做的那个什么这个优化，因为本身我们是分数据库，就是要取得最好的一个性能。所以这个优化是是那个什么，我们是在考虑到这个兼容性问题之后，我们再去做这个优化，这个优化是一个一个持续的一个过程啊。嗯，这个不管是集中式还是分布式都是要持续的优化哈，所以我们总结一下在分布式还是空间啊，首先先跑通这个呃业务，然后再去做优化，然后我们是先简单再去有了经验之后，我们再去调整一些复杂的，然后先去集中解决一些高频的应用，然后再解决一些频度比较低啊，但是可能比较复杂的一些业务啊。这是我们对于这种分布式改造的一些一些原则。

另外，在。在客户有的时候会经常问到一个问题，他说我的集成数据库。那好好的，我为什么要用你的什么数据库呢？然后我的目前这种业务压力，我的单机明显明显可以支撑啊。那另外就是。我在什么样的情况下，我需要去采取这个分布式，那如果我要是采取的分布式之后，那我每一个分分片它能存放多少数据能够处理业务？这是客户经常会问到一个问题，所以这里面的问题就是说，首先第一个就是我们单机，我们单机那个能够支撑多少业务。或者是多少数据量，那我们的衡量的维度是什么，然后第二就是我们要采用这个分布式数据库，我们在程那分片，我们怎么去怎么去分，我们是按数据容量还是按这个什么，这个单分片那个处理那个处理能力哈。所以在回答这个问题之前，我们要强调一点，就是说。

首先嗯，我们这种。没有一个一个这种严格的公式，或者没有一个严格的一个指标是多少多少容量，或者是说多少TPS，我们就应该去采取这种集中式，或者是分布那们采式，我们分容或一个提，没有这种这种办证公式能够去去套对话。那需要我们去，呃，多维的去考虑。而且还要去做那个呃，去做那个呃测试，这样才会比较精准，因为不同的那个业务场景哈，它的那个TPS带来的值是不一样的哈。然后我们在考虑这个地方这个这个呃型的时候，我们其实还要考虑，就是说我们要考虑未来业务的增长，考虑未来三到五年的这长情况，而不是说满足我现有的，有可能我现有这个什么，这个单机是能支撑啊，但是未来有可能我的那个一些新业务增加，或者是我的业务形态发生改变，有的一些什么这种互联网的类型的业务啊，那它的这种访问啊，它的数据量也会增长，所以。

我们要考虑这个问题啊，那在做那个选型的时候，我们其实比如说我在。什么样情况下我们去去选取，而是我们要多维考虑。首先第一个我们要。要选定这个硬件配置。这个。会部署在什么样的一个环境，那我们就应该以这个硬件环境一个配置哈，去做规划，去做测试哈，然后我们还要考虑到一个数据库的一个容量。这个文件的话，它不光是这个数据库的存量，更多的是这个数据库的这个它的一些呃一些就是呃业务这个热点数据，好比如说我这里面可能一个主要查询里面，它可能会涉及到多少那个什么那个呃这个数据量可能我这个数据库可能有有一个T，但是真正去查询过程间可能只有可能只有几十G哈，数据可能会传到那些那个等数据都可能，一般情况下我们都不会访问好。

所以数据容量是要考虑，但是我们考虑的更多的是一些啊。一些热点数据哈，然后第二就是说我单个单机我要支撑多少的TPS。或者是QPS，就是一秒钟能够处理多少事务，或者是一秒能够处理多少查询哈，这个是跟我们的这个业务是强相关的，那不同。它是TP单机的的tpi是不一样的。比如说我们一个简单的一个什么这种这种呃，这个。支付简单支付，或者是一个一个什么这个客户信息查询哈，啊，他PPS跟一个这种什么这种跑批啊，一个报表它肯定是不一样的，所以而且我们在做测试的空间。我们不能单看这个TPS的这个峰值哈，我们还要考虑就是在这个TPS是在什么样的那个什么这个响应时间之内哈。

比如说我们业务要求响应时间在50毫秒，那我们这个TPS值就不应该获得这个TP的时候，我们要考要考虑到这个响应时间哈，一般TPS越高，可能我的响应时间可能就会就可能会越长哈，所以这要做好。要优先满足我们的业务的需求啊，同时我们包括我们CPU的使用率，在峰值的时候，我们CPU使用我们不建议超过60%啊，对我的这个系统稳定性会影响，所以我们应该。综合的考虑这些因素，然后那个什么，就是说要以要一定要结合我们这个业务，业务的特点去做一个规划，那最好是。以那个业务场景业务去做测试，以这个测试结果为准啊，呃，有的时候可能没有这测试条件，但是我们如果要说有一些这种类的一些业务的一些测试数据，那我们可以拿这数据去做一些一些那个关联啊。但是更多的还是还是希望就是拿这个什么，这个真实的业务团队去做实测啊，所以这是我们在做选型的时候，一个一个考，一个一个选型指引哈。

然后我们关于那个数据库的一个高回用，因为我们政务行业我们讲就是业务对这个高回有一些更多的需求，那在数库的高上面，好，我们TL具备以下的能力哈，首先我们提供的不同维度的这个监控指标哈，可以全方位的监控不同组件的这个运行状态，还能够。根据业务的需求自定义。这个监控规则能够。发现这个隐患之后，能够及时处理。啊，另外就是说会有我们也提供一些自动化的一些处理的一些能力啊，比如说我们能够自动检测这个异常，发现这异常之后，我还能够去判定这个异常是因为一些网络抖动，或者是说一些服务器的小应不及时造成的这种这种假时状态，还是说是一个真正的一个一个故障。在确定它是故障之后，那我们能够自动化的去处理啊，能够快速的实现这个主动切换，且能够自动更新这个路由，整个过程不需要另外否。

在每一个部件。它的每个部件里面都有这个设计哈。避免了任何的这个单点故障。而且它还有一个就是我们有这种多层级的高层设计，比如说进程级哈，那进程当了之后，会有这个进程去去监测到，然后把它会尝试把它自动拉起啊，另外我们的那个磁盘的那个什么。通过这个磁的这个read，加上我们这个数据的那个什么这个多副本，能够保证我们数据的个这个这个高可用啊，另外我们的那个呃，一组多重多副本可以部署在不同机架的不同的服务器上面哈，这样可以应对这种服务器的故障，以及这种机架的那个故障啊，另外我们是支持那个多地多的部署。

可以应对这种机房这种事故，以及这种区域级的事件，比如说像地震呀，像水灾哈。那。对于那些提供这种公共服务的这些业务面向一个啥，或者是一个全国的公众，那我们希望能够提供其他市服务要求，这个要求我们的业务恢复时间能够在一小时能恢复。一些这种经营类的一些一些计费的一些金融服务，比如说像医疗保险啊，养老保险啊什么的，它是一些跟钱相关的一些业务，那我们就希望就是说发生单上之后，我们的这个什么这个数据。在恢复之后，它能够不丢失哈。啊，所以我们对于这个什么，这个业务的这个数据库的这个RPU这个恢复时间和这个RPU这个数据，那么这个保护保护级别哈，我们都有很高的要求。能够保证在一分钟之内完成这个数据库的切换。

啊，通过我们这个传的复制技术，能够保证我们这个组成的完全一致啊，那实现那个什么这个同那个数据的那什么那个丢失哈。其实我们也提到，就是我们在建设一体化平台的时候，我们要做审，我们另外我们做这种审计啊什么的，都会有一个数据迁移和数据同步的问题啊，那我们老系统要上要下线，数据就要做，要全部迁移到我们的系统。我们的不同部门之间，包括我们审计平台啊，到什么我们的布局平台好，我们的数据要做这种实时同步啊，那我们在选在做数据迁移和数据同步的时候，我们要考虑几点，就是我们的不管是我们的方案还是我们的工具。我们应该考虑到我们的端和服端可能是一个异构的。不管是。啊，有可能我的原端是Oracle啊，或者是搜so哈，那么端可能是我们的T啊，或者是其他数据库，所以我们要考虑到这种异构数据异构的情况，同时呢，就是说要全量的迁移，然后实时的增量的去去增加，就是要有这种全量迁移的能力和这种什么，这种实时增量的那个同步能力哈，另外就是有一些业务，它可能他的那个什么，这种可能性要是比较高哈，那可能在迁移过程中间，我希望你能够在线去签啊。

对我的那个什么，这个业务中断时间能够降低，降低的比较低哈。那还有就是我们在不管是在同步还是在还是在做迁移的过程间，我希望你那个这个同步的做迁移，这个效率很高哈，特别是中迁移啊，那你你的迁移的效率越高，那我的那个呃，平均窗口就越低哈。啊，另外就是我们不管是迁移还是同步，我们有一个很重要的一点，就是我们需要有一种机制能够做这种在线比对哈，啊，只有我们。人和目标保持一致的情况下。那我们。我们的迁移哈，我们我们的同步才有效，要不然我们的水同步过去之后是丢了，丢出去了，或者是说数据错乱了，那其实我们这个迁移和同步是失败的，因为那个数据根本就是无效的，无法使用的，那我们的提供了一个工具，我们的bridge，我们bridge的话是是可以做到，就是说这种呃构数据库的。

这个迁移它和同步基本上这种主流的啊，不管是主流的这什么这种关系数据库，还是说这种什么这种大数据哈。我们T都支持，我们地域位置都支持，像我们这个里面列出来这些东西都是我们的目标，那我们都是支持。另外就是我们支持这种全。同步和这种实时的这种精神同步，可以做到那个什么实时的啊。那个同步啊，另外就是说能够呃在线迁移啊，就是在就是迁移的过程中间就是它基本上那个整个同步，这个迁移好基本上是说它那个前面时间是基本上是呃是在是在啊分钟级哈，然后我们的那个效率很高哈。

啊，一般比如说二到这种什么，到我们的话，只要只要我们那个网络那个什么和那个人事处的那个资源足够的情况下，我们基本上能够到这种到这种什么，这个一百七一小时哈，因为我们提供的这个数据比对工具能够。去比对我们的原端和目标的那个数据哈。啊，另外就是除了这个这个呃，数据同步和迁移之外，还有一点就是说我们的那个呃，应用的这个什么这个异构迁移啊，就相当于我们以应用。这里面不是说一个简单的把数据同步过来，其实这里面还有很多功能需要做，因为它是异构的一个一个一个数据库，一个数据库，所以它那个什么，它的那个除了数据对象之外，它还有很多一些应用，这些应用更多的是一些，比如说我指的是数据库上的应用，比如像S语句，或者是存储过程这些它的一些迁移啊。所以他不是说我通过一个工具直接把这个数据端过来就就OK了，因为有很多这种社会语句，它是写在我们那个应用数据里面啊，所以整个这个。

这个迁移的话，它其实有很多工作需要做。这是整个应用迁移里面过，大概是这么几部分，一个是我们在迁移，我移的看里面数据对象有没有不兼容情况，它的数量有多大有多少。然后我的应用里面，从我的语言到目标，它这个语句之间交性怎么样。然后我们要去评估，这样的话，我们可以知道他什么这个呃，这个工作量和这个这个改造量，或者是这个风险，然后我们在迁移之前，我们要做一些应用的改造。要有些改造方案，然后我们去改一些这个什么不兼容的这个这个语句哈，然后还要做一些功能测试。在迁移的时候，我们要把要做数据迁移的一些测试，然后要先全量迁移，然后再迁移哈，那最后我们在服务交割的时候后，在之前我们要去比对一下我们那个就是端的数据是不是一致的哈，然后我们还要去做一些这个功能性的一些一些比对，然后我们的那个迁移会之我们的性能它的那个什么是啊，比以前有没有一些降低哈，然后最后再去做交割，这是我们整个做购应用的引里面要涉及的库存，那一般我们在迁移过程间会有这么几个痛点，就是说第一这个。

人工的这个迁移会比较大，因为你不知道有多少对象。要去过去这里面有多少是兼容的，还是不兼容的，然后这些东西。如果是靠人工的话，都是有可能会漏掉，有些语句在写的那什么程序里面，但是我可能没办法去去那么去去找到，所以可能会漏掉。另外就是说这里面我们这个引这个工这个工具，它那个技术可能比较杂，那我们能还要懂我们的那个数据库，那什么那个那个技术还懂我们据的技数据，你还都要去了解所种的技术需去。

嗯，另外就是说一旦那个我们要评估一下这个。购迁移过程间这个改造这个什么这个呃，风险和这个难度这个东西我们靠人工是很不太好评估的哈啊，所以而且整个迁移过程我们没有一个这种比较标准的流程啊，不能觉我们做什么样的事情。那针对于这种应用迁移啊，我们腾讯就有一套就是数据库的应用迁移服务的解决方案，那我们是个移平台，我专服我们这移。那这个迁移平台能够帮助我们去做这个迁移的看。和对象。

他都有哪些对象，然后这个什么这个兼容程度，然后有些不兼容的不兼容，我们会给出一些建议，怎么去不同的数据。给一个报告，给一个建议，这些怎么去改造，就是做一做一个出一个这种这种评估报告，然后我们在做数据迁移的时候，他可以做增量和这个全量和移哈，然后移之后还可以做那个什么，做这个移校验哈，那除了我们这个。通过这个利用这个平台，我们还有还提供这个专家服务，通过这专家服务，我们可以帮助我们的啊开发商，包括我们的客户去做那个什么这个迁移的评估啊，基于那个什么bridge那个那些评估报告，我们去做一些迁移的评估哈，然后去支持我们这个什么这个迁移的这个这个方案设计哈，然后会提出一些这种改造的一些建议啊，以及在最后这个交交割的这个过程中，我们会提供这个什么这个保证的服务。

呃，我们现在有很多已经有很多这个客户的案例哈，对，就是说做那个这个服务哈。然后再说我们这个国产化替换，国产化替换的一个最终的目标是。现就是我们能够实现全的这个扩化，从中数到器，磁盘，网络等等全的那个什么这个产化，这是我们的标。其中最关键也是最难做的事情就是这环节，就是我们的数据库。T，我们已经通过各种机这个这个专业的那个什么测试认证。然后我们的，呃，腾讯的这个互联网和会的业务啊，已经对我们产品经过打磨。而且我们在全国有超过600，这个600个政企和金融的案例哈。

那。对于个软硬件面，像这种国产CP，像飞腾啊这种C能，它的性能本上已经跟我们那个叉八六视频，虽然可能单核处理能力可能不如这个叉八六，但是它的那个可以通过这个数那个优势。够跟这产作成。而且我们T已经跟这些CPU。这个过程的CPU系统和服务的厂商已经做了互认证哈，而且我们跟他们是啊紧密的配合，就是一旦双要是有这种产品的，我们都会在第一时间去做。

另外就是关于那个那个这块，可能大家可能觉得这个。没经验，另外C没C个业去验，通过一些设计，比如说通过这种分布式的这种这种架构。来弥补它的这种可用性的这个什么这个这个短板哈，啊，另外就是我们在做替换的时候可以简单。然后有了经验之后，然后再去做这个复杂的系统，然后先去改造我们的那个，替换我们的外围系统，然后再去做替换这个核心系统，另外我们还有一个我们一个经验，就是说像很多这种有些客户。

其实我们可以就是它的它的一个一个一个业务，一个应用，其实我们是可以就是说以这种单元化的方式来去做设计哈，就是说应用对对于我的客户来说，它是它是一套。但是他的那个什么，它是按单元来划分，比如说那个。像那个啊，可以按，比如一个我们就是一单元，那这个单元里面它的应用服务器应用啊，这个中件啊，数据库啊，存储服务器网络哈，它都是独立的哈，就是在底层，它是它是一个一个独立单元哈，那我们有了这种单元化架构之后，我们可以。以这种单的方式去做这种化替换，我们在一个里面，我们可以全式的就是从这应用到数据采设。

这样的话就相当于我们可以把这个故障的这个这个范围到一个单元里面，而且我们可以通过就是说先做一个一个单元去，然后再去全局的一个部署，有点像我们以前讲的就是说这种灰度发布。那这个关于这个众这个这块，我们已经有很多这个案例哈，像这种数字广东里面还有我们工信部的那个物资程序，包括像广东医保啊，包括中行啊，农行啊，都有很多那个什么，已经有很多这种国产化的这个什么，这个这个案例的就是。全套的那个什么那个全能式的那个那个过程化。嗯，其中这个跟那个们是相对来说是比较多的哈。

先看一下，就是我们在去年的那个第七次全国人口普查哈。相比前六次的普查里面。这个人普它是有一些新的，首先这个采集方式啊，全部都是电子化登记哈，就是登记方式，这个普查员上记之。还增加了就是这个普查对象自主填报方式。然后采集的内容啊，就是比以往任何一次都要多很多哈，就是啊，每个人的信息都每一项信息都是非常非常完善的哈，所以的那个数据量会会很大啊，这个表里面会这个会比较多哈，另外就是就是采集了之后，我们还会去跟行政部门的一些大数据去做一些对比，做比对。这样保证我们那个普查的数据能够做到不重不漏，就是烟普烟灯灯哈，就是一个啊，跟以往的吐槽的一个一个一个区别哈，那就是因为这些区别哈。

所以就导致对于我们这个数据库的这个什么，就是带来一个很大的一个挑战哈，你看我们首先第一个。嗯，会有。它是面向这种互联网用户，全国近有1亿的用户通过这个微信小程序自主填报，另外就是有700万，超过700万个普查员，拿一个这种企微，拿一个手持机卡去上门去登记。而且我们是国家要求，就是在15天之内完成全国那个什么这种短表的那个什么这个数据采集。所以还有包括就是这个。整个的这个采集过程中，我们是是要保证我们这个系统是要。要七十二十在线。而且因为这个这个压力比较大，所以我们也不知道他那个什么业务评估的时候，也是没办法去评估在他个什么，他的这个这个这个机器的这个这个容量容。

啊，而且这个数据量收集来说，一个是一个一个很大的一个数据量，我们还需要对它进行各种维度的去统计哈，所以。那对于我们的数据库来说，首先第一个是高并发。高性能下面我们要提出很大的挑战，然后对它的可用性，它的扩展能力啊，以及我们的TP和AB这种什么这种混合场景啊，它的一个处理能力哈，那的话。在系统这个底层的数据库是我们的T，那我们T首先通过这种负载的组件。将业务分发到不同的那个，我们叫计算节点叫prox，能够实现这种高并发，而且我们那个底下的那个有很多有多个这种数据节点，一个分布式的一个一个一个处理能力很强，所以它对于这种高并发和高性能的一个处理能力，我们能够能够能扛下来哈，另外就是说我们通过多能冗设计啊，包括我们前面提的那些那些那些高可能设计哈，能够就我们已经实现了，就是说自动化的这种我的切换能够保证七天24小时的那个提供服务。

另外就是说我们这个。数据库能够实现这种啊，一式就是图形化界面，一件式的那个什么那个在线扩容啊，它这个扩容几乎对我们业务来说几乎是透明的。然后另外就是说我们是啊。前端有那个就是TP这种这种呃业务理，后端会有这种什么这种分函分理，所以我们有提供了一个这种一个混合的一个载的一个场景，我们的一个处理处理场景。那我们看下这个最后那个那个统计数据，那我们这里面就是说前端的话，基本上就是说并数并发已经达到那个什么百万百万级的并发入的那个峰值达到了30万，230万均是一秒钟是12万哈，然后那个在这种统计的过程中间。

我们表那个什么个大小超过1.5T数据量的话，表最大的数据也超过了二十二十亿。单库的那个什么，那个容量已经达到了10KB。嗯，而且我们在做做这种大表作用的时候，我们其实里面还有还还会有一些比如说这种千亿的那个那个10亿的表，跟跟这种什么这种几千万表的那个什么作用，是几万的那个什么2万的那S，另外有一些这种宽表的一些复杂查询那。我们那个。那第二个就是我们的那个数字广东哈，数字广东是在2017年，那个广东省是在全国是率先启动那个什么这个数字政府的改革哈，是所以那个数字广东是在2017年的七月开始建设和运营啊。

到现在的话，它是它是一个两地的一个省级平台和数库应用平台哈，那它的这个整个规模啊庞大，这我们来介绍一下我们数据库的，那么这个规模。整个数里面会用到那个腾讯个数据品，关系数据的话，主要会我个那个那个还个这种那。1万。一万零二十四一万的，然后那个数据那个存量已经超过了啊1.31.3PB哈，那我们那个分析那块的话，它的C超过了27000，然后数储已经超过了四二，而且它这个数里面了种个业务的场景，业务场景，呃，这个政务场景，比如说这种基于高并发应用的这个月城市。

然后还有那个就是基于这种分的这个这个大数据中心啊，还有我们那个啊流应用的那个广东服务网，还有一些这种综合性应用，像这种粤商通啊，粤正义哈等等。我们看一下那个月省市哈月省市的话，它是一个高并发的一个一个应用，它底层数据就是用的那个T，然后它是从最开始那个由这实名用户是由三千万那个到到今天的已经到了将近九千万的一个什么跨越增长啊。啊，累计的那个处理的那个什么，那个事务业务量已经超过了48笔。然后这里面的话，我们嗯，来看我们这个数据库里面的一些那个具体数据哈，这里面会因为它是一个在线的一个用户，我们的那个可以通过那个手机的那个APP去在线去办理这些业务，所以对于那个，因为它是一个公网的。

一个一个一个业务上，所以他对于这个数据的安全要求很高哈，整个数据库里面会有超过了，呃。那个6000的表都是加密表做的那个数据的脱敏啊，然后通过一些这种白名单，还有这个链路的一些加密，就是保证我们那个数据的安全哈。他们那个什么，就是在疫情的高峰期，这个数据库的那什么，那个问的那个什么量已经达到。1700万次哈，一天的那个总访问量已经超过了那个1.8亿次哈，这是月省市，然后那个政务大数据中心啊，它是一个，呃，它的目标是要实现以应用为驱动，建设一个省市级的一体化大数据中心啊，这是一个典型的一个分应用啊，那层用到那个关系数据就是T，我们大产T种大数据中心的例中经我们那个T和PG跟我们。

TPDS做一个组合，我们会把这结构化数据放在我们那个TC和PG里面，把那些化数据放在我们TPDS里面。在这个，呃，应用里面。这个我们的那个，嗯，TG的那个TS已经超过了5万。然后我们这个大中心有一共有19个项目，最大的一个项目呢，它的数据有超过了那个，呃，300T哈。这是，呃。政务，另外还有就是说那个呃，最近我们那个呃，人社部，我们江苏人的一体化技术平台哈。啊，他是人社部。呃，第一个就是基于那个，就是基于那个六的一个，呃，省集中的一个一体化平台哈那江苏它是一个人口大省。那个他要为近8000的那个什么人口和差不多是3000的那个事业单位去提供这个服务，在整个一体化的中间，我们在。

江苏。这个人一化平台里面啊，他是选择了以这个T4为底座。想打造一个智慧人的一个案例哈。这里面基于分布式数据库的T，为这个人事系统、调度指挥、公共服务、小程序、一化档案等关键的业务构建了一个高性能可扩展的一个呃，一个系统的一个呃。一个数据库，一个数据库平台哈。整个这个这个平台里面，呃，它的那个什么那个数据库那个服务那个服务器那个那个数量已经那个超过了，就是说呃，100台啊。啊，另外就是一个就是我们的那个广东医保。那广东医保的它是医保专区，是在广东政务云的一呃上面构建的一个啊，以物理隔离的方式单独的的一个独立专区哈。那目前这个医保已经。

那个。里面有150台那个服务器。这要就是说这个。是用的是T数据那个操作是为那个C啊，是一个全站式的那个那个一个一个平台哈，然后它是同两中心部署那业务备数据备哈，然后它整体的R是那个分，那R10分目的。他的每天那个结算量是每天50万笔，最高的时候能够达到那个90万，那个60万笔，那个高峰时段的那什么那个结算是10万笔。

这些数据的话，还是嗯，是没有接入那个什么，就是说还没有完全入，像那个他们有大城市，像什么广州啊，还有那个深还没完全接入，就是没有接入这两个大城大城市的那个什么那个数据，如果要是接入后那那个什么那个数据库那个。那个数据库的那个容量会超过那个400，然后那个的那个访问请求会更多哈，另外就是说在医保行业里面，除了那个什么这个广东医保之外，我们还有还有提出还有其他的一些案例，比如说医保局。还有像什么湖北啊，然后北啊，福建天津重等等这些医保的那个平台啊都。啊，那我们介绍几个，嗯，就是非政务行，非政务行业那个，我们几个那个典型的案例吧，就是那个。首先介绍一下，就是我们那个，嗯，商银行核心系统。

嗯，当当农商行的这个核心业务最开始是跑在IBM的小机的，设它是一个集中式架构，那这个业务的发展原有的系统。性能和高用上面已经没办满我们这个业需求了，当时他们去做改造应用，造，要造最终选择的那个T口。那上线的时候，他们为了这个稳妥。是，当时设计师是用T去支撑业务，同时他们还搭了一个一个做备用，通过那个同步工，T数同到里面去。那随着那个一八上线。

是10月30号，就是平安的平安银行的信用卡A加新核心系统那个投产。

那。再一个系统的话，它是基于它的底层，就是基于我们的系统，是基于我们的那个T。插的一个哈。嗯，这个核心系统的话，活跃的数量已经超过了6000，嗯，是是首。就是全球首就是T代替。D two，这是全国那个什么，就是全球首家的银行应用，从大机核心应用从大移到那个什么六的一个案例哈，所以我们会拿出来在里面跟大家去啊。讲一下，另外就是嗯。以这个TC为核心的信贷，这个信用卡系统，它的处理能力比以前来说它提升了十倍，它的成本也降了原来的1/3哈。降分之一啊，那我们评估就说这个行，那个费很个硬件配置什么的，配件都是也是很贵的，所以我们在评估在未来的五里面，其实是可以成本节省成本14亿哈。

目的达。嗯。OK，这是。以上就是我今天要分享的全部内容哈。然后那个非常感谢大家，就是参加我们。我们今天的这个这个直播，大家以描一我们屏幕的这个这个二维码。嗯。可以，大家可以加入一个微信群哈啊，以便我们后续的一个沟通和交流哈。我们今天这个本次呃，这个分享政务的，政务的这个分享我们就到此结束啊，非常感谢，感谢大家的那个参与哈。