下文为申万宏源资深研发经理王晓飞的演讲全文：

我今天要讲的是业务中台建设相关情况，分为三部分，第一个是背景介绍，第二个是建设情况，第三个是未来的总结展望。

﹀

﹀

﹀

01

#背景介绍

金融行业大家应该都比较了解了。前阵子热播剧《繁花》，中间讲到了上海第一个证券柜台，我们公司当时是公益信托旗下静安的代理的一个网点，这就是我们公司的起源，它比交易所成立时间还要稍微早一些。

现在的申万宏源证券是由最早的申银证券、万国证券以及2015年宏源证券三家合并而成。本身证券行业的系统会比较多，有合并重组这些历史渊源，再加上我们是三家集团合并到一块，那肯定更多。最新的数据应该有四五百套系统，主要分成几大类，第一个是核心业务，有账户清算、核心交易这些系统。然后是客户服务，业务办理、营销相关的，还有些是内部用的信息系统。

证券行业的特点，可能同业比较清楚，包括我了解到的一些银行、保险都有类似的情况，有不少的系统都是采用外购的形式做建设，早些年可能绝大部分都是外购的。相对应就会出现一些问题，比如说传统架构已开户业，只要是对客的渠道，形式是各种各样的。我们公司在建设中台之前就是这种情况，不同的部门、服务的不同的渠道，有不同的技术和不同的业务。有一些是传统的，有一些是新兴的。大家从头到尾自己去建流程，非常纷繁复杂。

这个只是一个典型的业务场景，通过这个场景大家能感知到这里面有一些问题。第一是烟囱式的系统会比较多，同样是开户业务，那么多线、那么多交互，又有那么多的逻辑、工作量和维护的成本。其次系统之间各自为政，是网状交互的。以及对应的自主研发这方面，多种多样的主体，多种多样的技术路线和架构，沉淀复用无从谈起。那相对应的，有这么多的主体，如果想做一些技术路线的自主可控，那它的实质成果也不显著。

基于这个现状，我们就要想办法去改变这些现状，主要的目标是三大方面，第一就是生态构建上面，是以中台化的理念，推动服务多总部、多业务领域中心化的系统建设模式。第二要把研发体系建立起来，研发过程当中所涉及到的开发框架、研发平台、制度规范、最佳实践的东西沉淀下来，不断地去持续复用。再一个就是要建好公司的技术底座，供业务层快速上线。

02

#建设情况

第二部分主要是建设计划。首先外购类的可能很难去突破，只能从自研这一部分去下手。那我们转变一下思路，比如传统烟囱式系统建设的模式，无论是客户服务、业务管理，以往烟囱式的就把它完全打散。然后换成这种模式：底下这些东西都是统一建立规划，无论从管理上、开发上、运维上，底层完全是复用的。在此公共的基础设施平台上面，上层去构建各自业务场景，这些业务场景统一规划、集中管理、高效利用，规则是统一的，同时可以积累沉淀，以及可以横向任意拓展。还是以开户场景举例，按照这种新的模式去建设之后，架构中可以加入业务中台，相对来说它的建设脉络清晰了很多，所有东西都集中在一个重要项目上。同样的这种思路和方式可以在其他业务里面去建设。

比如说产品维度，包括产品业务领域的状态，业务部门也和产品维度相关，属于业务领域里面。还包括前端的对客渠道，横向拉通依靠需求部，此外产品相关的系统里面有关于产品维度上不同的东西。产品方面有事都拉会，一拉几十个人，沟通成本很高。按这种方式做了重构，中间有一个中台，中台上面搞一个产品中心，由一个人来统筹产品中心的建设，把底层的稳态的系统里面关于产品的能力，把它抽象出来，封装成标准接口，提供统一的服务。这个人来负责这整套东西，他既跟业务部门打交道，又跟前端渠道打交道。以后再开会的时候，只需要几个人在一个地方开会。我们用类似的方式把公司里面多个业务领域的东西去做重构，常用的业务场景做整个的聚合。

更进一步的，就形成了公司层面一站式综合服务中台。最前面是一些对客户的场景，包括零售客户、企业客户、金融客户，通过各种各样的终端，APP、 H5、ETM会员机、内部的系统等等，他们都属于平台的用户。用户跟一个业务中台网关对接完了之后，底下这么多的横向拓展的业务领域，全部都可以用了。底下是传统的稳态的系统。通过这种方式至少在自研这个领域，这个方向上面，把核心的关键的业务里面东西做一些聚合。

因为这些东西是统一规划、统一建设。建设的时候就是奔着至少平台级，逐步演进成公司级的基础设施。相对应，我们选中了比较新的这些技术路线。上层的应用系统开发的时候，它所依赖的底层本身就是比较强大的、先进的、稳定的。我们刚开始的时候是基于开源的技术路线，中间还使用了不少国外的技术。最近这几年信创建设如火如荼，我们也是在公司里第一批去做系统改造的。通过两三年的建设，逐步把整个技术路线全部优化。当然我们因为前期传统的集群建设成本蛮高的，我们现在是一个异构多活的一种方式，流量可以按需随机动态分配。

除了在业务领域里面不断沉淀以外，我们的基础设施不断地扩容、更新。中间所用到的，比如开发框架，也在不断地更新迭代，不断地丰富。开发过程当中所用的工具平台也不断地建设，总体形成了一整套体系化的自研的方案。包括运行态、人群、平台、中间件以及运维监控相关的体系，以及开发态、各类开发框架，还有在研发过程当中很重要的、测试环节的重要的工具平台，单元测试、自动化相关技术等等，以及把整个流程全部打通串起来高效流转。

经过几年的持续建设，这个体系我们自认为也算是比较成熟。但是公司里面也许有些声音，老是你们一帮人在自嗨，这肯定不行。去年的时候我们还做了一个事，就是说跟行业相关的一些机构合作，做了一个DevOps认证，一次性通过了三个认证，持续交付的三级，持续测试的三级，这个测试是国内的首家，还有一个是安全及风险管理的二级。刚开始我们还不知道，是后面有相关的老师给我们反馈，说我们好像是这个认证有史以来第一个同时通过三个认证的团队。我们这个项目前后还拿了好几个奖，拿到后面领导说，你们拿奖太多不要再申报了。

03

#总结展望

#过去

我们从这几年的持续建设过程当中，自身觉得蛮有成就感，因为我们切实地为公司做到降本增效，从业务上的集中管理、系统建设过程中的节约成本，以及从价值交付上的提升效率，各方面确实对公司有些帮助。

另外一方面，因为中台好几年前特别火，各种公司、互联网公司、传统公司、金融公司都有建设中台的不同的路径。我们17年在酝酿， 18年立项在做，一点一点从小到大，从一个项目级发展成平台级，从平台级再发展公司级。这个过程也算是稳扎稳打，没出过大的乱子。相比较而言，我觉得这个实施路径现在回头看是比较稳妥的，因为金融行业很难去搞运动式的建设。

#未来

接下来就讲到了未来，就是我们现在以及之后要做的。前面讲到的都是比较好的，现在呢就是要“从无到有，从有到好，边建设边治理”。

确实客观上我们会存在一些问题，前面也讲到了系统特别多，主要是自研和外购两大类。整个中台也仅仅是自研当中比较大的一个板块，站在整个公司的角度上来说，我们仅仅是其中的一个板块而已。整个公司级有这么多的系统、这么多的接口，要去做更高维度治理的时候就会遇到一些问题。简单来说就是几个方面，大概定义了几个词。

第一个是“找到”，因为公司里面有这么多的系统，每个系统都有各自的产品经理负责人，所有的文档都各自维护，没有一个集中的管理平台。你要跟哪个系统对接，你先知道这是什么系统，谁在负责，你去联系他，发微信，他给你发个文档，然后你再去问他地址，都是通过这种方式口口相传。沟通交流的成本特别高，它经常会出现一些，你去对接，到后面发现接口文档是旧的，掉坑里了，就是这种情况。所以我们要建一个公司级的管理平台，大家要把所有的接口一站式录到一个地方，后续不需要人找，大家都在一个平台上面去登记、去查询。同时还有一个很关键的点，金融行业的接口相对来说是比较敏感的。实际上大家也都清楚，现在不少公司里面去写具体写代码的，可能都是找外包的，他们在定一些接口的时候不会想那么多，就是有个需求过来，我能把这活给干了就行了。至于数据敏感性、权限、交互是否合理，他们不考虑这么多。但是一旦要发布到了生产上面去，这个影响是很大的。因此在中间的过程化管理上面，一定要有平台承载它，不然就失控了。所以要建一个接口管理平台，实现一站式的查询或保密。

还有一个是建设公司级的网关。大家也看到了，网状交互是一个很恐怖的事情，你的系统规模体量越大，网状的交互带来的负面的影响就越大。虽然我们建设中台在一定程度上解决了很多的系统网状交互的问题，但站在整个公司的角度上来讲，仍然还存在网状交互的情况。所以我们准备建个公司级的统一网关，我们内部叫企业级组件。当然这个东西也还在建设过程当中。建设完成之后，后续各自系统就不允许直接对外服务了，所有的对外服务一定要挂在这个网关上面，哪怕说只是做一层中转也可以。也就是说所有网状交互、系统之间的直连就要断掉，各个系统跟网关进行一次对接，然后才能跟公司内的系统做交互。

同时要建公司级的监控数据大屏。我们领导经常会提起来，比如说公司里有这么多系统，业务都在正常运作，但是到底有多少系统？日访量大概是多少？每天的业务高峰是啥时候？以及哪些系统提供的接口服务又快又好，哪些系统的接口经常报错？类似这种情况是没有一个统一的平台的，如果有客户办不了的，还要一层层反馈。前阵子还听到有些大客户业务办不下去了，然后找到领导，领导再来处理。如果有一个公司级的统一的平台，流程都报错直接反馈到相应的人，这个事就会有公司的统一的标准解决方案。现在的话是各个项目团队自己建，自己做的统计。

第四点是把所有前面的这些工具、平台、实践，打包形成一套治理体系。比如定义几套公司级的标准，比如稳态类的系统，你上线要经过几套审批流程？经过谁的审批？

我们对于公司级的服务治理所规划的整体的架构图，主要分成几个维度，首先组织协同上面，我们也在公司内部的技术条线上例会上做了多次汇报，就对于这个事基本上各个部门都表态了，都很认可。所以从组织协同上面这个项目就行了，就可以实施了。从项目的具体建设的维度上来讲，我们定义那些业务相关的流程，具体定义成标准的制定阶段，制定完之后就会发布出来。以后各个项目组再去定义接口的时候，就要按照这个接口的标准做设计，不能再有拍脑袋的情况。在开发阶段有统一的查询、管理、审核、快速测试、版本管理、内容通知等等，这些都是在开发过程当中系统对接联调之间常见的痛点需求。在测试阶段，前面也提到我们有接口的自动化测试平台，管理平台的接口数据作为输入，能实现自定义的流转。再一个就是运行态和生产运行维护，通过这种方式切实地把整个接口从最早期的定义、到后面的上线、全生命周期全部连起来。当然还依赖一些协同和工具平台的支持。

最后讲到景，当然这个愿景可能80%以上我们已经做到，就是说要建公司级的大平台，底层的基础设施来不断地建设和完善，后台的稳态的系统仍然按照自己的节奏去更新迭代，中间这一层业务中台跟技术中台不断地更新迭代。现在业务中台上面已经有100多个微服务，有大概六七千个接口，大概有二三十个团队每天常态化地在上面更新迭代。技术中台把下面的研发体系、公共服务、中间件运维相关也都打通了，还在不断地更新巩固过程中。数据方面有专业的大数据团队，提供算力的支持。包括今天所讲到的AI大模型相关的，就是数据团队在做这方面的事情。前台各种各样的终端渠道会不断演进出来。

我的分享就到这里，感谢大家！