“五年6次POC测试，最终拿到农行核心系统项目，对我们来说意义非常大。”时隔快一年，腾讯云副总裁李纲想起这段经历时仍感慨不已。

金融行业是腾讯云数据库目前的主战场。近年来，中国人民银行、银保监会等主管部门密集出台文件，推动以银行业为主的金融行业加快实现自主可控技术创新。

核心系统是银行的心脏，面对“卡脖子”的现实困境，银行核心系统的全链路信创国产化尤其紧迫。

此前尽管各大云和数据库厂商都重兵投入，但在这项关键环节上一直未有大的进展，而现在这一纪录被腾讯打破。

在李纲看来，与农行，以及类似中行的合作中，腾讯云数据库不仅实现了国有大行案例零的突破，更助力了国有大行首次实现核心系统全链路信创国产化，完成行业从0到1的跨越。

事实上，腾讯云数据库的成绩远不止这些。自2014年第一次作为交付型产品赋能微众银行至今，腾讯云数据库目前已服务了近半国内TOP 20银行，在TOP10银行中的服务比例高达60%，颇有一骑绝尘之感。

而这些成绩背后，是腾讯云数据库在树标杆、插红旗、拓生态上持续不懈的爬坡向上，五年6次POC测试最终拿到大单，更像是其一路成长的缩影。

赤身肉搏下的产品创新力

“每次的POC测试都是对抗性的，友商坐在对面，甲方坐在旁边，都盯着看，完全是检验产品和技术实力的赤身肉搏战。”

李纲回忆道，“每次测试都像是一场友商大聚会，结果时间一长，客户发现只有我们这帮人一直没变，其他友商或多或少都出现了团队重组。抗压、有耐力，也是我们能拿单的原因之一。

除了耐力比拼外，在他看来，大量的摸底测试和POC测试，还让团队养成了“人有我无，就敏捷跟上；人有我优，就继续保持和优化。”的好习惯，整体团队能力得到了有效提升。

这种“边战边学”，让腾讯云数据库在过去十几年的发展中，一直保持着在产品和技术研发上的创新迭代力。

据了解，发展至今，腾讯云数据库已形成较为全面的产品矩阵，包括关系型数据库、非关系型数据库、国产分布式数据库、数据库SaaS产品四大部分，其中，国产分布式数据库是其重中之重。此次11月4日的腾讯数字生态大会上，腾讯云数据库针对该板块，集中发布了两款新产品，对原有产品做了重要升级。

（腾讯国产数据库产品体系）

雷锋网AI金融评论了解到，腾讯云数据库此次针对金融政企场景发布了新的Oracle兼容引擎，以满足金融核心快速去“O”需求。据李纲介绍，这款引擎在保险和运营商等行业兼容度达98%以上，可以帮助行业在短时间内，近乎零成本改造下实现国产化；同时最高20倍的压缩比和查询性能，可大幅节省资源成本。

同时，为应对金融敏态业务发展过程中业务形态、业务量的不可预知性，会上还发布了一款新敏态引擎。该引擎实现了EB级存储的Online DDL，有效提升了表结构变更过程中的数据库吞吐量，并且腾讯独有的数据形态自动感知特性，使数据能够根据业务负载情况自动迁移，打散热点，降低分布式事务比例，增强扩展性和性能。

此外，对于云原生数据库TDSQL-C，腾讯云数据库也做了新升级，包括吞吐率提升50%、将IO延迟降低80%，整体性能提升85%，并带来新形态Serverless，通过全局工作流预测以及动态扩缩资源，进一步降低成本，做到按需计费。

在分析引擎TDSQL-A方面，新自研列式存储引擎，搭配新智能执行引擎，向量化执行性能有10倍以上的提升，同时凭借分布式延迟物化技术，大幅优化分布式场景下关联查询的计算效率，有助于进一步挖掘数据价值。

用稳扎稳打回应半信半疑

2007年腾讯云数据库伴随着内部增值业务、计费业务等泛金融场景起步，先后经历了赋能互联网新兴产业和民生政务两大发展阶段，近两年，金融行业逐渐成为其主战场。

“主要是发展阶段到了。”在腾讯云数据库副总经理王义成看来，经过前期的实践积累，数据库产品已经成长到了能够独立输出的阶段，足以支持腾讯云数据库在金融行业里大展身手。

与前两大行业相比，金融行业对数据库的要求最为苛刻，尤其对银行而言，核心系统数据库是“生命线”，它存储着银行多年来收集的数据信息，包括用户财务隐私、银行交易记录等重要信息，因而银行在核心系统数据库替代方面尤为谨慎。

在李纲的回忆里，腾讯云数据库多年来都在不断“面对疑虑、消除疑虑、获取信任”，持续向上爬坡。

“从互联网银行到农商行、城商行、股份行，再到国有大行，一边是客户对我们半信半疑，一边是我们稳扎稳打。与腾讯大多业务风格类似，攻一城、扎一寨的踏实积累，才是挑战更高难度任务的绝佳铺垫。”他总结道。

在这样的理念下，腾讯云数据库一路通关，截至目前积累了2000多家金融客户，其中包括超20个金融核心系统标杆项目的落地。

但这还远远不够。实际上，目前国内排名靠前的几家公有云厂商，总体实力相差并不大，当这些巨头争夺同一个客户时，往往是标杆案例越好，脱颖而出的概率越大。因此做好标杆案例，仍是此后一段时间里各大厂商的主要角力点。

“我们未来两到三年的重点也还是做好标杆案例，但标杆的颗粒度会更细。”王义成表示。近几年，他发现，越来越多的中小型城商行和农商行，对股份行和国有大行的案例不再感冒，反而更愿意看一些与自己同类型的案例，于是树标杆进入到精细化阶段。“会细到是什么类型的银行、是核心系统还是单系统，甚至细到具体的攻坚点。”他表示。

而精细化趋势的背后，是对产品和服务标准化的要求。不断领先的市场地位，永远无法靠苦做项目打下来，但可以靠标准化和规模化的能力锤炼出来。 

据了解，在下一步发展规划里，腾讯云数据库会把服务按照不同的能力和工种进行拆分，做标准化打磨，同时在产品体系上，重点投入协议兼容、应用迁移、规范化部署等的标准化，努力从苦做项目进化到规模化复制阶段。

“我们希望未来三到五年，腾讯云数据库能够基于过去丰富的经验和逐渐标准化的解决方案能力，助力1000家金融机构实现核心系统的数据库国产化转型。”李纲表示。

“免费版计划”正当时

然而To B业务的规模化复制远比To C要难，需要对服务体系、产品能力、上下游合作伙伴等整个生态进行全面提升，才有可能实现。

在王义成看来，过去，腾讯云数据库的生态布局广泛，更多是点到点的连接，需要一条能把ISV、服务商、转售商等上下游伙伴都串联起来的纽带，而此次生态大会上重点推出的数据库“TDSQL免费版计划”正是那条寻觅已久的纽带。

具体来说，该计划将通过“软件+服务”的形式来实施：软件部分，用户将通过腾讯云官网提供免费版下载介质以及对应的文档；对于普通开发者，将通过官网社区提供答疑和交流的平台。 

“在行业里，我们可能是首家正式提出‘免费版’这个点的，它和简单的开源不一样。”腾讯云副总裁李纲强调到。

目前国内数据库市场上的开源主要有两种模式，一种是“羊毛出在猪身上”，把数据库开源，放弃掉这部分利润，借此带动其他板块如硬件的发展，然后以此获利；另一种是通过数据库开源来低成本获客。 

事实上，撬动生态从来都是说起来容易做起来难。

近些年经过各大厂商的纷纷开源，开源在某种程度上已然“内卷”，简单的开源再难打出水花，而且在国产化市场上，很多用户需要的并不是更多的开源工具，而是生态和生态中的商业机会。

因此想要做好生态，不能再靠简单的开源，而要建立起一种打造商业化平台的思维。从这个角度看，免费版策略可能要比目前市场上大多数的开源策略更具优势。

在王义成看来，免费版是一种比开源更大的生态布置。把辐射群体从开发者扩展到更多的上下游伙伴，并通过商业化模式，把各方都串联起来，形成有效互动，从而实现生态闭环。

具体来说，在最外层，针对免费版数据库产品，培训伙伴和基础服务商可以通过开设在线问答平台，解答开发者的各类疑问来赚取收益，也帮腾讯构建起了TDSQL社区或问答互助平台。

往里一层，当用户在使用免费版的过程中遇到一些升级需求时，ISV可以承接下来，或针对免费版软件的特性去做定制化新功能，并推向市场。

再深入，免费版软件还能帮助挖掘出一些基础功能部署上的踩点，有助于创新产品的孵化。

如此一来，就形成了一个以免费版数据库产品为核心，不同合作伙伴环绕，相互间合作程度层层加深的圆环，然后针对不同的合作伙伴，在基础认证、技术支持、渠道政策、培训体系等方面给予不同的扶持，让各个板块和整个生态尽量飞转起来，形成良性循环，吸引更多伙伴加入进来，不断扩大生态边界。

“我们之前提过一个词叫‘TDSQL insight’，就是希望不管是生态伙伴还是集成商，当他们二次开发后做出一个更有竞争力的产品投放到市场上，我们只在里面做一个‘TDSQL insight’就OK了。”在李纲看来，这种生态策略和此前赋能各个行业企业的思路一脉相承，都是以一个服务者和底层支持者的姿态去真正助力国产化信创事业。（雷锋网雷锋网）

封面图片来源：电影《特洛伊》

2021年6月30日，值得写进中华财险的历史。中华财险与阿里云合作的新一代核心业务系统，其业务中台的最小可用版本已完成交付，进入最后验收阶段。

一年前，中华财险和阿里云正式达成合作意向，双方的合作金额高达7亿元，是国内金融云领域迄今为止的第一大单。

在他们看来，这场合作不仅是交付一个项目，更是要打造一支新团队、共建一种新模式。

一年后，两方共同在无人攀登过的高峰上，率先竖起一面旗。

一家拥有4万名员工、去年单财险营收就超过500亿的老牌选手，要完成这场前所未有的“手术”，对中华财险和阿里云来说，实力和魄力，底气和勇气，缺一不可。

在中华财险数字化转型一周年之际，这场转型到目前为止的成果和细节，终于展露于世人面前。

不动核心，言何重生

中华财险和阿里云正式签约那天，正值2020年的儿童节。

“巧合遇到这个日子，一个新生儿，开始重生。”中华财险副总裁王永祥说。

2020年6月1日，签约当日

转型启动的时点不能算早，但一定够巧。因为就在签约前数天，银保监会下发了一份文件，给各家财险公司出了道题：

到2022年，车险、农险、意外险、短期健康险、家财险等业务领域，线上化率≥80%。

——2020年5月26日《关于推进财产保险业务线上化发展的指导意见》

监管层对此类保险行业的具体指标下发指导意见，尚属首次。

无论是疫情的影响、市场的驱动还是监管的鼓励，都让数字化浪潮的水花，比以往任何时候都要逼近保险行业。中华财险也适时开启了自己的数字化之旅，和阿里签下全面战略合作协议。

但千头万绪，从何做起？

事实上，智能化应用几年前已经深入保险业务的细枝末节里，像是智能客服机器人，音视频能力+线上营销。

可若是俯瞰这场数字化革命，就会发现，故事已经从那些炫目耀眼的“黑科技”应用，转向夯实基础设施的“内功修炼”。

中华财险的选择也正体现了这一趋势，他们目标清晰：不破不立，就从核心系统动起。

这堪称“地狱级”任务：从核心业务系统的重构开始，直接触及这家成立三十五年的资深险企的“中枢系统”。项目难度在保险乃至整个金融业都实属罕见，所采用的设计理念、产品架构、建模方式和容灾方案均在行业前列，甚至是保险业内首创。

“起初，行业里是有一点质疑的，甚至不太看好。”阿里云工程师赵非回忆。

之前并非没有险企试水上云，但赵非告诉雷锋网《AI金融评论》，应用上云的情况较多，核心系统的重构却是涉及到生产关键，这是从未有过的挑战。

这对于资产规模超过900亿的中华财险而言，挑战巨大。

但如果改造不彻底，原有的核心系统老态龙钟，根本无法快速响应市场海量的新需求。“核心系统是业务层的基础设施，能够称之为基础设施的东西，一定是做得越深入扎实，对未来的商业投影面会越大。”阿里云新金融事业部副总经理娄恒说。

金融行业对核心系统的合规性、稳定性要求都很高，高并发、低延时。而保险的核心系统上云，又与银行、券商颇为不同。相比之下，“保险的交易链路和用户服务时间的跨度都要更长。” 娄恒说。

打个比方，证券的一笔实时交易，买入卖出用时不过几秒，但要进行一次保险购买或者理赔，涉及的环节、花费时间都得翻倍计算。

阿里云工程师江冉补充称，保险的并发性、实时性不及证券等业务，但一个保单可能就涉及10+流程、20+系统的交互，还可能受发生时间点不固定等一系列因素影响，因此在流程设计上，也要对系统交互的便捷性、可实现性，以及业务逻辑的关系上有更周全的考量。

加上保险在技术方面，较银行也有一定程度的落后，这些都意味着其他金融业务的改造上云经验，未必能成功复制到保险领域。

而这家险企的老一代核心系统，投产以来已有十余年，有如一间旧屋落满尘埃，让人无从下手，改造步步维艰。

架构转型：从0到1，没有先例

如此庞大的工程，非一日之功，自然要先进行任务拆解。

中华财险的核心系统升级改造，有两个“华彩篇章”不得不提：基于双中台的应用架构转型，和基于单元化、混合云基础架构的转型。

双中台方面，主要是业务中台和数据中台的建设。

众所周知，传统烟囱式架构纵向割裂，相应的Web、APP、DB以及计算资源和存储资源在系统内重复建设；一旦有突发状况，系统间联动起来更是费劲。

中华财险信息技术部总经理陈小虎表示，接收一个业务的变动需求，可能要同时修改3~5个系统，甚至更多，重复的修改和维护对公司的人力财力来说都是严重浪费。

但与其说“拆烟囱”，这次的双中台更像是一次彻底的推倒重建。

传统金融机构的IT架构转型往往都背着历史包袱，以前积累的数据标准不一，光是做数据清洗都已经筋疲力尽。更不要提几十个系统搅在一处，像极一个物品堆放无序、电线乱缠一通的房间。

这么困难，要不数据中台和业务中台先选其一？

双方经过讨论大胆选了双管齐下。“破釜沉舟，用同一个数据标准，重构两个中台。” 阿里云数字保险总监马荣强说，他是双中台项目里阿里侧的总设计。

推翻重做，意味着不用考虑传统系统留下的“脏数据”，直接绕开让金融机构头疼的数据治理问题。

在这一认知之上，构建沉淀通用能力的业务中台，和以数据智能为主的数据中台。马荣强告诉雷锋网，与传统模式相比，现在的双中台都更侧重模型和场景的匹配。

数据中台会预判保险场景，做相应的模型设计和落地。丰富的数据导入其中后，产生各种数据要素，可供未来的业务智能决策所用。

业务中台则围绕前端业务去识别公共服务，构建微服务的共享库以供调用。“简单来说，就是把我们业务上的所有的功能原子化，前端场景有什么需求，可以重新编排，快速响应业务。”负责中华财险双中台具体建设、落地工作的创新中心总经理胡岱磊说。

总体而言，中华财险的中台设计，就像一个定制款的乐高工具箱。中台整合之后，业务、产品、服务、客户要素等进行原子化，公共技术也抽象、归并到中台里，同时借助云技术，实现资源的弹性扩展。在这样全分布式核心系统建设中，一致性、微服务的设计、服务的编排都是挑战。

如今，回望过去一年的推进过程，搭建云平台和构建双中台MVP的“打基础”阶段，是最艰巨的一环。

这里的MVP指的是最小交付版（或称最小化可实行产品，Minimum Viable Product）。

MVP就相当于先花费最小的代价，在“新房”尽快布置一套麻雀虽小五脏俱全的家私，测试宜居程度，有问题也可以及时迭代更新，试错成本比直接整体搬迁要小得多。

核心系统的新老交替，和搬家异曲同工。如果一股脑全部搬完就入住，一旦发现问题，又不能退回旧房子暂避，但又要保证搬迁的进度，确保日常生活不受影响。

“建设新一代分布式核心系统虽然是项目组双方all in的目标，但是在建设过程中，老的业务系统也不能停掉，还要保障业务正常进行。新老系统‘双规’并行，其中的磨合适配过程充满挑战。”娄恒对雷锋网《AI金融评论》坦言。

马荣强更愿意把打基础环节称之为“从0到1”，基础没打牢会影响到后面的试点和全面上线——“但如果做成了，对行业的影响和价值就会凸显出来。”

“没有先例”像一枚徽章隐隐发光，象征着第一和开创，只等中华财险和阿里云一起凿开眼前的墙。

而前面提到的所谓弹性，很大程度上来自于分布式、单元化、弹性多活的混合云基础架构。

部分保险公司号称完成系统部署在云上，但在陈小虎看来，恐怕业内只有极个别公司实现真正意义上的全云架构适配。

这种适配意味着什么？“未来的核心系统将永远在线，用户请求会从顶端的云解析引导到相应的端，在每个点的服务都是‘活的’，都具备实际业务承载能力。”陈小虎说。

例如在平时，云上只提供5%的业务承载能力，但当遇到双十一这样的业务高峰期，云可以将原有的承载能力快速扩展到翻倍，支持突如其来的业务并发。

而单元化意味着云的能力可以像积木一样，依需求而定，可快速复制成千上百。“云是可弹性的，给我们提供未来的横向的扩展能力，也提供了很多的想象的空间。”陈小虎感慨道。

在架构转型推进之下，中华财险的研发和运维效率呈现了指数级提升。陈小虎表示，银行核心系统的大版本升级，通常以半年和年为单位，保险公司则通常以月为单位，而中华财险的研发周期已经缩短到了以天为单位。

现在，在新架构下支撑近200个应用上云，代码的构建频率也从原来的两到三天一次，提升到一天三到四次。生产环境今年五个月内发布近600次，无重大的P1级故障和资损事件发生。

打通云上云下

值得注意的是，阿里云还为中华财险构建了一套云上应用级灾备方案。

中华财险的不少数据系统都依赖线下搭建的机房，时间一长，机房老化，存在较大的故障风险。

阿里云意识到，虽然系统上云在稳步推进，但线下机房在短期内也不会完全失效。抱着“适合客户的才是最好”的服务理念，阿里云公有云CSM团队在最短时间内拉通内部专家资源，为中华财险迅速制定一套打通云上云下的灾备策略。

这又是一块“硬骨头”。

阿里云工程师江冉解释称，线下如数据库，往往搭建在IBM小型机上，而云上目前以x86体系为主，倘若云上云下要发生数据交互，就会涉及到很多大表的拆分。“拆分是和业务逻辑强相关的，就需要双方团队专家既懂保险行业，又懂云计算产品。”

这就像是一张庞大的电路图，元器件之间的联系极其复杂，如果不看连接就随便挪动，可能会导致开关失灵、灯泡不亮。

但这些系统的“岁数”实在太大，江冉告诉雷锋网《AI金融评论》，不少交互关系只能靠客户口授或者印象来提供相应信息，跟实际情况还未必吻合，开发人员也不一定能在当年的设计文档里找到答案。

因此，阿里云的前期调研中，最耗时的工作之一，就是把核心系统之间的关联梳理出一整张关系逻辑图，归入对应文档，确保在云上灾备时不出现系统间的断连。

江冉介绍称，项目整体开始之后，首先要完成云上系统搭建，包括专线打通和整体网络架构的复制，其次则是周期较长的整体数据迁移，也就是前面提到的云上云下两套体系间的交互，需要反复数据验证、调整设计逻辑。

紧接着，就要在云上跑通整体链路，保证云上系统能够单独成为一个独立的节点，提供相应的服务。“这一阶段更多的是压测，交易模拟，录入测试数据。”

之后便是最惊心动魄的环节：云上云下切换的测试和验证。

在某次切换演练中，有一个操作始终过不去，事关演练乃至整个项目成败，所有人的心都悬了起来，所幸在阿里云专家服务团队和客户方的共同排查下，演练最终顺利完成。

云上灾备取得阶段性成果，中华财险的业务稳定性迈上新台阶。陈小虎称，UM-SSO、内容影像等33套系统已部署到云上灾备。今年5月，中华财险与阿里云也成功完成了首批2套关键系统从本地IDC机房生产环境向金融云的切换演练。

这恰巧反映阿里云所提供的服务，不仅是交付一款产品，更是交付一种能力

阿里云帮助中华财险构建全面的系统灾备体系，使其掌握了独立的系统容灾能力，灾备建设周期由按年提速到按月为单位进行计量。同时，该方案采用金融云按需购买资源的特点，极大降低首次投入成本。

数字化转型，知难而上

保险行业的数字化转型，某种程度上是一件“难而正确”的事。

正如前文提到的种种麻烦，有时候保险公司的核心系统和机房，说不定比技术团队里的年轻人们还要年长，内里繁复又脆弱，动弹不得。

不光是技术层面如过蜀道，组织架构和企业文化层面上更是重重关卡。

开启转型，就意味着进入“无人区”，很大程度涉及到现有业务、流程、人员、系统、数据等多方面因素。

转型不仅仅意味着“敏捷文化”与传统“瀑布文化”的碰撞，更重要的是思维模式、获客模式、运营模式、管理模式的改变，要冲破部门间的阻力，改善一线执行态度，短时间内应对无数的新技术、新观念涌入。

但在王永祥看来，数字化转型是整个保险行业必须面对的问题，没有退路可言。

中华财险副总裁王永祥分享转型经验

曾经，许多保险公司车险一个产品独大，部分公司占比80%以上，可去年“919车险综改”提出“降价、增保、提质”的目标，保费下降，责任范围扩大，赔付率直接从60%以下的水平飙升到75%~80%之间，这对消费者来说是让利，对保险公司来说却是巨大的成本挑战。

王永祥指出，综改之后，车险保费规模急剧下降，车险行业呈现整体亏损的局面；目光放到整个保险业来看，原有的传统业务也在逐步萎缩。

靠车险的好光景不再，保险公司能否抓住新的市场机遇，在他看来，“取决于对风险的完整把控能力”，要建立更直接的触客通道，缩短交易链条上的中间环节，建立成本上的巨大优势。

以前的保险业务经常被吐槽：除了收钱，其他时候都见不着面。因此，销售和服务之间需要被打通，保险公司要告别信息化时代的闲散，走向智能一体化的未来。

以营销为例，中华财险加速实现销售的智能化升级，不但提升销售成单率，更为客户提供更好的互动体验。

今年3月初，中华财险销售智能一体化项目在杭州试点上线。截至6月上旬，杭州家用车续保率提升超6%，首日报价率提升近9%，保费多元化率提升约4%，均取得超出预期的成效。

“业务系统不再只记录交易结果，而是要记录触达客户的全链路，学习互联网产品思维方式去洞见客户的需求，去提升自身主动分发的能力，提升客户黏度。”王永祥说，“这是数字化真正对一个企业组织能发生的业务模式的变革。”

双中台也好，混合云架构也罢，核心系统的种种改造升级，智能一体化平台的不断改进，也是在同业异构和异业同构当中融会贯通，赋予新时代的保险公司更多想象空间。

行业风云变幻，这是中华财险的关键时刻，这同时也是阿里云的关键时刻。

赵非对雷锋网《AI金融评论》说，与中华财险的项目合作三年打底，300余人的服务团队已经做好了驻场陪伴三年的准备，打一场决定行业价值的“举国战争”。他们也希冀这场战役之后，能够沉淀一套可复用的打法和技术，服务到更多的保险机构。

那些无人攀登过的高峰，只有知难而上的人们，才会留下足迹。

华为发布鸿蒙系统后，中行、浦发等数十家银行，立刻发声力挺鸿蒙，并接入系统。

鸿蒙的面世，也立马引发了金融IT从业者的三个疑问：

 • 哪些金融机构会支持鸿蒙，怎样支持？

 • 金融机构接入鸿蒙，有哪些方式和形式？

 • 接入鸿蒙可能存在哪些隐患和风险？

带着疑问，雷锋网《AI金融评论》与业内多位银行IT专家进行探讨。

（一）哪些金融机构力挺鸿蒙？

在鸿蒙发布后，老字号的中国银行、股份制银行的代表中信银行和广发银行就率先第一时间用行动力挺：加入鸿蒙！

除了上述三大银行，当前其他多家银行、大型基金公司以及券商也纷纷表态支持鸿蒙。

于是，鸿蒙第一梯队的金融合作伙伴，成了。

（二）如何金融机构如何接入鸿蒙系统？

从形式来看，金融机构接入鸿蒙系统，目前主要有三种形式：（1）APP适配鸿蒙系统；（2）商城上线鸿蒙专区；（3）推出原子化服务。

值得注意的是，各家金融机构接入鸿蒙操作系统的程度不尽相同。

以中国银行、中信银行两家银行为例，两家银行与鸿蒙合作“原子化服务”。

所谓原子化服务，就是在鸿蒙“原子化”系统架构下，客户无需重新下载app，而是像“小程序”一样使用相关服务。也就是使用者能够即搜即用，不需要事先下载应用程序软件。

其中，中国银行在鸿蒙“原子化”系统架构下，使用者通过鸿蒙的服务中心搜索“外币”二字，即可快速进入“中银外币现钞预约”程序进行预约。

这种方式，能够让使用者更便捷地获取超过20种外币的现钞预约服务，省去应用下载安装、用户注册等步骤，简化了业务办理流程。

中信银行，则推出借记卡原子化服务。

客户无需下载App，通过“中信银行”的服务卡片，即可享受中信银行借记卡申卡及进度查询服务。

其他银行更多选择：将旗下手机app完全适配鸿蒙系统。

如广发银行将信用卡app适配鸿蒙操作系统，光大银行旗下云缴费app全面支持华为鸿蒙系统。浙商银行、宁波银行、上海银行等将手机银行app完全适配。

其中，广发银行信用卡的官方APP——“发现精彩”，在成为首批适配鸿蒙系统的APP的同时，广发信用卡在广发商城还上线了鸿蒙专区。

广发商城上线HarmonyOS专区的作用主要是，消费者可以在该App上购买搭载鸿蒙系统的相关产品。

此外，保险机构方面，众安在线是华为鸿蒙全场景应用生态伙伴中唯一一家保险公司借助鸿蒙OS的能力，用万能卡片为用户打造个性化、场景化、智能化的保障产品和服务。同时，中国人寿app以及e店均已支持华为的鸿蒙系统。

从银行三种不同的接入鸿蒙系统的方式，可以看出：目前大部分银行比较常见的方式是：支持手机APP兼容；而少部分银行在商城上线鸿蒙专区的方式，很可能是出于与合作伙伴构建更好的行业生态的考量。

而原子化服务，是目前银行接入鸿蒙系统较为创新的其中一种方式。第三种方式很有想象空间，雷锋网《AI金融评论》在后期也会积极和传统金融机构的资深人士进行交流，以期将原子化服务更充分向大家展现。

（三）存在哪些隐患和风险？

鸿蒙的问世，迎来了一大批金融机构的盟友，助力了金融机构的数字化转型。

与此同时，鸿蒙的问世，也给黑灰产带来了一些作案契机。

近日，同盾情报部门发现，在网络上已经有黑产利用HarmonyOS的作案案例。

小盾安全解决方案专家向雷锋网《AI金融评论》分享了以下两个案例：

案例一：

羊毛党在升级鸿蒙系统后，旧设备绕过某电商原有设备指纹，可以重新进行薅羊毛行为。

某电商平台的风控系统机制是：一个手机不管是在原有系统（安卓&ios）做了版本升级还是用了改机作弊软件，该电商平台都会识别出是同一个手机。所以，即使有些黑产想通过同一个手机登录不同的账号来薅羊毛，也是无法实现的。

例如，黑产在账号A上获取了“新户优惠券”，想通过登录账号BCD再获取更多的“新户优惠券”，该电商平台的风控系统就能够自动识别和检测出：黑产使用的是同一部手机，从而限制其无法获取。

但是，目前黑产升级了鸿蒙系统，在同一个手机再次登录B账号后，就能够再次获得“新户优惠券”。

这说明：黑产在升级鸿蒙系统后，手机因为系统的变化而不能被电商平台识别出是同一部手机，因此黑产薅羊毛成功。

案例二：

某多开工具已经在6月7日实现兼容HarmonyOS 2系统，“多开工具”是一种能够让一部手机同时装几个相同APP的支持性工具。

黑产在手机上可以装“多开工具”，然后装几个相同的APP，从而登录不同的账号薅羊毛。

也就是，黑产如果想在同一个手机装几个微信，可以先装一个“多开工具”的APP，然后在多开工具的支持下，就可以在一个手机装几个微信APP。

在过往，黑产不管是在苹果系统还是安卓系统，如果在通过“多开工具”去登录，企业是能够及时发现这种情况，从而限制黑产的操作。

但是，目前黑产升级了鸿蒙系统后，发现只要装了“多开工具”，企业的风控系统则无法识别出黑产是在“多开”的环境下进行操作，因此黑产可以在手机装多个相同的APP，然后登陆不同的账号薅羊毛。

以上案例可见：目前部分黑产通过升级鸿蒙系统进行作案，可见企业APP在鸿蒙系统支持下存在数据隐患。

从前述可知，目前多家银行的APP适配了鸿蒙系统。那么，用户在鸿蒙系统前提下进行银行APP的相关操作，是否安全？

小盾安全解决方案专家提到：“如果要解决这些风险问题，则需要企业针对鸿蒙系统部署终端设备指纹技术。”

终端设备指纹技术能够支持安卓、ios、鸿蒙、H5、小程序全业务场景，为每一台设备生成唯一的设备ID，可实时检测当前终端风险状态，识别模拟器、作弊⼯具、改机、⼆次打包App、位置伪造等风险⾏为。

不仅是终端设备指纹技术方面，原来已有其他技术应用，诸如人脸识别等，在与鸿蒙适配的过程中，还需要积极进行反复沟通。

在金融行业，目前鸿蒙已与多家金融机构进行了合作，但是新系统面世跟原来的金融风险管理体系还需要继续磨合。如何及时找到漏洞，防范于未然？这应该是鸿蒙与金融机构，还有技术服务商都应该关注的问题。 

雷锋网雷锋网雷锋网

其实他们最在意的，是希望技术保证核心稳定运行，是整体完全自主掌控，是最后达到每单笔交易/每个账户成本下降的目标，是在业务稳定性、连续性不降低的前提下，支撑业务敏捷。

抽丝剥茧数个实践合作案例后，我们可以看到，金融机构的诉求，或许可以分为三环：

• 最难解决的是“1环”问题，分布式事务怎么实现？各种模式应用在哪些场景？有何利弊？异地多活情况下，数据库怎么保证良好的支撑？

• 到了“2环”，重点落在领域化建模，机构们要参考最佳实践，思考底层模型框架如何处理，他们也在关心集中化架构——分布式架构——云化架构，有没有一些特殊的差异？

• 上升到“3环”，诉求就会涵盖整个云化环境下的运维保障体系、devOps体系、整体的部署架构体系……

2020年被认为是云原生核心的元年，更多金融机构逐渐从混沌中醒来，与科技公司联手摸索出核心系统的“病灶”所在，对症下药。

陈威是阿里云新金融事业部金融核心部负责人，曾从事企业级信息技术产业十余年，具备丰富的应用架构与设计，数据智能，云平台，互联网等领域的理论与大型复杂项目实践，尤其在金融行业具有多年的交叉实践经验，服务于近百家大型机构与客户。

在雷锋网《AI金融评论》与阿里云联合主办“银行系统云化升级”实战体验营中，陈威就从阿里云服务金融机构的过往经验中提取精华，详尽深入地讨论了他们在金融核心系统转型方面的探索和实践。

欲获得所有讲者视频，可关注公众号“AI金融评论”（ID: aijinrongpinglun），进群获取回放链接。

以下为陈威演讲内容，雷锋网做了不改变原意的编辑和整理：

今天的主题是《金融核心云原生转型的探索与实践》。

在整个金融业，尤其在银行领域，核心系统是IT整体支出占比最大，最为复杂，对于技术要求最高的一块。这也是我们认为，整个金融行业包括银行，在朝着云化转型的理念里，最后最难的一部分。

今天的内容首先会讲到银行核心系统云化转型的诉求，简单来讲就是客户和我们为什么要做这件事？其次是核心云原生转型的挑战与应对。

银行核心系统云化转型的诉求

可能在座的听众有所了解，金融核心实际上经过了好几代，存在代际的差异。

最早是传统综合业务系统这部分，然后到第一代基于主机的单体式核心系统。比如钱存在国有大行那里，都是在主机系统Mainframe（大型机）上。

大量的农商农信体系是在AS400上；还有一部分在Power小型机系列。

第二代就是我们通常看到银行会走到瘦核心的阶段，从原来的核心系统进行拆分，尤其是面向敏态的部分，通常会建设一个叫互联网核心的系统。

第一代的技术架构的改造或者升级，通常的做法，基于从单体下移到基于ESB的SOA架构。近几年有些开发商会基于开源Spring Cloud把这部分SOA架构升级到微服务的架构。

从技术架构路线来讲，这是从ESB向微服务框架的体系改进，这就是我们经常听到的分布式核心的实际的现状。

从应用架构路线来看，技术层面虽然有一些升级，但是它底层模型和应用架构，其实没有太大变化。

第二代核心的典型特征就是以ESB为核心和微服务架构，但有个问题没有解决：底层对业务敏捷的支撑是心有余而力不足。支撑一些新的产品，服务或者功能上线需要大量的人力定制化开发，业务并不够敏捷。

随着云计算技术的不断发展和成熟，云化的潮流势不可挡，不论是传统企业还是金融系统，有意愿和动力升级到云上核心，这就是所谓的第三代，也叫云原生核心，基于容器云原生或者基于PaaS等技术。

它跟我们通常理解的分布式核心，实际上有较大差异。第三代是完全走向IaaS/PaaS化，但在底层应用架构方面，其实也有相应的变更，类似于大家听到的中台化、领域设计，这些关键字都会在第三代核心中有所体现。

• 第三代金融核心关键性标准

我们试图总结一下第三代核心的一些关键词，经过长时间的调研与归纳，形成了这么一些标签，云原生，异地多活，中台化，数字化。

云原生和异地多活，偏向技术架构和基础设施；中台化和数字化，偏向于业务和应用。

云原生：金融核心实际上也是应用系统，本质上和其他业务系统没有特别大的差异，但是它比较复杂，对业务连续性和一致性的保障会比较高。

同时，它本质上是一个应用，所以云原生应用该具备的特征，它实际上也具备。比如容器化部署模式，PaaS的资源供给应用需要的能力，这都属于云原生范畴。

异地多活：大部分新建的银行要做的核心，基本上会有异地多活。它不光是同城容灾或者异地容灾，是能够做到多地多活的模式，可以做到城市级的容灾。对于传统金融机构而言，异地多活也是比较大的挑战。

中台化：原来的集中式架构，就是传统一个大的单体化应用，牵一发而动全身。

当需要定制化或创新金融产品服务，尤其是疫情常态化之后，未来有很多不见面的流程服务，包括基于互联网或者视频的新渠道形态，原来的架构不能复用。

这时希望打造一个坚实的业务中台能力，能够支撑未来多变的挑战。中台化最终是为了提高面向创新的效率，这也是建中台的初心，这是支撑业务敏捷非常重要的手段。

数字化：能够以数字化模式，展现里面所有运营相关内容，有了数字化运营的基础和能力，智能自动化运维才有空间，这是核心未来发展的重要方向。

其次，因为核心系统的生命周期非常长，可能会要支撑全行的业务支撑十年八年的的时间。如果遇上比如数字货币这种国家大力推行的方向，它对于核心有怎样的挑战？所以架构上的设计，一定要把这个（时间跨度）也考量进去，具备很强的扩展能力。

• 第三代金融核心的重要意义

自主创新：首先它是自主创新的一个标杆。但从我们的观察来看，2020年是云原生核心的元年，诸多传统金融机构在逐步的进行尝试。

行业标准：在第三代核心，或者全分布式、云原生、多活核心架构领域，还没有公认的标准。金融机构非常想去打造行业的先锋标杆，沉淀的卓越实践参考。

实施工艺：核心是一个庞大的项目群，周期很长，可能有不同的开发商，涉及的人员非常多，不可能按照原来的小应用开发模式，必须要有一套统一规范的框架和实施工艺，支撑长生命周期的大型系统开发，能够在上面开发整个核心系统上百个应用。

能把这三点做好，是我们认为第三代核心在金融机构落地的标志。

• 第三代金融核心的业务价值

首先是全栈式的自主可控，满足相关的要求。

多活架构，可以做到RPO=0，甚至是城市级的容灾，RPO=0，有问题的话恢复时间＜1分钟。如果大家对于基础设施比较了解，就会了解要达到这样一个指标会有多么巨大的挑战，只有达到城市级别的RPO=0，RTO分钟级，才能够真正的保证业务的连续性。

弹性扩展，基于分布式架构的扩展性，一定比集中式架构要好，所以它完全能够满足业务的特殊要求或者线性增长，支撑传统金融机构做类似于双十一这样的大促销，金融爆款产品的秒杀，或者是一些高并发的场景金融。

业务敏捷，产品团队能很快在该框架的核心上，实现新的金融产品和服务。在传统的集中式架构下，上线新的大一些的功能就可能需要大量改动核心内部、关联系统，造成业务上架用时较长。基于微服务或分布式架构的，可以通过devops模式缩短业务交付时间。

运维成本，云原生架构基于相对低廉的x86服务器构建，同等处理能力下，分布式架构的单位运行成本大幅降低，分布式架构的年均运行维护成本是大型机的17%。

• 金融机构们的诉求是什么？

在一个分布式的云化环境中，要保证核心稳定运行，其实有三个非常关键的标志。

1. 整体完全自主掌控。

2. 从财务的角度看，最后达到每单笔交易/每个账户成本的下降。

3. 业务稳定性、连续性不降低的前提下，支撑业务敏捷。

这三点衍生出金融机构对供应商/合作伙伴的诉求，大体分为4个方向。

咨询与设计：架构咨询指导，技术，开发规范等，配套的组织体系架构等。

服务交付：服务的长期交付过程，一般来讲建设周期在2~3年，所以整体的人员投入，开发实施交付规范等。

运维保障：后续的长期运维保障，出问题怎么监控、解决，怎么更自动化；

产品与方案：最底层的是产品方案的支撑，包括整体规划路线图，产品的延续性、一致性、无缝升级维护，还有产品计划的发布策略、相应的生态丰富度。

客户的诉求可以分为三环，最难解决的是“1环”问题：

业务一致性，怎么实现分布式事务？各种各样的模式，到底用在哪些场景？各种模式的利弊是什么？

数据一致性，尤其是异地多活这种情况下，数据库怎么保证良好的支撑，尤其在异地之后的数据容灾等问题，都是基础架构部门非常关心的“1环”内容，通常很难靠金融机构自己解决，一般需要外部供应商来做。

“2环”重点是怎么领域化建模，有没有一些最佳实践？底层模型框架怎么处理？集中化架构到分布式架构，再到云化架构，有没有一些特殊的差异？

“3环” 涵盖整个云化环境下的运维保障体系，devOps体系，整体的部署架构体系，比如怎么做单元化架构等。

云原生转型的挑战和应对

从哪些框架/思路，去解决转型诉求带来的挑战？

可能原来大家理解的，主要是在业务和数据建模，以及底层的技术软件支撑。但在大量调研之后，发现其实中间还缺两层，就是架构集成、开发运维部分，这也是要攻克的难点。

之前讲到，第一代、第二代（金融核心）里这块业务流程不会有太大调整，但在第三代，一定要真正让它敏捷，对业务流程清晰梳理，同时要能转化为类似中台的模式。

上半部分属于企业级架构建模的范畴，下半部分是建模之后怎样在云上落地。

• 我们怎么做敏捷的架构设计？

做敏捷的架构设计，首先要考虑中台化领域设计。

相对传统的服务集成架构是渠道层+整合层+核心系统，但中台化分层就会拆成渠道层、开放层、产品服务层、中台能力层、基础服务层等。

其中，渠道层，包括各个电子化渠道，开放互联网渠道，线下的渠道等。

像产品服务层，其实不是产品真正执行代码的地方，实际是业务能力编排的领域。例如存贷款这些业务，也是经过一个流程编码，调用不同的引擎账户和中台能力，去支撑完成业务链。

其次是思考云原生应用框架的搭建。

为什么要考虑框架？我们在客户项目中经常遇到一个客户的问题，感叹懂业务的不懂云原生分布式；懂云原生分布式的，对业务理解可能也没有那么深。

现在更先进的底层技术，比如云原生分布式数据库，学习使用和运维的难度可能比原来要高，这样会极大影响技术的可获得性，就是好不好用的问题。

这需要一套框架整合起来，在业务组件技术层面封装，降低开发难度，最后让普通的应用开发人员，能够像普通单体架构一样开发业务应用，而不用关心这后面到底是在什么样的环境里部署的。

再就是底层基础设施部分。

因为开发周期非常长，难免中间有老的核心系统，怎么统一完成服务调度治理，怎么在尽量不改代码的情况下，更平滑地接入和交互？

其实我们讲的mesh技术，就比较好解决这个问题。我们也发现很多客户不由自主地运用mesh来支撑集成的架构核心。

使用mesh，下一代的微服务技术，结合分布式网关，能够跟ESB对接，支撑传统业务调用——这也是服务网格目标。这部分与现在经常讲到的low code低代码、低侵入，都具备相近似的模式。

如果想用mesh的模式实现异构架构集成等？这就尤为需要关注云化分布式改造方面的新进展。

以往来讲，spring cloud这套体系，如果你要写一个比较健壮的核心应用，一定要在体系里把所有代码和编排都放进去，实际上每个真正的业务代码量占整体比较少，会有大量业务无关的逻辑。

这部分如果通过mesh技术，直接用sidecar处理，对于原来的业务应用不会有大量的侵入。因为走的是网络层所有监控，所以能够把整个架构的链路全部清晰表达出来。这对全方位监控也是很重要的内容。

• 如何保证质量安全与稳定性？

客户无论是大机下移还是云化转型，都有一个非常重要的前提：保证自身业务连续性；保证整体业务安全情况下，能支撑业务敏捷。

在质量安全与稳定性方面，我们有一整套可回滚可灰度可监控的防控体系，分为三层质量网。

未来一旦微服务化、云化，它会有大量的容器应用，不大可能靠人力定位最终的问题，一定要靠自动化、智能化的方式解决传统的巡检监控问题。总的来说，会有配套机制保障终端客户不出问题，设施是不可靠的，要从应用、软件、机制规范、工具体系支撑。

另外就是异地多活架构。

这部分实际是支付宝能去支持双十一的底层核心架构，是三地五中心的多活架构。在互联网上，我们一般采用客户ID号尾号分片的方式，最后拆到100个单元，能够在不同机房之间精细调拨流量。

所以任何一个机房或城市出现问题，我们都能把流量瞬间调拨过去，同时业务应用能承担起来，机房级或城市级容灾都能做到RPO=0。这里面非常核心的，就是底层分布数据库，真正能够支持异地容灾的分布式结架构。

比如在异地机房，整个单元从端到端升级到一个新的架构，现在可以做到机房级的逻辑单元架构更新，或者应用版本大规模升级，这些都可以通过单元化方式实现。

无论在哪个级别，RPO都能做到等于0，但由于网络或者物理限制，无法做到RTO=0。

陈威在本场演讲中，还谈到了金融核心转型的实践路径和案例分析，并回答了银行大机下移、数字货币对金融核心的挑战等提问。欲获得本场演讲回放，可关注公众号“AI金融评论”（ID: aijinrongpinglun），回复关键词“参会”，进群获取回放链接。

雷锋网

 “开门红”通常是上一年年末12月份到第二年的3月份。在这个活动高峰期，保险订单的峰值有可能是平常的10倍以上，而如何保障营销、销售、服务等全链路系统的稳定运营，在关键时刻不掉链子，对于任何一家保险企业的技术团队而言都是一个不小的挑战。

 “类似‘开门红’这样的活动，我们不上云的时候非常难以处理。”在回忆多年从业经历时，友邦人寿首席信息技术官刘立民坦言道，按照以往经验，技术团队会采购性能强大的服务器放在数据中心内，但是一年中这些机器绝大部分时间所支撑的订单量可能只有高峰时期的十分之一，“造成了巨大的成本浪费。”

现在，通过将销售、精算、财务等数十个核心系统部署在阿里云金融云上，友邦人寿可以根据业务拓展的节奏，提前几天时间来购买充足的计算资源以应对可预见的业务高峰。在大量运用云的基础能力之外，友邦人寿同时还在广泛使用云上开箱即用的数据处理分析能力，在云上持续挖掘数据的价值。

“采用这种比较灵活的方式，可以使我们所花的每一分钱都物有所值，并且可以高效支撑业务高速增长。”刘立民说。

“逐步上云”的五年

友邦保险是一家拥有100多年历史的国际化保险公司，2020年位列财富500强榜单第250名，在中国内地、中国香港等亚太地区的18个市场开展业务。友邦人寿是友邦保险在中国内地的寿险子公司，也是中国内地首家获批的外资独资人身保险公司。

最近几年，数字化转型大潮涌来，云计算、数据智能等关键技术加速渗透，如何运用新技术提升效率，促进产品与服务创新，已经成为保险企业构建未来核心竞争力的关键所在。紧跟产业发展趋势，友邦保险也加快了数字化转型步伐。

2015年年底，友邦保险在集团层面制定了Cloud First战略，推动业务系统从传统数据中心迁移上云。在经过细致的安全、合规、技术领先性等详细市场调研之后，友邦人寿决定与阿里云展开合作，推动中国区业务系统的上云工作。

虽然认准了上云的大方向，但是友邦人寿在具体实施上采用了非常稳健的策略——逐步上云。2016年4月，友邦将旗下的电商业务系统率先迁移到阿里云金融云上，这也是该公司首个上云的业务系统。

相比传统模式之下需要耗时3-6个月才能买到服务器，在云上的流程可以说非常敏捷，只需以天为单位就可以准备好运行系统的资源和环境，效率提升非常明显。正是尝到了云计算带来的红利，友邦保险紧接着又把重要的客户健康管理系统部署在了阿里云金融云上。

真正让友邦决定大规模开启上云进程的拐点出现在2018年。这一年，友邦把非常核心的SAP S4财务系统迁移到了阿里云金融云上。相比传统IT厂商给出的线下部署方案，不但成本大幅降低，系统稳定性也得到大幅提升。

“核心财务系统放在云上，其实经过了一番心理斗争。”刘立民谈到SAP系统上云时坦言，“作为一家国际化的金融机构，这样一个核心系统，如果放在云上出现了问题，对于我们来说是一件压力很大的事。非常高兴地看到，在上云之后的几年中，财务系统运行得比线下还稳定。”

SAP财务系统的成功上云，充分验证了阿里云金融云的可靠性和便捷性。在这之后，友邦就启动了大规模系统上云的方案。

“随着业务扩展，很多业务系统需要快速灵活地部署，同时又要考量成本，这种情况下，传统数据中心就显现出不适应性，而云就比较符合业务需求。”刘立民透露，友邦人寿现在已有几十个系统跑在云上，其中包括销售系统、管理系统、精算系统、财务系统等。

外部冲击与数据难题，保险云化如何招架

随着加速上云，友邦人寿所尝到的云红利也越来越多，除了IT层面的降本增效之外，还助力业务从容应对外部冲击。这一点在去年疫情时期表现得比较突出。

2020年年初，新冠疫情突然爆发。面对疫情对线下保险业务带来的冲击，友邦在极短的时间内就全面实现了云培训、云招募、云管理，保障了内部运营以及外部服务的连续性，而阿里云金融云上开箱即用的丰富功能，也为疫情期间的业务正常开展提供了支撑。

疫情期间，由于保险营销员不能跟客户面对面，在“非接触”的情况下，如何合规地完成人寿保险合同的签约，一时间成为了一个难题。而通过阿里云金融云上的“智能双录”应用，友邦保险很快就解决了这个难题，实现了“空中签单”。

“最初我们的业务比平时下降了80%，但是这个功能上线之后，几乎当天业务就恢复到了正常水平。”刘立民透露，随着疫情缓解，客户已经可以跟营销员面对面签约，但现在仍有很高比例的客户因为工作忙等原因选择远程签单服务。

“从某种意义上讲，云上的技术帮助保险企业扩大了接触客户的可能性和销售的范围。”阿里云智能新金融事业部总经理刘伟光认为，随着客户行为加速向线上化全面迁移，保险机构必须加快数字化和智能化转型进程，学会“数据驱动”，才能在数字时代获得竞争优势。

除了外部冲击，行业内部的数据问题也同样不可忽略。

过去几百年间，虽然保险行业的发展严重依赖数据，但是数据收集和高效使用的能力始终是个难以解决的问题，今天保险行业很多关于客户体验的问题的根源都在于此。

在数字化浪潮带动下，仅过去两年间产生的数据就占到了世界上既有数据的90%。数据存储、数据处理、计算和算法的大幅进步，为保险企业带来了新机遇。

据阿里云新金融技术架构师王磐介绍，以往很多保险企业把各个业务系统部署在数据中心内，各有一套集中式技术架构，导致“数据孤岛”现象严重。而通过上云，使用数据中台，保险企业可以很自然地解决类似问题，最大化数据资产价值。

而致力于成为一家数据科技驱动的公司，也正是友邦人寿正在践行的事情。据刘立民介绍，随着上云的深入，友邦人寿正逐步在云上建设数据中台，并已经在日常运营中引入数据智能技术，助力内部高效培训、精准识别保险诈骗等业务场景。

以培训营销员为例。友邦保险内部构建了一套交互式的智能评估系统，对营销员的培训效果进行评估。以前培训效果主要借助考试成绩来评估，而今天通过这套智能化系统，主管人员可以对营销员的整个培训过程进行“切片式”分析，及时发现问题所在。

“友邦人寿营销员出单率远高于行业平均水平。”刘立民表示，通过智能化的技术，友邦人寿不但降低了培训成本，更为重要的是帮助营销员提升销售业绩，降低流失率，助力整体业务的稳定增长

押注数字化转型，2023年争取90%的系统上云

新冠疫情是一场大考，倒逼整个保险行业加速发展数字化能力。与此同时，保险公司正在经历着从关注“保单”向关注“人”和“家庭”的转变，而要在新一轮变革大潮中拥有可持续的竞争力，积极主动进行数字化转型成为了必选项。

据刘立民介绍，如今友邦人寿已有超过50%的核心业务系统完成上云，公司云上使用的服务器数量稳居友邦保险集团第一名，而在2023年，友邦人寿还将努力实现超过90%的系统部署在云上的目标。

“头部保险公司其实都在积极地转型。”刘立民认为，这样的形势之下，对于任何一家保险公司而言，数字化转型都是必须要做的事情，没有选择。“大象都能够跳舞了，如果不跟着跳的话，可能就意味着淘汰。”

中国保险行业尤其寿险行业，是一个大型保险企业占据80%以上市场份额的市场格局。在过去的2020年，头部保险公司几乎全都在重兵投入科技，部分保险企业还成立专业的保险科技子公司，加速充实技术实力。

这些大型保险企业重磅押注科技，背后的思考并不再是单纯加大IT投入，更多地是提升自身科技力量，运用新数字科技孵化全新的保险产品，对保险的定价、理赔、体验等方方面面进行重构。

保险行业中也经常会有新来的入行者，它们的商业模式可能跟过去完全不同。这类企业刚成立的时候，保险业务体量可能非常小，但是通过数字化和新模式，可能一两年时间就会变得很大。

在刘立民看来，保险公司无论强与弱，都需要在数字化转型做出大量投资，保持一种警醒的心态，使自己不要在这场竞争中落到后面。此外，刘立民强调：加强科技投入的目的在于通过电子化、数字化平台的能力，更好地赋能产品服务创新和营销员团队，以数据化的形式构建出对客户和营销员团队更精准的认识，从而更好地认知、分析和满足客户的需求，优化客户体验、创造客户价值，并提升渠道效率。

展望未来，他说友邦人寿将会加速规划数据中台，优化数据模型，进一步最大化数据资产价值。“友邦人寿会在数字化转型的方向上一直做下去，在竞争激烈的保险行业中占据一席之地。”

雷锋网雷锋网雷锋网

但这些问题，在传统银行大步向前、业务飞速发展的过程中，一定会遇到：

• 怎样才能在整个底盘升级过程中，尽量避免对已上线业务造成打扰？

• 想做到架构平稳切换，压测方案如何设计定夺？

• 银行怎样改造数据中心，才能保证不同业务间的流量调度、隔离一切正常？

而网商银行就用自身的云原生实践给出了解答。从云平台+分布式架构，演化到云原生、混合云弹性架构，这家被称为“国内首家跑在云技术之上”的商业银行，他们五年来的云化升级历程，所遇到的典型挑战、解决思路都颇具借鉴意义。

在雷锋网《AI金融评论》与阿里云联合主办“银行系统云化升级”实战体验营，网商银行基础技术架构部负责人蒋易民就深入讲解了他们的云原生演进之路。

欲获得所有讲者视频以及PPT回顾内容，可关注公众号“AI金融评论”（ID: aijinrongpinglun），进群获取回放链接。

以下为经雷锋网AI金融评论编辑的蒋易民演讲内容：

今天很荣幸和大家分享网商银行的实践情况。

从云计算走向金融级云原生

从这张图来看，网商银行主要经历了三代架构的演进。

一，2015-2016年，主要是基于云平台+分布式架构建立起来的。整个的部署模式是同城双活模式。

二，2017-2018年，在同城双活的基础上需要建设一个异地数据中心，希望这个异地的数据中心在日常过程中能承载业务流量，能与杭州数据中心同时对外提供服务。

在满足异地灾备要求的同时考虑提升整个IT基础设施的资产利用率，所以打造了单元化多活架构，它是一个三地五中心的部署结构。

三，2019年，网商银行开始关注云原生架构，包括开始引进一些产品，设计建设相关能力。在这个过程中，我们也建设了混合云弹性架构，具备了在两朵云之间调度资源的能力。

在上图右侧的曲线可以看出，从网商银行开业，全行的容量水位大概是50 TPS，经过多年的发展，到现在已经到了5万TPS。

但在整个过程中，也发现了存在的一些问题：

在底层基础架构频繁演进过程中，需要大量上层业务研发去配合。这个时候升级改造，控制进度、周期是非常难的。

一代架构的演进大概需要两年左右的时间，基本上把全行所有的系统都切过了。过程中，研发人员的体验感也不是特别好。

怎样才能在整个底盘升级过程中，尽量避免对已上线业务造成打扰？这也是我们引入云原生最初的一个原动力。

放眼多年的发展，我们的路径是一种双模路径——为什么叫双模？就是在多个架构运行过程中，除了对新技术的探索，最重要的是要做好技术风险的防控，保证业务的连续性。

怎样保证在新旧架构演进的过程中，最大化地减少对业务的影响？

我们在进行新技术探索时，也需要做好风险防控。

新一代架构诞生以后，并不是立马全面投产，新老架构会经历较长时间并轨运行，这种情况下是基于增量式的交付，逐渐把老的架构往新的架构演进，并且具备快速回退的能力。

网商银行的技术架构特征

回顾网商银行多年的发展，全行的技术架构特征，有以下几个方面：

因为网商银行是一家没有线下网点的互联网银行，IT系统需要支撑上亿的客户，每天处理上亿的交易量，双11这种活动也会带来流量的一个突增。同时还要确保安全、稳定和可控。

从我行的架构特征来看，要满足这些高性能、高可靠，还有高弹性、高标准，低成本、低风险等要求，架构演进主要也是围绕着解决稳定、效能、安全、容量、成本等多个方面进行。从安全角度来看，有两个维度：

一，信息安全，主要是确保抵御恶意攻击的能力，保证用户数据和隐私安全。

二，资金安全，需要避免在交易过程中数据不一致，特别是一些缺陷导致公司和客户的资金出现问题。

多年的架构演进，“压舱石”是什么，那非全链路追踪和压测能力莫属。如何做到架构平稳切换，压测方案的设计是其中重要一环。

从开业至今五年多，三代架构的演进整体上是平滑的，我们认为很关键的一点是从第一代架构诞生就已具备了全链路压测的本领。我们的方案跟一些业内方案可能存在一些差异，我们是直接拿生产环境去压测的，没有去做模拟的环境，尽最大可能避免环境配置和服务器的水位不同带来的一些差异。

从上图可以看出，我们计算上是共享的，但是存储层面是同库不同表。从这个角度来看，在压测过程中是能最大化还原真实的生产流量对生产系统的压力。

云原生在网商银行的关键实践

云原生架构是基于云原生技术的一组架构原则和设计模式的集合，最关键的点就是把一些业务处理逻辑中非功能性的代码剥离出来，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等）。

图左可以看到，传统架构的一段代码逻辑包含三部分，非功能性代码、业务代码、三方依赖。
而云原生，希望非功能性的代码在理想情况下最大化的减少，相对的业务代码只要聚焦自己的业务即可。

大量非功能的特性，包括弹性、容量、安全可观测性、灰度等都会逐渐下沉到底层的基础设施，特别像高可用能力、容灾能力、容量保障、安全特性，还有一些可运维的特性，逐渐让基础设施去接管。

这种情况下可以看出，在我们在部署上会发生的一些变化。从图的右下角看到，容器会进行进一步的拆分，拆成应用一个进程，边车（sidecar）一个进程。

网商银行云原生的关键实践，主要包含4个部分：微服务，容器化，不可变基础设施，服务网格。

受益于第一代跟第二代架构打下的基础，前两个层面已经有了较好的积累，我们在进行云原生实践过程中没有投入太多的精力，后两个部分投入很大。

涉及到不可变基础设施最重要的一点，就是要完成它的镜像化改造。对此，我们的要求应用是无状态化。

早期的微服务有部分系统并不具备无状态化，此时要求逐渐变成无状态化。对于服务网格，我们引进SOFA Mesh来实现Mesh的落地。（注：SOFA是蚂蚁金服自主研发的分布式中间件，Scalable Open Financial Architecture；SOFAMesh即其第三轮开源产品）

现在网商银行部署的一个基线，主要是三地五中心的模式。

从应用层看，现有容量运用三个数据中心已经足够，但在存储层面选择了5个中心。这种情况下，我们做的是多活的模式。

那么这套架构是怎么建起来的？依赖于商业化的一些成熟产品，包括金融级中间件SOFASTACK、分布式数据库OceanBase。

这套架构最核心的一个特征，就是可以做到同城和异地容灾切换时，RPO=0。

如图所示，IDC1跟IDC2如果同时出现问题，我们可以做到分钟级内把流量切到IDC3。这个过程基于异地多活架构提供的能力是非常快的。从近期生产演练的数据来看，同城大概是2分钟，异地大概是3分钟。

• 微服务与单元化架构

如图所示，网商银行早期也是非单元化。

非单元化有一个很典型的特点：在计算跟存储上，会存在交叉访问的情况。虽然网商早期设计中，做好了分库分表的设计，但从上层计算层面看，它也会出现跨层。

早期运用同城双活的模式，两边的数据跟计算存在交叉，这是没什么问题的。但要建设异地数据中心时，两地之间的延迟可能会导致一次服务的耗时大幅上涨，可能会导致最终客户的一笔交易会出现超时，这种情况下计算跟存储之间的跨城通讯是不可以接受的。

如何解决？采用的是单元化的架构模式，最典型特征是，它的流量是受控的，能形成一个小的闭环，让计算跟存储基本封闭在一个逻辑数据中心，但不排除有部分的跨城或者跨数据中心的访问。

当跨城、跨数据中心的访问是基于服务级别，不是数据级别的情况下，它的延迟是可以得到很好的控制。

当我们进入了单元化架构，在服务上会有多种路由模式，除了在同一个数据中心内部，单元之间、同城的数据中心之间也都会存在通讯的情况。最重要的是我们解决了跨城数据服务通讯。从实践来看，延迟是可以接受的。

重点看右下角的路由表，分片标记用户，用户属于某一个数据中心下面的一个单元，通过该路由表，用户的请求进入后会找到对应的数据中心下面的单元。也可能会出现一部分用户进入后，并没有到正确的数据中心，这种情况下我们会在接入层把用户的请求转到它对应的一个数据中心。

路由的核心是在SDK层面解决的。在业务系统代码里引入一些关键的API去做一些路由的定制，这种情况其实是非常重的。

从全行的单元化升级来看，花的时间也较长，这个跨度至少是一年以上，才会把一些关键的系统全部切到单元化架构上面。

• 容器技术

网商银行早期也经历过富容器，这种较重，包含了所有的应用发布部署需要的依赖，不限于一些关键的RPC、消息、数据库等SDK。

最小的部署单元也是一个容器，在云原生里做进一步划分。

容器会区分为APP的容器，跟Sidecar 的容器。根据现在的实践来看，主要是包含Service Mesh里面MOSN的容器，还有DBMesh的容器。这两个容器解决的是 RPC、消息，还有数据库跟缓存层面的转发。

这种模式有一个最大的好处，就是MOSN跟DBMesh可以独立演进，即可以不需要在上层业务容器配合的情况下，自己完成一些升级跟发布。

当我们做一次全行的架构升级，富容器模式会带着全行所有的应用，可能会进行一到多次迭代的发布。

升级一个SDK最大的问题是什么呢？因为各个系统有自己的进度安排，各自资源可能不一致。要做到全行统一升级，周期往往会拉得非常长。

最不可控的是什么？升级过程中，不同的系统质量保障各有差异。有些可能做得非常好，但有些如果稍有瑕疵，就会引发生产问题，这种情况下很难通过统一的手段去保障。

全行架构升级过程中，关注质量的品质，一致性和普遍性。

相对而言，轻容器较好做，因为所有的能力下沉到MOSN跟DBMesh之后，只要在这两个层面做好质量保障，聚焦后能保障升级品质的一致性和普遍性。上层云的应用很少会关注下层的一些变化。

举个例子，有一次全行升级，大概是一个人花了不到一个月的时间，把全行上万的容器全部进行升级，基本不会对上层的业务造成打扰。所以轻容器相比富容器模式有了极大的提升。

• 不可变基础设施

早期发布时，这是分阶段的，一般要先创建服务器，再下载依赖，过程中可能还要安装一些插件。全程存在很多变量，包括环境标记，依赖于不同人的配置能力。

早期配置的过程，会把一部分代码的参数放在配置平台。相当于引入一个可变的变量。

当配置平台发生一些变化，整个部署的效果就可能会出现差异，最明显的就是线下环境部署没问题，但在生产过程可能会发现问题。

怎么解决？在云原生架构理念上，我们考虑把所有的信息都放在镜像化包中，最大的好处是所有东西都包含在一个镜像里面，就可以从镜像环境到生产环境都使用同一个镜像。

这个过程需要应用保证它的无状态化。如果做不到无状态化，它就不能做到自动的扩收容和自动恢复。

从图中可以看出，我们的镜像是分层的，这有利于不同的团队可以聚焦在自己的那一部分，然后整合起来形成一个大的镜像。在发布过程中，能保证质量品质的一致性，不会受限类似于一些环境或者人的操作水平。

• 单机故障问题的云原生解决方法

在实际的生产过程中，全行几百个系统最典型的问题是单物理机故障对业务产生的影响较大。

物理机的规模较小，很容易导致部分核心系统的容器分布集中。普通的PC物理机会有宕机问题，造成影响面的半径较大。

比方说一个核心系统，可能有百分之四十容器集中在这台物理机上。当它出现问题，对业务稳定有极大的挑战，即使只是小部分出问题也会引起较大的抖动。

怎么解决？有了云原生架构后，我们根据业务特点，包括应用等级，去制定策略，确保所有的调度不会集中在个别的物理机上，也可以说是把它“打散”。

另一方面，之前配置中心不能自动发现物理机上的容器问题并自动剔除，通过监控 MOSN的监控状态，探测它的服务健康状态。下发自愈策略后，当它发现监控报警有问题，让它自动剔除。

因为在分布式架构下，很多业务最终会汇集到同一个服务上。怎样保证这些服务占用的资源不会互相影响？这也是我们目前面临的一个较大的挑战。

其实除了物理机故障场景，在实际生产过程中还经常遇到这种问题：因为业务场景增多，有一些日常过程中流量非常少的业务场景，突然间提速后，会导致周边跟业务相关的所有系统发生变化。

这种情况下，很可能出现部分服务器请求积压，导致其他业务请求发到这台服务器时处理时会失败。这种情况下可能会影响很多业务，严重情况时会出现“雪崩”效应。

很多时候联机交易跟批量交易并没有拆分系统，所以他们占用的资源是同一批。

这种情况下，在新的云原生架构下，借助资源调度和流量的标记能力对资源进行隔离使用，这样联机交易和批量任务所依赖的资源就可以区分开来，同时，我们希望把这些批量任务托管起来，做到资源的弹性调度。

当批量任务开始跑批时，能动态给它更多的资源；但没有跑批时，把资源给释放出来，可以减少对联机交易的一些影响。

• 不同业务的流量隔离与调拨

从上图可以看出，当一个流量进到生产系统时，它经过了多个系统，最终它会反映到的底层是容器，当没有进行有效区分时，不同的流量在容器内部是互相干扰的。

基于新的云原生能力，在流量转发的过程，它会有具备染色能力，可以在流量通过mosn时进行标记，让它路由到指定的一些容器上，就可以做到不同业务请求下，它会路由到不同的容器集群里，业务之间的相互影响就得到进一步降低。

最典型的是生产遇到的热点账户问题，很容易导致全行的交易抖动。如果我们可以识别不同的业务所导致的热点，可以做到有效的隔离，发生热点时不会影响到非产生热点的其他业务场景。

而近几年银行在改造数据中心，新中心的流量调度能力以往是比较弱的。

数据中心间的流量调拨的一般做法会在流量入口层做处理。如果投产过程中出现问题，对业务打扰较大。虽然也能做到快速回切，但从银行每天上亿的交易笔数来看，哪怕是几十秒，受影响的用户数可能也非常大。

在新的云原生架构之下，基于mosn可以打造更细粒度流量调拨，从数据中心层面进一步下沉到单个应用级别。可以找一些不敏感的应用服务先切流，避免影响到关键业务内容。

云原生架构的核心价值是可以实现流量的精细化隔离。

在单元化异地多活架构下，可以做到数据中心里某一个逻辑区域的隔离。到云原生架构下，可以把流量的隔离能力做得更细。

原来的模式下，两个业务同时进来，还是会互相影响。而云原生模式，可以按业务等级进行管理。

我们会给不同敏感度的业务打上标记，以此区分业务应该到什么样的容器下去做完成交易。

标记能力因为有MOSN，所以实现起来较容易。相比早期第二代架构做单元化用UID做标记，是通过研发人员编写代码实现的。因此借助MOSN，可以用很低的代价实现这个逻辑。

运用MOSN之后新的数据中心启用方式会有什么不一样？

我们早期做新数据中心压测，一般来说有两种方式。

1、 通过找一些系统进行流量转发。做流量转发往往需要系统自我改造，这样不具备规模化、快速化的复制能力。

2、 直接把流量入口迁入新的数据中心。

早期做数据中心压测时，很难做到较细粒度，这和网商银行是异地多活模式有很大关系。它有一个全局的路由表，如果做不到新旧数据中心隔离，就会有问题。

举个例子：在没有升级能力的情况下，如果做压测，可能就需要让全局路由表在新的数据中心生效。新的数据中心在没有经过充分验证的情况下，一旦路由表生效，生产流量进入就很有可能导致故障。我们通过Mesh进行了路由表的隔离。

新旧数据中心的路由表是有差异的，这个差异体现在哪里？

两个老数据中心生产流量配比可以做到50%：50%，新数据中心没有生产流量，而压测流量在两个老数据中心和新数据中心中配比可以做到40%、40%、20%，压测流量有一部分在新的机房进行处理，根据新的路由表转到了新的数据中心。

Mesh在我们新的实践过程中，可以支撑不同的技术栈。从网商银行建站以来，我们是有一部分外购的系统，虽然它是Java技术栈，但是它可能和我们的体系，比方说基于SOFA，还是有差异的。

实践层面上看，让外购的厂商改成SOFA框架是很难的。传统模式下是希望厂商适当改一部分，框架不用修改，他可能修改服务调用方式，而我行内部的这些自研系统，他会提供某种轻量级的HTTP服务，暴露给外购系统进行互联互通。

整个过程来看，代价是较高的，它对相关的每个系统都有改造要求。

现在随着我们整个业务的发展，特别是智能化和新技术引进，逐渐出现了JAVA之外的其他语言系统，最典型的就是Python、GO语言，这些系统怎样跟Java系统互联互通？这种情况下其实也会带来新的问题。

在云原生模式下，这个问题就变得简单。因为sidecar解决了，像服务发现路由、加密。鉴权，限流等通用性问题，它集成了一些不同的语言，这种情况下，它只要提供一个SDK，轻量化就能对接上系统。

这样服务提供方和服务消费者都不用做大的改动，只要单边系统修改就可以，不需要所有相关方做改造，对我们整个研发效能提升和业务拓展带来非常大的帮助。

未来：可信原生

总结下来，前面提到的云原生实践更多的是在稳定性、效能方面去提升。现在需要关注的问题，在云原生架构模式下，我们做安全会有哪些不一样的地方？

• 解决应用层的安全。

• 从整个基础设施层面做到安全可信。其中包含多个环节，包括硬件准入，从主机的供应链层面可能要防止物理机入侵。

• 从镜像准入层面做一些控制，防止镜像被非法篡改后在生产上运行。

在有了MOSN以后，最大的好处就是可以做到全局的服务和数据鉴权。

原来那种架构模式，如果要做数据鉴权跟服务鉴权，也需要很多系统去改，去做 SDK的升级。

在写入镜像中心时，要做安全可信。

1、首先，控制在研发环境的镜像编译、准入。

2、在整个镜像被使用的过程中，去验证镜像是否安全。

3、从底层的物理机层面，在供应链采购时可能会做准入控制。

4、在上层应用层的容器启动时，我们也会探测它是不是可信的。

有了MOSN，我们在进行服务的鉴权，还有数据的加密都可以下沉到相关的sidecar，这种时候做安全方面的控制都集中在底层的基础设施，可以明显看到云原生带来的红利。

上层的业务可以不用关心相关的要求，基本上安全工程师通过配置一些规则，然后把这些规则下发到全行相关的一些sidecar产品上即可，包括 MOSN、DBMESH。

答疑环节精选

问：压测采用的是生产流量还是模拟的流量？

蒋易民：我们用的是模拟的流量，它跟生产流量是不一样的。这是另外一套账号体系，它不是真实的。

生产流量是真实的用户，压测流量来源于压测平台，且流量并不是同一套流量，用户体系也是不一样的。在存储结构上是同库上两套不同的表（表结构完全一致但表名不同），落的数据处于不同的区域。

问：关于客户统一视图查询的问题。

蒋易民：如果要在多个服务中获得最新的客户信息汇总，就需要把数据集中化处理了。但是从实际的过程看，至少在交易层面，是很少用到客户信息的汇总，更多的是在批处理层面。在批处理层面，我们会把它放到类似于odps大数据平台去解决。

所有数据回流到大数据平台，多库多表，最终会集中到一张表里，这个数据是全量的。

采用 sidecar以后，我们运行这套架构也有较长时间了，对日常其实没什么影响。基本上层业务对它没有什么感知。整个sidecar引进以后，对资源的占用是非常少的，不会影响到整个系统的容量水平。

系列全回顾丨银行系统云化升级·实战体验营

本次实战体验营由雷锋网《AI金融评论》与阿里云联合主办。欲获得所有讲者视频以及PPT回顾内容，可关注公众号“AI金融评论”（ID: aijinrongpinglun），进群获取回放链接。

“工业革命不得不等候金融革命”。

英国学者、诺贝尔经济学奖得主约翰·希克斯的这句原话，道尽了金融与社会经济变迁的规律：历次消费升级伴随的产业结构的演进变化中，银行都发挥了极其重要的作用：

17世纪末，英国依靠中央银行和商业银行体系提供资本燃料和动力。以蒸汽机为标志的工业革命，其实是金融革命的产物。

20世纪初，摩根、卡内基等一众金融大鳄掀起了第二次金融革命，主导了五次并购浪潮，完成了第二次工业革命；

如果说，此前的数百年，是银行为科技革命体注入新的活力。那么，在五年前，银行差点被“科技革命”所抛弃。

作为数据密集型行业，银行业一直是与科技走的最近的一个行业：上个世纪80年代的ATM机、90年代的网上银行、十年前的手机银行。

在以大数据和人工智能为标志的第四次工业革命，银行业的转型并不简单。

在2018年年报里，针对金融科技对传统金融机构的重塑，“零售之王”招行做了深刻反思：

“过去十年，传统金融机构已惘然目睹了金融科技重新定义零售业务的全过程，从支付延伸到存贷款、财富管理，传统银行的资金中介、信息中介职能已受到深刻冲击，信用中介作用亦面临威胁。

随着社会发展从消费互联网向产业互联网深入，金融科技重新定义公司金融和资产管理也迫在眉睫。”

金融科技的转型，不是一次简单的小修小补，而是一次全面的“大扫除”。

首先是底层系统架构的转型，从传统集中式架构转为分布式、开放式架构；其次是业务流程的重塑；再次是用户运营和场景生态搭建。

如果从云计算、人工智能等科技属性的角度来说，网商银行反倒是新银行的“前辈”。

网商银行被认为是“国内首家跑在云技术之上的商业银行”，开了时代的先河。

从2015年起，这家没有线下营业网点的创新金融机构将通过互联网来开展服务。比如，网商银行利用数据智能进行贷款发放，300人就可以支撑了全国的业务量。

2009年9月成立的第一天起，阿里云就是一家金融级的技术和服务厂商，支撑网商银行最初的雏形——牧羊犬项目。

2018年，南京银行宣布联手阿里云，国内首个商业银行分布式核心业务系统顺利上线运营。其基于阿里云飞天系统构建的“鑫云+”平台已服务多家银行的上百万用户，平均每个客户的放款时间只需1秒，日处理订单量可达到100万笔，是原来的10倍。

同年的8月，民生银行通过与阿里云合作，将核心系统上云，并且成立民生科技有限公司。

在一些中小行的身上，也能看到非常多金融云的求变身影。

2020年，民营银行华瑞银行与阿里云正式签署全面战略合作协议，推动华瑞银行核心业务系统加速向云架构转型。

上海华瑞银行科技部总经理叶宁曾表示，“移动银行上云之前，华瑞银行三年软硬件的投入逾千万元，上云之后，每年投入可以控制在数百万元以内。”

2019年底，华瑞银行在阿里云“飞天”云计算操作系统、蚂蚁金融分布式架构SOFAStack、mPaaS移动开发平台和大数据风控平台的帮助下，已成功构建并上线了“祥云”私有云平台，支撑手机银行、营销系统、反欺诈系统、贷款核算等业务系统运行，同时实现了App的迭代升级。

数年的时间，国内大大小小的银行，都实现了“云上作业”。

然而，上云从不是一件简单的事，一味的跟风和不加选择更是不可取，核心在于认真梳理好业务需求和投入产出比。

要知道，上云是过程，而不是目的。在上云之前，银行的IT人员，一定要多问自己几个问题：

不同类型/规模的银行核心上云的价值差异在什么地方？

如何确保核心安全可靠的下移上云？

要启动核心上云下移的工作该如何准备，如何着手，需要考虑哪些方面的内容？

核心上云的实施路径有那些, 采用什么样的步骤会比较好？

核心下移上云目前的生态是什么样子，有足够的服务和支持能力吗？

工欲善其事，必先利其器。思考银行为什么上云，从来不是一件太晚的事情。

基于此，雷锋网《AI金融评论》与阿里云联合主办“银行系统云化升级”实战体验营，邀请到五位顶尖行业专家线上分享。

从本周起，阿里云新金融事业部金融核心部负责人陈威，网商银行基础技术架构部负责人蒋易民，将分别带来《金融核心云原生转型探索与实践》和《构建云原生架构-网商银行SOFAMesh应用实践》的主题演讲。

广度而论，从银行、云厂商、ISV（独立软件开发商）三大角色出发，不同视角讨论银行核心系统与应用的云化改造；

深度而论，专场内容覆盖银行上云的标准与选型、成功上云实战复盘、金融核心建设、云与AI的关系与内涵等多个方向。

本次实战体验营，为雷锋网2021金融云峰会的首场线上活动。后续将有更多嘉宾加盟。

同时，《AI金融评论》也将围绕银行上云、核心系统建设、云金融等主题，陆续推出多篇深度稿件。

为银行业乃至金融界，和科技圈，输出最立体化、最具前瞻性和参考价值的银行云、金融云内容，同时搭建高质量的微信社群，促进上下游企业交流探讨。

关注《AI金融评论》，对话框发送关键词“参会”，进入专家微信群，观看直播。

嘉宾分享议程

开场致辞：刘伟光，阿里巴巴集团副总裁、阿里云新金融事业部总经理

嘉宾介绍：刘伟光毕业于清华大学电子工程系。曾负责蚂蚁集团金融科技的商业推广和生态建设工作，以及蚂蚁链的商业拓展工作。

他在企业软件市场深耕多年，曾经创建Pivotal软件大中华区分公司，开创了企业级大数据以及企业级云计算PaaS平台的市场先河。

在创建Pivotal中国软件公司之前，刘伟光曾经担任EMC公司大中国区数据计算事业部总经理，并在Oracle公司工作多年，曾经创建了Exadata大中国区的产品事业部并担任事业部总监。

第一场：张晓丹，阿里云新金融事业部CTO

演讲时间：1月19日（周二）20:00-21:00

演讲主题：《新一代金融IT基础设施：阿里云的金融云前瞻与实战》

演讲大纲：

• 金融IT基础设施发展需求与趋势

• 金融云应用场景 

• 打造安全、稳定、敏捷的云上金融

嘉宾介绍：曾任工商银行总行部室副总级专家，先后在工行分行、数据中心、总行IT部门任职22年。

曾任恒丰银行科技部总经理，期间建设了国内银行业第一家多租户的金融IAAS行业云，首次将一家全国性股份制银行的应用系统全部迁移上云。

2018年，张晓丹加入阿里云。

第二场：吴守钰，中电金信（原文思海辉）金融解决方案事业部产品总监

演讲时间：1月21日（周四）20:00-21:00

演讲主题：《建设基于金融云敏态业务系统的探索与实践》

演讲提纲：

• 从云下到云上，从稳态到敏态

• 云上敏态业务系统要点分析

• 云上敏态业务系统建设实践

嘉宾介绍：拥有18年金融IT行业经验，熟悉银行互联网金融、开放银行、核心系统、支付结算等领域，有丰富的行业调研、架构设计、需求分析、产品研发等经验，擅长云环境下的银行解决方案设计，近年专注于数字化转型方向产品研发与项目实践。

第三场：陈威，阿里云新金融事业部金融核心部负责人

演讲时间：2月2日（周二）20:00-21:00

演讲主题：《金融核心云原生转型探索与实践》

演讲大纲：

• 银行核心系统云化转型的诉求

• 核心云原生转型的挑战与应对

• 相关路径与案例介绍

嘉宾介绍：现任阿里云新金融事业部金融核心部负责人，负责金融核心相关解决方案。曾从事企业级信息技术产业十余年，具备丰富的应用架构与设计，数据智能，云平台，互联网等领域的理论与大型复杂项目实践，尤其在金融行业具有多年的交叉实践经验，服务于近百家大型机构与客户。

第四场：蒋易民，网商银行基础技术架构部负责人

演讲时间：2月4日（周四）20:00-21:00

演讲主题：《构建云原生架构-网商银行SOFAMesh应用实践》

演讲大纲：

1、网商银行开业以来基础架构的演进历程 

2、网商银行基础架构演进和业务发展过程中的典型问题 

3、网商银行基于云原生架构的应用实践和展望

嘉宾介绍：负责全行基础架构的规划、落地以及全局稳定性保障，打造高可用，高并发的系统技术底盘，经过3年发展，将全行核心交易峰值能力由50TPS提升到50000TPS，从开业以来参与和见证了技术底盘的快速演进，完整经历了“同城双活”到“两地三中心”再到“三地五中心”的发展历程，主导了异地多活单元化、混合云弹性和云原生架构的落地，荣获过人民银行科技发展奖。

如何预约专场？

1、关注公众号“AI金融评论”（ID：aijinrongpinglun）

2、在公众号对话框回复关键词“参会”，即可进微信群观看直播，亦可与技术大佬们谈笑风生。

本次活动面向的人群

• 银行信息技术/IT部门，和研发部门团队；

• 云服务供应商、金融科技公司高管；

• 传统IT厂商和软件供应商高层；

• 券商、险企等持牌金融机构IT建设部门；

• 高校计算机、软件专业、人工智能教授与研究生

雷锋网雷锋网

但也正是因为这样的“上云潮”出现，业界需要更加深入探讨：到底银行核心系统转型的诉求是什么？价值又何在？到底有哪些成功案例可供借鉴参考？

核心业务系统，自然是银行的“核心”。对银行核心上云的讨论，则是银行云化升级进程里的“核中之核”。

为此，雷锋网《AI金融评论》与阿里云联合主办“银行系统云化升级”实战体验营，第三场演讲由阿里云新金融事业部金融核心部负责人陈威带来。

明晚8点，陈威将针对金融核心云原生转型这一主题，带来阿里云近年来的实践探索经验。

演讲嘉宾

陈威，阿里云新金融事业部金融核心部负责人

演讲时间

2月2日（周二）20:00-21:00

演讲主题

《金融核心云原生转型探索与实践》

演讲大纲

• 银行核心系统云化转型的诉求

• 核心云原生转型的挑战与应对

• 相关路径与案例介绍

嘉宾介绍

陈威，现任阿里云新金融事业部金融核心部负责人，负责金融核心相关解决方案。曾从事企业级信息技术产业十余年，具备丰富的应用架构与设计，数据智能，云平台，互联网等领域的理论与大型复杂项目实践，尤其在金融行业具有多年的交叉实践经验，服务于近百家大型机构与客户。

近两年，利用科技革命实现银行产品和服务的线上化、移动化，成为大势所趋。从渠道体系到核心系统，银行正在经历全面的数字化。

但是，2020年突发的疫情，让银行业从常态、稳态的运行环境中，切换到一个不确定状态。

传统集中式架构和分布式架构，两者一直存在着技术争论：分布式架构银行由传统IT架构支撑的核心系统，一时半刻不可能完全抛弃。但同时，银行也希望像互联网企业一样，敏捷地支撑应用场景，敏捷地支撑业务开发。

敏捷响应，成为银行金融服务能力的一大考验。

作为中国电子旗下帮助金融行业数字化转型的代表，中电金信（原文思海辉）在建设金融云敏态业务系统方面有着自己的心得。

中电金信金融解决方案事业部产品总监吴守钰，从用户域、产品域、支付域、公共域等四大基础能力入手，分享了金融云敏态业务系统的架构和功能实现。

以下是吴守钰的演讲内容，雷锋网做了不改变原意的编辑与整理。

大家好，很高兴能够参与本次的云峰会。我叫吴守钰，任职中电金信数字银行部产品总监。

今天，我分享的主题是《建设基于金融云敏态业务系统的探索和实践》，主要分享我们在建设金融云敏态业务系统方面的一些理解和实践。

近几年，在金融新业态下，商业银行面临着新的挑战：

一、经济双循环，引新与活存并重，To B领域持续创新，商业银行需要快速适应市场变化；

二、监管趋严：近期金融监管政策不断出台，划分厘清银行与互联网平台的边界，要求银行回归本源、服务实体、产业赋能；

三、新科技：ABCDMIX技术日益成熟，应用越来越广泛，重塑金融科技。

在新背景下，商业银行IT系统建设呈现出了六大方面的趋势：

平台型银行，平台化经济实现价值提升；

开放型银行，服务自营渠道、服务开放生态伙伴，能力和服务具有对内外共享开放属性；

生态型银行，建立生态圈和生态体系，拉近、拉紧与各类合作伙伴的距离和关系；

体验型银行，提升用户体验，构建用户全旅程，提供个性化服务；

敏捷型银行，具备从IT架构、业务能力、场景金融等多方面的快速适配能力；

智慧型银行；

以上市场变化和系统建设趋势，都指向了“敏”，敏态的技术平台和敏态的业务系统；建设基于金融云的敏态业务系统正是对症下药的一剂良方。业务中台是敏态业务系统的基础设施之一。

业务中台，实现上是对业务能力的综合治理，可以分为三层，从下往上看：

最下层是基础能力层。

根据领域化分可分为用户、产品、支付、公共等能力域，每个域内部又包含若干基础能力中心。

用户域：解决平台谁用的问题。建立开放用户体系，对包括银行内外的使用者、各类产品和服务的上下游等，进行统一的管理和治理；具体又可以分为用户、合约、标签画像、营销等能力中心；

产品域：解决平台卖什么的问题。对各类金融、泛金融、生活服务等产品进行工厂化管理，建立分类的产品模型，实现产品组合、差异化定价、绩效评估等。账户也可一类特殊产品纳入产品域，包括资金账户、权益账户、关联账户等，支持账户的组合和创新，如集团账户、钱包账户、创新存款等；

支付域：解决资金流转及流转过程中的控制问题。可分为支付、费用、额度、对账等中心。其中支付中心实现线上线下一体化收单、聚合支付、资金划转拨付、代收代付等服务，通过模型化的订单流转和支付决策引擎实现标准、高效的流转；费用中心实现费用计收、清分、分摊等功能；额度中心实现用户、渠道、场景、产品等不同主题的限额管理；对账中心实现实时、定时等的交易检查、核对。

公共域：提供安全、消息、资源中心、审批和运营等功能能力。

第二层是场景构建工具。

我们称之为服务编排，可分为两大中心：交易中心和参数中心。

交易中心通过可视化流程编排IDE平台实现对内外部微服务的编排，提供运行态的订单化处理；

参数中心实现对能力、产品、流程、运营等参数的维护和管理，包含参数定义，更新、下发、订阅、变更、同步等功能。场景构建工具让业务人员、运营人员能参与到开发、运营过程中，看得懂、能维护。

通过以上两层，实现强中台、大中台的能力支撑，及敏捷交付能力。

最上层是场景服务层。

包括银行自营场景、开放银行场景及其他合作运营场景。

有效的资产、服务的治理，通过标准流程、动态参数管理，实现前中后全流程的数字化管控，提升综合服务能力。

敏态业务系统的实践

下面介绍一些我们在阿里云平台上构建敏态业务系统的实践。

某省农信依托于阿里云，建设了行内敏态系统，该系统目标及定位如下：

提高系统的可用性和可靠性；

降低对基础设施投入的成本，以及运维、管理的成本；

提升快速响应能力以及系统服务能力。

系统支持多法人、核心业务系统下移、分布式场景下的研发运维一体化、存量应用系统云化改造、三地多中心多活架构，以及分布式场景下的安全运维管理方案等。

业务中台分为基础能力层和场景层，既提供宽度、深度，也实现敏捷快速交付。

某城商银行的数字化业务系统建设项目，技术底座采用阿里云平台，建设范围包括业务中台、数据状态、运营中台等。业务中台由基础能力中心提供厚度，自营及开放场景服务中台提供敏捷业务交付。

通过与阿里云效平台集成，提供了从需求、设计、开发、测试、上线到运维的一体化服务。

中电金信是中国电子旗下的成员企业，是中国规模最大的银行业IT服务公司，连续三年在中国银行业IT解决方案市场排名第一。

中电金信员工超过26000人，拥有数字化业务、数字化营销、数字化运营等的完整的金融解决方案体系和服务体系。

以上是我今天的分享内容，谢谢大家。雷锋网雷锋网

金融机构IT架构的“成长”中，有太多“阵痛”：

• 从集中式演变到分布式，标准化、开放化的建设是有了，应用人员要操心的事为什么更多了？

• 一台大机支撑上万台服务器，是很节能环保，但研发周期太长、售价太贵，一个性价比更高、更敏捷开放的替代方案是怎样的？
  

• 银行如果不做全面上云，继续长期维持双模IT，不可行吗？

• ……
  

在阿里云新金融事业部CTO张晓丹看来，谈金融机构的IT建设，谈云架构转型，其实不只是在谈一个技术问题，同时还是一个经济问题。

这场IT架构的云化改造，不仅事关时间、人力、物力，更关乎金融机构的人员能不能摆脱复杂架构的束缚，更加专注业务和应用的创新。

“整个IT基础设施交由专门的金融行业云承载，实现按需、敏捷、弹性获得算力以支撑应用创新。”张晓丹这样概括发展金融行业云的目标。

在雷锋网《AI金融评论》与阿里云联合主办“银行系统云化升级”实战体验营中，这些围绕在金融云化周围的疑问被一一解开。

本次实战体验营的首日分享中，阿里巴巴集团副总裁、阿里云新金融事业部总经理刘伟光带来开场致辞，他表示银行业正在全面应变，掀起线上化、数字化、智能化的变革，无处不在的银行服务逐渐由蓝图变为现实。

此后，阿里云新金融事业部CTO张晓丹带来了首场演讲——张晓丹曾是工商银行总行部室副总级专家，先后在工行分行、数据中心、总行IT部门任职22年；在恒丰银行出任科技部总经理期间，建设了国内银行业第一家多租户的金融IAAS行业云，首次将一家全国性股份制银行的应用系统全部迁移上云。

这次，他结合自身二十余年在银行的IT经验，分享金融IT基础架构全面云化、机构应用迁云实录等干货。

以下为经雷锋网AI金融评论编辑的张晓丹演讲内容：

大家好，我今天分享的主题是《阿里金融云，新一代金融IT基础设施》。

金融IT基础架构的全面云化

整个金融行业正在面临着向数字化转型的大潮过程，这个阶段中，我们不断在发展在线化、数字化以及网络化、平台化以及智能化。转型过程对金融IT基础设施提出了更高的要求，需要我们能够按需、敏捷、弹性的获得更经济和廉价的算力。

传统的IT架构比较安全、稳定、可靠，但是其开放性、弹性、敏捷性、经济性存在一定的局限性，所以需要不断向云架构进行转型和升级。

在这个过程中，私有云、行业云、混合云，还有公共云具备各自的优、劣势。我们专门为金融机构建设一个行业云，跟现有的私有云进行混合，在提升金融云的监管合规、安全稳定的同时，最大限度地提升经济效益。

• 为什么要向云架构转型？

首先，降低成本，提高效率。

云本身，不仅仅是个技术问题，还是经济问题。

通过规模化的运营、建设和共享实现规模效益，以获得便宜、廉价的算力。通过软件化、系统化和服务化，提升整个运行效率，间接降低成本。

第二，云转型的核心就是要改变应用架构和原来的技术路线，广泛采取近十年来发展起来的开放开源、分布式的互联网技术路线，提升整个应用研发的敏捷性，促使研发和运行一体化以支撑业务的敏捷和迭代。

一旦IT能够低成本，提升敏捷度与迭代，整个业务竞争力会跃上一个新台阶。以前长期的自上向下的建设，变成快速走向市场、并与用户进行业务尝试和迭代，在业务与客户的互动过程中来升级业务系统，其中会不断应用到一些分布式、微服务、云原生的技术。

第三，保持整个IT技术路线的现代化。长期不升级会带来技术架构的老化，运行风险增加和效率低下，以及人才队伍难以保持等问题。只有进行稳定、持续的架构升级，才能保证整个IT的能力。

云架构也是借助于云平台化的效应，来拓展金融机构的业务边界。通过开放银行、开放证券、开放保险，和周围的生态各方建立网络化的连接，拓展自己的业务场景，从线下走向线上。

再者，利用高性价比的、丰富的按需可获的资源，加上数据化处理能力，帮助金融机构在架构转型的过程中，树立起以积累数据资产为目标的客户运营、流量运营的意识，提升企业运用数据智能的能力，提供高精准、更高效的客户服务。

未来的竞争是数据智能的竞争，只有拥有更多的数据资产，建设强大的数据中台，才能实时支撑好数据的智能并且发展业务。

IT架构的发展历程，从最早的大型机、小型机等集中式架构，再到scale-up架构，基础设施、应用架构、研发模式都发生了很大的变化。

随着整个架构的演变，最大的问题是成本高，研发周期过长，一台大机能够支撑上万台的服务器的能力,节能环保。但研发成本周期长、成本高，售价太贵。

同时，传统的应用架构技术比较封闭，生态没有得到发展，而分布式云原生架构，目的就是更加开放，更加敏捷。

原来在一台大、中型机以及小机里面，操作系统、应用软件、中间件，数据库都在一台大机器里运行，是一种高度集中耦合的架构。

而分布式架构，开始用一堆的服务器来替代大机时，相应地，就从一个操作系统变成很多小的操作系统——如何将这些小的操作系统重新耦合起来，变成一个大的操作系统，就是IaaS云的使命。

• 全面上云怎样降低IT基础设施的总拥有成本？

上层从一个大的中间件，演变成一个分布式的微服务架构；从原来的SOA，进一步发展到分布式微服务，再发展到现在的服务网格。

集中式架构与云原生架构之间的分布式架构阶段，存在一个问题：

当底层开始从几台大型机器，变成众多的小型机器及服务器以后，上层做应用开发的人员，将要面对下面的分布式的计算架构。

因为下面的平台封装得不太好，能力不太强，所以使得上层原来只关注业务和逻辑的开发人员，开始更多关注下面的基础架构。

虽然技术架构的建设更加标准化、开放化，但是应用开发更加复杂，应用人员要关心的事也越来越多。

进一步的云原生架构转型，实际上是经过循环迭代以后，回归到更高层次的平台化、服务化水平。将分布式架构的复杂性封装在整个云平台，其中包括IaaS、PaaS、DaaS等各种技术，让业务和开发重新回归到业务逻辑，而不需要太关注下面的平台。

最上层的业务中台、数据中台、协同平台、AIOT平台，以及支撑其的服务网格、湖仓一体、HTAP、流批一体等技术，都是为了把平台越做越厚，让基于分布式架构的应用开发越来越简单。

底层是从大机、小机、物理机到虚拟机、容器，以及兼具容器和虚拟机的特性的安全容器。

原来的大机通过专有的网络连接大容量的集中存储阵列，到后面小机通过SAN网络连接SAN存储的计算存储分离架构，发展到现在：没有硬盘的神龙服务器，通过标准的以太网连接后面分布式的云盘，形成新一代的计算存储的分离架构，从原来的两地三中心发展到现在的两地四中心、多地多中心的新的容灾体系架构，对原有的体系架构进行全面升级。

在这个过程中，金融云的底层的平台完全交给云服务商进行建设，使得金融机构的人员将专注力放在业务和应用的创新上。对金融机构而言，它有资本充足率的限制，宝贵的核心资本，实际上是要用于金融业务的发展更加高效。

银行的核心竞争力实际上并不在IT基础设施，而是在应用研发和业务的创新方面，帮助中小金融机构整个IT基础设施交由专门的金融行业云承载，实现按需、敏捷、弹性获得算力以支撑应用创新，是我们发展金融行业云的目标。

• 上行业云过程中，需要考虑的问题

从规模化建设和运营角度来看，我们持续在做规模化的运营，用液冷将机房的PUE下降到一点零几的PUE，通过每年几十万台服务器这种规模化的采购以降低其成本，甚至采购零配件自己组装服务器，云服务价格每年持续的下降，可以给客户带来综合的TCO（总拥有成本）的下降。

在对比TCO成本的时候需要考虑几个因素：

第一，必须要全面上云。如果长期维持着双模IT，而且是以过去老旧传统架构为主的双模IT，客户长期维持两套技术架构和运维体系，是很难节省成本的。

在全面上云的过程中，将原来的传统的硬件F5、负载均衡、防火墙、DNS，加密机等专有硬件设备，都用部署在标准服务器上软件集群来替代，通过NFV替代各种硬件网络设备，以实现全面降本，效益将更加明显。

在上云过程中还解决了软件正版化的问题，不能用原来没有采购跑量的授权软件来与现在的云授权软件做比较：同时IDC建设往往有很大的空闲面积和空闲资源的闲置成本。再将建设机房所用的变电站和维保核算进来，成本是很高的。

上云以后，降低成本的核心是on demand的能力。

On demand就是按需获得资源，获得资源后随时可以释放，所以上云以后一定是要把应用部署进行扩展，能够弹性、敏捷得以进行。

其目的就是需要计算时，将整个基础资源容器化全部拉起，计算完成以后，所有的资源释放，不再继续收费。现在的Serverless、函数计算都是这样的目标，只有达到这个程度以后，才能最大限度的节省成本。

上云以后，底层的IT基础设施这部分的容灾、运维、高可用、切换都交给了服务商，实际上变相降低了人员成本。

未来数据中心、IT技术设施的建设和运营，包括在软硬件上的投入和在人员上的投入，将会呈现出不同的比例。

未来当IT人员能够占到像国外的金融机构的15%的比例，甚至占到金融科技公司40~50%比例时，人员成本会大幅高于软硬件的成本。

我们进行云架构的转型，核心目的就是节省人力成本。

• 中小保险&金融云

在金融云上，会构建出保险所需要的一些能力。我们会与中科软、软通动力、易宝、文思海辉等各种ISV合作，将他们的应用软件和云上的IT基础设施IaaS、PaaS提前对接，客户在迁云过程中不需要自己全客支付改造成本，进行应用的兼容和适配。

同时与一些中保车服等行业云的客户，一块为中小保险提供服务。

保险业是一个监管比较开明的行业，将IT架构搬到云上，实际上会带来很大的收益。

• 中小证券基金&金融云

由于证券业务的特殊性，券商对4个小时内高可用的要求很高，甚至超过银行，所以对可能存在的交易敏感性，和出现故障的损失性，在合规符合性、系统安全可靠性没有得到实际长期验证之前，监管还是不放心进行集约化的、公有云式的管理。

对此，我们与上交所在三年前已经构建了一个合建的证券行业云，联合建设、联合运营，共同进行对外销售和售后服务。

通过对这个行业云的建设，帮助中小型证券和基金，将其整个系统托管到离上交所交易所最近的机房，在本地建立一个同城多中心的容灾架构，上面提供各式各样的服务，中小金融机构和中小证券基金行业就不用再建设自己的机房了。

金融云XaaS的产品服务能力

金融云上整个的产品架构，基本上跟公有云上所有产品都是一样的。

最底层是内部的数据中心的机房能力，再上层是IaaS能力，然后是DBaaS数据库服务化的能力，还有包括 Paas层的各种能力。

• mPaas移动开发平台何以“最受欢迎”？

在金融云上，除了Paas能力，我们还会提供一些特色的业务。

比如阿里最具特色、最受客户欢迎的移动平台——mPaas，很多机构使用这个平台构建自己的手机APP系统，打造一个超级APP移动开发平台，它甚至是一个开发、运行、测试、运营一体化的平台。

它脱胎于支付宝强大的 APP底层能力，不仅提供安全稳定的开发管理，还将其变成一个客户运营和流量运营的平台。

这个平台支持native的移动开发，提供一个小程序框架。客户可以把支付宝等平台上的所有小程序迁移过来，也可以利用小程序框架发展自己的小程序生态，让周边的生态合作伙伴不用开发非标小程序，直接将既有其他平台上的小程序迁移过来。

• 不同成熟度应用的全面迁云

我们对金融行业也是支持不同成熟度的应用，都能够全面的迁云。

现在的很多传统应用还是处于传统、标准和成熟的虚拟化的应用阶段。我们希望这些应用能够向云上进行迁移。

云上迁移并不是要做很多很复杂的改造，例如应用的自维护、自描述，是否进行分布式改造、服务网格改造，我们希望在虚拟化的标准化和成熟度状态，做少量的适配、修改，就能够迁移到云上，不同成熟度的应用迁到云上，可以获得不同云上的红利和特性。

云的原生化改造越强，就能更好的获得云原生的特性。云原生实际上就是云的核心的按需自助，敏捷、弹性等方面的能力。

我们会在上云过程中对所有客户的应用、可用性、连续性、容量性能都做一些分类和标准，根据它不同的要求，制定其上云的标准的部署模板，然后分批进行迁云。

近期，雷锋网《AI金融评论》与阿里云联合主办“银行系统云化升级”实战体验营，关注公众号“AI金融评论”（ID：aijinrongpinglun），回复关键词“参会”，立即进群观看直播。

其中最受关注的IT建设问题之一，就是稳、敏双态业务与金融云该如何“协同作战”。

当银行面对上云大潮，同时自身又有庞大业务扩展需求，云厂商和ISV服务商应该怎样助力银行？

基于此，雷锋网《AI金融评论》与阿里云联合主办“银行系统云化升级”实战体验营，邀请到多位顶尖行业专家线上分享，讨论银行核心系统与应用的云化改造，内容覆盖成功上云实战复盘、金融核心建设等方向。

今晚8点，中电金信（原文思海辉）金融解决方案事业部产品总监吴守钰将带来第二场演讲，以18年金融IT行业经验，分享敏态业务系统如何基于金融云进行探索与实践。

近期，《AI金融评论》也将围绕银行上云、核心系统建设、云金融等主题，陆续推出多篇稿件，为银行业乃至金融界，和科技圈，输出最立体化、最具前瞻性和参考价值的银行云、金融云内容，同时搭建高质量的微信社群，促进上下游企业交流探讨。

欲了解更多活动详情，可联系负责人周蕾（微信：LorraineSummer）。

演讲嘉宾

吴守钰，中电金信（原文思海辉）金融解决方案事业部产品总监

演讲时间

1月21日（周四）20:00-21:00

演讲主题

《建设基于金融云敏态业务系统的探索与实践》

演讲提纲

从云下到云上，从稳态到敏态

云上敏态业务系统要点分析

云上敏态业务系统建设实践

嘉宾介绍

吴守钰拥有18年金融IT行业经验，熟悉银行互联网金融、开放银行、核心系统、支付结算等领域，有丰富的行业调研、架构设计、需求分析、产品研发等经验，擅长云环境下的银行解决方案设计，近年专注于数字化转型方向产品研发与项目实践。

但还有多少人的普遍认知只停留在“银行应该上云”？

在这个肯定的答案背后，还有太多的疑问没有被解开：

银行怎么上云？怎样才算上云？从核心系统到应用上云，定义、选型、场景、标准、优先级、与AI的关系、为数字化转型创造的价值……

这些问题，不只是银行要面对的“迷云”，更是所有金融机构未来数年必须直面的议题，也是金融科技助力一切业务和细分场景之前，最该优先解决的基础设施建设问题。

五年前，银监会就明确指示：截至“十三五”末期，银行业面向互联网场景的重要信息系统全部迁移至云计算架构平台，其他系统迁移比例不低于60%。

过去的五年，是银行云乃至整个金融云行业迅速发展、国产云厂商蓬勃成长的五年。但五年时间过去，这些众说纷纭的疑问，仍未得到太确切的定论。

下一个五年已经到来，我们试图找到解答。

基于此，雷锋网《AI金融评论》与阿里云联合主办“银行系统云化升级”实战体验营，邀请到四位顶尖行业专家线上分享：

• 广度而论，从银行、云厂商、ISV（独立软件开发商）三大角色出发，不同视角讨论银行核心系统与应用的云化改造；

• 深度而论，专场内容覆盖银行上云的标准与选型、成功上云实战复盘、金融核心建设、云与AI的关系与内涵等多个方向。

本次实战体验营，为雷锋网2021金融云峰会的首场线上活动。后续也将有更多嘉宾陆续加盟。

同时，《AI金融评论》也将围绕银行上云、核心系统建设、云金融等主题，陆续推出多篇深度稿件。

为银行业乃至金融界，和科技圈，输出最立体化、最具前瞻性和参考价值的银行云、金融云内容，同时搭建高质量的微信社群，促进上下游企业交流探讨。

欲了解更多活动详情，可联系负责人周蕾（微信：LorraineSummer）。

嘉宾分享议程

开场致辞：刘伟光，阿里巴巴集团副总裁、阿里云新金融事业部总经理

嘉宾介绍：刘伟光毕业于清华大学电子工程系。曾负责蚂蚁集团金融科技的商业推广和生态建设工作，以及蚂蚁链的商业拓展工作。

他在企业软件市场深耕多年，曾经创建Pivotal软件大中华区分公司，开创了企业级大数据以及企业级云计算PaaS平台的市场先河。

在创建Pivotal中国软件公司之前，刘伟光曾经担任EMC公司大中国区数据计算事业部总经理，并在Oracle公司工作多年，曾经创建了Exadata大中国区的产品事业部并担任事业部总监。

第一场：张晓丹，阿里云新金融事业部CTO

演讲时间：1月19日（周二）20:00-21:00

演讲主题：《新一代金融IT基础设施：阿里云的金融云前瞻与实战》

演讲大纲：

• 金融IT基础设施发展需求与趋势

• 金融云应用场景 

• 打造安全、稳定、敏捷的云上金融

嘉宾介绍：曾任工商银行总行部室副总级专家，先后在工行分行、数据中心、总行IT部门任职22年。

曾任恒丰银行科技部总经理，期间建设了国内银行业第一家多租户的金融IAAS行业云，首次将一家全国性股份制银行的应用系统全部迁移上云。

2018年，张晓丹加入阿里云。

第二场：吴守钰，中电金信（原文思海辉）金融解决方案事业部产品总监

演讲时间：1月21日（周四）20:00-21:00

演讲主题：《建设基于金融云敏态业务系统的探索与实践》

演讲提纲：

• 从云下到云上，从稳态到敏态

• 云上敏态业务系统要点分析

• 云上敏态业务系统建设实践

嘉宾介绍：拥有18年金融IT行业经验，熟悉银行互联网金融、开放银行、核心系统、支付结算等领域，有丰富的行业调研、架构设计、需求分析、产品研发等经验，擅长云环境下的银行解决方案设计，近年专注于数字化转型方向产品研发与项目实践。

第三场：陈威，阿里云新金融事业部金融核心部负责人

演讲时间：2月2日（周二）20:00-21:00

演讲主题：《金融核心云原生转型探索与实践》

演讲大纲：

• 银行核心系统云化转型的诉求

• 核心云原生转型的挑战与应对

• 相关路径与案例介绍

嘉宾介绍：现任阿里云新金融事业部金融核心部负责人，负责金融核心相关解决方案。

曾从事企业级信息技术产业十余年，具备丰富的应用架构与设计，数据智能，云平台，互联网等领域的理论与大型复杂项目实践，尤其在金融行业具有多年的交叉实践经验，服务于近百家大型机构与客户。

如何预约专场？

1. 关注公众号“AI金融评论”（ID：aijinrongpinglun）

2. 在公众号对话框回复关键词“参会”，即可进微信群观看直播，亦可与技术大佬们谈笑风生。

本次活动面向的人群

• 银行信息技术/IT部门，和研发部门团队；

• 云服务供应商、金融科技公司高管；

• 传统IT厂商和软件供应商高层；

• 券商、险企等持牌金融机构IT建设部门；

• 高校计算机、软件专业、人工智能教授与研究生

雷锋网

通过永安在线数据资产泄露风险监测平台统计，金融行业是数据资产泄露的主要来源，占到了42%，而数据资产泄露高发的互联网行业也只排名第二，占27%。出现这种情况是因为金融行业涉及到的人群大多是高净值人群，数据转化率高，变现能力强。

腾讯云数据库TDSQL首席架构师张文认为：“虽然企业数据安全不只依靠数据库，但数据库一定要做这种最后一根救命稻草的保障。”

张文还介绍到，“数据的误删、误操作，对于一些银行客户而言，可能一年或者几个月都不会发生一次，但是，我们面对着云上的客户，每天都有客户误删、误操作，在这方面TDSQL积累、总结了大量的经验、教训。对此，我们也有很多的解决方案包括SQL防火墙、透明加密、自动备份等——如何更快速的帮助用户找回数据、恢复其可用性，经过这么多年的打磨，我认为我们是非常专业的。”

恰逢新年，雷锋网《AI金融评论》邀请到张文参加「银行业AI生态云峰会」，他分享了腾讯云是如何在「银行数据库」这一领域深耕发展；如何在国外商用数据库的“压力”下，突破求生，拿下多个银行核心系统大单。

目前「银行业AI生态云峰会」已成功举办4场，微众银行区块链安全科学家严强、达观数据联合创始人纪传俊、腾讯云数据库TDSQL首席架构师张文、阿里云金融科技AI产品负责人王巍给观众带来了十分精彩的演讲，后续还将有360数科首席科学家张家兴、融慧金科董事长兼CEO王劲、华为云FusionInsight首席架构师徐礼峰、摸象科技董事长高鹏等众多大咖前来分享最新、最有货的科技观点。

以下为张文的演讲内容，雷锋网AI金融评论作了不改变原意的编辑：

大家晚上好，很高兴能在雷锋网这个平台带来关于分布式数据库的分享，今天主要的议题是《腾讯云分布式数据库在银行核心系统的改造实践》。

众所周知，2020年12月24日，腾讯云数据库官宣TDSQL品牌整合升级计划，集中发力数据库技术创新突破。腾讯云原有的TDSQL、TBase、CynosDB三大产品线统一升级为“腾讯云企业级分布式数据库TDSQL”。全新升级后的腾讯云TDSQL将涵盖金融级分布式、分析型、云原生等多引擎融合的完整数据库产品体系。本次分享将主要以金融级分布式版TDSQL的实践进行介绍，下述以“TDSQL”为简称。

基础技术创新背景与当前行业趋势分析

银行的“核心系统”，对于数据库厂商而言是一个比较大的挑战。

银行，我们都知道有核心系统和外围系统，核心系统是银行心脏中的心脏。

银行的核心系统改造，对于数据库厂商而言是一个很大的考验。数据库厂商需要面对包括数据的一致性、高可用，以及SQL的兼容性等等一系列复杂问题。

信息技术创新的大势所趋

过去我们的核心系统，包括银行核心，还有一些政务核心系统，对外国厂商的依赖度超过了90%，包括软、硬件，硬件主要是依赖于国外的大型机，小型机。

软件方面，像操作系统和数据库软件，整个一套技术架构都采用的是国外的产品。直到现在，在技术自主创新大趋势浪潮下，从硬件到软件，我们逐步在进行国产化的探索。

硬件上，我们开始尝试用基于X86或者是ARM的国产化硬件，以构成底层的硬件平台；软件上，从操作系统到数据库，包括一些中间件，在国产化方面近几年涌现出了很多基础类软件。

所以，现在整体的技术导向是：从软件到硬件整个基础平台开始向国产化的态势发展，而不仅仅局限于数据库。

金融级分布式数据库的挑战与难点

分布式数据库的挑战（技术层面）

对于分布式数据库而言，如何迎合这样的契机和挑战？

为什么早期国外的商用数据库和商用的基础软件，在国内的银行、政务系统占据了大量份额？大部分企业选择这些基础软件，主要诉求是其稳定性。以稳定性为口碑，经过多年打磨，因而国外厂商的这些软件占据了垄断性的地位。

这种垄断性地位在短时间内是不容易被打破的，因为它有个长时间的市场效应，对于使用国外软件的这些厂商而言，一旦涉及到替换或者升级，就容易产生一些兼容性问题，还有一些迁移成本和改造难度等问题。

对于国产的分布式数据库，如果想要切入政务及银行系统，首先需要打破长期被国外商用数据库建立起来的一系列壁垒，这些壁垒对于国产物数据库是一系列的挑战点。

强一致性高可用

作为金融级数据库，可用性和数据强一致性是至关重要的，因为在金融场景下，一条数据的价值是无法估量的，没法评估它到底是错了一分钱还是一个亿，或者更多，所以金融级高可用是国产分布式数据库首要面对的一个挑战。

性能成本

在国产化方面主要基于廉价存储，因为在分布式的架构下，可以实现线性水平扩展。但是数量对于分布式数据库而言，并不是一昧的堆机器、堆存储、堆计算，那样实际上是很浪费资源的。分布式数据库组成一个较大的集群，假如有上千台机器，那么如果在性能方面提高20%，就能节省上百台的机器，甚至能节省出来一个机房。

所以，性能成本也是分布数据库一直在探索的以较低的成本获取较高的性能，这也是我们追求的一个性价比。

水平伸缩

对于分布式数据库，水平伸缩能力是必须要具备的，因为分布式数据库在互联网场景算是需要比较常态化的水平伸缩。

例如应对如双11购物节、春晚红包的突增流量，需要有一个迅速的弹性扩展能力以承载这些流量。而业务有峰值就有谷值，活动结束后，需要再将这些资源进行回收。这种水平伸缩能力，是分布式数据库应当具备的基本点，任何分布式数据库都需要具备这种可伸缩、可拓展的能力。

产品化程度

产品化程度是用户能否快速上手的关键。

比如从一个传统的集中式数据库转换到分布式数据库，尤其是对于一些政企类、金融客户而言，他们能否从传统观念或者传统数据库的环境下，过渡到分布式数据库的环境和条件，这类客户其网络往往跟外网是隔离的，也就是在用户出了问题之后，我们没法第一时间登录他的环境，帮助其进行调试，就需要他自助的完成。

如果没有比较成熟且产品化的一套解决方案，用户出了问题只能7x24小时找到厂商解决，非常低效。所以，产品化程度也是至关重要的。

早期那些国外的商务数据库也是历经多年打磨，才慢慢的让这些传统厂商的数据库团队、科技团队接受的。

关键案例

前面几点做得再好、再花哨，如果是没有关键案例的验证，一切都是竹篮打水一场空，“实践是检验真理的唯一标准”，做得再好都需要有案例加以证明其可行性，对于分布式数据库的挑战，最重要的一点也是最为关键的一点，就是实实在在的案例。

如果没有人用，大家都处于观望状态。关键案例是分布式数据库面临的最大挑战，目前来看，国内的传统厂商、银行、政企，还是外企的份额居多，国内的分布式数据库也是在近几年才杀出一条血路。

所以，关键案例方面，除了需要TDSQL，也需要所有的友商共同探索，将关键案例不断的迭代、铺开，有了更多案例的证明，国产分布式数据库的影响力也好，口碑也罢，包括大家的接受程度，才能慢慢地得到提高。

分布式数据库的挑战（非技术层面）

这里的非技术层次的挑战更偏向于产品侧，主要分为以下4个挑战：

质量可靠

对于一款分布式数据库，需要经过大量业务的验证，产品在成熟或者说正式用于外部之前，一定需要经过内部的打磨和锤炼，像TDSQL数据库，我们往往都是在内部打磨得非常成熟后才将其推向外部。

因为我们的内部场景非常多，腾讯也有很多业务线，例如在类金融场景、社交场景、医疗健康、互动娱乐，以及各种各样的公有云的场景加以打磨。

我们秉承着对自己产品认真、负责的态度，先经过内部的打磨才推送到外部客户。因为将产品推送到外部客户时，实际上已经是一个黑盒的环境，要求我们一定要在内部尽可能的提前发现一些比较关键和显而易见的问题，比如用户的体验性和一些使用方面的问题。

持续投入

数据库的更新迭代非常快，从TB级PB级再到更高数量级的提升。

因为迭代更新比较快，所以要求厂商要有一个稳定的数据库团队持续地跟进演进。

对于TDSQL而言，作为腾讯内部唯一的自研数据库品牌，我们团队也要紧跟技术的演进和变化，除了服务外部客户还要服务内部，因为无论是内部还是外部都是我们的关键的客户，都是我们非常重视的使用场景。

像腾讯这种体量的互联网公司，需要一支比较稳定，并且可以不断紧跟着技术的演进和发展不断迭代的数据库团队。

团队建设

需要我们的数据库有自己的生态，包括用户从集中式转换到分布式的配套工具，周边文档资料，人员的招聘，还有一些过渡保障措施。

TDSQL是兼容MySQL、PostgreSQL生态的，而这些生态是一个非常庞大的数据库圈子，其文档和资料，以及全世界的活跃社区都给我们提供了很多的学习参考的途经，我们一些技术水平比较高的银行合作伙伴往往在出了问题之后，对于一些比较基本的问题，都是自己通过查阅相关资料加以解决。

对于我们的客户而言，选用了一款分布式数据库，它也要考虑自己团队对新型分布式数据库的维护能力。

服务能力

服务能力要求分布式数据库的具有完善的服务机制与生态体系。比如用户出了问题之后，能够第一时间真的需要到现场，能够第一时间去就近服务，包括一个完善的区域的合作伙伴的服务机制。

在服务能力方面，TDSQL也在全国培养了很多的技术支持团队帮助，引导客户解决问题。比如一些重大的节日保障，或者是涉及到一些重大变更，需要我们的合作伙伴立刻到达现场，做业务的割接、切换或者是大规模的灾备演练。比如对一个机房进行断电的容灾演练，我们也有专门的团队去支持，DBA团队也有服务合作伙伴，共同为客户保驾护航。

目前，我们在华东、华南、华北都有专门的服务团队。

作为一款成熟的分布式数据库产品，除了要在技术侧加以打磨，还需要有足够的案例输出，同时在服务体系、整合能力还有持续演进能力方面，都要有与之相匹配的能力。否则，它就没有办法成为一个成熟完善的商业化产品。

TDSQL的发展历程以及架构原理

腾讯的土壤

为什么在腾讯的土壤下能诞生出像TDSQL这样的数据库？

首先，腾讯是一个依托百亿级账户数量的互联网公司，其数据规模、场景相对而言比较有挑战性。

例如，几年前微信春节红包的峰值超过了每秒20万笔，对于任何数据库而言都是一个比较大的考验，如果不按照分布式进行拆分，那么，没有任何一个大机或者小机能承载这样的业务压力。

众所周知，互联网业务营销活动比较多，在活动前、活动后，其请求还有峰值都是指数级的数量，对数据库的容量、伸缩能力是一个很大的考验。

TDSQL，依托腾讯云这个载体，服务于政务、金融、电商、社交，还有智慧城市等等各种场景的打磨。另外，TDSQL在公有云上服务于各行各业和各种场景的用户，这些都是对TDSQL各种场景的打磨。

最后就是持续的投入。

伴随着TDSQL迭代的这10年，腾讯加以持续的投入，不断的打磨产品。因为数据库对于这种体量的互联网公司而言至关重要。腾讯有着百亿的账户，丰富的内部产品线和业务线，任何一个这种互联网业务产品都会对数据库有着强依赖。在数据库方面，TDSQL不仅是作为外部的一个产品，在内部也是承担了一个比较重要的作用。

在这里，详细的介绍一下到底什么是TDSQL，其应对的主要场景有哪些？

按照官方最新解读，TDSQL是腾讯推出的一款多引擎融合分布式数据库品牌。

所以TDSQL覆盖三类数据库场景，分别是：分布式数据库，云原生数据库以及分析型数据库。所以，TDSQL分为三个产品序列，分别是金融级分布式TDSQL、云原生共享存储的TDSQL-C以及分析型数据库的 TDSQL-A。

这样的多引擎超融合体系针对数据库场景的几个关键领域，都提供了特定场景的解决方案，比如云原生数据库，在存储层基于共享存储做分布式的就是TDSQL-C。

在面对金融场景或者政务系统的联机交易和离线跑批场景，分别是分布式TDSQL和分析型TDSQL-A的两个产品。实际上，TDSQL是腾讯整个一套分布式数据库的解决方案，无论是在线联机型的，还是离线分析型的，或者是基于共享存储的分布式型场景，它都可以轻松应对。

核心特性

金融级分布式版TDSQL的核心特性包括以下几点：

首先，数据强一致，因为在金融场景下，数据不丢不错是至关重要的。

第二，金融级高可用，在金融场景至少要保证99.999%的可用性，因为金融除了其本身的行业因素外，更重要的是它还受到监管的约束。无论是对内还是对外服务，TDSQL是按照99.9999%的可用性要求的。高性能低成本，作为分布式数据库，尽可能要让所有的X86、ARM的廉价存储方式榨干机器的资源，带给整个分布式数据库高吞吐量的增益效果。

再者，企业级安全，虽然需要实现企业级安全的不只是数据库，但数据库一定要做这种最后一根救命稻草的保障。比如数据的误删、误操作，对于一些银行客户而言，可能一年或者几个月都不会发生一次，但是，我们面对着云上的客户，每天都有客户误删、误操作，在这方面TDSQL积累、总结了大量的经验、教训。对此，我们也有很多的解决方案包括SQL防火墙、透明加密、自动备份等——如何更快速的帮助用户找回数据、恢复其可用性，经过这么多年的打磨，我认为我们是非常专业的。

线性水平扩展能力：分布式数据库一定要具备伸缩、可扩展能力。

最后，便捷的运维——这套分布式数据库交付到客户手里，用户要能够自行掌控、操作。而不是出了问题后，只能7×24小时的给厂商打电话，这也不是我们的初衷和诉求。

产品体系

最底层的是资源池。

TDSQL既可以基于物理机部署，也可以基于虚拟机，我们可以将这个资源池简单理解成一个iaas 服务层的概念，在资源池上方提供了两种形态的存储节点，一种是Noshard数据库，另外一种是分布式数据库，分别代表了单机版和分布式两种形态。

作为分布式TDSQL，为什么还要有一种形态是单机版的？

对于一个厂商、一个银行或者一个金融客户而言，并非所有业务都会用到分布式数据库，或者不一定所有的都是业务大表，它可能是多个业务之间有交叉，真正涉及到分布式的可能是一部分表，还有一部分可能是非分布式的。

在这种产品形态下，同时兼容分布式和非分布式，因为分布式下有一些使用限制，比如语法的限制、分布式事务的性能损耗，以及跨数据节点的join.

在分布式下，因为两个数据节点是一定分布在两个不同的物理节点上的，如果在这两个物理节点之间的数据做join，很容易造成拉表，相当于是把两个物理节点上的数据要统一汇总到一个节点上进行join，这样的效率不是很高。

而单机版的则没有这个问题，因为数据的拖拽都是在单台物理节点的内存中，所以，Noshard的形态可以自由做表与表之间的join，但是在分布式上会有性能方面的消耗，这也说明了分布式和非分布式两者各有优缺点。

所以，我们在存储节点保留了两种形态，用户可以根据需要自行选择，比如业务实例要求必须得做到分布式，需要将数据分散，包括将来考虑到业务的拆分，我们就要用分布式的；如果没有强烈的诉求，我们提供单机版的就能满足需求。此外，从单机模式转换成分布式模式，TDSQL自带的同步迁移工具也是支持的。

再往上是计算节点。

首先，OLTP型引擎主要包括了读写分离、SQL改写、分布式事务以及关联查询。

除此之外，对于计算节点，需要处理一些比较复杂的SQL，需要对其进行拆分，包括将执行计划下推等等，就属于OLAP型的计算逻辑。

所以，计算节点在分布式下的工作相对还是比较复杂的，在内部，计算节点又被称为SQL引擎，作为所有SQL的入口，它会对SQL进行分发，对一些复杂SQL拆解成对应的SQL，再发到对应的存储节点，当存储节点取完数据之后再回吐到计算节点，计算节点对其进行分类汇总，最后回吐到客户端。

如果把计算节点、存储节点、资源池比作一个黑盒，那么赤兔运营管理平台就是一个用户接口，所有的DBA操作都是通过赤兔管理平台来操纵存储节点、计算节点、资源池。

以往，DBA要做数据库的变更，比如主备切换或者重启，需要登录到后台，比如计算节点，存储节点执行SQL命令，现在只要通过赤兔管理平台页面按钮可以完成90%以上的操作，极大地减少了DBA的误操作风险。

虽然有用户界面，但是如果DBA确实是要登录到后台了解更详细的信息也没有问题，一样允许登录到对应节点的后台进行查看。

赤兔运营管理平台主要是为DBA提供用户接口，它还对计算节点、存储节点，包括机器IO、CPU网络等各种信息的上百项指标进行统计汇总，并且当监控告警系统的指标出现异常时，可以在第一时间发出告警。

那么，“扁鹊”智能DBA平台有什么作用？

打个比方，某天晚上发生了机房断电，数据库也发生了切换，第二天早上DBA收到一个告警，线上前一天晚上发生了切换（当然这个业务是正常切换过来了，然后对业务的影响也是可控的），DBA需要知道为什么会发生切换，只需要在智能DBA平台上点一下“故障分析”，智能DBA自动到机器上分析操作系统和数据库日志，原来是操作系统发生了重启，这样 DBA就不需要再手动登录到机器上查看信息。

再比如上线了一个新业务，上线了新业务之后瞬间卡死不可用。这时就找到DBA投诉，“之前数据库用得好好的，怎么一上新业务就不行了？”

实际上，可能是新上线的业务产生了一条慢SQL，慢SQL并发量又比较大，然后把数据库连接耗尽。按照传统的做法，这时DBA也是先分析日志，找到这条慢SQL，然后再一点点的进行分析。

而通过智能DBA平台，可以进行一键诊断，智能DBA平台可自动筛选出那条慢SQL，并且告诉DBA需要对这条慢SQL如何进行优化。

有了智能DBA平台，就可以将我们从一些日常的、重复性的繁杂工作中解放出来，这套平台也是我们对外口碑最好的一套平台，尤其对于传统客户而言是非常受用的，能极大地提高DBA的工作效率，同时降低处理问题时在时间上的损失。

调度系统，负责整个集群的资源调度和管理，包括计算节点，如何组成一套数据库实例，跟下方资源池里的资源如何进行重组、搭配，都是调度系统需要做的事情。

备份系统，没有备份的数据库属于一个裸奔状态，在这方面，TDSQL提供了丰富的备份策略，如全量的、增量的、物理的、逻辑的、日志的等各种各样的策略。可以完成定点恢复、库表结构恢复、指定表的恢复等等。

服务模块，服务模块属于比较高级功能，主要应对一些特殊性场景，如：审计、数据订阅、数据治理，以及SQL防火墙，数据迁移等等。

比如用户需要从原生的MySQL迁移到TDSQL，或者从其它异构数据库把TDSQL迁移到其中，都涉及到数据迁移，我们有专门的数据迁移模块，包括TDSQL的两种形态之间，包括从分布式到单机版，从单机版到分布式，都依赖于这样的数据迁移。

数据迁移也彰显了TDSQL不绑架用户的一个初衷，这也是TDSQL开放生态的一个特点，基于MySQL生态的数据库在迁移过来之后一定不用担心将你绑架——也就是它不让你迁出去，因为日志、数据结构都是开源的，有很多种工具提供了在线、离线的迁移方式。

如果用户觉得TDSQL不好用，可以通过我们的迁移工具再将数据迁走，数据进出自由，并非绑死在TDSQL。

运营管理

• 赤兔监控：这里罗列的几项指标，是SQL引擎请求量的对比，包括与前一日的对比曲线。

• 智能告警：如果报警标红就会闪烁，如果只有监控而没有告警，其实是起不到任何作用的，一定要将监控与告警关联，才能起到预警作用。

• 扁鹊系统：其内部逻辑非常复杂，主要是基于腾讯多年来海量运维的经验，形成的策略库、语法库。通过在这方面经验的积累，对一些常见的故障进行分析和识别并处理。

• 一键运维：TDSQL赤兔管理台的首页，它包含的功能在我们看来如果DBA数据库管理员有这套东西，基本上是可以做到只在页面上完成所有的操作，不需要登录到后台进行变更、维护。

系统数据库向国产分布式数据库迁移与转型实践

第一个案例：微众银行

微众银行是在2014年开始筹建，最终采用了TDSQL，并搭建分布式架构核心系统。微众银行对于机房的部署是，在同城有5个机房异地有2个机房，按照传统意义上的理解，这同城的5个机房如果做成1主4备，其余4个机房都有可能会浪费。因为只有1个机房没有读写请求。

微众银行对上述机房的部署肯定没法充分利用机房的资源。对此，又是怎么解决的呢？

首先，将数据库规划成一个个的 DCN，一个DCN模型就是一个小的微众银行的分行、网络分行，一个分行只固定500万的账户数，这500万的客户数也是经过了一系列的压测验证，至少这500万放在这个单机版的TDSQL上是安全的，不会有性能的瓶颈。

如果超过500万，比如客户数到了600万，就再加一个DCN，实际数据库的实例层是由多个DCN组成了一套集群，而多个DCN之间相互没有联系，因为用的都是单机版的TDSQL。

那么，微众银行是如何利用这种单机版的Noshard模式实现整体的分布式呢？

微众银行还引入了一个组件GNS， GNS被称作全局路由，业务访问数据库一定要经过GNS，之后，GNS告诉他所需要的数据在DCN的具体位置，业务再把对应的SQL发到对应的DCN。

所以，GNS解决了路由的问题。

在这种情况下，如果要做分布式事务该怎么办？传统的分布式数据库，对于用户侧而言就是一个begin，然后增删、改查、commit。

如果增删、改、查里涉及到的多个DCN对业务是透明的，但是在这种情况下，实际上没法做到完全的透明。

对此，微众银行又引入了一个组件RMB——可靠的消息队列，是处理分布式事务的，也就是在一笔分布式事务到达后，首先要在RMB这里注册一个分布式事务的总事务，之后再由RMB完成子事务的分发，最后它会确保所有的分布式事务所涉及到的 DCN在处理完成后，返回给业务端。

微众的数据库是怎么部署的呢？利用多个IDC交叉部署，第一个DCN的主放在IDC1，第二个DCN的主放在IDC2，以此类推，其所有DCN的主是交叉部署在这5个机房的。

如果最后是500个DCN，有5个机房，每个机房就放100个DCN，这样的好处在于每个机房的读写流量是均匀的，并不会造成像原来所有的读写都压在1个机房，其余4个机房都是stand by的角色。

所以，微众银行这套架构从整体上看，实现了5个机房资源的充分利用。

任何一个机房的故障都只会影响1/5的流量，不会造成系统性的宕机。

像以前这种1主4备的模式，如果主节点坏掉，整个全行所有的服务都会瘫痪，虽然最后也会切换，但是其过程对全行的业务是有影响的。

如果按照分散的方式，就会产生另外一个问题，一个节点坏掉之后，使得1/5的业务受到影响，而原来的1主4备的模式，如果坏掉的是一个备机，那正常业务就不会受到影响。所以，这其中存在着可用性和成本之间的博弈。

第二个案例：张家港银行

张家港银行是我们对传统银行核心系统进行的一次彻头彻尾地改造。

首先，它是一家传统银行，并非新成立。其次，它的核心系统是针对传统银行打造的。从微众银行到张家港银行已经过去大概5年的时间，整个TDSQL在产品迭代方面已经有了很大的变化。

对于张家港银行而言，首要考虑的问题是性能，其早期的数据库是Sybase数据库，大概是10年前的一个架构。在张家港银行在业务高峰期经常有卡顿、超时的问题，所以其诉求就是要升级成一个能满足行里现在业务场景的数据库。

第二，张家港银行的量级相对较小，其诉求就是成本。

另外，改造的难度，在业务方面，微众银行在数据库方面做了很多的自身的改造。

比如引入了GNS、RMB，这些都是微众自己进行维护的。并且从一开始，微众银行基于自身的定位，更多地还是想参与金融创新，定位自身为一家金融科技公司。而张家港银行更希望能快速地解决自身的问题并且把东西用起来。

所以，张家港银行的架构图就非常清晰和简单，就是一个标准的分布式两地三中心的架构，同城总行机房部署一组主节点和一组备机节点，同城的灾备机房部署一组备节点，整个分布式实例采用一主三备四分片的架构。

此外，在异地还有一组异步节点。从整体看，没有任何的复杂组件，张家港银行采用的这种形态与微众银行的截然不同。

TDSQL有两种形态——Noshard和shard，张家港银行完全采用了后者的形态，这样，张家港银行就不需要引入诸如GNS、RMB等组件,因为我们的SQL引擎会助其自动做路由，以及分布式事务管理。

所以，张家港银行直接使用分布式shard版的TDSQL，对于业务而言，只需进行细微的调整和改动，例如重新设计库表。按照这种分片关键字，一些大表需要选择其分片关键字。

再者，就是将之前用到的存储过程、触发器的一些计算逻辑，尽可能地上提到业务代码中。因为在分布式数据库下，数据库尽可能的只做数据的存取，否则很容易产生性能问题。

按照这种策略和思路，对张家港银行的改造大概历时半年完成，改造完之后，整个性能提升非常明显，查询交易在100毫秒以内完成，高频交易在300毫秒内完成，像贷款结息这种跑批业务与原来相比得到成倍的提升，体现出分布式的一个优势。

性能方面，原来在硬件成本方面需要4~5000万，现在不足1000万。同样的成本，在oracle下是8000的TPS而在TDSQL下是6200的TPS。

在整体性能差异不大的情况下，成本已下降到了不足原来的1/5。同时TDSQL可以通过继续加机器来提高集群的吞吐能力，所以性能还可以不断地提升，具备横向扩展的能力。

第三个案例：平安银行

平安银行更具代表性。平安银行的体量与张家港银行相比又上升了一个数量级，同时其应用改造的难度相对而言也是一个比较有挑战性的工作。今年，我们完成了支持平安银行信用卡核心从传统集中式架构的大型机下移至分布式平台。

平安银行采用了TDSQL Noshard和Groupshard两种架构。为了配合此次改造，应用引入了微服务架构对应用进行了拆分和解耦。对账号的分布进行了单元化划分，以DSU为一个逻辑单元，单个DSU包含200万个客户信息，单个DSU同时处理联机和账务两种业务。这样做的好处：一方面避免跑批时段消耗资源过多对联机交易的，另外一方面避免由于基础架构的故障导致全局不可用。。

平安银行也有统计分析类型的业务，如果按照Noshard架构，对应用开发要求比较高，需要将统计类的SQL拆分成多个子SQL分发给多个noshard实例。

groupshard架构更适合， 从逻辑上来看，Groupshard架构对于应用而言就是多个独立的逻辑表，应用不需要关心数据是如何组织分布的。由于要对数据进行统计分析，数据访问量较大。所以，这种场景下，在访问需要的数据时，应用只需把SQL发给SQL引擎，SQL引擎会对SQL进行拆分、并行下推,再进行结果集的聚合。

同时，TDSQL Noshard和Groupshard两套集群之间通过TDSQL自带的同步组件完成实时数据同步。

政务系统

第七次全国人口普查的数据采集处理工作，对于我们的TDSQL而言也是具有重要意义的。

首先，其数据量的规模是10亿级别的，峰值QPS是百万级。

这种情况，无论在我们内部业务还是外部业务都是非常罕见的，对于TDSQL性能的要求，包括跨节点之间的通信、分布式事务的处理都是比较大的挑战。

因为人口普查涉及到国家政务的敏感信息，我们不便将其详细的架构图画出来。

但可以肯定的是，基于TDSQL多引擎融合技术，第七次全国人口普查稳健完成了数据采集处理工作。

欲了解更多活动详情，可联系负责人周舟（微信：18811172358）。

如果没有实现平滑顺畅的云架构转型，银行想要推出更多智能化应用、开展数智化赋能创新的想法，无疑是空中楼阁。

2020年10月，央行也发布了最新版金融上云配套管理规范，明确了金融云的建设标准、评测办法、备案管理要求，以及金融机构上云的要求。这一规范的出台，也足见监管层对银行信息科技的重视程度。

值此新年之际，雷锋网《AI金融评论》与阿里云联合主办“银行系统云化升级”实战体验营，邀请到多位顶尖行业专家线上分享，讨论银行核心系统与应用的云化改造，内容覆盖成功上云实战复盘、金融核心建设等方向。

明晚8点，阿里云新金融事业部CTO张晓丹将带来首场演讲，结合自身二十余年银行IT经验，分享金融IT基础架构全面云化、机构应用迁云实录等干货。

近期，《AI金融评论》也将围绕银行上云、核心系统建设、云金融等主题，陆续推出多篇稿件，为银行业乃至金融界，和科技圈，输出最立体化、最具前瞻性和参考价值的银行云、金融云内容，同时搭建高质量的微信社群，促进上下游企业交流探讨。

欲了解更多活动详情，可联系负责人周蕾（微信：LorraineSummer）。

演讲嘉宾

张晓丹，阿里云新金融事业部CTO

演讲时间

1月19日 20:00-21:00

演讲主题

《新一代金融IT基础设施：阿里云的金融云前瞻与实战》

演讲大纲

• 金融IT基础设施发展需求与趋势

• 金融云应用场景 

• 打造安全、稳定、敏捷的云上金融

嘉宾介绍

张晓丹曾任工商银行总行部室副总级专家，先后在工行分行、数据中心、总行IT部门任职22年。

曾任恒丰银行科技部总经理，期间建设了国内银行业第一家多租户的金融IAAS行业云，首次将一家全国性股份制银行的应用系统全部迁移上云。

2018年，张晓丹加入阿里云。

如何预约专场？

关注公众号“AI金融评论”（ID：aijinrongpinglun）

在公众号对话框回复关键词“参会”，即可进微信群观看技术专场直播，亦可与技术大佬们谈笑风生。

本次专场面向的人群

• 银行信息技术/IT部门，和研发部门团队；

• 云服务供应商、金融科技公司高管；

• 传统IT厂商和软件供应商高层；

• 券商、险企等持牌金融机构IT建设部门；

• 高校计算机、软件专业、人工智能教授与研究生

而这一切都离不开一个产品——数据库。

我们在朋友圈保存的文字和视频、在银行中储存的数字化财产，我们对整个社会的管理、对经济社会的维持，都是在成千上万个数据库的帮助下完成的。

于银行而言，数据库是“生命线”，它存储着银行多年来收集的数据信息，包括用户的财务隐私、银行的交易记录等重要信息。

然而由于传统数据库在技术边界、成本、可控性方面与时代技术、银行业务创新需求而言越来越不相匹配，同时由于采购数据库的来源单一，银行一直陷入非常被动的处境，急需市场上出现更多类型的数据库产品和厂商。

被卡住脖子的银行

一位业内资深的数据库专家最近感慨：数据库，是银行“命脉”，需要投入大量的人力、物力，非十年起步不可，非大厂不行。

1989年，Oracle正式宣布进入中国市场，很快成为银行从业者眼中数据库的代名词。20多年来，银行等金融机构只信赖和使用Oracle数据库，金融拼的是长跑、谁活得久，而不是快跑、谁花样新。对于把安全始终放在第一位的很多银行从业人员来讲，Oracle一直是第一选择，而新兴的国产数据库厂商只是“备选”。

“用Oracle就是安全，时间和太多的实践经验证明了这一事实。”平安银行分布式数据库技术负责人李中原坦言。

想在金融这一领域和Oracle这样经受过时间验证的数据库厂商竞争，国产数据库厂商并不轻松。 

腾讯云副总裁李纲表示，“在和银行客户交流的时候，大家都信任Oracle，他们认为如果一个问题如果连Oracle都解决不了，那其他厂商也没办法。”

对于国内数据厂商来讲，Oracle的强大和不可替代性，成为他们绕不开的话题。而对于银行等金融机构而言，因为长期使用Oracle，他们形成了较严重的路径依赖，轻易不会更换数据库。除非出现了新的业务场景，而现有的技术不能很好解决，否则很难让银行下定决心。

“毕竟系统的迁移和重新建设，需要大量成本。”李中原说道。从单机变为多机群体，故障发生的故障发生的概率和维护成本都会加大，这对整体的系统运维也是一个极大的挑战。

在这种情形下，2020年中国数据库软件市场规模200亿元，Oracle等海外厂商市场占有率超过了80%。 

此前，《科技日报》总结出了中国35项被外国“卡脖子”的关键技术，数据库位列其中。

但是，和Oracle等国外数据库厂商相比，国产数据库长期以来在安全性和可用性上，不具备足够的竞争力。采购来源单一使得银行不仅要付出更高昂的采购成本，还时时受制于人。

2020年5月，全国人大代表、合肥工业大学应用数学研究所所长檀结庆对《证券日报》记者表示，中国几千家银行，核心交易系统几乎都采用了甲骨文或IBM的数据库产品。

云厂商“破局之路”

Oracle在银行业的影响力依然强大，但是云计算的出现，使得Oracle帝国坚固的城墙有了一丝缝隙。

云计算，让国内外互联网巨头嗅到了打破Oracle常年霸占数据库领域的契机，各大互联网巨头云厂商拔地而起，2006年亚马逊AWS成立、2009年阿里云成立、2010年腾讯云正式对外提供云服务。

有业内人士认为，Oracle数据库无疑是一个伟大的产品，但它和新兴的云数据库厂商相比，在成本和易用性上开始显露疲态。

腾讯云的李纲认为相比Oracle等传统数据库，云化数据库有成本低、容易扩容两个特点：

一：云数据库是分布式的，它的硬件要求、它的成本很低，任意一台X86的PC服务器就可以运行。

二：云数据库是横向扩展的。因为云数据库是分布式的，所以理论上它的横向扩展能力是无限的。而用传统数据库的客户，当面临业务数据有了非常大的增加时，可能要再买一台大型机。

目前，中国有几千家银行，每个银行所处的阶段千差万变，金融科技能力也呈现不均衡的发展状态，即使同一家银行的不同业务它所要的技术需求也迥然不同。

广阔的市场和部分可以超越传统数据库的技术优势，给了国内数据库厂商和Oracle数据库竞争市场的机会。 

就拿腾讯云为例，它便一步步通过在金融领域的深挖，获得了不少银行订单：

2013年及以前，腾讯内部计费业务，以及微信支付（财付通）成立，使得腾讯数据库在偏金融的场景中获得了初步的锻炼。

2014年，腾讯牵头成立的民营银行——微众银行成立，腾讯集团第一次将数据库产品TDSQL，放进银行的核心系统中。这是腾讯云第一次“吃螃蟹”，从此正式开始了向金融行业拓展客户的步伐。

2019年，张家港行将其核心业务系统放在了腾讯云TDSQL数据库上，这是传统银行第一次将传统核心系统应用在国产分布式数据库。

从腾讯云数据库的发展路线可见，互联网云数据库厂商一般先从自身偏金融业务开始，再尝试向互联网银行发展，最后将数据库产品应用并赋能到张家港行、平安银行等传统银行。

其中，微众银行和张家港行在使用腾讯数据库产品时，又有所不同。

微众银行是新成立的银行，一开始便用的是分布式数据库，不存在之前已有数据库更换的问题。但是张家港银行等中国大部分银行，本身有自己集中式的数据库。从集中式数据库到分布式数据库，这其中涉及到一个迁移的过程。

而“大机下移”相关业务，在很长一段时间内都是国产数据库厂商需要重点攻坚的对象。

银行业“求变”，国产数据库加速发展

张家港行和平安银行选择国产云数据库厂商这一现象，看似“不走寻常路”，其实是整个银行业正在积极求变、努力“上云”的一个缩影。

基于云计算的应用程序，比传统系统提供更多的连接和功能，银行等金融机构可以因此获得新兴技术和高端技能。李纲认为：“用分布式技术，所有的架构对客户来说都是透明的，客户可以在上面加持自己的应用、灵活的去发展。”

前不久，平安银行信用卡的核心系统完成切换投产，这一新核心系统也采用了国产数据库。

关于平安银行为何放弃Oracle，选择国产数据库厂商，李中原表示团队内部也经历了非常多的讨论。

“信用卡这个项目在立项之处，平安银行就花了三四个月的时间，专门研究选型的问题。在数据库的选型上，选择Oracle的呼声最大，但最终通过各种论证，平安银行最终选择了腾讯云TDSQL数据库。”

在选型的过程中，一方面需要让所有员工思想统一，另一方面需要把技术方案的优劣递交给上一级的领导“敲板”。

李中原认为有三个原因，让平安银行最终选择了腾讯云TDSQL数据库。

第一，云数据库的横向扩容能力，让平安银行可以快速的进行自动化扩容。

第二，兼具同城多活和数据强一致性。同城多活方案会给业务系统设计带来更大复杂度，跨机房服务调用带来的耗时增加、带来成本上升，但是腾讯云数据库很好的平衡了这一点。

第三，腾讯云可以在自动运维上给予平安银行支持，比如在Oracle数据库上，平安银行如果要部署一个几百套数据库的集群来做统一管理是很难达成的目标。

成本，也是平安银行推动更换数据库的原因之一。

李中原表示，“从硬件建设来看，把大型机扩容到目前TDSQL同等规模处理能力，仅此一项需要多花费大约几亿元；而从后续的维保角度，每年大型机的维保费用也更高。”

使用分布式数据库，对于巩固平安银行整个系统的稳定和培养分布式数据库方向的人才也是一个很好的“试验场”。

“整个分布式集群的产品组件非常多，精通掌握每个组件其实很困难，我们着力把这些做得更加自动化，我们团队几十人，每个人对系统的掌握不一样，但是自动化可以最大限度保证系统运行和维护的效果是一致的。而这对于员工来说，就需要更深入的学习、接触更大的技术面。而同时，TDSQL的运维自动化能力也让后续的运维工作更加方便。”李中原说。

目前，有许多实力较强的银行已经展开对内部分布式数据库的人才培养计划，2020年8月，中行便在官网上宣布对“软件中心2020年云计算与分布式技术培训项目”进行采购，培训人数多达上百人。

一场“银行数据库国产化”浪潮

随着国内云计算技术的发展，银行有了更多数据库产品上的选择。

2019年中国人民银行印发的《金融科技（FinTech）发展规划（2019-2021年）》中指出，将有计划、分步骤地稳妥推动分布式数据库产品先行先试，形成可借鉴、能推广的典型案例和解决方案，为分布式数据库在金融领域的全面应用探明路径，确保分布式数据库在金融领域稳妥应用。

除了平安银行等全国性商业银行、张家港等地方性城农商行、微众银行等新成立的互联网银行外，四大国有银行其实更是走在了变革一线。

比如在2020年7月，中国农业银行分布式核心银行客户信息系统便顺利投产，完成全行8.37亿个人客户信息数据下移和应用重构，实现架构转型升级；

2020年9月，中国工商银行采用国产数据库，其对公理财系统完成从大型机到分布式架构的改造，在同业中率先实现大数据体系由传统架构向自主可控、分布式架构转型。

国有大行系统的业务体量非常巨大且并发极高，天然会有对新技术架构的需求。他们也可以深度地和BATJ等互联网巨头旗下云厂商进行更加深入和全面的合作。

而随着互联网乃至5G、物联网的快速发展，将有更多银行出现单一集中式架构无法较好满足某项业务的场景，这就推动着银行拥抱新的架构、选择更符合业务发展的数据库产品。（雷锋网雷锋网雷锋网）

财报显示，百度核心非在线广告收入29亿元，同比增长14％——百度点名智能云业务，称该项增长“得益于智能云业务收入攀升，以百度智能云为代表的AI新业务为营收带来的驱动价值凸显。”

李彦宏对此点评：“第三季度，AI新业务稳健增长，特别是在智能云领域，百度凭借领先的AI解决方案形成了差异化发展路线。”

百度智能云之所以能在本季成为百度AI新业务的亮点之一，主要因为百度智能云持续在多个行业签下大单，财报也对此有所披露：百度智能云在智慧金融、工业互联网等领域，分别拿下了中国邮政储蓄银行项目和贵阳经济开发区工业互联网基础设施建设项目。

尤其是在中国邮政储蓄银行项目中，百度智能云将通过机器学习和其他AI能力，助力其旗下近4万个分支机构开展风控审计工作；贵阳经济开发区工业互联网基础设施建设项目中，百度智能云将对区内400多家工业企业，实施工业互联网改造。

不难看出，今年的百度正借着这朵智能云，在金融赛道奋起直追，其金融AI to B战略布局的野心展露无遗。

• 与宇信强强联合
  

2020年初，百度战略投资宇信科技集团。双方表示，将在金融云、大数据、人工智能、区块链等关键领域展开合作，以百度大脑为核心，依托智能云，推动云+AI在金融行业大规模落地，加速金融产业智能化升级。

成立于2006年的宇信科技，已在金融IT服务领域深耕十余年，向金融机构提供咨询规划、软件产品、应用开发、技术服务、运营维护、系统集成等全价值链服务。

而百度智能云也已打造完备金融云解决方案，全面服务于银行、证券、保险、互联网金融等金融机构的营销、风控和运营各业务场景。

不仅输出全链条自主可控、技术能力持续领先、高等级安全合规的金融互联网核心，同时也提供覆盖228多项领先AI能力的一站式金融智能引擎，还提供数据管理技术能力及对公金融服务。

此次合作被概括为“打通技术与场景，进行深度技术和产品整合”，面向金融业，在金融云、分布式数据库、大数据分析平台、智能金融大脑、区块链、可信计算、智能交互等多个层面都将展开创新合作，充分发挥协同效应。

• 度小满+百度智能云+亿联银行的三边共赢

今年4月，百度智能云、度小满与亿联银行在北京官宣战略合作。

亿联银行是东北首家民营银行，也是国内四家取得互联网贷款业务资格的银行之一。

百度智能云将为亿联金融业务和服务提供“AI+云”技术能力，度小满金融利用自身渠道和用户资源为亿联提供流量支持。

两方协同作战，沿承了百度的技术基因和搜索场景优势，利用私有云、AI技术等在金融领域布局，构建了包括智能获客、大数据风控、身份识别、智能投顾、智能客服等多项核心能力，与亿联银行形成三边共赢的战略合作，共同打造“未来银行”新范式。

百度智能云事业群组副总经理、智慧金融事业部总经理李硕透露，其实在2019年，百度智能云就已经与亿联银行在人工智能平台、声纹、NLP等领域取得诸多的合作成果，此后三方的合作会进入到“一个更加亲密的‘铁三角’状态”。

• 发布未来银行解决方案，落地浦发、百信

同样是在上半年，百度智能云在ABC SUMMIT 2020百度夏季云智峰会上，还发布了未来银行解决方案。

基于这一解决方案，浦发银行和百度智能云联合打造了数字人员工“小浦”，可出现在APP、网银和各类服务终端上，为人们提供智能化的金融服务，用户在家就能获得真人一样的情感交互体验，以及“千人千面”的个性化定制服务。

据悉，除了与浦发合作的数字人，该解决方案还会在2020年上半年内落地百信银行。

李硕介绍，百度智能云依托知识中台，可以帮助金融机构将门类繁多的零售金融产品构建出一套知识体系，产品的销售将基于这套智能知识体系，在手机App、营业厅坐席、商超里的服务大屏为每一位用户提供最佳的销售服务体验。

每一台手机、屏幕和ATM都能够成为业务办理和成交的终端，这相当于为每一位用户在场景中配置了一位AI客户经理。此外，通过百度的智能流程机器人、审核策略机器人，后台业务处理也能实现秒批。

除了金融零售领域，百度智慧金融还为金融机构提供获客、风控到运营的端到端智能化解决方案。据悉，百度智慧金融的基础平台以自主可控的软硬件为底座，其中图数据库是新一代支撑知识图谱应用的关键产品。在AI中台和知识中台的支撑下，银行保险的大量产品实现数字化营销，百度智慧金融的智能营销与客服、数字员工等能够帮助金融机构以统一的服务标准以及个性的服务体验触达用户。

• 与捷信消费金融打造智能客服2.0
  

除了与银行、金融IT厂商携手，百度智能云今年还与消费金融公司保持着良好合作关系。

捷信消费金融上半年就曾公布，将与百度智能云通力合作，引进其业内领先的自然语言理解、对话管理、自然语言生成、知识图谱等技术，并将它们应用到电销、催收、咨询服务等业务全流程。

之所以选择百度智能云智能客服，捷信IT呼叫中心部长何子文透露，一是因为百度作为业界领先的科技企业，各方面的服务以及支持体系相应更加完善；第二是在项目选型时，“百度智能云的POC场景测试效果是最好的”。同时，在ASR engine方面，百度积累了大量数据，包括百度核心NLP引擎技术的表现也尤为突出。

• 为大智慧量身定制“上云”

百度智能云今年技术能力输出的典型案例，还有为金融信息服务公司大智慧打造一套轻资产、易应用、弹性伸缩的云上数字化解决方案。

大智慧以软件终端为载体、互联网为平台，向投资者提供及时专业的金融数据和数据分析，服务于国内的大量个人投资者和众多金融机构。

但随着业务范围不断扩展，用户量和市场交易量快速增加，传统的机房部署模式很难抵挡业务系统面对的压力，既不能实现灵活部署，又需要投入大量硬件设施，自建机房运维服务容易在出现故障时不便于维护，让用户体验度大打折扣。

为此，百度智能云从高并发、稳定性、成本三个关键要点出发，将大智慧业务无缝迁移到公有云中，以敏态的基础架构，支撑弹性按需的业务，同时可以为大智慧分布于全国各地的分支机构，进行统一管理、统一运维。

百度智能云介绍称，这一解决方案能让资源灵活扩容，从容应对业务峰值，支撑系统平均每天千万次的超高访问量。

在更新金融资讯时，大智慧甚至可以使用标准模板自动化生成html文件后直接存入百度智能云对象存储BOS系统中。同时利用BOS的静态网站托管功能实现轻量化运维，并通过CDN对其进行加速，让用户享受极速、流畅、安全的访问新闻资讯，稳定性高达8个9。

• 联手太保、泰康，优化保险定损理赔环节

今年9月底，百度智能云与中国太保产险联合发布车辆智能定损产品“太·AI”，实现了秒级的定损，将客户理赔旅程从1天到数天，降至分钟级。

百度智能云还联合泰康保险，利用百度大脑OCR技术，解决了理赔中票据识别的关键瓶颈问题，实现了8类票据类型的智能化识别，促进泰康保险财务共享中心效率提升110%，实现了智能化理赔业务的升级。

据百度方面透露，目前，百度智能云已拥有200多家金融客户、30多个合作伙伴，包括国有6大银行、9大股份制银行、21家保险机构，涉及营销、风控等十几个金融场景。

百度智能云打造的数字员工也已在75家客户落地，自动化完成业务处理，助力客户的运营效率提升50%以上；零售金融科技在28家行业客户落地，广泛应用于在信用卡智能营销、信贷智能风控、保险理赔反欺诈、保险智能定价场景，其中贷款不良率低于行业均值相对值的10%。

值得一提的是，在今年夏天的ABC SUMMIT 2020百度夏季云智峰会上，百度智能云也披露了自身在数据中心、网络、算力与芯片、云存储、边缘计算以及区块链等领域的更多产品和技术优势，发布了AI中台、知识中台以及新一代智能办公平台。

例如针对政务、金融等行业需求，百度混合云方案核心ABC Stack发布2.0，以契合企业云战略升级需求，同时全面支持国产化芯片、操作系统和生态软件，实现了完全的自主可控。

升级“天算”数据湖分析平台、“天合”云原生平台以及承载区块链产业化落地的“天链”平台。其中，升级后的“天算”数据湖分析平台可以在满足分析应用场景需求的情况下，为客户的存储成本降低50%以上，计算成本降低到了只有60%。目前，百度智能云在基础云领域的这些技术方案已经广泛应用在工业、商业零售等多个领域。

AI中台则依托百度大脑的AI能力，包含AI能力引擎、AI开发平台两大核心能力以及管理平台。百度CTO王海峰在会上透露，AI能力引擎为企业提供百度已有的250多项成熟AI能力，AI开发平台拥有全球前三、国内第一且具备自主知识产权的深度学习开源框架“飞桨”。基于AI中台，企业将拥有建设AI开发和应用的自主能力，集约化管理企业AI能力和资源，统筹规划企业智能化升级版图。

百度智能云智慧金融事业部算法负责人谢国斌，也曾做客雷锋网公开课，分享百度智能云在金融领域的安全计算布局和技术思考，以及基于联邦学习技术的百度金融安全计算平台（度信）建设与实际应用，讲述如何借力安全技术架构、脱敏方法和合规制度设计，在“用户充分授权、数据来源合法合规”前提下，打破数据孤岛，实现多方数据加密融合建模，助力金融企业业务的开展。（雷锋网）

雷锋网雷锋网

IDC指出，进入5月之后，重点金融项目实施与交付加快，有力提振了上半年金融云市场；同时大型机构上云步伐并未被明显延缓，包括核心系统、核心数据库下移等项目均有序推进。

厂商方面，IDC报告指出，阿里云继续领跑金融云市场，其中金融云(平台)解决方案市场份额达到27.7%，大幅领先华为、腾讯等企业。

IDC预计，2020年金融云在整体金融行业IT解决方案市场中占比将接近20%，2024年这一比例将达到40%以上。

雷锋网雷锋网

近年来，在金融安全上升为国家安全的背景下，监管要求日益规范和严格。同时，银行面对的市场竞争压力日益加大，客户对银行产品需求也更加多样化。在多重外界因素的作用下，银行业实现管理创新、科技创新已成为未来的主要潮流，国产化数据库的业务融合也成为银行信息系统建设的必然选择。

据了解，神州信息基于自身全栈金融信创产品和解决方案体系，已成为拥有行业最多金融信创适配应用案例的金融科技企业。其分布式核心系统及分布式技术平台在浦发银行、北京银行、晋商银行、重庆银行、宁夏银行、北部湾银行、唐山银行等实现广泛应用。

站在“新基建”的风口上，面对金融行业数字化转型带来的考验，今年9月，腾讯云发起金腾计划，将与合作伙伴携手打造深度开放共融的金融数字化合作生态，共同推动金融机构全面数字化转型。此次，腾讯云联手神州信息发布的“腾讯云分布式数据库CynosDB（TDSQL）+神州信息分布式核心”联合解决方案，正是双方为满足银行业数字化转型的全方位需求，交出的一份答卷。

通过腾讯云分布式数据库CynosDB（TDSQL）与神州信息分布式核心系统的有效融合，联合解决方案大幅提高了银行系统的并发处理能力、高可用能力以及容灾能力。此外，该解决方案结合银行金融业务场景的特点，有效缩短了日常业务处理的耗时。在实际测试中，联合解决方案可实现将常用账务交易响应时间控制在150毫秒内、常用查询类交易响应时间控制在60毫秒内。同时，基于解决方案，平常日跑批、季度结息跑批、年度结息跑批时间相比原有方案缩短20%，大大提升了银行业务批处理的效率。

与此同时, 联合解决方案基于神州信息分布式核心业务系统，不仅融入微服务理念实现系统功能的独立部署和灵活组合，具有极强的可扩展性，帮助银行打造多个高内聚、低耦合的中台化微服务群，各业务形成完整的功能闭环，可独立运行、扩展和升级。而且依托腾讯云分布式数据库CynosDB（TDSQL）作为此次解决方案的核心系统承载，凭借巨大的数据吞吐、数据强一致性、数据高安全等性能优势，以及高可用、高扩展等特性，面向金融行业分布式架构提供了跨区容灾、多地多中心、故障自动恢复等功能，保障业务稳定高效运行。

其中，通过对数据库内核的大量优化，CynosDB（TDSQL）极大地提高了系统处理性能，很好地满足分布式应用系统的需求，同时为系统提供了⼆阶段XA分布式事务，确保分布式事务的完整性。在扩展能力上，CynosDB（TDSQL）支持在线扩容数据库节点，使分片数据自动按指定规则平滑过渡至新扩容节点中，且整个操作过程对应用系统无感知。针对数据安全，CynosDB（TDSQL）采用强同步机制来确保主从节点数据完全⼀致，同时，支持物理备份、逻辑备份等周期性备份方式备份数据，最大限度确保数据的安全性。此外，CynosDB（TDSQL）在数据的传输、存储方面也添加了大量的安全机制来确保数据不被窃取、篡改。

近年来，中国金融行业数字化进程不断加快。数据显示，腾讯云服务的金融领域客户已超万家。其中，作为腾讯自主研发的金融级数据库，CynosDB（TDSQL）正在成为众多金融机构数字化升级过程中的“使命担当”。目前，CynosDB（TDSQL）已经为超过600机构提供数据库服务，客户包括张家港行、微众银行以及省部级政务机构等，行业覆盖银行、保险、证券、第三方支付、政务等领域。

雷锋网雷锋网

腾讯金融云总经理胡利明在演讲中表示，目前，腾讯云在金融新基建方面构建了涵盖专有云、金融专区、数据库、微服务治理、运维等在内的分布式基础云平台，以及移动中台、业务能力中心、数据中台、AI中台等落地方案。

而在数字新连接方面，腾讯云提供基于微信生态的微金融渠道、云景开放金融平台、云霖产业金融平台等渠道升级解决方案，并打造了智能营销和风控支撑平台，为业务开展提供支撑，助推金融机构实现数字化渠道转型。

在上个月发布的2020Q2财报中，腾讯就披露过“金融科技及企业服务”当季收入同比增长30%至人民币 298.62 亿元；云及其他企业服务收入同比、环比都在稳步增长，主要受互联网公司及公共服务领域客户的云服务用量提升带动，强调“与金融机构及公共服务领域客户签订了重大合同，同时扩大了在医疗、教育、会议及展览等新兴垂直领域的业务，协助客户实现数字化转型”。

而这些腾讯云与金融机构的合作细节，以及战略升级之后的最新布局，也在胡利明的这次演讲中有所体现。以下是胡利明演讲全文，雷锋网AI金融评论做了不改变原意的编辑：

首先给大家汇报一下腾讯金融云今年的主要的进展。经过5年多的发展，我们服务了超过150家银行、几十家的券商和保险公司，以及超过90%的持牌消费金融还有数量众多的泛金融企业，付费客户数超过了1万。另外协助建行构建了集团云，帮助中行构建了全行的数据智能平台，帮助交行建设了移动金融开发平台。

今年我们又有更多的突破：帮助人保集团打造了多地多中心的全分布式基础架构；帮助中国银联建设了超大规模的集团云，支持它的核心业务云化以及金融科技的输出；和深交所深证通合作打造了资本行业新一代的金融云，降低了整个行业的创新门槛，加速了行业的数字化。

另外我们今年还有非常多的业务赋能的案例，典型之一是帮助龙江银行快速地构建了网贷和风控的能力，放款规模在很短的时间内超过了80亿的规模，打造银行零售业务赋能的标杆；在产业金融方面，也帮助瀚华金控打造了它的区块链加上供应链金融的平台。

腾讯云眼中的金融业五大趋势

对于金融行业未来变革的趋势展望，我们联合腾讯研究院共同打造了未来金融变革的蓝图，详细材料会在腾讯研究院官网线上发布。

随着技术的发展、市场大环境和客户行为的变化，未来金融行业呈现以下几个方面的趋势：

第一、渠道的变革。疫情加速了整个行业的线上化，零接触的模式成为重要的方向，渠道端是以移动端为主。

第二、利率市场化导致整个的行业利差降低，竞争加大，利润降低。

第三、线上业务风控难度在加大，风险逐步地在累积，监管整个的政策也是在趋严。

第四、在零售端细分的一些客群，包括企业的普惠金融客户，仍然存在非常广泛的市场机会。

第五、金融产品同质化严重，市场呼唤具有差异化，尤其是具有地域特色的一些创新型的金融产品和服务。

在后疫情时代，因为这些趋势，数字化的进程在持续地加速。

那么，什么是数字化？我理解是将客户、场景、产品、服务等等转化为数字形态，优化服务和流程，

提升整个的内在价值，增强创新力和竞争力，建立基于数据以及客户体验为中心的产品和服务。这张图是我们围绕行业的趋势，打造的未来金融变革蓝图。

左侧在新的消费端，像新的技术5G和IOT，就带来整个终端的泛在化。除了手机以外，像眼镜、手表、智能音响等等，越来越多的终端也将成为用户的载体，客户的体验形态将会前所未有的丰富。比如说VR、AR，包括混合现实、沉浸式的社交等等，非常多的体验方式慢慢会出现，就是应用于各类的场景。

在金融行业，其实也会很快地出现一些革新和变化。在这些新的体验当中，需要金融服务的相应的场景也在指数级地增长。

右侧在新的产业端，各个行业自身的数字化，也为金融供给侧改革提供了基础条件。区块链、数据智能等等新的技术，它的采用帮助了金融机构在产业端的信用的评估、风险监控等等领域，提供了新的抓手。有机会更有效地推进产融结合，然后线上的管理、在线的办公的出现，为2B2C开辟了新的场景。

线上的金融服务，比如说代发薪、财务报销、银企服务、企业保险等等，都可以绑定在线上的办公、线上的管理场景进行植入。未来金融的企业，将打造敏捷、创新的新组织，具备强大的金融新基建的技术底座不断创新，形成更个性化、普惠化的金融产品，通过无所不在的客户的连接渠道，触达和服务新的消费群体和产业金融、服务实体经济。

我们认为，未来金融的核心要点，是打造新基建和新连接。在数字新连接方面，是帮助金融机构完成渠道升级和超越、驱动增长，要点包括四个方面：

第一，新体验，基于5G、社交网络和IOT之上打造像微信小程序、直播、视频、虚拟人、包括AR、VR等新的体验的方式。客户的注意力也会越来越集中在一些更直接、更友好的交互形式当中，金融服务的体验将被重塑。

第二，私域流量的兴起。从以前以线下流量为主扩展为基于像微信的开放体系，12亿用户流量池，基于这个流量池，构建属于这个金融机构本身特色的私域流量。

第三，场景金融。金融机构从以前的坐商以及被动的开放，转变为主动嵌入到各类的生活的场景，包括企业经营的场景当中，甚至包括同业业务合作的场景当中去。

第四，互联网运营。由以前的重建设轻运营的这个模式，升级为把互联网运营的方法、工具和基因注入到金融机构运营的日常当中去。

金融新基建方面，主要是帮助金融机构练好内功，要点主要包括以下三个：

第一，在核心系统和业务系统方面，主要是瘦核心加上微服务的这个架构。

以前的巨型的系统升级为稳态的瘦核心，加上业务的微服务模块的方式，通过技术建模、业务建模，使用这个微服务的模块，快速地迭代业务的能力，逐步地积累和发展，再形成这个金融机构公司内部特色的业务中心平台，服务于公司内部各个业务场景，进行复用。

第二，当前传统的、局部的智能方式，将升级为全流程的数据智能，通过全公司的数据湖、数据治理平台加上机器学习的平台，共同形成一个决策大脑，作用于行业的各项的业务。

第三，也是最基础的一部分。指的是自主核心的基础架构的技术、传统的金融机构核心技术，主要依赖于外部，甚至说国外的技术。将来会逐步升级为信创自主可控的技术平台，比如说核心数据库、分布式的中间件、云平台，甚至更底层的硬件。

如何实现未来金融的蓝图落地数字化转型？腾讯云从14年支撑微众银行全面采用云架构上线业务以来，那么从金融云的底层的基础设施逐步地走向了上层的金融科技业务赋能，最终形成一个体系化、全面的数字化转型，1+4+5的产品架构方案。

底层是一个自主可控的分布式云平台，包括专有云、金融专区、包括数据库、区块链、微服务治理、金融安全等等的部分，都包含在这个基础云平台当中。

中间层是四大中台，包括我们的移动中台业务能力中心、数据中台以及AI中台。

在上层新连接的部分，包括三个渠道平台，一个是微金融的渠道平台；第二个是云景的开放金融平台，以及产业金融侧的云霖产业金融平台。那在支撑这个渠道平台的这个后端，是两个非常关键的智能营销平台和智能的风控平台。

整体上形成一个全渠道、新体验的客户的界面，具有敏捷进化、云智一体的特点，能够抓住未来金融发展的脉搏。

「金融新基建」五大特色技术方案

接下来我展开介绍一下新基建和新连接方面，腾讯的特色的方案以及实践在新基建方面。

首先是最底层的云平台——TCE。TCE的全称是Tencent Cloud Enterprise，它是基于我们久经考验的公有云技术，把非常多的组建私有化形成全栈的一个专有云解决方案。

现在很多金融机构，包括金融科技公司需要支持集团云，包括对外输出的生态云的模式，那么一朵云不仅服务于自己内部的业务，也服务于集团内的多个子公司，甚至包括对外部公司的一个输出。

腾讯在这个场景方面，是走在业界的前列。我们成功地服务于像建行、人保、中行、微众、银联等等非常多的大型机构，其中像微众和建设银行都是超过万台的一个非常大的服务器规模。

TCE今年也有很多增强和升级：

第一个方面是成本持续的优化，使得我们IT的成本相对于传统的架构降低了80%；

第二方面，我们提供了像行业版、企业版、大数据版、敏捷版等等好几种的版本，针对不同的场景进行了定制；

第三方面，我们全栈的产品支持了当前主流的国产化的操作系统以及芯片，实现了整个的平台+底层的、技术的自主可控，这个在现在非常复杂的国际形式下是非常重要的。

新基建的第二个特色的核心技术，是分布式的金融交易数据库——TDSql。它也是腾讯支付底层的交易数据库，目前服务于包括中国银行在内的500多家金融机构。

早在15年1月份，我们就支持了微众银行上线，微众银行目前总的账户数是超过了2.5亿的客户交易的最高峰值，达到了22.5万笔每秒，这个是非常大的一个峰值。

在去年的9月份，我们也支持了张家港银行，它的核心系统完成国产化的、分布式改造。这个案例也成为国内首个传统核心，采用分布式数据库的一个标杆。今年我们也和平安银行进行了信用卡核心系统分布式改造。

TDSql除了极致的可靠性以外，也具有非常大的、非常强大的性能，支撑着腾讯内部超过300亿的各类的账户。系统的性能支持最大500万的QPS，整个的技术接口兼容mysql的这个接口，技术的门槛非常的低，体系非常开放。同时TDSql有非常完备的自动化故障诊断和恢复的工具。

新基建的第三个技术方案，腾讯云原生的解决方案——TCS云原生架构，近年来因为非常的灵活、轻便、部署简单，而且配合，搭配了像devops和完善的微服务治理的能力，已经越来越成为了金融企业基础架构的一个新的选择。我们的TCS云原生平台有几个特点：

第一，是非常灵活。一台机器就可以快速地部署；

第二，是我们把运维的应用模型进行了抽象，实现了运维模型的一个复用以及云端的运维；

第三，我们是以应用为视角，管理业务的生命周期取代了传统IaaS，以虚拟化资源为视角的模式的业务交付，交付的效率整整提升了100倍；

第四，我们在这个平台上，其实搭载了大量的腾讯云的PaaS和SaaS产品，比如说腾讯会议。

新基建的第四个方面，金融的分布式核心业务系统、核心业务系统是金融机构业务的心脏。我们联合长亮推出了金融分布式业务服务框架TDBF，做到了整个的业务流程和核心能力的预置。开放业务调用的接口，可以灵活的叠加定制业务，极大地提高了业务系统的建设以及扩展的效率。真正地做到了金融业务系统即服务。

今年我们也还全新升级了架构，首创了业界领先的分布式核心技术底座的替换方案，为金融机构搭建自主可控、单元化、跨机房 多活的分布式核心贡献腾讯力量。

新基建的第五个特色的产品就是移动金融平台（TMF）今年也进行了全新的升级，我们帮助客户开发的效率提升到150%，拥有更强大的移动端的生态和更智能的线上能力。

首先，今年新支持了线上业务流程的自动化和智能化，包括事中的实时质检，事后的留证回溯，包括多端的数据分析洞察等等。

第二，对接了云景开放金融平台，诸多的开放金融的场景。

第三，我们针对微信小程序平台进行了深度的对接，提供了非常丰富的小程序组件，包括金融机构快速、安全合规的融入微信生态。

TMF已经服务了非常多的国内的头部金融机构，覆盖超过1亿多的客户。比如说我们今年帮助交通银行的APP4.0上线，在两个月之内它的日活用户的增长超过了30%。

在新基建的数据智能创新方面，联邦学习绝对是目前炙手可热的方向，也是解决金融数据在合规的前提下合作难题的最好的解决办法。

腾讯神盾联邦计算通过密码学和机器学习技术的结合，让数据合作的双方不需要在外传自身数据的情况下，能够合作建立机器学习的一个模型，联手发挥出这个数据的价值。

神盾平台计算不需要第三方，解除了第三方合谋的风险，同时通过非对称的算法杜绝了像数据样本泄露风险。我们也有非常多的专利研发了新型的同态的密文。让整体的计算的时长减少了99%。

如何助力金融机构用好微信端流量红利？

目前，其实金融机构大部分的客户来源于线下的网点以及业务员。通过APP获客非常的有限，目前流量成本在行业里面也越来越高。流量经过一些多轮的清洗之后，质量越来越差。银行界里面近年来实践的直销银行其实效果也不是太明显现阶段。

我们觉得最大的机会和红利其实在微信端。微信有12亿的月活用户，有消费端的公众号、小程序、直播 广告、支付……非常多的生态。在产业端也有企业微信上百万的企业以及腾讯云产业互联网跨界合作的这个生态。

不管是在零售端的客户还是小微企业的客户，通过微信端的服务和推广入口进来都可以快速导引到我们金融企业的私域的流量池。

这里举个例子，像拼多多，在电商竞争已经非常红海的情况下，把微信的社交流量发挥到了极致，快速地在几年之内从0构建了一个拥有5.8亿用户的电商帝国。

其实在金融行业，哪一家公司能够把微信端的私有化的流量池用好，将会是行业里面下一个拼多多，具有非常巨大的潜力和机会。

我们腾讯团队会提供非常专业的互联网的流量运营的经验、方案和工具，来助力大家从用户的获取激活、存留、裂变、转化等等整个的过程。

基于数据精细化、智能化，具体要怎么做呢？首先在直接触达客户的数字渠道方面，我们建议金融机构建立自己的微信小程序门户，作为自己流量的阵地，运营客群，带动业务，微信小程序有几个优势：

一，海量的微信用户，天然已经在平台上面。小程序的日活也超过了4亿。

二，小程序是一个去中心化的入口，也是我们金融机构私域专属的入口。

三，用户使用小程序不用下载，不用更新，使用的门槛非常低。

四，小程序非常方便分享、传播、裂变，和传统的快消品、电商等等一些简单的广告推广方式不同，金融的客户和金融机构之间的连接，需要值得信赖的一个强连接，才能够带来好的转化和存留。

微信端的连接恰恰非常得契合，并且社交的裂变相关的效果是出乎意料得好，整体的成本也非常非常得低。

在和某家股份制银行合作的实践当中，小程序的转化的成本是他们以前APP渠道的十几分之一。所以我们建议，金融机构要大力发展小程序端，成为和APP并列的一端，进入双端时代。除了获客转化率的传统的APP，还增加小程序这个强通路。

打造一个小程序门户，加上多个业务功能矩阵。作为流量池的载体，快速地承接所有的线下线上推广的渠道，也可以精准的关联到单个的业务的场景。比如说缴费、信贷、理财等等对客户来说非常得贴近场景。

我们也会向金融机构提供专业团队，进行小程序的设计和开发的服务，通过业务模块内容模块相关的组装，再加上企业特色的定制整体形成体验领先的微信小程序门户和矩阵。

另外一方面，员工或者客户经理和客户的连接其实也是目前金融机构主要的业务来源，非常需要通过数字化的方式来武装和激活起来。大多数的客户经理都通过个人的微信联系客户，那么有可能逐渐地变成一个私人的连接。

腾讯的企业微信加上微信它之间是打通的，通过这个关键的能力，我们打造了BC一体的客户运营的工具。

社群通。客户经理通过企业微信和客户交流所有的数据，我们通过社群通的管理可以做到数据的可存档、自定义的群发，包括客户的可路由、再分配等等，真正的把客户的关系沉淀到公司，实现一切沟通的内容均数字化。

获客通。获客通相当于是帮助客户经理打造个人的专属微信小店，除了认证的名片、金融的产品的展示以及权益推广这些以外，我们还可以帮助客户经理打造个人的人设，形成一个有温度、鲜活有个性的人，对客户形成非常专业、值得信赖的形象。

另外，在这个平台内部也建立了客群的、精准的标签，基于这些标签去推荐最合适的业务以及呈现的资讯的内容。

第三，采用AI的策略话术，通过智能的NLP，提取相应的内容的观点，这些工具给到我们的客户经理去对客户进行交流。

右边呈现了某个农商行的客户经理一天当中使用企业微信的整个的轨迹，可以看到从早到晚和客户的所有的交流的互动、营销的拓展，从公司的早会、记录信息、总结等等，都能够在企业微信的平台上非常好地完成。所有的客户关系、服务的信息都沉淀在公司的平台当中。

在后疫情时代，零接触金融服务的模式是非常明确的方向。

之前需要在网点办理的业务，逐渐地都能够迁移到线上。我们在去年年底就推出了，虚拟营业厅的产品，实现了7×24小时的移动视频营业厅，能够支持像私人银行服务、信贷的初审、面签、续贷、信用卡的营销、对公开户、理财风评等等超上百种业务。

截至目前，金融虚拟营业厅已经在57家银行落地，从大行如工商银行，到股份制如浦发银行，到城商行、农商行。

在开放金融方面，我们有提供云景开放金融平台，那数字化的金融一定是开放的。除了自身的私域流量构建以外，当然还需要全方位的，拓展合作方的场景。

腾讯在发展互联网业务以及云+产业拓展的这个过程当中，形成了非常丰富的金融+互联网、金融+产业生态，在云景开放平台当中全部提供出来，包括像微信缴费等等非常多的场景。

在实现以上非常多的客户营销，和业务开展的业务场景过程当中，其实需要一个非常懂得客户的后端营销平台。我们腾讯把多年互联网客户运营的经验整合对外输出形成了云隆金融营销平台，具备营销自动化的能力，汇聚了腾讯系超过100多种特色权益。

同时我们最新打通了对微信支付营销的这个接口，像支付优惠券，这些场景对于金融营销是非常契合。此外平台也能做到基于大数据的用户画像，千人千面的活动内容、定制化产品的推荐；内容上也提供10万+素材，实现了营销活动和内容的高效生产，整体提升客户黏性。

举一个小小的例子：在疫情期间，我们帮助某大行的分行持续地进行营销的展演，累计生产了差不多超过100多场营销的活动，带来了超过31万的微信新客户的获客，平均贷款的进件转化率高达13%。

除了金融的零售业务赋能以外，为了应对产业互联网转型过程中，出现的金融的需求，我们推出了云霖产业金融解决方案，覆盖了包括工业、交通、零售在内的十多个场景。

根据产业链的特性，我们在应用侧推出了三大类，九个子类的行业解决方案，包括以供应链为主的供应链金融，依托量化数据授信为主的中小微企业解决方案，以及服务细分行业的保理云、租赁云、ABS云等等解决方案，为应用侧提供基础支撑，还有产业风控能力以及全栈的金融科技能力。

同时依托风控决策包括机器学习、区块链以及AI工具箱，覆盖超过2400条以上的产业链，形成了超过3500个以上的风控变量，能够为产业金融业务的开展提供企业的风控画像、产业链分析、全网的舆情以及产业智能风控服务。（雷锋网）

雷锋网

平顶山银行是平顶山市委市政府主导的地方法人金融机构，是河南省仅有的5家城商行之一。2019年末，平顶山银行资产总额突破千亿元大关，成功迈入千亿级银行行列。

本次合作，腾讯云将为平顶山银行提供符合公有云标准的金融级生态云平台，并提供持续运营的基础设施支持，包括完整的底层基础设施、互联网络、安全防护、开发运维、运营管理等相关能力支持，保障云平台的平稳建设和持续运营。

在金融业务基础上，双方将探索在数字化银行、大数据精准营销、用户画像、智慧风控、信贷科技、社区金融、农村金融、小微金融等领域的深度合作，共同提升服务平顶山市及河南省内客户的整体服务水平，建设智慧银行的标杆样例。

除此之外，双方还将在智慧政务、智慧教育、智慧社区、智慧医疗、智慧住建等多个层面展开深入合作。

目前，腾讯云已经服务了超万家金融领域客户，包括150多家银行、数十家保险及证券公司、70%的持牌消费金融公司和80%的新筹保险公司，四大国有银行中已经有三家和腾讯云进行紧密合作。

在疫情期间，为了帮助金融机构服务畅通，腾讯云紧急上线了虚拟营业厅抗疫情快速部署包，全力支持金融机构在线提供24小时营业厅、贷款和对公开户面签、视频客服等能力，满足疫情期间个人及企业的金融服务需要。

随着5G、大数据、人工智能等在金融领域的普遍应用，加大金融科技投入已是行业共识。尤其是本次疫情中，当线下网点无法有效触达客户时，推动金融服务线上化、智能化的迫切性更加突出。

从多家银行披露的年报来看，银行普遍希望拥抱金融科技，按下数字化转型的“快进键”，但是传统IT架构却成为了创新最大的“拦路虎”。

“国内银行业信息化建设开始较早，总体以传统集中式IOE架构为主，扩展性和更新速度受限，

已经无法跟上以互联网化、在线化、数字化驱动的银行数字化创新的高速发展。”阿里云研究中心高级战略专家崔昊表示，将集中式IOE架构转为开放的分布式x86架构，并逐步以云计算服务取代周期冗长的硬件建设，将为银行创新提供强大的技术驱动力。

据上市银行最新年报显示，科技赋能金融已经成为银行业共识，一些先行的银行通过牵手阿里云等金融科技巨头公司进行中台架构转型，以及核心业务全面上云，收获了新技术带来的红利。

行业人士认为，以云计算为代表的数字新基建在银行业的应用逐渐广泛和深入，金融与科技将加速融合。

科技赋能金融成共识

近年来，金融监管机构持续推动科技赋能行业发展，金融科技的应用呈现逐渐开放的态势，加上“互联网+”概念在国内银行业的认知不断加深，国内各大银行均已认识到用科技赋能金融的重要性，纷纷加大金融科技领域的布局。

2019年8月，中国人民银行印发《金融科技（FinTech）发展规划（2019—2021年）》，该规划指出：强化统筹规划、体制机制、人才队伍建设等方面的战略部署，为金融科技发展提供保障。明确要求金融机构要在年报及其他正式渠道中完整披露科技人员数量与占比。

日前，上市银行年报密集披露，金融科技毫无意外成为年报高频关键词。不仅仅是六大国有银行，诸多的股份制银行以及城商行都在用大篇幅描述对金融科技的引入和投资。据统计，仅仅六家国有银行在2019年在金融科技领域的投入达到了710多亿元。粗略统计，全部上市银行在金融科技领域的投资远远超过1000亿元。

工商银行在年报中提出，“金融科技是过去一年本行创新发展的重头戏”。 2019年工商银行发布智慧银行生态系统(ECOS 1.0)，从生态、场景、架构、技术、体制等多端发力，促进科技与金融的深度融合。2019年年末，工商银行还与阿里巴巴集团、蚂蚁金服达成合作，将加强在云计算、数据智能、金融科技等关键技术领域的探索，加速金融产品创新。

作为股份制银行的代表，民生银行也在持续加大金融科技投入。2019年，民生银行提出以分布式架构转型为动力、以数据治理为抓手，为战略实施和改革转型提供技术“动能”、数据“赋能”和资源保障。

事实上，民生银行早在2108年就借助用阿里云的分布式核心技术，完成了直销银行系统全部上千万电子账户迁移，系统成本大幅降低，交易速度和能力明显提升。

金融新基建红利凸显

梳理近期年报还可以发现，对于银行而言，金融科技已不再停留于早些年的战略讨论阶段，而是逐步渗透到业务运营之中，成为转型的核心驱动力之一。少数率先深度使用金融科技新基建的银行已经开始从科技转型中谋得红利。

以长沙银行为例，2019年该行资产规模突破6000亿元，营收、净利润均实现双位数增长。2019年，被长沙银行称为是“数据驱动年”，全行加快了从“应用启动”向“数字驱动”的动能转换，通过牵手阿里云等厂商，逐步实现线上化、数字化和智能化转型。

在对公业务竞争白热化、利率市场化导致利差大幅收窄的背景下，深耕零售领域成为银行寻找新增长点的重要抓手。而银行业的金融科技转型，零售业务也成为主战场。

已经公开上市招股书的顺德农商银行日前公布携手阿里云进行数字化转型的阶段性成果，基于阿里云输出的mPaaS移动开发平台和大数据风控平台，实现个人贷款业务的全流程纯线上操作就实现了零售业务的快速增长。

在广东农信，金融科技的创新让银行与实体经济更加紧密的结合在一起。广东农信以云为“底座”，与阿里云一起落实数据中台与业务中台的 “双中台”架构，初步形成“厚中台、薄前台、稳后台”的体系建设。

在服务某棉纱行业客户时，广东农信在相对同质化的金融服务之外，输出云、APP、中台的能力，帮助客户构建了B2B电商交易平台，不仅获得了这一大业务规模、大资金流量重点客户的金融服务业务，更与该棉纱客户的业务流程紧密相连。

“金融科技将不再只是提供后台技术支持、，而是直接关系到银行利润创造。”一家股份制银行的高层表示，金融科技带来了银行业务重塑，这种重塑将对整个行业格局产生重要影响。

金融行业上云有望迎来拐点

麦肯锡研究发现，数字化业务逐渐成为传统银行的重要收入来源，因此数字化转型升级也是银行未来发展的必经之路。

首先，银行业实体网点规模持续收窄，业务在线化需求日趋迫切。数据显示，2016年-2019年，六大行三年内累计裁撤线下网点1749个，仅2019年，工商银行就裁撤了220个线下网点。与此同时，科技决定银行的未来已成业内共识，金融科技人员在银行中变得不可或缺，2019年工商银行披露其金融科技人员规模多达34800名，占比高达7.82%。

另一方面，纵观全球金融行业，上云趋势势不可挡。国外，Capital One、高盛等银行相继与AWS合作“上云”，而国内民生银行、南京银行等上百家银行也在跟阿里云等合作“上云”。权威市场研究机构IDC报告指出，阿里云位居中国金融云解决方案市场第一，成为支撑金融行业面向未来的关键数字基础设施。

业内人士认为，在互联网行业，云计算已高速发展到了“业务系统互联网化”和“数据在线智能化”阶段，而在金融业，云计算仍处于“非核心系统上云”和“基础资源全面云化”阶段。而持续至今的新冠病毒疫情可能是一剂催化剂，将加速银行核心系统的上云步伐，迎来行业拐点。

以云为基础，未来银行将构建一个生长在平台上的“数字（孪生）分行”。银行将利用云端的能力和智能的技术开展金融服务，并且和多方建立新的基于数字技术的紧密连接、高效协同和场景创新，让国内银行业具备与互联网公司一样的快速迭代速度，吸引大量新鲜需求和创新场景。

“突发的疫情把银行线上化运营和数字化经营推向了一个新的高度。”一家省农信社科技部高管指出，非接触金融服务背后，IT技术的重要性比以往任何时候都更重要。

布莱特-金在《BANK4.0》这样描绘未来的金融服务：“金融服务无处不在，就是不在银行网点。” 显然，汹涌而来的数字化浪潮中，金融科技新基建决定着银行的未来。

雷锋网雷锋网

吴军在《浪潮之巅》中揭示当下工业革命的范式：现有产业+大数据=新的产业。

如何正确得使用大数据，将公司现有的业务和市场规模变得更大，成为当代几乎所有企业都必须思考的一个问题。而大数据平台便是这个问题的解决方案之一。

对此，雷锋网采访了京东数科T1大数据平台负责人。

他和我们分享了京东数科T1大数据平台的产品特点和技术特色、在金融领域的服务情况以及在具体实施过程中遇到的困难等内容。

以下为对话实录：

雷锋网：T1大数据平台是一款什么样的产品？

T1大数据平台是一个涵盖数据采集、加工、处理，包括数据资产管理、数据服务和数据应用等一整套从底层到上层的、全生命周期的一站式大数据平台。

平台有两个特点，首先它是一站式的平台，从底层快速地帮助用户搭建一整套的大数据体系，帮助客户迅速完成数据的资产化和价值化，并且通过数据服务层的能力组合，比如数据接口或者画像、标签、相关的系统支撑各种业务场景。

第二，整个大数据平台本身是一个配置式和自动化程度比较高的系统，能为用户提供良好的操作体验，大大降低用户操作门槛。

雷锋网：T1大数据平台面向哪类型的客户？

一般是金融机构，目前我们做的比较多的有民营银行、股份制银行和城商银行，可以简单的分为三类：

第一类金融机构，目前还不具备高效的实时处理和分析功能，它们需要建设一个实时的大数据处理平台。

比如一家中型银行，每年产生的数据量可以达到数十TB，涵盖了应用数据、行为数据和系统日志等多种多样的数据来源和格式。如果没有合适的运营管控工具，这些数据只能“沉睡”在后台，无法发挥价值。

第二类金融机构，具备传统的数据仓库，可以解决分析报表的需求，它们需要建设一个整体的大数据解决方案。

第三类金融机构，本身具备不错的大数据平台能力，但建设的比较分散、孤立，业务之间存在gap，它们需要一些产品，比如数据接口或画像系统，在大数据平台和应用之间架起桥梁。

雷锋网：如果客户本身已经有大数据平台，再对接T1大数据平台，会遇到哪些问题？

客户在已有大数据平台上再采购集成其他的大数据产品，主要会碰到的是兼容适配的问题。

相对于业内某些产品的封闭性和排他性，T1大数据平台是一个开放式的架构，既可以把平台整体输出给用户，也可以按需输出某些子产品作为客户的能力补充。

T1的子产品对外部依赖都做了兼容性的处理，也预留了一些对接接口，可以快速和客户本身已有系统进行对接。比如T1大数据平台曾输出画像产品给某家客户，需要和客户已有的ETL系统进行调度对接，由于画像产品已经预留了调度对接的接口，所以非常顺利地就完成了对接工作。

雷锋网：金融机构十分注重安全性问题，京东数科对此做了哪些工作？

的确，金融公司对数据的归属性都比较敏感，T1大数据平台提供私有化部署的服务，可以把大数据平台部署到客户的环境当中，将数据划定在一定区域中，非公司内部人士不可能直接访问到相关数据，从机制上保证了数据安全。

在使用大数据平台时，对于企业客户内部的操作人员，京东数科提供数据全生命周期的安全管理服务，对敏感数据进行分级分类。这种方式下，操作人员只能接触到一定范围内的数据，保障了操作时的数据安全问题。

雷锋网：T1大数据平台有直接对标的产品吗？国外有Cloudera，Hortonworks，国内有神州信息、华为、星环、明略数据等大数据平台产品，相比这些厂家，T1大数据平台有哪些优势和劣势？

京东数科T1大数据平台具备实时异构的海量数据处理能力，比如实时数据处理平台，已经达到TB级的数据在线实时处理，并且能够提供毫秒级的延时。

此外，京东数科T1大数据平台还提供了一套新的数据服务架构，在以前传统的架构中只能处理结构化的数据，而T1能够对各种结构化、半结构、非结构化的异构数据，实现统一的数据接入、数据整合以及数据加工处理和分析。

雷锋网：之前您说道，T1大数据平台”是一个全套的解决方案，可以给我们讲一讲它“全”在哪里吗？它比较特色的组件又在哪里？

T1大数据平台的“全”主要体现在三个方面：一是产品功能覆盖了从异构数据的采集、存储、加工和使用的数据全生命周期的端到端的整体流程，具备采集的数据类型全，采集的时效性高和使用方式灵活多样的特点。

二是产品操作方式覆盖了大数据技能水平的所有用户群体，既提供了拖拽式、智能化的不需要具备专业大数据技能的便捷操作方式，也为算法工程师、数据科学家等高阶用户提供了自由式的数据探索入口，让平台的作用最大化。

三是在大数据价值链的传递上能够为数据应用的全场景提供良好的支撑，数据接口、标签、模型等服务都可和上层数据应用场景做无缝集成和对接。

有不少比较有特色的组件或功能，比如数据复制组件可以实时解析采集MySQL、Oracle、DB2、HBase和Mongodb等多种主流数据库的数据，在整个业界同类产品中功能也是非常领先和突出的。标签画像组件不仅仅具备标签画像的加工查看功能，还提供了和上层业务的快捷对接方式和应用效果评估，解决了使用上“最后一公里”的问题。

雷锋网：对于一些本身体量较小或者目前数据量积累较少的公司，有人认为没有必要搭建这一套系统，暂时先租用AWS和阿里云就够了。对于数据量大，但数据分析需求较简单的公司，可以直接买Tableau，Splunk，HP Vertica，或者IBM DB2等软件或服务即可。您觉得数据量或者记录规模大概达到什么级别就必须上大数据平台？

大数据平台的使用可能和数据量没有直接的关系。

有的初创公司或者某些行业的公司，对于数据的使用和数据归属性的要求没那么高；有些公司目前的需求是解决一些业务运营分析，它们的确可以去购买一些公共的服务。但是当这些公司发展到一定阶段之后，如果想去更好的开展一些业务，比如说营销拓客、在线个人信贷或者风控，是需要具备大数据平台能力的。

雷锋网：T1大数据平台是开源的吗？

T1大数据平台的底层基于开源的生态体系来打造，这样能帮助我们的客户去利用到开源生态体系的一些能力，支撑业务的发展。但就产品本身来说，目前不开源。

雷锋网：T1大数据平台从开始定制到正式使用，一般需要多长时间？

目前，T1大数据平台已经是非常成熟的一套标准化的产品。我们也提供了一键式安装部署的服务，可以把T1大数据平台以标准化的方式，非常迅速的融入客户的IT系统中。基本上一周之内，它就可以实现投产运行。

雷锋网：您提到，一周内可以完成产品的部署。那把产品从0到1部署到银行原有IT系统的大致流程是什么样的？你们这一周主要干哪些事？

T1大数据平台为了保障对客户的交付效率和体验，更多的工夫会体现在这一周之外。从技术层面上，T1大数据平台可以实现自动化和容器化的安装部署模式；从交付方式上，专业的交付实施团队会提前和客户规划好部署架构，并在T1大数据平台的自有演练环境完成部署演练，从而达到在客户现场最快速部署落地的效果。

雷锋网：在这一周的部署过程中，你们需要帮银行IT部门解决的最复杂的技术和系统对接问题，您认为是什么？

在真正部署的阶段前，我们会同银行IT部门一起来解决适配和对接的问题。在银行落地过程中，主要会碰到基础环境兼容、既有系统对接和客户自有工作流程的衔接等问题，相对来说既有系统的对接是比较复杂的部分，T1大数据平台各个子产品对可能发生外部交互的功能逻辑进行了抽象封装，以接口化、插件化的方式实现最小化代价的对接。

阿里金融云总裁徐敏认为，新金融是一个云计算、大数据、AI、IoT、区块链所支撑的数字金融，而新金融的实现以数据为纽带的金融和产品指引。他也在近期的2018云栖大会上，分享了阿里云过去数年间在分布式微服务、人工智能和场景方面与金融机构合作的案例和心得。

以下为演讲全文，雷锋网做了不改变原意的编辑：

金融到底该被谁来定义？说实话，美国的华尔街金融定义影响了我们很多年。我认为华尔街金融最和谐的诉求是资产的保值和增值。但是资产增值，到底应该是目标还是结果？

“金融实现民主化和普惠，扩大化和人性化”，这应该是一个目标，增值保值是一个结果，要反过来思考。而今天，互联网能够帮助我们实现这一点，互联网我们把金融服务带给每个人，而不是用户来这边取。互联网是能够让我们以更低成本服务更多的客户，这一切正在发生。（雷锋网AI金融评论注：本段所引用句子来自经济学家Robert J. Shiller《金融与好的社会》）

新金融的三种发展方向

我认为新金融是一个云计算、大数据、AI、IoT、区块链所支撑的数字金融，这五个方向我也认为是金融机构、金融科技的重要方向，而数字金融是新金融的本质。而新金融的实现以数据为纽带的金融和产品指引，无论2B、2C，强调数字为代表，强调数字成为纽带，强调直连。

今天想分享的这三个方向，是在过去几年经过实践，在今天已经基本成熟，能够大规模利用，并且有很好业务效果了。

• 互联网分布式微服务

微服务本身是一个IT概念，可以叫做SOA（Service-oriented Architecture，面向服务的架构）的升级版。我发现它的很多理念，不仅适用于IT，也适用于金融业务、金融服务。例如大中台、小前台，让更多能力放在中台，让前台变成以更灵活的方式来实现，强调能力的沉淀——这里说的是持续的沉淀。

我觉得微服务项目跟SOA项目最大的区别是：SOA是个项目，单做完之后打通之后就放走了；而微服务架构是要体系，强调用沉淀的能力来去赋能新的应用，形成体制和机制，而机制也能够用在银行业务之上。

另外就是业务打通和能力嵌置。过去数据的价值是我们应用的财富而已，但今天我认为，应用是数据的改革形式，主要是数据。在阿里巴巴，我们强调一切业务数据化，一切数据业务化。最重要的是，要强调从生产型模型向运营型模型来转变。这什么概念？我们发现，花很长时间开发的系统就放着不动了，统一技术半年或者两年变革一次。金融机构的产品也是这样，做个产品放这边，后面就没有什么优化了。

但是扩展公司（的时候），强调运营，我们会用很快的方式上线一个项目，然后不断迭代，项目来自银行，现在我们能做到每天版本升级更新，核心上线才花4个月。这样的模型我觉得对IT、对业务，都会有很大的帮助改变。

我认为分布式微服务架构能对经济带来一个所谓的乘法效应，就是交易的性能成倍提升，交易的成本也大幅降低，它是乘法效应，例如我们跟民生银行一起来做分布式的银行，交易能力从每秒7800笔到30000笔。包括广发银行，我们在做整个中台的搭积木创新，性能提升几十倍，整个的交易能力提升很多，成本降低五分之一。基于这个平台的业务创新，一年交易量是过去10年总和，所以他们叫线上一年，线下十年。

同样今天在广东农信，包括杭州银行、苏州银行，很多地方都在实践，这是一个方向，通过微服务方式让我们整个升级引擎、交易核心带来乘法效应，同时做完之后带动业务创新，让业务也能逐步实现微服务化。

• 人工智能

抛开数据智能的伦理观不谈，我认为很长一段时间之内，将是人脑制定规则和机器执行规则，但关键是数据在线。而且我认为数据智能将会为金融机构带来一个指数效应，因为分布式提升的是生产力，而数据智能和大数据改变的是生产资料和生产关系——这个变化才刚刚开始。

之前也做了一些实践，例如和银河证券合作，帮助银河证券把整个理财的购买预测模型的性能提升了，包括优化证券开户的全流程，之前30%的客户会开户不成功，现在降到百分之十几。还有和南京银行的合作。

我们做了几个事情。一是营销引擎，一家活动想清楚业务规模以后就上线了，今天一个平台去做试算，做测试。我们一个月之内，做了差不多20个批次的营销测试。在真正投入资源之前，用数据做测试。测完之后，我们就知道哪个效果更好了，才能把有限的营销资源投入到更好的效果里面去。今天我们去发现客户更加需要什么服务，比如用花呗来支付手机话费的方式把整个信贷的自用率提升了48%。

又比如国泰君安的很多客户，我们进去以后做数据分析，去发现这个客户的喜好是什么，例如客户喜欢看优酷土豆，那就发一些优酷土豆的代金券吸引他，所以这是我们跟很多金融机构做数据方面的创新，这只是一个尝试而已，才刚开始。另外也有跟中国基金行业做一个证券行业、投资行业的数据智能大赛。

• 场景

很多金融机构一直在说缺场景，但是久了你会发现，其实我们并不缺场景，缺的是场景的消化能力。例如有一家银行他们的网络金融部很厉害，把当地的运营商谈好了，运营商线上买手机的时候可以利用贷款分期付款，但是银行机构每天一千多笔交易进来之后，被风险部全部砍掉了，为什么？有风险我不能做。

我们目标是说，一方面我给金融机构带来一些场景，在过程中我们和金融机构一起来合作，来把整个金融机构对风险、对流程的改造做起来。把这个流程做好以后，能够消化场景之后，未来基于他可以吸收更多场景进来。

就像量子跳跃这个物理概念，电子吸收更多能量以后可以到更高的轨道上面去，我认为金融机构会发生（这样的情况）。但那时候金融机构还是不是传统的金融机构？需要思考。就像一个电子从这个轨道跳到那个轨道的时候，还是不是这个电子？这是不一样的，但这个情况是一定会发生。

讲几个场景，比如天猫有阿里巴巴电商能力，包括移动、电信服务、银行APP进来以后，可以通过银行的收银台来支付买天猫商品，无论是积分还是信用付或是各种方式都支持。售后、物流我们搞定，通过这种方式把全世界最大的消费金融场景给到银行、给到保险、给到券商，包括三大运营商，来做客户运营，做消费金融一系列。通过这种方式，金融机构一方面活跃你的APP，有更多用户使用。其次是面向2B场景的工具，比如供应链金融+区块链。要把整个数字化中国结果对接的话，会加入IoT。

我认为做数字化中国，不仅仅是把产业的流程和一些线下的积累上线了，更是通过数据变成企业和外部交流的桥梁，所以数据将成为全社会企业面向内部、外部生态的协同调度桥梁。同时我们发现资源本身也是一种介质，在全社会范围内调配资源，数据跟金融这两者，在今天相遇了。

以阿里云的风险服务为例，客户来买云计算的时候，可以获得银行贷款，分期付款，银行基于一些像芝麻信用分数来看，今天到底应该给他多少信用额度，能不能放贷款。当客户发生坏账的时候，这时候我们可以通过云资源场景做资源保全，例如买了一年的云资源，第6个月发生了坏账，我把云资源的钱还给银行做这个事情。再例如企业采购平台，里面有上万家的大企业集采，员工福利可以通过他去买，同时那个场景下的金融需求可以跟金融云合作。

总结一下，今天金融行业的云会出现两种形态，一是叫金融行业云，目标是让金融机构本身数字化能够推进；二是金融产业云，用金融视角看产业数字化的进程。在这之后，用金融机构力量来帮助产业做数字化升级；同时通过API的方式，把金融能力嵌入到产业里面去。最后是企业数字化之后，把结果带回来。所以金融行业云跟金融产业云现在相遇了，这也是阿里云未来一两年之内要做的事情。

创新、数据、开放……金融转型的未来还需要什么？

最后讲一点我个人对金融转型的思考：

1.创新一定需要特区，必须有个地方能够把金融创新业务和IT能够完成。我们没有足够的时间去让行业里每个人来配合我们。很多时候，我们跟银行、保险、证券掌门人谈的很好，他们决定方向要去做，但是到中一层，到某些部门都会卡断，这是最大问题所在——最长木板决定方向，最短木板决定效果。

2.关于数据，“不知己岂知彼，不知所至岂知所需。”首先大家把自己的数据看清楚了，把里面的数据充分挖掘之后再引进来，同时一定要基于场景基于自身数据。

3.很多银行和我们合作非常好，是因为他们（思维）更加开放，在整个合作中没把自己当老大。自己不是老大，所以他们走得更远。金融会用什么路径实现创新，这个思维要想清楚了。我认为成为“平台”不是唯一路径，却是最难的一条路。

更多金融科技资讯，请关注雷锋网AI金融评论（公众号：aijinrongpinglun）