分布式架构技术在金融业的应用探索

Posted 2021-04-14 浙江省金融科技研究工作组

    

本文摘要

随着移动互联网、云计算、大数据、社交网络等新兴金融科技的兴起，带动了互联网金融的蓬勃发展，同时也给金融体系的传统运营模式带来很大冲击，整个金融行业不得不面对海量数据和海量交易所带来的技术挑战。而分布式架构技术在这种挑战下应运而生，2004和2006年google分别发表了MapReduce以及Bigtable论文，标志着基于分布式数据库技术开展数据分析处理的研究获得了突破。在此基础上，在互联网应用需求的推动下，以分布式计算框架和分布式数据存储技术为基础，支持大规模、海量并发处理的分布式架构技术逐步发展成熟，并逐步在实践中得到验证，支付宝“双十一”秒杀促销和腾讯微信春节“摇一摇、抢红包”活动创造了单位时间并发交易量远超于各大商业银行的奇迹。这一方面证明了分布式架构通过横向扩展所能实现的强大处理能力;另一方面也体现出目前分布式架构在技术上已经给常成熟和可靠，在一定程度上已具备满足传统企业级应用可用性、稳定性要求的能力。

分布式架构技术的应用也为摆脱商用闭源软硬件厂商的依赖带来了机会。近些年，业界领先的互联网企业投入大量研发力量发展出一套基于低成本PC服务器(x86平台)的分布式自主开源技术体系，基本摆脱了对“IOE”的依赖，并不断推进其自有IT平台向云计算、大数据平台发展，该技术体系的系统架构遵循互联网相关的各类开放技术标准，且有灵活的横向扩展能力，能很好地应对互联网场景下特有的交易量突发和快速响应要求，技术上通过引入开源软件与自主研发相结合的方式实现了自主可控。这也给金融行业长期依赖“IOE”的技术架构体系开辟了一条“希望之路”。

本文通过对银行、保险、证券为代表的金融行业分布式架构技术的应用情况的调研，向读者介绍分布式架构技术的特点和实践经验，同时结合当今国内金融行业现状，分析了分布式架构技术应用所面对的挑战和应对策略。

第一部分 分布式架构技术介绍

一、什么是分布式架构技术

分布式架构技术并没有明确的定义，从广义上理解，分布式架构技术其实就是实现分布式架构所需要的各类技术体系，从目前业界的应用情况来看，分布式架构技术主要包括：分布式存储技术、分布式计算技术、分布式事务处理技术，以及其所依赖的诸如分布式服务框架、消息中间件、数据访问中间件、配置中心、负载均衡系统、运维自动化系统、硬件虚拟化及镜像管理系统、分布式文件系统、日志收集系统、监控系统、数据仓库等等基础设施支撑的相关技术，以上这些整体上构成了分布式架构技术体系。

二、分布式架构技术的演进和发展阶段

根据我们的研究，以银行业技术架构演进为例，分布式架构技术的演进大致可以分为两个阶段，如下图所示：

（一）以IOE为基础的数据大集中阶段

集中式架构系统的底层一般采用成熟的商业基础软件构建，这种架构的优点是成熟稳定、可用性强、可靠性好，技术人员可专注于业务功能开发，无需过多关注底层技术的实现。金融行业经过十多年的集中式架构技术探索和实践形成了丰富的技术积累，使得底层技术架构基本保持不变，运维手段更为集中统一，有力地保障了业务快速发展和生产的平稳运行。集中式架构下银行业IT也经历了两个阶段：

第一阶段是以核心业务系统为中心的”大前置”阶段，外围系统一般通过直连或大前置的方式接入核心。这种以核心系统为中心节点，外围系统围绕着核心建设的系统架构模式实现了数据的集中管理，也能满足当时的主要业务需求，同时在业务管理和IT管理方面也相对简单。但随着竞争程度的不断加剧，业务变革不断加速，业务需求呈现出爆炸性的增长，业务流程化、服务多样性、管控精细化等对IT都提出了更高的需求。在这种情况下，问题集中表现在：大部分的业务耦合在核心一个点上，核心系统牵一发而动全身，任何修改都可能造成整个系统不可预知的结果。另一方面越来越多的系统被独立的建设，越来越多的系统需要相互沟通，以完成复杂的业务功能。尽管在一定程度上建立了用于整合的系统，如大前置系统，但往往由于缺乏统一的整合规范，导致业务的灵活创新并不是一件容易的事。正是这些问题和需求为整个银行业带来了一次IT架构的变革。

第二阶段是面向服务的SOA架构阶段。SOA不是一种技术，更像一种哲学，是人类在探索现实世界的过程中，随着认识的深入，对现实世界不断的进行抽象和建模的一种思想方法。通过SOA，把现实世界的各种实体（组织、客户、存款、贷款等）抽象成一个个独立自洽的“服务”，并对这些实体与外部其他实体之间的关系进行界定和清晰的表述。在这个模型里面，每一个服务独立的存在着，对外提供公开的服务界面，服务与服务之间通过这些公开的服务界面进行沟通，沟通的结果将反馈到服务本身。SOA理念正适合用来解决上述银行业务和技术发展过程中所遇到的关键问题，通过SOA思想构建一个由不同厂商、不同技术的软件所组合起来的银行IT架构。在这个架构体系下，所有的软件能协同工作，发挥出各自的优势，对业务的支撑形成合力。但是随着SOA架构的深入，传统的集中式大应用开始向微服务小应用拆分，服务粒度变的越来越细，应用的规模变得越来越小，大量的小应用需要从资源调度、部署运维上提供更灵活、更强大的支持，这些都对传统IOE架构下资源调度能力形成挑战。

（二）以X86为基础的云计算和分布式阶段

分布式云计算架构按照一定的维度将系统和数据进行拆分，通过特定的负载均衡机制，将业务分摊到多个节点上处理。这种架构的优点是可以采用更开放的软硬件架构，各节点松耦合，对底层产品的可靠性、可用性依赖降低，可以基于廉价的硬件和开源软件构建。分布式和云计算相辅相成，云计算是实现分布式的有效手段和关键基础设施，分布式又是云计算下的必然选择和技术前提。分布式架构本身不只是简单的服务调用的分布式，更重要的是数据的分布式，因为一切服务的基础是数据，数据分布式的粒度直接决定整个分布式架构的能力。分布式云架构下的演进大致又分为几个阶段：数据垂直拆分，数据水平拆分，数据单元化，数据弹性架构和在线/离线资源混合部署等。

   1.数据垂直拆分

业务系统由很多业务模块构成，垂直切分是指按照业务模块将数据表进行分类，分布到不同的数据库上面，这样也就将数据和服务的压力分担到不同的数据库和应用服务器来完成一定程度的分布式部署，进而降低系统耦合性和复杂度，提升系统整体性能。

   2.数据水平拆分

云计算平台的计算服务器和数据服务器都普遍采用x86架构的服务器，单机处理能力有限，当单表数据过大（例如账户数据上亿），x86架构下单机性能不足以支撑高并发（例如上万TPS）请求时，数据水平拆分势在必行，需要将原来一张大表（上亿记录）的数据在水平维度拆分为多张小表，分开存储在不同的数据库中进行并发处理。水平拆分虽然能带来处理性能的水平扩展，但同时也带来了数据一致性问题，因此，分布式事务处理能力是数据水平拆分的前提，目前只有极少数互联网公司掌握了成熟的金融级高性能分布式事务框架。

   3.单元化

单元化是将一个系统的架构按某种数据特征维度进行单元的划分，比如银行有1亿用户，假如按照用户维度进行划分，则可以分成20个单元、每个单元存储500万用户信息。每个单元是一个从流量、到应用、到数据形成的完整、自治、独立的生态系统，能为客户提供绝大部分服务，数据访问都尽量封闭在这个单元内。因此可以将一个单元部署到任何地域，单元和单元之间能够互为备份，这为异地多活部署提供了可能。有少量服务确实存在跨单元情况，这就需要具备单元间的分发和调度能力，以及分布式事务框架支持跨单元的事务一致性保障能力。

   4.弹性架构

云计算讲的弹性架构，不仅包括IaaS层，也包括如何让数据服务也具有弹性。结合前面单元化能力，数据上也实现了单元化，这样辅以数据迁移工具，就能够实现数据服务的弹性，进而形成整体架构的弹性能力。

   5.混合部署: 

在线交易系统的特点是日间交易负载压力比较大，凌晨后业务往往处于低峰期，而离线大数据处理系统日间负载低，日终负载高。如能结合上述业务特点，根据不同时段进行计算资源混布，就能错峰利用服务器处理能力。进而延伸思路，线下服务器（开发测试环境）也存在明显的负载低峰期，仅从技术层面考虑，通过混部的方式可以在日终利用线下服务器的计算资源进行离线大数据处理，日终完成后归还，继续服务日间的研发测试工作。混合部署就是让这几套体系中的资源混合部署、综合调度，充分利用硬件计算资源达到节约硬件成本的目的。

第二部分 金融业分布式架构技术应用案例研究

一、分布式架构技术在银行业应用研究

分布式架构技术在银行的应用目前尚在起步阶段，部分新兴互联网银行凭借自身的技术优势在这方面的应用走在行业前列，下面以网商银行为例介绍分布式架构技术的在银行业应用的典型范例。

（一）网商银行分布式架构技术应用情况

网商银行信息系统建设依托于蚂蚁金服成熟的、完全“自主可控”的技术体系，结合自身轻资产、交易型、平台化的运营思路，完成了基于分布式云计算的架构建设。在整个建设过程中作中，进行了一系列技术架构创新来提高系统吞吐能力和资源供给效率，提升了系统可靠性，实现了7*24*365的服务能力和99.99%的可用率。目前杭州双机房已实现全业务同城双活，整体容量达到4000TPS。以下是网商银行整体架构示意图：

网商银行云架构体系主要分为四层：IAAS（Infrastructure as a Service）层提供低成本的服务器、网络设备、存储等物理设施，通过虚拟化和云计算技术使得基础资源具备成本低廉、安全、可伸缩的特性。PAAS（Platform as a Service）层提供面向金融场景的分布式技术框架、组件和运行环境，并提供运维平台进行服务和资源的管控。DAAS（Data as a Service）层围绕大数据处理和计算，面向业务提供风控和数据分析能力。SAAS（Software as a Service）层提供面向用户端的金融服务和产品，提供最为直接的服务和体验。

网商银行之所以能够顺利完成分布式的云计算架构建设，主要依托了蚂蚁金服的两项核心技术——分布式事务框架XTS和OceanBase分布式数据库，其应用情况介绍如下：

（1）分布式事务框架XTS

众所周知，金融交易对于一致性要求非常高，传统银行集中式核心采用单一事务，要么全成功，要么全失败，非常好的满足了强一致性要求。网商银行在设计初期决定采用微服务架构，实施业务垂直拆分和数据水平拆分，这就意味着存在大量的微服务和大量的单元数据库，一个完整金融业务需要调用多个服务和数据库完成，因此，保证服务与数据处理达到金融级的强一致性将是面临的首要难题。为了解决这个难题，网商银行使用了蚂蚁金融云的XTS分布式事务框架。XTS框架引入事务观察者协调分布式事务的各参与方，达到整体的事务一致性。实现了两阶段提交协议，第一阶段采用本地端事务，操作仅预留必要的资源，处理成本足够低，第二阶段可以异步执行，使得业务整体具备了较高的性能和较强的吞吐能力。

（2） OceanBase分布式数据库

网商银行从2014年筹建开始便摒弃了IOE架构，采用了全套自主研发的分布式云架构系统。尽管通过分布式事务框架，解决了数据库水平扩展的问题，但是单个数据库的高可用、高可靠和容灾能力依然未得到解决，选择一款优秀的金融级数据库是面临的另一个难题。2014年的双十一大促中，支付宝100%的交易都运行OceanBase数据库上，为当时选型提供了新的思路。经过调研，OceanBase在以下几个方面，对传统数据库架构进行了突破：

高性能：数据库的一个显著特征是总数量比较大，但每天变化（增删改）的数据只是总数据量的很小一部分。因此OceanBase将数据划分为基线数据和修改增量。基线数据即数据库在某个时间点的一个快照，存放在每台OceanBase服务器的硬盘中，修改增量即快照点之后的增删改数据，相对比较小，通常存放在每台OceanBase服务器的内存中。通过这种方式，使得增删改操作基本都在内存中进行，从而获得接近内存数据库的事务处理性能。

强一致：经典的主库+备库方式的数据库，很难兼具高可用与强一致能力。为了解决这个问题，OceanBase使用多数据副本（不少于3个）投票协议。对于每个写事务，OceanBase只有在事务日志（redo log）到达超过半数服务器后，才应答客户。这样当少数服务器（例如 3 台中的 1 台，或者 5 台中的2台）异常时，剩下的服务器至少有一台有事务日志， 保证了数据库不因为少数服务器故障而导致数据丢失。

高可用：关键业务的数据库必须达到 99.999% 的可用性，服务器故障、机房或网络故障都不能影响数据库的可用性。OceanBase 通常由分布于多个机房的集群组成，每个集群有完整的数据，其中一个集群作为主库对外提供读写服务，其余集群作为备库，接收主库的事务日志和回放日志。当主库故障时，剩下的集群会立刻自动发起投票选举，选出新的主库，新主库从其他集群获得可能存在的最新事务日志并回放，完成后对外提供服务。这个故障切换过程在秒级就可以完成，意味着传统机房容灾最难解决的数据容灾在秒级就可以切换完成，极大的降低了机房容灾的复杂度。

目前网商银行核心业务100%运行在OceanBase数据库上，在日常运行、应急演练和容灾切换等中都有优异的表现，产品的特性得到了充分发挥和证明。

（二）网商银行分布式架构的支撑体系

网商银行分布式架构技术成功应用不仅仅依托于核心技术的使用，还依赖与各方面的支撑体系来实现，简单介绍如下：

（1）微服务架构与治理

网商银行在微服务的设计上，引入了以业务域为单位的架构划分思路，划分了客户平台域、产品平台域、融资产品域、存款理财域、支付结算域等，每个业务域内按功能职责继续细分，形成各个微服务的应用。比如在支付结算域内划分出支付、转账、商户结算、支付受理、挂账中心等应用，在每个应用里设立更为内聚的微服务，比如在支付模块内会建立快捷支付、贷款支付、B类支付等服务，以服务接口方式对外提供。按照这种架构域—功能域—微服务的逐层细分的设计思想，完成了全行应用层的微服务化，形成了180多个应用、近1500个服务接口，部署在近2000个虚拟服务器上。

（2）全链路分析

分布式微服务架构下，如何快速、精准地确认一笔失败的交易流经了哪些系统、哪些服务器、在哪个环节出现了问题，这是一个巨大的挑战。为了解决此问题，网商银行所有应用会在请求最开始的服务器上生成一个全局唯一标识，请求经过的每个应用、中间件和服务器时都会将这个标识输出到日志。网商银行内部链路分析平台可以根据这些日志文件，通过分析该标识获取到一条完整的链路信息，能完整的反映一笔交易流经哪些系统、中间件、存储，并通过图形化的方式直观展现出来。

（3）线上性能压测

早期的压测基本上都是在线下测试环境进行，其优点主要体现在实现相对简单、风险低，能够发现一定的性能问题。其不足体现在线下部署结构、网络、硬件设备与线上生产环境存在巨大差异，无法模拟线上真实的调用场景。后面发展到线上压测，往往通过负载均衡软件工具（例如：nginx proxy、tcpcopy）引流完成，通过线上进行单机压测，精确获取单机性能极限。该线上压测方案不仅需要有专门的压测设备投入，还无法实现脉冲压力下的瞬间压测、对数据库容量压测等。网商银行利用蚂蚁金融云的多租户机制，做到从应用到数据的全隔离。再结合蚂蚁金服分布式框架中一系列中间件对压测流量的识别，引入了测试租户和影子表（基于真实业务表建立的一张别名表），应用只需简单遵循一定的规范开发，就能获得在应用和数据层面的有效安全隔离，做到了和真实业务等同的全链路压测。

二、分布式架构技术在保险业应用研究

与银行业相比，保险业在分布式架构技术的应用还处于起步阶段，下面以浙商保险为例介绍保险业的应用案例：

（一）浙商保险在分布式服务技术上的探索

浙商保险在长亮科技分布式服务技术的基础上做了专门的分布式服务课题研究，形成了体系化的分布式服务架构设计方案。分布式服务主要由服务网关、服务调用框架、分布式数据路由服务三部分组成，如下图所示：

服务网关（edsp-gateway）是外部系统调用服务统一入口，提供授权、认证、限流、路由（负载均衡）的功能。

服务调用框架（edsp-rpc）是内部服务调用框架，集成高性能rpc、容错、熔断等机制，避免服务故障引起雪崩，同时还集成服务治理接口、链路追踪接口。

分布式数据路由服务（edsp-drs）是分布式资源调度程序，根据对数据库资源池资源负载的动态监控，合理触发合理分配规则，最终实现资源池中的数据库节点资源重新合理分布的目的。

基于分布式服务的三层框架，形成了完整的分布式服务框架，如下图所示：

针对分布式服务所依赖的各项基础设施及服务，浙商保险目前尚未完全成熟；另一方面，伴随着浙商保险日益增长的业务量，大数据、高并发的业务场景，浙商保险对分布式服务的应用是个必然趋势。但现阶段，高性能内存计算更胜任目前的现实状况。现对浙商保险在SAP HANA方面实践探索情况简介如下：

浙商保险在2016年引入SAP HANA高性能内存计算框架。Sap采用系统复制的方式来实现，HANA对于原生的SAP HANA 系统Primary System ,利用软件跟硬件冗余, 建立一个Secondary System。Primary System 与Secondary System 之间就不共享存储了, 而是独立存储, 但是二者的数据保持同步, 这样其中一个系统崩溃, 另一个系统会自动接管。如下图所示：

SAP HANA支持横向扩展，这种场景支持多个主机同时工作，组成一个集群，主机可以很多，如果主从节点中的一个节点出现故障，导致其所有HANA 服务终止，备用的（standby）节点在侦测到故障后会自动转换为故障节点的角色，并接替它的工作。浙商保险应用SAP HANA高性能内存计算框架，计划将OLTP的系统所用的scale-out架构由2+1扩容到3+1的scale-out架构，继续在scale-out的基础上做多租户应用，保证各个应用系统之间相互没有影响。scale-out部署如下图所示：

 

浙商保险基于SAP HANA高性能内存计算框架，搭建了自有的高性能数据平台，数据平台分为三层，分别为基础数据层、ODS平台、SAP实时数据分析平台，如下图所示：

 

通过实时数据同步工具DSG将公司基础数据统一归集到ODS数据平台，ODS数据平台为今后数据分析、数据挖据做准备。然后数据再从ODS平台通过Sap Dataservice 、SLT等ETL工具根据业务需要全量、增量，实时同步到Sap Hana实时数据分析平台（Sap Hana高性能数据计算）。随着Sap Hana高性能计算在浙商保险应用更加广泛，硬件资源表现出紧张，于是浙商保险做出了3～5年的扩容规划。计划将OLAP的系统做scale up的扩容，做HA双机热备。如图9所示：

 

基于SAP HANA数据平台，浙商保险优化了保监会上报数据提取体系，建立了基于Hana+BO的多维报表系统，计划实现3个分析主题（车险、非车险、财务）共计51类235张多维报表的开发。同时，基于大数据分析，未来浙商保险将建立基于大数据分析的高性能应用架构，基于目前现有的Sap Hana高性能数据计算平台，在数据平台周边引进Hadoop、引进R语言、利用爬虫技术，对公司内部数据做归集，通过大数据的统计学技术、SPSS、SAS、机器学习等高新技术逐步完善浙商保险在大数据方面的系统建设。

（二）基于分布式服务的下一代核心业务系统的规划

随着业务的发展，保险行业需要处理大规模、多渠道、高并发的业务场景，与此同时，还需快速适应金融数据一致性和完整性的监管要求，保持业务系统的高可用、低延时、高性能和低成本。面对以上挑战，浙商保险未来将从业务模块分布式和数据分布式两个方面入手，规划下一代核心业务系统的分布式服务框架。

业务模块分布式是将核心业务系统按照业务场景拆分成多个子系统，每个子系统只负责特定的业务场景，配合Docker等高可用容器，形成各项可独立部署的微服务，以微服务为计算单元，以持续集成和持续交付为目标。系统被拆分后，依赖分布式中间件来实现子系统间的交互和数据的同步，从而完成完整的业务场景。不过，由于采用了分布式架构，一个完整的业务流程会经过多个子系统处理，系统处理时间因此增加。而为保证业务处理性能和用户体验，需要将核心业务处理过程拆分成同步响应与异步处理，但这又对数据的完整性和一致性提出了很大的挑战。需要设计一套数据补偿机制，在各个子系统通过幂等重做、容错隔离、数据实时自检，离线报警等机制，以确保分布式系统的数据最终完整性和最终一致性。如下图所示：

随着业务的快速增长，存量数据越来越大，而传统数据库存在单机（单库）性能瓶颈的先天性缺陷，并且扩展困难。数据的分布式存储就成了必然的选择。对此，通过分布式数据库中间件，将海量的数据分布存储到不同的数据库节点的不同表中，从而提高了数据库并发的读写性能。对数据进行分布式，形成对每个微服务高可用的数据支持。如下图所示：

分布式服务可以解决集中式架构低效高价、代码复用性差，缺乏灵活性和继承性等问题，尤其可以解决高并发的问题。基于容器技术的微服务，单个服务功能单一、灵活，又不失高稳定性，且具有极高的性价比。同时，分布式的存储、中间件、数据平台等将分散的计算资源、存储资源高效利用，让金融行业不再需要曾经必需的大型机，小型机和高性能数据库。

不过，分布式架构也引入了全新的安全风险。比如内部安全威胁包括网络传输不可控，增加了数据泄露的风险；过多的接口暴露增加了系统安全的脆弱性；过于分散的功能，增加了对访问者授权和访问控制的难度。系统外部的威胁则包括黑客的攻击行为、用户的欺诈行为等。

总体来说，分布式架构还在不断发展之中，保险行业在微服务、高可用容器等方面将持续开展研究和实践，随着互联网业务的深入发展和各类基础架构的完善，未来，互联网保险领域将实现大规模的分布式计算、海量数据离线和实时运算、机器学习和人工智能技术融合发展，提供更便捷、更高效、更安全地新型金融保险服务。

三、分布式架构技术在证券业应用研究——财通证券

证券行业的“大数据”是在日常经营中生成并积累的交易生产数据、经营管理、用户行为和网络日志等各类结构化和非结构化数据的汇总，存在来源广、规模大、价值大和高速增长等几个显著特征，这些数据被誉为新的“金矿”，是证券公司重要的资产。

财通证券现有信息系统之间存在多个信息孤岛、系统间的依赖复杂、维护难度高、重复的数据采集对核心交易系统的压力增大以及数据冗余且口径不一致等系列问题。如何对这些极其庞大的数据进行有效的数据治理，如何为监管层、决策管理层和业务单元提供全方位的数据服务以及如何快速响应各类数据需求，对于传统的数据库技术、数据仓库技术以及软件体系架构来说，都带来了极大的挑战，存在技术瓶颈。随着大数据时代的到来，财通证券开展一系列基于Hadoop架构的分布式大数据平台技术应用探索和实践。

（一）财通证券分布式应用架构实践

1.分布式计算架构

Hadoop是整个财通证券大数据平台的基石，大数据平台通过分布式文件系统HDFS实现流式读取文件系统数据，解决数据访问的高吞吐量的问题。大数据平台使用MapReduce通过数据划分和计算任务调度，实现了并行计算的功能，同时能满足出错检测和恢复等要求。

在财通大数据平台中，使用了Spark作为数据的基础计算引擎。通过Spark提供的框架，管理各种有着不同性质（文本数据、图表数据等）的数据集和数据源（批量数据或实时的流数据）的大数据处理的需求，提升Hadoop集群中的应用在内存中的运行速度。

2.分布式集群架构集群规划

财通大数据平台基于分布式大数据平台CDH，一期搭建了一个40节点，总容量为200TB的大数据分布式集群。节点支持无限扩展，预计3年内可达100台左右，适用于公司5年规划的大数据平台。

财通大数据平台使用Cloudera Manager（简称 CM）来配置、监控和管理CDH集群。节点的复用程度可以降低，整个集群按照管理节点、主节点、工具节点和工作节点来划分。

 

管理节点上安装Cloudera Manager、Cloudera Management Service；

主节点上安装CDH服务的管理节点以及HA的组件；

工具节点部署的角色为： HiveServer2、Hue、Oozie Server、Flume Agent、Gateway等等；

工作节点部署的角色为：HDFS DataNode、YARN NodeManager、HBase RegionServer等。

3.网络拓扑

在集群的部署中，给机架分配角色时，为了避免接入层交换机的故障而导致集群不可用，大数据平台将一些高可用的角色部署到不同的接入层交换机之下。以下是财通证券大数据平台的网络部署拓扑图：

（二）基于分布式大数据平台的应用情况

   1.大数据中心

通过分布式大数据平台，汇集来自各个业务系统的海量业务数据，包括：咨询数据（聚源资讯、万得资讯等）、交易所数据（上交所、深交所、股转系统）、证券业协会数据等，形成数据集中存储。

   2.经营分析平台

以经纪业务分析为核心，辅以零售业务分析及证券事务分析的经营分析平台（一期），主要实现了经济业务的历史数据集中、分析、统计与呈现，现金理财的零售业务分析与呈现，证券事务的分析统计。服务对象包括公司领导层、机构管理部、零售业务部、证券事务部及各分支机构。

对于领导层面，直观展示了公司上一交易日及历史的业务经营数据，整个证券行业的市场行情，为领导了解公司经营情况及市场行情提供服务。

对于机构管理部，平台提供了涵盖上百个指标的业务报表数据，实现了业务数据的及时计算与呈现，为机构管理部提供准确、及时的数据，帮助其形成不同时期的业务报表。同时，对于各分支机构的经营情况，平台也能很好的反馈出来，为机构管理部优化业务管理提供了很好的服务。

对于零售业务部，平台能够及时提供现金理财的交易数据、客户数据及份额数据，为零售业务部全面掌握现金理财产品情况提供决策和分析的需求，以帮助其进一步优化产品，实现科技辅助金融业务的目的。

对于证券事务部，平台汇集了来自多个业务系统的数据统计与分析，解决了证券事务部对于关联交易分析困难的问题。

对于各分支机构，平台提供上一交易日的交易、资产和客户等情况，为分支机构进一步拓展业务提供支持。

   3.两融大数据分析平台

通过对融资融券客户分析及业务统计，主要实现如下功能：

（1）两融业务数据统计与分析；

（2）利用数据挖掘技术深度了解两融客户特征和发现潜在客户；

（3）通过数据建模，进行类似客户推荐；

（4）事件预警，及时避免黑天鹅事件以及把受影响客户降至最低；

（5）通过对用户行为数据的有效处理，分析出客户各种行为事件为决策提供数据服务支撑。

   4.人力资源大数据分析系统

人力资源大数据分析系统，通过分析公司的人力资源情况，达到如下目的：

（1）可视化全景展现公司的人力资源分布地图，一目了然地查看公司组织架构、人员编制以及招聘情况。

（2）通过人力资源效能评估及趋势分析，全面掌握公司人力资源的素质结构情况，科学地进行人员配置和人员培养。

（3）对标协会数据,及时发现人力资源方面的不足和差距，及时改进，提升公司竞争力。

财通大数据平台和应用已经初步形成，基于分布式大数据平台，利用其强大的分布式数据存储和计算能力，可以更好的对已有的重要数据资源，分析和挖掘其中宝贵的信息，更好的服务于决策管理、业务提升和客户服务。

  （三）基于分布式大数据的发展规划

在一阶段完成搭建大数据平台，落地大数据应用的基础上，财通证券将继续稳步发展大数据应用。计划在第二阶段将数据应用支持范围和深度进行扩大完善，丰富数据应用服务场景；在第三阶段深入数据挖掘和人工智能等专业的数据分析应用，建立以数据为核心的生态体系。

从具体的实践角度出发，财通证券将从以下方向继续加强大数据平台的建设和应用落地：

一是继续建设数据仓库，在一期完整抽取集中交易系统数据的基础上，将对O32自营系统、融资融券系统、资产管理系统、统一账户系统、集中财务系统、法人清算、用户行为数据、呼叫中心以及子公司等系统数据进行统一整合。实现多格式海量数据的集中分布式存储，整合各应用系统主数据，打破数据孤岛。充分利用大数据平台的分布式并行计算能力，提升数据计算的处理性能，提高数据需求的响应能力。

二是构建公司级的数据总线，实现数据共享服务的统一管控，降低系统耦合。建立数据共享规范，通过严谨的数据权限和安全审计手段，确保数据安全可控。通过数据订阅和API标准协议，实现数据共享的一站式服务。

三是实现自助BI（商业智能）在公司的落地。随着自助BI工具的快速发展，业务人员自助进行数据可视化分析已变得可能。计划进行自助BI试点，激发业务人员对数据的创新应用，充分挖掘数据价值。

此外，今后还计划在用户画像下精准营销、基于实时流计算的日志行为分析等应用场景下进行实践，不断的打造和完善各类大数据应用，加快金融科技的落地，提升金融科技服务功能。

证券行业目前信息系统数量多且分散，早期依赖外部采购商品化软件以满足自身业务发展需要，缺乏统一的规划。这些系统来自不同的厂商，技术架构也各不相同，系统之间相互独立，较难集成，数据共享困难，很难实现整体的协同价值。部分证券公司目前也尝试采用SOA的服务总线或基于微服务的架构，实现自主研发系统的架构标准化及对外购系统的集成互联。另外，面对业务的变更与创新，证券行业集中式的IT信息系统和半人工的管理模式较难满足业务需求灵活应对、快速响应的要求。有些证券公司正尝试将部分业务系统部署到云服务平台，以满足资源按需弹性分配、自动快速交付等要求；同时也计划考虑部分系统使用云服务器来为系统备份，满足灾备快速切换的需求。

第三部分 金融业分布式架构技术应用现状和趋势

从目前情况看，银行业IT系统建设面临诸多考验：

第一，需要应对互联网+金融快速发展的挑战，银行需要提供更加多样化的产品服务于更广泛的人群，这给信息系统的健壮性和灵活可扩展能力提出挑战；

第二，银行对IT方面成本投入渐渐纳入综合成本的考量；

第三，国家和监管部门对信息安全、技术自主可控的要求逐步提升，银行业必须尽快打破技术受制于人的局面。

面对上述挑战，部分金融机构开始尝试向分布式架构技术转型，整体上呈现了一下几个趋势：

一、架构有集中式向分布式迁移，并长期共存

集中式架构逐步向分布式架构在很长一段时间内仍会两者共存，部分大型金融机构已开始尝试部分业务的实现向分布式架构迁移，比如直销银行、手机银行、数据挖掘与分析等相关的业务处理以开始采用分布式架构模式实现，但核心交易和账户处理仍保持以集中式机构实现，即使采用分布式集群提供基础计算能力，但在数据和文件的分布式存储调度上仍有技术障碍。

受CAP原理的约束，分布式架构很难同时满足高可用、高可靠、实时强数据一致性，而数据的强一致性恰恰是银行核心交易和账户数据所必须满足的一个要求。未来随着技术的进步，各种软硬件部件的可靠性持续提高，尤其云计算技术，为计算和存储提供了更高的性能和更可靠的服务，很多金融竞购也在考虑或者已经开始讲核心系统向云平台迁移，再通过分布式架构来提升整个系统的研发效率和业务处理能力。

二、分布式云计算技术的应用将逐步降低银行业的TCO

对着商业银行逐步分布式云计算技术转型，廉价的X86服务器逐步取代昂贵的IOE体系的基础设施,商业银行完全有可能利用低成本的设备构建高稳定性、高可用性的银行系统。另外，分布式云计算技术的应用也会降低研发成本投入，提升研发效率，目前DevOPS的研发运维一体化受到普遍关注，互联网银行几个人管理几千台机器构成的大型机房基础设施，正是DevOPS优势的一种体现。

三、由“IOE”技术体系逐步向开源分布式技术体系迁移

经过过去十几年的实践和改进，开源技术获得了较快的发展，实践证明开源软件的可靠性和稳定性并不比商用软件的低。以mysql为代表的开源关系型数据库管理系统、以Hadoop为代表的适应结构化和非结构化数据处理平台，在国内外银行业以及大型的商业互联网机构已经积累了不少的成功案例。未来，传统IOE将逐步被替代，并退出历史舞台，而且目前IOE的厂商已经开始着手转型，甚至想开源技术倾斜，这也加快了商业银行向分布式技术转型的进程。

第四部分 金融业实施分布式架构技术转型几点建议

通过们的调研和对行业基本情况的掌握，尽管分布式系统架构、云计算已经成为IT业界的大趋势，但是金融业要实现向分布式架构转型，依然面临巨大挑战和困难：

一、整体思想观念重塑

长期以来，金融业信息科技团队将确保客户和资金安全作为恪守铁律，使用最成熟、稳定的技术，保证系统交易的实时一致性，是信息技术部门的基本工作原则。因此金融行业架构基本上选择使用以IOE为代表的成熟、稳定、具备良好技术支持保障体系的“经典”商用软件和体系架构，并培养了大批熟悉应用相关技术的优秀技术人员。分布式架构与传统架构相比，在架构、设计、开发、运维、管理上需要有不同的思维和技术能力，会对现有技术团队的思想观念和思维模式造成巨大冲击，需要有一个“脱胎换骨”的转变过程。

二、尽快完成关键技术攻关

在分布式架构上，为了适应云计算下资源弹性变化和快速部署等需求，必须有一套成熟的金融级分布式架构体系。分布式架构体系的关键不在分布式的服务调用，分布式事务框架和分布式数据库才是金融级分布式架构的核心能力。目前这样的核心技术掌握在少数互联网科技公司，传统IT厂商并无成熟可靠的适用产品，外购的可选性较小。而此类基础能力自研的难度也非常大，不仅面临研发的时间周期较长，短时间很难成熟，还面临不成熟技术应用可能带来的风险，其转型面临核心技术的难关。

三、研发测试运维体系构建

金融行业在业务上面临互联网金融带来的冲击，技术上又面临云计算和分布式架构转型，这需要在业务产品上强调用户体验、谨慎试错、持续改进，技术上需要支持快速迭代、风险可控、故障快速定位等能力。这些对于传统的研发运维体系提出了巨大的挑战，如何在符合监管的条件下推进敏捷研发、DevOps，实现研发测试运维一体化，这既是技术挑战，更是管理流程挑战。

四、尽可能保护现有IT资产

金融行业特别是银行，通常都在现有的IT基础设施上投入了巨资，包括服务器、存储设备、数据库和中间件等软件许可，甚至还包括大量的应用软件。如果要实施云计算与分布式架构转型，就意味着前期巨大的投入将面临淘汰。为了避免完全推到重建（这也是不可能的），上云的应用与传统架构下的业务系统必然有一个较长的并行期。在这个并行期中，需要处理好老应用迁移节奏、老业务自然增长的扩容压力、新增投资方向等问题，因此分布式架构转型是一项长期的系统性工程，需要非常精准的组织和管控，以达成最有效的现有IT资产保护，减少转型投入。

五、团队能力建设与人才培养

云计算相关技术与传统技术发展路径不同，云计算技术往往来自于开源技术，由于开源技术的变化很快，难以提供持续、稳定的技术支持，研究这些技术的大多为创新型公司，云计算技术专家也集中在互联网公司。而一般的互联网公司往往对于金融业务的高一致性、高可用和高安全的理解不足，缺乏对金融应用特点的理解和实践经验，技术上的积累自然不足。因此，需要培养和拥有一批既掌握新技术，又有丰富金融应用经验的技术人才，而现有的招聘、薪酬和激励机制，不足以吸引此类紧缺人才。