架构揭秘：「东方证券」业务中台架构探索
一、背景
近年来，随着移动互联网、大数据和人工智能等新技术的全面深入应用，以及新商业模式的涌现和财富管理转型，对证券公司的 IT 能力提出了新的挑战。如何快速响应业务的需求、提供差异化的服务、满足投资者个性化的需求，成为摆在证券公司 IT 建设面前的巨大挑战。总体来说，券商在系统建设过程中仍存在不少的痛点，主要如下：
-
“烟囱式”建设，与大多数公司一样，东方证券系统以往多采用“烟囱式”发展方式，系统各自为政，功能大量重复，例如证券公司面向零售客户的网上交易系统，一般都有通达信 / 同花顺等，面向机构客户的 PB 产品端往往有恒生 / 迅投 / 根网等系统，架构层面也缺乏统一规划和管控，技术成果更加无法共享；
-
单体架构，牵一发而动全身，且系统相互之间耦合度高，相互影响，无法保证 7*24 小时业务开展；
-
技术架构异构化，各个系统的功能调用方式、支持的开发语言、调用入口等等也不尽相同，形成了系统间的技术壁垒。在此基础上再进行系统开发以及进一步的迭代，其技术难度和风险也非常大；
-
交付速度慢，核心系统建设多以购买为主，需求响应缓慢，受制于人；
二、中台定义
从 2015 年开始，以阿里巴巴为代表的各互联网巨头，陆续开启中台化进程，随后，“中台化”的理念与相关实践开始快速向各行业渗透和发展；对于金融行业，打造中台能力，无论是银行、证券或是保险等细分行业，均已是高度共识的战略举措之一。与此同时，证券行业财富管理转型、客户需求日新月异、IT 改造难度加大等现实状况也日益严峻。为了促进公司数字化转型，基于企业现状及未来展望，东方证券也提出了“薄应用 厚中台 稳后台”的企业中台战略规划。
中台的定义各有不同，如阿里[1]官方定义“业务中台就是将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新，实现以数字化资产的形态构建企业核心差异化竞争力。”Gartner [2]将中台定义为企业应用系统的 SOD 层，是灵活响应的前台与稳定可靠的后台之间的“变速齿轮”，ThoughtWorks[3] 定义为企业级能力复用平台，是面向用户与创新的新兴平台型企业组织。
东方证券企业级业务中台的核心建设目标是基于 API 化的开放式模块化架构核心思想，将核心业务知识进行沉淀，以模块化、服务化、共享化的形式建设企业级业务能力，从而快速响应市场变化和客户需求，提升业务交付效率，破除证券前台业务快（敏捷响应）和后台稳（坚实支撑）之间的“发展速率脱节和失配”的突出矛盾。
三、企业业务中台建设原则
企业业务中台建设对于证券行业来说也是一个新生事物，为此在实际建设过程中，我们遵循如下建设原则：
-
业务引领
中台的建设是以提高业务响应为目标，所以需从自身商业模式和市场需要出发，围绕业务目标，按照中台的理念推进业务 / 技术架构变革，而不是简单跟风和模仿，为中台而中台；
-
领域划分
按照领域驱动的原则，在战略阶段划分问题域，确定核心领域，将系统划分为多个业务能力中心，当系统划分为多个业务能力中心后，中台建设就进入战术阶段。在战术阶段，针对已确定的各业务能力中心，结合业务需求进行具体的领域设计。
-
统一视角
企业业务中台面对众多业务线，需要站在业务整体视角，如 PC 网上交易、APP、临柜等，梳理业务流程，统筹考虑建设，要将后台资源抽象、沉淀和整合，包装成便于前台使用的可复用、可共享的核心能力，实现后台资源到前台易用能力的简化。
-
能力复用
中台是针对“商业模式”和“业务模式”的抽象与复用，沉淀共享能力，以可重用和可复制方式输出给各渠道产品线，以组件和能力编排实现业务场景化应用，并以服务化的形式输出能力。
四、用户业务旅程
区别于互联网行业及其他传统行业，证券行业也有其自身行业特点，我们站在用户的视角，具体来分析下券商用户的核心业务旅程，以券商用户目前应用最为广泛的 APP 应用为例，其典型具体业务旅程如下：
-
打开 APP，进入首页，查看各类资讯；
-
进行手机号注册，注册后点击登录进行认证登录，进行积分等权益登记；提示开立资金账号，点击开立后，上传各类资料，进行风险评测及双向视频验证；
-
资金账户开立，适当性管理，可进行各类业务办理；
-
点击银证转账，设置银行账号，转入 / 转出资金；
-
点击理财页面，查看各类理财产品信息；
-
点击产品购买，进行适当性判断，进入理财产品购买流程；
-
点击基金投顾页面，配置基金投顾服务；
-
点击行情页面，查看市场行情；
-
点击交易页面，点击买入 / 买出，进行场内交易；
-
点击资产页面，查看资产详情；
-
点击商城页面，查看 LEVEL2 等非金融产品，可使用积分 / 第三方 / 保证金等方式购买非金融产品；
图 1 用户业务旅程图
五、业务中台整体架构
通过对用户旅程进行分析，可以得知，券商客户的核心业务领域主要涉及行情、资讯、账户、资金、认证、产品、基金销售 / 投顾、场内交易、资产及商城等核心场景。因此，根据业务单一原则，如图 1 所示，东方证券将企业业务中台主要划分为账户、产品、财富、资产、行情、资讯、交易、认证、支付、会员、权益、投研等能力中心，形成“薄应用 厚中台 稳后台”的企业架构全景。
图 2 东方证券企业架构全景图
部分能力中心定位分别如下：
-
账户中心，建设权威、完整、标准的账户主数据中心，进行账户类业务受理及办理，提供各类账户全生命周期及适当性管理，并为各业务渠道提供数据服务；
图 3 账户中心架构图
-
财富中心，对接场外交易系统原子能力，进行金融产品销售业务流程封装，提供场外交易统一接入服务能力；
图 4 财富中心整体架构图
-
产品中心，建设公司级金融产品仓库，覆盖公司全业务全类型的金融产品及产品化业务，从产品引入、产品上架、产品库管理、销售支持、营运管理到售后的分析报表与绩效考核，实现金融产品全生命周期管理，成为公司金融产品标准和权威的来源；
图 5 产品中心架构图
-
交易中心，统一制定场内交易协议，一方面屏蔽各柜台接口差异性（各交易中心须按交易接入中心协议进行对接），进行交易系统路由，对交易业务进行管控，另一方面对接场内竞价原子能力，对竞价业务流程进行组合包装，统一提供场内竞价业务能力；
图 6 交易中心架构图
-
资产中心，整合各个相关业务系统的底层数据，汇总交易和回报的实时数据，承接交易清算数据，进行交易明细数据、资产查询及各类衍生指标的计算和服务，为客户提供更加深度的资产交易查询分析服务等功能（7*24 小时服务)，统一提供用户整体资产解决方案；
图 7 资产中心整体架构图
-
资讯中心，统筹管理公司内外各类资讯数据源，对资讯数据进行提取、清洗、加工、存储等操作，形成资讯数据标准，对资讯数据进行全生命周期数据管理，并对外整体提供资讯类服务；
图 8 资讯中心架构图
-
行情中心，整合接入了国内外主要金融市场的交易行情，提供了行情接入与推送、存储、回放、计算及分析等领域的一体化解决方案；
图 9 行情中心架构图
-
权益中心，旨在为公司客户的数字化商品权益和卡劵类等虚拟资产提供管理功能，为相关的运营体系提供基础服务，系统提供的主要服务包括权益管理、卡劵管理和内控管理。
图 10 权益中心架构图
-
投研中心，贯穿投前、投中、投后整个投资研究过程，进行分析、决策、投资的整体投研流程生命周期管理，提供资产配置，数据服务，算法服务，因子计算、策略回测与分析等投研相关服务；
图 11 投研中心架构图
-
认证中心，以用户身份管理为核心，加强管理 B/S、C/S、移动 APP 等结构的多应用的安全访问机制，集身份管理、身份认证、授权管理、应用资源访问控制及其安全审计于一体，构建多信息资源的应用整合、集约管理和安全防护的安全基础服务平台；
图 12 认证中心整体架构图
六、DDD 领域驱动建模
-
领域拆分各能力中心内部先进行模块化的拆分，可以先按照业务类型进行拆分，如场内交易可拆分为股票、信用、期权等模块。模块内部要进行更为细致的服务拆分，运用领域驱动建模的方法论，实现“高内聚低耦合”的业务模型。根据模型的关系进行划分限界上下文，限界上下文往微服务转化，并得到系统架构、API 列表、集成方式等产出，形成良好的微服务架构设计，避免形成大单体或混沌的微服务架构，核心原则是单个服务可独立开发、独立部署及运行，如财富中心 / 交易中心服务可拆分为下图所示：
图 13 领域模型示意图
-
分层代码架构如图 14 所示，在具体代码模块内部，基于 DDD 模式，建立清晰的应用层、接口层、领域层和基础设施层代码结构，易于后续的代码变更、升级及维护；
图 14 分层代码架构
七、技术架构
技术框架是业务中台成功的基石，为此，东方证券进行了体系化的技术架构建设，为企业业务中台提供了全方位的技术支撑。
图 15 东方证券企业中台技术架构图
7.1 服务治理框架
券商传统信息系统多采用单体架构模式开发，把所有的功能都打包在一个独立单元中，并当作一个整体来开发、测试和部署。然而，随着业务的爆炸性增长，应用系统规模不断增大，单体架构将给业务系统的开发、维护、部署带来巨大的问题。为此，东方证券也制定了企业技术架构向以微服务为核心的现代化架构转型。通过对比 gRPC[6]、Dubbo[7] 及 SpringCloud[8] 等业界主流框架，基于证券行业的特点，我们选择了具有跨语言特性的 gRPC 为核心框架，并在其基础之上新增服务治理特性，建设了 gRPC-Nebula 服务治理框架和星辰服务治理平台，从而实现企业内部及外部服务的统一化管理，构建服务调用关系及拓扑结构，优化改进服务质量。图 16 展示了东方证券服务治理平台的总体架构。
图 16 东方证券服务治理总体架构
东方证券服务治理框架主要包括如下跨语言微服务通讯框架、注册中心、服务消费者（客户端）、服务提供者（服务端）、信息收集器、数据处理引擎、服务治理门户等模块。相对于原生 gRPC 框架，gRPC-Nebula 服务治理框架引入了 ZooKeeper 作为注册中心，融合了服务注册发现、负载均衡、黑白名单、动态分组、集群容错、流量控制等服务治理机制。服务治理框架详细介绍参见东方证券企业架构之技术架构转型实践[15]。
图 17 服务治理应用图
7.2 PaaS 平台
随着互联网场景的不断延伸，业务系统对高吞吐低时延的要求越来越高，而开源中间件作为其中的佼佼者很好地承接了互联网业务的发展，同时也支撑了其它各类业务场景的探索，为此我们在 PaaS 平台上做了如下工作：
-
建设了标准化的 PaaS 平台，对市场上主流的开源中间件进行了筛选，包括 Kafka、Redis、Zookeeper、Nginx、elasticsearch 等各类中间件，并设置相应版本基线；
-
发布了 PaaS 管理规范的架构决策，从架构治理上了规范了 PaaS 中间件的使用；
-
对各类中间件进行全生命周期的纳管，供各应用方申请使用；
-
对于业务应用最为常用的三个核心中间件 Kafka/Redis/Zookeeper，实现了同城三机房高可用部署，支撑各类应用由目前的单活向多活的高可用架构演进，如图 18，19，20 所示；
图 18 ZooKeeper 三机房高可用架构
图 19 Redis 三机房高可用架构
图 20 Kafka 三机房高可用架构
7.3 应用多活
“应用多活”是“应用容灾”技术的一种高级形态，指在同城或异地机房建立一套与本地生产系统部分或全部对应的生产系统，所有机房内的应用同时对外提供服务。当灾难发生时，多活系统可以极短时间内实现业务流量切换，用户甚至感受不到故障发生。常见的应用多活架构分为同城多活、异地多活、混合云多活，和传统容灾相比，应用多活具备 RTO 低、资源充分利用、切换成功率高、流量精准控制等优势。如图 21 所示，我们主要在同城多活做了以下工作：
-
首先，将各业务应用中经常使用的 PaaS 中间件 (Zookeeper/Kafka/Redis) 进行多活机房部署；
-
其次，由于 gRPC-Nebula 框架所依赖的 PaaS 中间件 Zookeeper 已实现多机房部署，并配合框架本身的多机房分组功能，实现 gRPC-Nebula 的多活架构；
-
最终，依赖 gRPC-Nebula 开发框架与 PaaS 中间件的结合，从而实现各应用的多活架构，最终实现企业架构整体应用多活；
图 21 gRPC-Nebula 应用多活架构
八、研发管理
整个企业业务中台为巨型系统，且从业务需求视角出发，关联系统众多，所以需要有规范的研发管理制度和工具链来保障整体的交付效率及交付质量。
-
代码分支管理，采用 Bitbucket 进行代码管理，并以经典的 Git Flow 模型为代码分支管理工作流程，以 master 版本生产发布，dev 分支为主开发，feature 分支为特性开发，release 分支构建，生产合并主干，hotfix 分支紧急修复 bug 的原则；
图 22 Git Flow 分支模型
-
版本火车发布，如图 23 所示，建立版本火车的研发管理模式，每个模块或服务建立清晰的版本发布计划，同时整体研发活动有明确的需求评审 -->架构设计评审 -->代码 review-->接口评审 -->测试案例评审 -->验收评审 -->各类变更评审 ;
图 23 研发版本火车发布模式
-
研发流水线，如图 24 所示，建设研发运行一体化平台，集成各类工具，紧紧围绕制品版本，建立严格的质量门禁和自动化测试体系，实现整个代码编译 - 打包 - 测试 - 发布自动化流水线作业，大幅提升交付质量及交付效率；
图 24 研发运行一体化平台架构图
图 25 研发运行一体化流程图
图 26 研发运行一体化应用图
-
数据治理，以业务中台为基准形成主数据中心，确定整体各业务的词根、数据字典、公共代码等数据规范，形成公司级业务术语、标准词根及公共代码，并将数据治理流程嵌入整体研发流程，在接口评审中对数据字段及人工代码进行审核；
图 27 业务术语标准示意图
图 28 数据治理接口评审示意图
九、实践成果
从 2019 年初开始，东方证券确定了企业大中台战略，围绕业务价值与 IT 用户体验，大力推进“薄应用，厚中台，稳后台”的架构转型，并通过制定架构标准推动相应领域建设，经过三年多的建设，截止到 2022 年 8 月底，形成了体系化的技术架构和数字化管理能力，各业务中台上线对外服务数 195 个，对外接口总数达 1822 个，日峰值请求量 4600 万 + 次，对接各类业务需求 450+（不完全统计），形成数据治理词根 2436 个，字段 1554 个，公共代码 13 个，已深入经纪、财富管理、期货、资管、PB、自营等业务领域，初步形成了集团协同能力，为东方赢家 APP、网上交易 PC 端、机构交易客户端、机构理财客户端、CRM 等业务线提供共享能力服务，并成功实现了财富管理业务领域需求全覆盖，助力东方证券以客户数排名 38 名，经纪业务排名 20 名，取得了公募基金保有量在行业排名第 7 位 [16]的成绩，整体上线业务需求达 90%，通过技术共享、服务共享、数据共享、研发规范，有力的提升了开发效率，降低了对开发商的依赖和系统研发成本，避免了系统的重复建设和异构化，提升了业务需求的交付速度，沉淀了证券核心领域业务知识库和领域，对于增强公司科技创新应用能力，激发行业技术创新动力，发挥了重要作用。
图 29 东方证券企业中台对外接口数
图 30 东方证券企业中台接口峰值访问量
-
账户中心，使原有账户系统的功能外延大范围扩展，支持 7*24 小时不间断接口能力服务，不受后端处理系统影响；具备健全、细化的投资者适当性管理，灵活满足监管要求；并为各个业务系统提供统一、权威、标准的客户账户数据服务。
图 31 账户中心应用效果图
-
财富中心，建成了基于金融产品全生命周期交易的业务组装平台，打破账户、产品以及各单一业务后台系统的局限性，促使业务融合并优化产品销售能力，面向 APP、PC 等终端，为客户提供产品适当性匹配、认购、申购、赎回、持仓等的交易前、中、后的业务逻辑编排能力，实现金融产品的 7*24 小时交易能力。
图 32 财富中心应用效果图
-
产品中心，实现了金融产品管理和服务从离散化向集中化、服务化、中台化的转化。
图 33 产品中心应用效果图
-
资产中心，其应用场景适用于除了核心交易链路之外的大部分资产交易数据服务场景，面向 PC/ 移动 APP/CRM 等业务系统，提供准确的实时资产查询 / 个性化资产分析，实时推送服务 / 推荐，其他衍生场景，能灵活适应业务的资产呈现方式，并将部分查询和统计分析类增值服务从交易系统解耦，降低交易系统查询压力。
图 34 资产中心应用效果图
-
交易中心，在机构交易方向，兼容 OST、集中交易柜台、新一代交易系统及其他第三方交易系统接口协议，为机构终端提供统一的场内交易接口协议及接入能力，大幅降低机构客户交易柜台切换成本。
图 35 交易中心应用效果图
-
资讯中心，统筹管理公司内外各类资讯数据源，对资讯数据进行提取、清洗、加工、存储等操作，形成资讯数据标准，对资讯数据进行全生命周期数据管理，并对外整体提供资讯类服务；
-
行情中心，为公司内各业务部门及子公司、机构及零售财富客户提供实时行情及历史行情服务，接入、整合和管理从全球交易所及其他三方行情源发送的各类市场行情，提供统一的数据接口标准、超低延时以及高质量的市场行情数据推送、查询服务，并提供多种衍生行情服务如全息处理、指标计算、智能盯盘等，以支持各类用户的量化投资研究、算法交易、高频交易、程序化交易、统计套利、组合管理、风险控制等各种业务应用。21 年实时行情 40 个有效用户共登录 4.1 万次，累计使用时长 32 万小时，历史行情查询服务全年共 35 个用户接入，服务请求量峰值为 128 万 / 天
-
权益中心，形成了东方证券虚拟资产管理能力，并对 APP 端提供了相应服务。
-
投研中心，初步形成了东方证券投资研究的服务体系，并在基金投顾等业务中取得了良好的应用效果。
-
认证中心，将公司内部各个组织、子公司等人员结构集中整合至认证中心统一管理，并将各类安全规则统一配置，实现了公司内部账户和应用的集中管控，使安全性得到提升，并大幅减少新建系统适配认证源的成本。
图 40 认证中心应用效果图
十、总结与展望
东方证券经过三年多的建设，并基于 API 化的开放式模块化架构核心思想，形成了“薄应用 厚中台 稳后台”的企业架构全景，并将核心业务知识进行沉淀，以模块化、服务化、共享化的形式建设企业级业务能力，从而快速响应市场变化和客户需求，大幅提升业务交付效率，金融科技核心竞争力取得重要突破。
未来，东方证券将继续以开放共享、合作共赢为原则，以金融科技规划为牵引，持续推进中台战略转型，并以新一代交易核心平台建设为契机，与交易系统配合形成更为全面的领域服务划分，合理清晰的原子及业务流程服务，精细化各系统内部及之间细粒度的服务、接口及数据库设计，持续推动金融科技研究应用，以金融科技赋能业务，引领创新，不断助力公司数字化转型与行业创新发展。