文/证券期货业金融科技中心
ID/gh_87d9b5e48782
研究机构/东方证券股份有限公司
01
引言
近年来，随着证券市场客户和业务量的不断攀升，以及互联网金融的兴起和金融科技的发展，各证券公司都制定了数字化转型的战略目标。为了把握新一轮数字化技术革命浪潮，企业信息系统架构正在不断升级变迁，很多企业内部的传统软件系统都开始向微服务架构转型，通过服务拆分、降低系统耦合性，达到“高内聚、低耦合”，提供更为灵活的服务支撑。
随着研发人员对系统进行解耦和拆分，对大量微服务实例进行有效管控、提升系统运行时的服务质量变得非常困难。在此背景下，东方证券为了顺应互联网 时代的潮流，响应快速更新的业务需求，迫切需要以统一、服务化的思路来进行系统建设，建设服务治理平台，通过分析服务调用关系及拓扑结构、优化服务质量、制定服务协议规范，达到新建系统与已有系统统一服务治理，实现轻应用（业务为导向，实现业务应用敏捷构建，及时响应市场需求）、重平台（将数据和核心应用转化成平台服务，成为整个架构的核心）、服务化（构建核心服务网络，简化应用开发与部署）的整体企业技术架构转型目标，实现应用全生命周期管理。
02
微服务架构
2.1
单体架构
传统信息系统多采用单体架构，单体架构应用把所有的功能都打包在一个独立单元中，并当做一个整体来开发、测试和部署。单体架构的优势是开发、调试、部署简单方便，在业务发展初期，信息系统的规模较小，使用传统的单体架构可以有效地支撑业务的发展。然而，随着业务的爆炸性增长，应用系统规模不断增大，单体架构将给业务系统的开发、维护、部署带来巨大的问题。
2.2
微服务架构
微服务架构可以很好地解决单体架构下的诸多问题：第一，将巨大的单体应用拆分成颗粒度更小的服务，服务内逻辑简单、高度内聚，易于开发和维护；第二，各个微服务独立部署，功能修改后可以针对特定部分进行发布，使得各个微服务系统能够持续化部署，加快了迭代的速度；第三，当单个服务系统出现故障时，只需要将出现故障的服务下线修复即可，不会导致整个系统的级联故障；第四，可根据不同微服务系统的访问量和资源需求，动态的实现横向扩展和纵向扩展，这大大的提高系统的利用率；第五，各个研发团队可以根据自己的需求选择编程语言和技术栈，具有更大的灵活性。
虽然微服务架构有着明显的优越性，但是证券公司普遍存在的系统异构化问题也给微服务架构的落地带来了巨大挑战。
（1）业务接口标准不统一，管控风险大
券商行业的核心系统由传统供应商组成，以东方证券经纪业务核心系统为例，分别由金仕达、新意、恒生、顶点、同花顺等厂商架构组成，SPX、T2、Rest、WebService等多种类型服务接口存在于企业内部，多业务协同适配问题突出，服务多样性对同步、异步、流式数据等都提出了技术需求，统一化难度大；缺乏有效的关键业务流量控制技术手段；全局化平台协同与调度困难，缺乏全局视角对内部服务进行统一化管理。
（2）自研系统上线面临诸多困难
随着金融科技的深入发展，证券行业纷纷开始进行自研核心系统，但因为缺乏统一的开发框架，各业务研发团队在具体开发过程中除了业务分析之外，还需同时会关注非常多的技术细节，如依赖服务接口对接，对外服务协议选型，服务故障定位，流量控制，配置管理，流量管控等，自研业务也面临着诸多现实问题。
（3）传统网关模式存在不足
传统核心系统采用网关模式进行接入管控，其一般具有身份认证、路由配置、负载均衡等功能，在对类似手机端这样的客户端时，其能起到比较好的作用，但用在核心机房内部服务调用就存在着明显的不足。
- 采用网关模式，渠道端须自己封装TCP SDK，进行网关切换，所有的流量都会打到单网关节点，网关本身往往会成为瓶颈；
- 采用网关模式，往往通过部署多个网关节点进行横向扩展，在运维部署上就会增加相当的工作量，也消耗资源；
- 采用网关模式，相当于多了一路网络跳转，增加网络耗时，在同等部署模式下，降低了系统整体能承受的并发容量，增大系统延时；
- 采用网关模式，系统内部微服务对外采用网关对外服务，无法发挥出微服务自动注册，自动发现的优势，新增服务往往需要修改网关配置进行发现，整体架构退化成了传统架构模式；
理想情况下，业务人员关心业务梳理和场景定义，开发人员把相关业务转换成服务定义，借助代码生成工具自动化生成接口代码，最后根据业务实现接口内部逻辑。由开发框架和外部工具负责架构扩展性、服务治理、配置管理等一系列非业务相关的功能实现，实现业务和框架的解耦，提高开发效率。
03
东方证券服务治理平台
完善的服务治理方案是微服务架构应用稳定运行的基石，东方证券在gRPC框架基础上新增服务治理特性，建设了gRPC-Nebula服务治理框架和星辰服务治理平台，从而实现企业内部及外部服务的统一化管理，图1展示了东方证券服务治理项目的总体架构。
图1 东方证券服务治理项目总体架构
东方证券服务治理方案主要包括如下几个模块：
（1）注册中心
注册中心是一个分布式、高可用的配置维护系统，用于服务的注册和订阅，它存放着所有的服务描述信息以及服务接口信息。在微服务框架系统中，服务和接口的数量非常庞大，注册中心通过将服务统一管理起来，可以有效地优化服务消费者对服务提供者的感知和管理，避免硬编码地址信息。
（2）服务消费者（客户端）
服务的消费者，通过注册中心交互获取服务注册信息，基于服务注册信息发起对服务端的调用；同时，采集调用端信息发送到数据处理引擎中进行分析处理，为调用链分析提供客户端数据。
（3）服务提供者（服务端）
服务的提供者，通过注册中心对外发布服务信息，响应消费者的服务调用请求；同时，响应控制台等发起的配置管理操作，对服务质量、安全策略、数据收集等进行配置管理。
（4）信息收集器
独立的部署的服务，收集服务调用过程中在服务提供者和服务消费者产生的服务调用、服务响应、服务异常、服务时间、调用链路、内部队列长度、安全事件等信息，收集后统一发送到数据处理引擎进行处理。
（5）数据处理引擎
数据处理引擎，对信息采集器发送过来的信息事件流进行实时分析处理，处理操作包括性能统计、依赖分析、阈值告警、相关聚类、状态跟踪等；同时，数据被存储到数据库，用于进一步的分析操作。
（6）服务治理门户
服务治理门户汇总了服务治理领域的运行数据和管理系统，它是全公司服务治理的综合平台。
04
gRPC-Nebula服务治理框架
4.1
技术方案
东方证券调研了目前比较流行的开源微服务框架，包括阿里巴巴的Dubbo、Facebook的Thirft、Google的gRPC以及从Spring Boot框架发展而来的Spring Cloud项目，它们都具有较好的连通性、健壮性、伸缩性和拓展性，但Dubbo和Spring Cloud框架不支持多语言，Dubbo开源社区曾有一段时间不维护更新，最近才重新启动更新。
因为历史原因，证券行业的原有核心系统存在多种语言开发的现状，例如核心交易系统和同花顺网上交易等系统采用C 语言框架开发，账户、产品、资产配置、APP及自研类系统大多采用Java语言框架进行开发，为了解决证券行业天然存在的跨语言场景，最终我们选择以gRPC框架为基础，研发gRPC-Nebula服务治理框架，为业务方提供服务治理整体解决方案。
相比其他几种框架，gRPC有以下优势：
- 全面的多语言支持，gRPC支持多种语言，包括C、C 、Java、Python、PHP、Node.js、C#、Objective-C、Go、Ruby、Dart等。目前券商网上交易和核心交易系统均是C 架构，而其他自研系统大多是Java和Python架构，gRPC 能有效解决服务的跨语言调用问题；
- gRPC在Google和广大开源爱好者的大力支持下，目前社区活跃、更新频繁，已在全世界多家大型科技公司内投入生产；
- gRPC使用Google开源的Protobuf 3.0协议定义接口服务，Protobuf是一种平台无关、语言无关、可扩展且轻便高效的序列化数据结构的协议，广泛应用于网络通信和数据存储，技术人员对Protobuf的熟悉有助于gRPC技术在企业内的推广；
- gRPC的传输使用HTTP/2标准，支持同步、异步、双向流，支持SSL和自定义鉴权，支持iOS、Android、Windows、Linux等平台，可以简单地实现客户端到后台的多路复用与RPC调用。
相对于原生gRPC框架，gRPC-Nebula服务治理框架引入了ZooKeeper作为注册中心，如图2所示，融合了服务注册发现、负载均衡、黑白名单、动态分组、集群容错、流量控制等服务治理机制，本章节后面的部分将详细介绍这些服务治理机制的技术方案。
图2 东方证券gRPC-Nebula服务治理框架架构图
我们分别对Dubbo、原生gRPC、gRPC- Nebula框架进行了性能测试，如表1所示，gRPC- Nebula框架的性能仅比Dubbo和原生gRPC框架低1%左右，满足高性能服务框架的需求。
表1 多框架性能测试比较
4.2
服务注册发现
服务注册发现是服务治理领域最核心的机制，服务提供者在启动时向注册中心注册它提供的服务信息，服务消费者向注册中心获取服务提供者的地址列表，如图3所示。gRPC-Nebula服务治理框架使用ZooKeeper作为注册中心，具有以下特性：
图3 服务注册发现机制
（1）具备高可用性。当注册中心任意一个节点宕机时，服务能够自动切换连接到其它正常的节点上；当注册中心全部宕机时，不影响服务的正常运行，服务消费者会使用本地缓存的服务地址列表继续调用。
（2）保证数据一致性。所有服务消费者同一时刻从注册中心不同节点获取到的服务地址列表是同一份数据，不能出现读或写数据的不一致。
（3）服务变更主动推送。服务消费者只需要在启动时向注册中心拉取一次全量服务地址列表，其后向注册中心订阅相关服务的变更事件，一旦服务地址列表发生变更，注册中心会主动将变更的内容推送给服务消费者，服务消费者即时调整调用的服务地址。
（4）实时感知服务状态。注册中心与服务建立长连接，通过心跳检测机制，能够周期性地检测服务的健康状态，当服务进程意外终止或服务器宕机时，能够立刻向消费者推送服务下线的通知，实现故障隔离。
4.3
服务路由
gRPC-Nebula服务治理框架的服务路由以下三大机制构成：
（1）负载均衡机制
gRPC-Nebula服务治理框架支持连接负载均衡和请求负载均衡两种模式，默认连接负载均衡，同时提供了四种负载均衡算法可供选择：随机策略、轮询策略、权重配置优先策略、一致性哈希策略。
- 随机策略即随机地选择服务提供者进行调用；
- 轮询策略即遍历服务地址列表，每次调用时依次选择一个服务提供方进行调用；
- 权重配置优先策略可根据配置文件或管理门户对每个服务节点配置的权重比来选择服务提供者；
- 一致性哈希策略中，相同参数的网络请求总由同一个服务提供者处理，当某个服务提供者的节点宕机时，系统基于一致性哈希算法来选择其他的节点；
图4 gRPC-Nebula负载均衡配置
（2）黑白名单机制
通过设置服务端实例的黑名单、白名单，可以动态实现请求流程的转移以及服务端实例的访问控制。如果将某IP加入一个服务的黑名单，部署在这个IP上的服务消费者无法从注册中心获取到这个服务的地址列表。
图5 黑白名单设置
（3）权重配置
gRPC-Nebula能够对服务提供者实例设置不同的服务权重，框架根据权重进行流量分发，这样可以达到根据不同的后端资源能力进行动态平衡。
图6 服务权重列表
图7 服务权重设置
（4）动态分组机制
通过分组一个微服务的集群可以被划分为多个集合，服务消费者可以按优先级调用某几个特定分组的服务，动态分组机制可以灵活实现同机房调用和业务隔离等场景。
服务端配置：
客户端配置：
图8 动态分组配置
- 机房调用场景，跨机房调用的高耗时可能造成系统的容量降低。如图9所示，假设所有服务实例均部署在A、B两个异地机房，服务消费者希望优先调用属于同机房的服务提供者，使用IP段定义机房的策略灵活性和扩展性不足，服务分组策略可以有效满足这一需求。
图9 机房调用场景
- 业务隔离场景，业务隔离是避免微服务系统雪崩效应的常用策略，服务分组功能可以将服务提供者集群划分为一个个独立集合，消费者只调用特定分组的实例，这样每个消费者的调用相互隔离、互不影响，可以有效保证整个系统的高可用性。如图10所求，后端服务通过设置tc、wmp、matrix分组，可对交易接入、财富销售中心、东方睿等系统分别提供不同服务等级保障，达到业务隔离诉求。
图10 业务隔离场景
4.4
集群容错
当服务提供者无法正常为消费者提供服务时，如连接被拒绝、请求超时、后台服务异常等，服务框架需要进行集群容错，重新进行路由选择和调用，gRPC-Nebula服务治理框架支持快速失败（Failfast）和失效转移（Failover）两种策略：
快速失败是指如果服务提供者返回异常，消费者不用重试直接报错。这种策略适合一些非核心的服务，可以为重要的核心服务节约宝贵的资源。
失效转移是指当服务调用异常时，重新进行路由选择，查找下一个可用的服务提供者来发起新的调用请求。
图11 集群容错配置
4.5
流量控制
历史上券商核心系统事故都是由流量冲击引起的，gRPC-Nebula服务治理框架通过设置请求数和连接数限制，动态实现对各服务接口的流控管理。
图12 流量控制配置
4.6
访问保护状态
访问保护状态功能是服务治理平台控制服务端节点上下线的方式，可以用于无损发布和快速摘除故障节点等场景。
图13 访问保护流程
图14 访问保护设置
4.7
多注册中心支持
GRPC-Nebula框架支持将服务同时注册到多个注册中心，并且可以将自定义的服务端IP端口注册到注册中心，这个特性为了适配多网段间可能存在的IP地址映射或代理的场景。
图15 多注册中心支持
4.8
主备服务支持
gRPC-Nebula框架支持主备服务，能够对实例设置主服务器和备服务器。当主服务器可用时客户端只能调用主服务器，不调用备服务器；当所有主服务器不可用时，客户端自动切换到备服务器进行服务调用。
图16 主备服务示意图
图17 主备服务设置
4.9
内外部服务
服务提供者实现的接口可以划分为两类服务，对于内部项目间gRPC调用服务，此类服务并不对外暴露，因此应该避免外部项目可见；对于项目对外提供的gRPC服务则需要允许外部系统可见。
图18 内外部服务
4.10
参数路由
参数路由是指在发起一次RPC调用前，通过自定义的路由规则过滤目标服务器地址，参数路由规则支持复杂的数学表达式，包含请求的字段、方法名、环境变量以及自定义函数，规则既可以定义在配置文件也可以通过服务治理平台实时配置。参数路由功能可以应用于灰度切量和渠道管理等场景下，例如可以灵活地根据营业部号或客户号等字段将请求路由到指定的服务端节点。
图19 参数路由配置
4.11
泛化调用
gRPC-Nebula实现了通用的泛化调用方法，不需要依赖proto文件，传入需要调用的服务名和参数值进行调用服务。其实现原理是客户端将JSON作为通讯协议调用服务端，而服务端将JSON请求转换为相应的PB对象交由业务逻辑处理，最后也同样将响应对象转换为JSON返回给客户端。泛化调用适用于一些网关应用，网关应用不需要因为新增一个后端接口而需要重新编译部署，保障了网关应用的通用性和稳定性。
图20 泛化调用
4.12
原生gRPC框架优化
- 断线重连指数退避算法支持
当gRPC连接到服务端发生失败时，通常希望不要立即重试(以避免泛滥的网络流量或大量的服务请求)，而是做某种形式的指数退避算法。参考链接如下：
https://github.com/grpc/grpc/blob/master/doc/connection-backoff.md
但这种形式往往会造成服务端失败后，客户端不断的退化重连时间，长时间会退化成一个非常大的时间，当服务端重新启动成功后，客户端反而长时间不能连接成功，故此gRPC-Nebula修改了原生框架，客户端可以自行配置最大的重连时间，规避此类风险。
图21 退避算法设置
- Keepalive心跳
gRPC原生逻辑具备keepalive心跳机制，客户端心跳默认关闭，服务端心跳2小时发送一次，参考链接如下：
https://github.com/grpc/grpc/blob/master/doc/keepalive.md。
但在实际生产网络环境中，防火墙通常设置为15分钟就会主动断开无请求的TCP连接，证券行业的特点造成了服务请求主要集中在9:15-15:30这个时间段，这样在非交易时间会有大量TCP连接断开，为此我们修改了gRPC框架，使客户端和服务端都可自行配置心跳时间。
图22 客户端心跳设置
图23 服务端心跳设置
05
星辰服务治理平台
5.1
建设目标
东方证券星辰服务治理平台的建设目标包括：
（1）通用治理能力：引入中间层设计，兼容多框架的通用治理能力，采用分发器和治理组件协调工作统一多框架通用治理能力。
（2）平台自服务：平台本身采用微服务架构及容器平台集成，提供更深度的治理功能，提供平台应用生命周期、组件部署管理、灰度、弹性和统一配置支持。
（3）多框架兼容的应用管理：兼容基于gRPC、Spring Cloud、Dubbo三种微服务框架，帮助客户快速部署或迁移微服务应用。
（4）业务服务架构防腐化：通过服务注册中心对服务强弱依赖进行分析，结合运行时服务调用链关系分析，梳理不合理的依赖和调用路径，优化服务化架构，防止代码腐化。
（5）快速故障定界定位：通过服务调用链日志、服务性能KPI数据、服务接口日志、运行日志等，实时汇总和分析，实现故障的自动发现、自动分析和在线条件检索，方便运维人员进行故障诊断。
（6）服务微管控：运行态服务治理，包括限流降级、服务迁入迁出、服务超时控制、智能路由、统一配置等，通过一系列细粒度的治理策略，在故障发生时可以多管齐下，在线调整，快速恢复业务。
（7）服务生命周期管理：包括服务的上线审批、下线通知，服务的在线升级，以及上线、下线，自动弹性伸缩，资源扩容。
5.2
功能模块
星辰服务治理平台包含以下功能模块：
（1）服务治理
平台支持对gRPC、Spring Cloud、Dubbo三种微服务框架进行管理，如图5所示，支持查询注册中心维护的服务实例信息，支持通过控制台配置注册中心、分组、黑白名单、流量控制、熔断等信息。
图24 服务治理功能
图25 服务间调用
（2）服务地图
服务地图将项目与项目、服务与服务之间的调用关系和调用量通过拓扑图的形式进行展示，如图6所示。
图26 星辰服务治理平台服务地图
（3）链路跟踪
通过链路跟踪，可以方便的看到每个请求各个环节的耗时以及异常，链路跟踪功能基于Google的Dapper论文实现，会为用户的请求分配一个唯一的TraceID，通过TraceID可以串起这个请求的完整调用链路。
图27 调用链关系
（4）文档中心
文档中心对ProtoBuf格式接口定义文件进行自动解析，提供技术人员查询各服务注释信息与接口定义的功能，打通各服务上下游的交流渠道。
图28 文档中心
（5）统计分析
统计分析模块支持对服务、实例、端点的性能监控，包括响应时间、可用性、吞吐量等；支持数据大屏，全景展示当前所有服务的运行状态。
图29 平台统计分析
（6）告警中心
告警中心支持基于监控数据的告警规则设置，并以自定义的方式发出告警通知。
图30 告警设置
（7）框架统一纳管
晨辰服务治理平台同时对多种微服务框架进行了统一纳管，在支持gRPC服务的基础上，增加了dubbox及Spring Cloud框架。
图31 多框架支持
06
转型实践
6.1
数字化转型
随着证券行业数字化转型的不断升级，东方证券也将“增强金融科技应用”列入公司的六大发展战略任务之一，并同步在企业技术架构上制定了大中台战略，这也是公司数字化转型中的三个核心战略之一（另两个为：核心自主研发、重构企业技术架构），旨在通过架构转型为公司科技工作的长远发展打下坚实基础。为了推进架构转型工作，2019年初，东方证券成立了以首席信息官舒宏总担任主任的架构委员会，旨在通过架构委员会重点进行企业架构转型的工作，同时创建了金融科技创新研究院，以整合东方证券及子公司的技术资源、倡导以研究为主导的技术应用为主要任务。核心自主研发战略的确立，不仅彰显了东方证券对自身技术实力的信心，同时也展现出在实现信息技术自主、安全、可控方面的胆识与魄力。
6.2
架构标准
为了建设各业务方遵循标准进行开发的能力，让企业架构建设有据可依，东方证券架构委员会制定了架构标准的决策流程及机制，通过架构标准去约束各系统相应开发实践，2019年5月，我们通过服务治理平台接入规范的架构标准，确定了企业技术架构转型的核心框架，各系统采用统一的接口调用方式，要求系统间调用必须使用gRPC提供服务，系统内部可以采用gRPC/dubbo/Spring Cloud三种框架，支持东方证券 IT 技术架构从传统架构向微服务为核心的现代化面向服务架构全面转型。
图32 服务治理架构决策
6.3
大中台战略
为了实现数字化转型，东方证券制定了三年架构规划，通过架构规划及落地实施，打造行业领先的IT架构和一流的IT队伍，形成公司科技发展的竞争力，架构规划中有七大重点任务，其中一项是建设强大的业务共享中台，提炼核心业务流程，为前端产品线提供业务共享能力，给前台提供强大的“炮火支援”能力，确保“厚中台，薄应用”的成功落地，。
按照证券行业的领域特点，我们将整个中台领域划分为产品、账户、财富、交易、资产、行情、资讯、日志、认证等中心，而服务治理框架也成为了整个业务中台的核心基础设施。
图33 东方证券大中台战略
6.4
开源共享/行业标准
东方证券gRPC-Nebula，本身就是在站在开源gRPC的巨人肩膀之上发展而来，为了更好的反馈社区，2019年6月中旬，东方证券宣布开源gRPC-Nebula服务治理框架，开源地址：https://github.com/grpc-nebula，并获得了2019年信通院OSCAR尖峰开源技术创新奖（基于社区开源二次开发）及第四届中国优秀云计算开源案例一等奖。
同时整个证券行业长期以来在技术架构领域没有统一标准，各家厂商都有自己相应的技术框架，从而造成了整个行业一直面对的异构化难题，gRPC-Nebula开源也旨在为整个行业提供参考建议，同时，我们也积极加入了深交所技术产品联盟，推广gRPC-Nebula在行业内的使用，希望能达成行业共识，形成统一技术标准，大幅降低行业各系统间对接成本。
6.5
实践成果
从2019年初开始，东方证券进行服务治理框架研发工作，截止2021.6月，gRPC-Nebula框架Java语言共迭代17个版本，C 语言共迭代8个版本，平台迭代了4个版本，较好的支撑了业务各类的需求。
同时，东方证券在内部大力推广服务治理框架及平台的使用，截止2021.6月，共接入各类应用57个，项目157个，服务数514个，方法数4200个，实例数483个，日承载各类请求量峰值已达到6800万。
从系统维度来看，东方证券服务治理框架已接入内部东方赢家APP、私行APP、通达信网上交易、同花顺机构版、东方睿、东方大脑、智能投顾、大营运平台、业务中台（财富、交易、产品、账户、资产、行情、资讯等）、资产配置等核心系统，从厂商维度来看，微软、恒生、金仕达、新意、顶点、通达信、同花顺等核心厂商及自研团队也已按照架构标准接入服务治理框架及平台，实践成果非常明显。
图34 服务治理平台实践成果
6.6
总结
本文探讨了企业架构领域的关键技术，并详细介绍了跨语言服务治理框架在证券行业的建设成果与实践经验。东方证券在企业架构层面制定了大中台战略，旨在通过业务架构转型为公司科技工作的长远发展打下坚实基础。作为大中台战略的核心组成部分，服务治理项目的建设，是公司提高金融科技核心竞争力的重要突破。gRPC-Nebula框架和星辰服务治理平台已经应用于东方证券业务中台（财富中心、交易中心、账户中心、产品中心等）、东方赢家APP、私行APP、东方大脑、投顾交易、东方睿机构交易产品线等数十个核心项目，同时实现了各微服务框架(gRPC-Nebula/dubbox/Spring Cloud)的统一纳管，为业务线开发提供了更多的开发框架选择，随着平台生态的不断优化和发展，未来将在内部全面推广，服务于更多产品线和用户，为公司IT治理规范和体系化架构建设做出更多贡献。
