但对传统金融机构，如何拥抱金融科技依旧是在探索的阶段。1月27日，虎嗅邀请到了蚂蚁金服基础技术部中间件团队技术负责人杨冰，蚂蚁金服OceanBase首席架构师冯柯，ThoughtWorks资深商业分析师、FinTech 团队负责人裴兴蕊，Pivotal中国研发中心初创员工、核心产品产品经理吴疆，众安科技金融业务线总监吴婧婍与众多金融机构从业者一起聊了聊“科技如何赋能传统金融？”。

蚂蚁金服系统架构的升级之路

首先由杨冰为参会人员介绍了蚂蚁金服的系统架构发展。支付宝的第一代架构就像一个个独立的烟囱，做一个业务就竖起一个烟囱。烟囱型架构能够较好地满足小团队开发、业务快速试错的需求，但随着业务生态越来越丰富，烟囱型架构的缺点就显露出来了。

比如，每做一个新业务就要将一个烟囱进行手动改造，而支持主要业务的大烟囱则要经历无数次的改动。再比如，每个烟囱里面都会涉及到会员支付等基础的服务模块，但由于烟囱之间关联不大，就无法做到资源的共享，不可避免地写大量重复性代码。同时，烟囱型架构的部署也是集中的，核心系统就是一个集群，数据库也只有一个，随着业务量的上升，这样的数据库和集群很容易达到极限。

从2006年开始，支付宝的技术团队意识到，烟囱架构无法支持支付宝未来业务的发展，如果要继续拓展业务，必须先把架构分布化，建立底层服务架构。正如蚂蚁金服OceanBase首席架构师冯柯所说，分布式架构可以通过架构设计和软件的可靠性来弥补硬件的问题，硬件本身不再需要为系统的可靠性而托底，从而实现基于普通PC服务器来构建核心业务集群，在性价比方面也会呈现出数量级的压倒性优势。

而从2010年因为双11的原因，交易量一下子就上来了，之前的分布式架构也开始无法支撑高峰值的业务需求，蚂蚁金服逐渐开始将系统部署到云端，变成了云平台架构。

到了2013年，蚂蚁金服开始涉足更多的金融场景，不仅有支付，还有理财、保险、消费金融等业务，整个业务的架构也从一个支付云变成了整体的云金融的架构。同时为了支撑丰富的业态，也开始从纯粹的云架构变成开放式混合云架构，逐步便有了蚂蚁金服当前的架构雏形。

在架构的演进过程中也存在很多挑战。据杨冰介绍，蚂蚁的金融级分布式架构有六大目标，分别是资金安全、高可用、安全、性能、成本和数据质量。一般来讲，一套承载重要业务的系统，必须是高可用的、安全、性能要高，而且要有很好的性价比，但用在金融领域的话，还要强调资金安全和数据质量。

类似蚂蚁金服这个体量的机构，对金融分布式架构就提出了四大要求或者说挑战：

一是无限扩展能力，为了支撑这么大的量，要求系统能够实现灵活地伸缩，突破数据库，机房，地域等各个层面上的瓶颈。

二是高性能分布式事务。当数据在一台物理设备上无法全部存储时候，就需要分摊到不同的数据库或者不同的存储上面去，但是在金融场景里面又要保证跨库或者跨存储的事务一致性，同时还要确保很高的性能，这是非常大的挑战。

三是强一致秒级容灾。这个不难理解，像支付宝这么大的一个体量，如果业务停三分钟，会产生很大的不良影响，用户体验会很差，所以要保证故障的时候能够快速恢复，以及业务整体的连续。

四是弹性供给与调度。即不能毫无边际的用金钱的方式去完成这些挑战，还是要控制整体的成本。

基于OceanBase的金融云赋能

从蚂蚁金服的整个金融级分布式架构进化过程不难看出，传统的集中式架构很难解决一个快速增长的核心企业，对于容量以及容灾能力的关键诉求。对于提供云计算服务的机构而言，如何构建可靠性更高、扩展性更好、成本更低的分布式架构便成为核心竞争力所在。

要构建这样的分布式架构，业界出现了几种模式，一类是单机数据库+分布式中间层，本质是把原本应该由数据库解决的问题向业务层上移。在冯柯看来，这种模式会带来业务侵入、数据库功能受限和难以确保跨库数据强一致等潜在问题，相比之下，蚂蚁金服的原生分布式关系数据库可能是更好的解决方案， OceanBase便是典型代表。

据冯柯介绍，基于OceanBase的扩展能力，可以方便地实现业务的快速水平扩展和一键的扩容缩容，包括完全自动的负载均衡等。结合蚂蚁金服的单元化架构，可以在小时级别将蚂蚁金服的任何一个业务从日常模式扩展至大促模式，这是传统的集中式架构完全无法做到的。而OceanBase的扩展能力完全是基于数据库内核的原生能力，也就是说，不管物理层面跨越多少个机房，跨越多少个城市，所有这些参与部署的数据库服务器在逻辑上是一个OceanBase集群的一部分，无论是从应用视角还是运维视角，都是整体交付的。

对国内很多自主研发做基础类软件产品的团队而言，除了产品研发之外，最大的挑战是如何向你的客户证明你的产品是可靠的。要证明这一点，要求产品能够长期的在一些有典型性的示范应用中持续的运行，这就变成了一个死循环，先有鸡还是先有蛋的问题。

而 OceanBase成长于蚂蚁金服这样的一个快速发展的互联网金融企业当中，最不缺的就是应用场景，尤其是金融核心场景。通过核心业务的不断上线，蚂蚁金服帮助OceanBase渡过了一个对自主研发的基础软件产品而讲最艰难的应用关。蚂蚁金服本身作为互联网金融的标杆企业，也通过OceanBase的应用于2017年真正实现了所有核心业务100%去商业数据库。时至今日，OceanBase已经支持了阿里巴巴、蚂蚁金服数百个关键业务的执行，参与了四次的双11大促。

在沙龙的问答环节，有观众问到蚂蚁金服科技输出的路径问题，杨冰做了回应，提到了三个阶段：一是把在实践中形成的金融级的大规模交易处理能力开放出来，包括数据库、分布式架构、微服务框架以及移动端研发平台、大数据处理平台等；二是逐步开放实时风控、反欺诈、客户洞察等金融级实时计算能力；三是会逐步开放一些类似于大数据的PB级的分析数据平台。此外，技术的开放也会与产品的输出同步进行，成熟一个输出一个。

微服务架构立大功

在云计算平台中，有IaaS云平台（基础设施即服务）、PaaS云平台（平台即服务）、SaaS云平台（软件即服务）等几类，在IaaS模式下，服务商主要提供虚拟计算机、存储、网络等计算资源和访问云计算基础设施的服务接口；在PaaS模式下，服务提供商提供的则是运行在云计算基础设施之上的软件开发和运行平台；而在SaaS模式下，服务提供商提供的则是可以直接使用的应用软件。

从IaaS过渡到PaaS的过程中，需要在云端部署软件和应用，就产生了云原生应用的概念，在冯柯看来，所谓原生是指真正在数据库内核层面去解决掉数据库本身的可靠性和扩展性问题。而Pivotal的吴疆认为，一个云原生应用应具有四个特点：一是开发运维一体化，二是可以使用CI/CD工具实现持续的发布，三是基于微服务的架构，四是运行在容器之中。在构建云原生应用过程中，微服务架构是不可或缺的基础和前提。

微服务架构是相对传统的单体而言的，指把一个复杂的功能分解为若干个独立的可以相互协作模块的一种新型架构模式。在互联网时代，对系统应用的要求就是“快”，要快速开发、快速部署、快速迭代，快速试错，微服务架构便是在这种“快”节奏下应运而生的。

单体架构下，各个功能模块耦合度非常紧密，牵一发而动全身，一点点修改所需要的测试工作量都非常巨大，交付速度很慢，不容易部署，系统吞吐量受限，一旦发生故障，影响范围较大，在扩展性等方面也存在局限。而相比之下，微服务架构的每一个微服务的功能都很简单，代码量少，所以功能交付快，也容易部署，且系统吞吐量大，一旦发生故障，影响范围较小，扩展性也更好。

  不过，有一利也有一弊，微服务架构对系统运维能力也提出了很高的要求，或者说挑战。吴疆介绍了Pivotal在这方面的一些感受。首先是服务拆分，拆分之后要考虑服务的隔离，同时服务之间会有同步或异步的依赖，此时需要对这些依赖进行管理，否则服务之间耦合度过高，在系统进行升级的时候，就会变得很困难。此外，还要考虑服务治理、服务追踪、服务监控等问题。以服务追踪为例，系统分布式化之后，一个请求进来，处理这个请求需要很多的微服务进行配合，互相工作，才能最终完成这个请求，还会涉及到日志的管理、会话的识别、还有联合诊断等等方面，这也是一个新的挑战。

传统金融机构科技转型的路径

据《哈佛商业评论》的调查，在包括消费金融领域的十个行业是受数字化浪潮最大的行业。在裴兴蕊看来，传统金融企业要建立开放的金融生态需要做到三点：第一要围绕客户全生命周期做整个用户体验的重构；第二要做到基于数据的全维度和数据分析。第三点是能够进行全价值链的布局。同时这三点也是传统金融企业做数字化转型的关键点。

同时，金融企业的Fintech创新引擎要解决四个关键性问题：第一个是如何聚焦价值，第二个是如何做到快速的验证，第三个是怎么能够做到内外部的协作，第四个是如何建设允许失败的创新文化。这四种支撑起到了价值闭环的作用。第四点在互联网公司是非常顺理成章的事情，但是在传统金融企业却举步维艰。

以ThoughtWorks的经验来看，以上的四大支撑其实体现了数字化企业在做转型的四个核心能力，第一个是以客户为中心的服务设计能力，第二点是面向价值的端到端的产品开发能力。第三个数据驱动的洞察和运营能力。第四个是以服务化为中心的开放中台能力。数字平台战略就是企业在构建上述四种能力的非常有效的方式。

企业数字平台是基于云计算Iaas能力之上为 数字化战略提供能力支撑的一系列平台服务（Pass），涵盖IT系统研发与运营全生命周期，处于这个环节的最中间，它是提供客户洞察、服务供给、数据决策和实验创新这四大支撑能力的基础。

在讲到资源服务化平台的快速供给时，裴兴蕊为听众举了一个如何区别微服务和单体应用的有趣例子：乐高的玩具有两种，一种是大块的拼装玩具，可以拼插几种固定的形状，组合方便，但一个部件坏了会对整体拼装有很大影响，这就像是一个单体的业务应用一样；另外一种是小块的乐高，它可以拼插成各种形状，非常灵活，它就像面向业务的微服务单元一样，但是小块乐高的拼装难度会更大，对小朋友来说组装较为困难。微服务的困难在于调用和组装难度大，包括它的配置管理、服务名册、服务网关等。它就像是面向大人的乐高积木一样，需要更强的专业性才能实现。这时资源服务化平台就很好的解决了这个问题，能够覆盖微服务的全生命周期，通过内部资源的服务化，促成内外部能力的打通，和内部能力的外化。有效的解决了微服务在构建调用和注册过程中的一系列的难题。

科技发展的量变到质变

最后由来自众安科技的吴婧琦分享了众安在Saas层面的应用与实际案例。在众安看来，金融科技的发展经历了渠道驱动型的1.0互联网金融、技术驱动型的2.0智能金融及跨界融合型的3.0融合金融三个阶段。

吴婧婍认为，金融科技的演进有两大驱动力，一是技术驱动，将原先需要人工花费大量时间处理的业务流程，通过系统升级、智能风控、生物识别、OCR识别等技术手段实现秒级处理，提升业务效率；二是业务驱动，通过增加运营分析、监管合规、增信措施等等的方式，提升精细化运营水平。

结合众安科技与城商银行的案例进行解读。随着前沿科技不断渗透到各行各业，城商银行也在寻求业务互联网化转型的契机，但该银行在现有的系统支撑，大数据风险管理以及互联网运营分析方面，都存在较大挑战。众安科技为该银行客户提供了以互联网的信贷交易系统以及资金资产交易系统为基础的解决方案，同时对接增信方，引入全流程实时风险控制、数据化运营管理涵盖整个信贷周期的消费金融解决方案。通过底层区块链的运用，所有资产数据不可篡改、逐笔还原，且基于大数据和人工智能技术对业务数据进行智能监控，实现业务风险实时预警，并提供标准的合规审计与监管报送工具，实现资产面对监管合规的穿透要求。

总体而言，众安科技为该银行提供的解决方案从技术和业务两大层面，驱动业务的成功开展，体现了技术创新和业务赋能的双重价值，最终实现互利共赢，共建生态的合作宗旨。

在最后的圆桌讨论环节有观众问到，众安作为互联网保险公司与传统保险公司的区别是什么？它的逻辑又有何不同？吴婧琦认为，严格意义上讲众安也并没有改变保险的核心逻辑，保险还是靠精算。但是之前的精算是拿精算表，更新速度相对缓慢。可用到大数据和实时计算的时候，精算赔付表是可以做到实时更新的。以众安的延误险为例，以往的延误险需要提前一天买，而众安的延误险可以提前半天甚至一个小时都能买，背后是有一整套的体系来支撑业务。科技赋能之后并不会改变保险的核心逻辑，而是把很多的底层的技术和应用做更好的提升，同时为保险创造更多的场景和可能。

写在最后

在新兴的互联网企业积极发展金融科技的同时，传统金融机构对大数据、云计算、人工智能、区块链等技术的接受程度也越来越高，银行等传统机构甚至更为激进地走在了浪潮的前沿，成立相应的数字化体验部门或互金中心。而随着监管体系的不断完善和技术应用的逐渐普及，金融科技的红利也将逐步显现出来，即使科技无法颠覆金融的逻辑，但以银行、保险、证券、基金、互金为代表的机构也必将迎来新的变革。