东方证券企业架构之技术架构转型实践

微服务架构是近几年受到各行业广泛追捧的技术之一，微服务架构具有轻型化、便捷化、敏捷化等特点，不仅能够适应业务创新和变化的需要，而且易于维护、变更、升级，契合当前证券业务发展的需要。然而向微服务架构转型也面临不少挑战，东方证券通过构建统一的服务治理框架，打造了一个多语言、多协议、可视化、灵活配置的服务管理平台，支持东方证券企业技术架构向以微服务为核心的现代化架构转型。本文将介绍东方证券 gRPC-Nebula 服务治理框架与星辰服务治理平台的建设成果，并介绍转型过程中的实践经验。

引     言

近年来，随着证券市场客户和业务量的不断攀升，以及互联网金融的兴起和金融科技的发展，各证券公司都制定了数字化转型的战略目标。为了把握新一轮数字化技术革命浪潮，企业信息系统架构正在不断升级变迁，很多企业内部的传统软件系统都开始向微服务架构转型，通过服务拆分、降低系统耦合性，达到“高内聚、低耦合”，提供更为灵活的服务支撑。

随着研发人员对系统进行解耦和拆分，对大量微服务实例进行有效管控、提升系统运行时的服务质量变得非常困难。在此背景下，东方证券为了顺应互联网 + 时代的潮流，响应快速更新的业务需求，迫切需要以统一、服务化的思路来进行系统建设，建设服务治理平台，通过分析服务调用关系及拓扑结构、优化服务质量、制定服务协议规范，达到新建系统与已有系统统一服务治理，实现轻应用（业务为导向，实现业务应用敏捷构建，及时响应市场需求）、重平台（将数据和核心应用转化成平台服务，成为整个架构的核心）、服务化（构建核心服务网络，简化应用开发与部署）的整体企业技术架构转型目标，实现应用全生命周期管理。

微服务架构

单体架构

传统信息系统多采用单体架构，单体架构应用把所有的功能都打包在一个独立单元中，并当做一个整体来开发、测试和部署 [1]。Java Web 应用就是典型的单体架构应用，项目被打包成一个 WAR 包部署在同一个 WEB 容器中，其中囊括了数据访问层的 DAO 对象、业务逻辑层的各模块、表示层呈现的 UI 等功能。单体架构的优势是开发、调试、部署简单方便，在业务发展初期，信息系统的规模较小，使用传统的单体架构可以有效地支撑业务的发展。然而，随着业务的爆炸性增长，应用系统规模不断增大，单体架构将给业务系统的开发、维护、部署带来巨大的问题。

• 第一，开发效率持续下降，庞大的代码规模和错综复杂的业务耦合大大增加了研发新功能的难度，开发者不仅要掌握自己负责的模块，还需要了解整个应用系统的逻辑，否则修改代码后可能会引发冲突或其他模块错误；

• 第二，持续迭代存在障碍，任何一个非核心功能的小修改都需要重新部署整个项目，使得系统运维中与发布相关的风险显著增加；

• 第三，系统可靠性变差，传统的单体架构将所有的应用都部署在同一个进程中，如果应用中某个接口发生故障，将会影响整个系统正常提供服务的能力，在巨大的瞬间流量冲击下，很容易引发系统雪崩；

• 第四，扩展性先天不足，单体架构的应用只能在一个维度上进行扩展，但是不同的模块可能有不同的资源需求属性，例如有的功能是计算密集型，有的则是 IO 密集型，由于它们运行在一个实例中，因此无法对特定模块进行扩展；

• 第五，技术僵化无法重构，各个业务使用的技术栈不得不与整个应用的技术栈捆绑在一起，很难更新 SDK 版本或使用新的技术框架。

微服务架构

由于单体架构已不能适应现代企业信息系统的需要，近年来微服务架构被广为推崇，并在越来越多的证券公司中得以实践和落地。微服务架构是由传统的单体架构逐渐演化而来 [2]，将大型单体应用按照业务功能设计拆分成多个能独立运行、职能单一的服务，与其他服务之间通过统一协议进行通讯 [3][4]。

微服务架构可以很好地解决单体架构下的诸多问题：第一，将巨大的单体应用拆分成颗粒度更小的服务，服务内逻辑简单、高度内聚，易于开发和维护；第二，各个微服务独立部署，功能修改后可以针对特定部分进行发布，使得各个微服务系统能够持续化部署，加快了迭代的速度；第三，当单个服务系统出现故障时，只需要将出现故障的服务下线修复即可，不会导致整个系统的级联故障；第四，可根据不同微服务系统的访问量和资源需求，动态的实现横向扩展和纵向扩展，这大大的提高系统的利用率；第五，各个研发团队可以根据自己的需求选择编程语言和技术栈，具有更大的灵活性。

虽然微服务架构有着明显的优越性，但是证券公司普遍存在的系统异构化问题也给微服务架构的落地带来了巨大挑战。

（1）业务接口标准不统一，管控风险大

券商行业的核心系统由传统供应商组成，以东方证券经纪业务核心系统为例，分别由金仕达、新意、恒生、顶点、同花顺等厂商架构组成，SPX、T2、Rest、WebService 等多种类型服务接口存在于东方证券企业内部，多业务协同适配问题突出，服务多样性对同步、异步、流式数据等都提出了技术需求，统一化难度大；缺乏有效的关键业务流量控制技术手段；全局化平台协同与调度困难重重，缺乏全局视角对内部服务进行统一化管理。

（2）自研系统上线面临诸多困难

随着金融科技的深入发展，证券行业纷纷开始进行自研核心系统，但因为缺乏统一的开发框架，各业务研发团队在具体开发过程中除了业务分析之外，还需同时会关注非常多的技术细节，如依赖服务接口对接，开发语言技能，灵活可扩展架构支撑，客户服务治理保障，对外服务协议选型，服务故障定位，请求流量控制，服务安全配置，配置管理，流量管控等，自研业务也面临着诸多现实问题。

（３）传统网关模式存在不足

传统核心系统基本采用网关模式进行对外服务，由网关进行接入管控，其一般具有身份认证、路由配置、负载均衡等功能，在对类似手机端这样的客户端时，其能起到比较好的作用，但用在核心机房内部服务调用就存在着明显的不足。

• 采用网关模式，渠道端须自己封装 TCP SDK，进行网关切换，所有的流量都会打到单网关节点，网关本身往往会成为瓶颈；

• 采用网关模式，往往通过部署多个网关节点进行横向扩展，在运维部署上就会增加相当的工作量，也消耗资源；

• 采用网关模式，相当于多了一路网络跳转，增加网络耗时，在同等部署模式下，降低了系统整体能承受的并发容量，增大系统延时；

• 采用网关模式，系统内部微服务对外采用网关对外服务，无法发挥出微服务自动注册，自动发现的优势，新增服务往往需要修改网关配置进行发现，整体架构退化成了传统架构模式。

理想情况下，业务人员关心业务梳理和场景定义，开发人员把相关业务转换成服务定义，借助代码生成工具自动化生成接口代码，最后根据业务实现接口内部逻辑。由开发框架和外部工具负责架构扩展性、服务治理、配置管理等一系列非业务相关的功能实现，实现业务和框架的解耦，提高开发效率。

东方证券服务治理平台

完善的服务治理方案是微服务架构应用稳定运行的基石，东方证券凭借在服务治理领域的技术沉淀和实践经验，在 gRPC 框架基础上新增服务治理特性，建设了 gRPC-Nebula 服务治理框架和星辰服务治理平台，从而实现企业内部及外部服务的统一化管理，构建服务调用关系及拓扑结构，优化改进服务质量，图 1 展示了东方证券服务治理项目的总体架构。

图 1 东方证券服务治理项目总体架构

东方证券服务治理方案主要包括如下几个模块：

（1）注册中心

注册中心是一个分布式、高可用的配置维护系统，用于服务的注册和订阅，它存放着所有的服务描述信息以及服务接口信息。在微服务框架系统中，服务和接口的数量非常庞大，同时由于系统的动态调整，服务运行的实例数量也是动态变化的，注册中心通过将服务统一管理起来，可以有效地优化服务消费者对服务提供者的感知和管理，避免硬编码地址信息。

（2）服务消费者（客户端）

服务的消费者，通过注册中心交互获取服务注册信息，基于服务注册信息发起对服务端的调用；同时，采集调用端信息发送到数据处理引擎中进行分析处理，为调用链分析提供客户端数据。

（3）服务提供者（服务端）

服务的提供者，通过注册中心对外发布服务信息，响应消费者的服务调用请求；同时，响应控制台等发起的配置管理操作，对服务质量、安全策略、数据收集等进行配置管理。

（4）信息收集器

独立的部署的服务，收集服务调用过程中在服务提供者和服务消费者产生的服务调用、服务响应、服务异常、服务时间、调用链路、内部队列长度、安全事件等信息，收集后统一发送到数据处理引擎进行处理。

（5）数据处理引擎

数据处理引擎，对信息采集器发送过来的信息事件流进行实时分析处理，处理操作包括性能统计、依赖分析、阈值告警、相关聚类、状态跟踪、可用新分析等；同时，数据被存储到性能管理数据库，用于进一步的分析操作。

（6）服务治理门户

服务治理门户汇总了服务治理领域的运行数据和管理系统，它是全公司服务治理的综合平台。在服务治理门户，可以查询每个微服务的实例信息、接口信息、服务状态、依赖和被依赖关系、数据统计、服务调用追踪记录等关键信息和数据，展现了企业服务治理生态的全景图。同时服务治理平台支持黑白名单、流量控制、权重配置、主备配置、上下线状态的管理功能，支持调用量、性能、服务质量、可靠性、故障事件等对象的监控告警功能，是管理人员对微服务进行集中式管理的人机接口，也是故障定位与可视化呈现的中控界面。

gRPC-Nebula 服务治理框架

技术方案

东方证券调研了目前比较流行的开源微服务框架，包括阿里巴巴的 Dubbo[5]、Facebook 的 Thirft[6]、Google 的 gRPC[7] 以及从 Spring Boot 框架发展而来的 Spring Cloud 项目 [8]，它们都具有较好的连通性、健壮性、伸缩性和拓展性，但 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 多框架性能测试比较

服务注册发现

服务注册发现是服务治理领域最核心的机制，服务提供者在启动时向注册中心注册它提供的服务信息，服务消费者向注册中心获取服务提供者的地址列表，如图 3 所示。gRPC-Nebula 服务治理框架使用 ZooKeeper 作为注册中心，具有以下特性：

图 3 服务注册发现机制

（1）具备高可用性。当注册中心任意一个节点宕机时，服务能够自动切换连接到其它正常的节点上；当注册中心全部宕机时，只影响新服务的发布与已发布服务的下线，不影响服务的正常运行，服务消费者会使用本地缓存的服务地址列表继续调用。

（2）保证数据一致性。所有服务消费者同一时刻从注册中心不同节点获取到的服务地址列表是同一份数据，不能出现读或写数据的不一致。ZooKeeper 使用 ZAB 协议作为其数据一致性的核心算法 [10]，是具有严格的访问控制的能力的分布式协调服务。

（3）服务变更主动推送。服务消费者只需要在启动时向注册中心拉取一次全量服务地址列表，其后向注册中心订阅相关服务的变更事件，一旦服务地址列表发生变更，注册中心会主动将变更的内容推送给服务消费者，服务消费者即时调整调用的服务地址。

（4）实时感知服务状态。注册中心与服务建立长连接，通过心跳检测机制，能够周期性地检测服务的健康状态，当服务进程意外终止或服务器宕机时，注册中心能够立刻向服务消费者推送服务下线的通知，实现故障隔离。

服务路由

在生产环境上，微服务都是多实例部署，服务路由决定了服务消费者如何从服务地址列表中选择服务提供者进行调用。gRPC-Nebula 服务治理框架的服务路由以下三大机制构成：

（1）负载均衡机制

gRPC-Nebula 服务治理框架支持连接负载均衡和请求负载均衡两种模式，默认连接负载均衡，同时提供了四种负载均衡算法可供选择：随机策略、轮询策略、权重配置优先策略、一致性哈希策略。

随机策略即随机地选择服务提供者进行调用；轮询策略即遍历服务地址列表，每次调用时依次选择一个服务提供方进行调用；权重配置优先策略可根据配置文件或管理门户对每个服务节点配置的权重比来选择服务提供者；一致性哈希策略中，相同参数的网络请求总由同一个服务提供者处理，当某个服务提供者的节点宕机时，系统基于一致性哈希算法来选择其他的节点；

图 4  gRPC-Nebula 负载均衡配置

（2）黑白名单机制

通过设置服务端实例的黑名单、白名单，可以动态实现请求流程的转移以及服务端实例的访问控制。如果将某 IP 加入一个服务的黑名单，部署在这个 IP 上的服务消费者无法从注册中心获取到这个服务的地址列表。

图 5  黑白名单设置

（3）权重配置

gRPC-Nebula 能够对服务提供者实例设置不同的服务权重，框架根据权重进行流量分发，这样可以达到根据不同的后端资源能力进行动态平衡。

图 6  服务权重列表

图 7 服务权重设置

（4）动态分组机制

每个微服务实例都有一个分组属性存放在注册中心，分组属性既可以通过配置文件预先设定，也可以通过管理平台动态配置。通过分组一个微服务的集群可以被划分为多个集合，服务消费者可以按优先级调用某几个特定分组的服务，动态分组机制可以灵活实现同机房调用和业务隔离等场景。

服务端配置：

客户端配置：

图 8 动态分组配置

机房调用场景，在数据机房安全性越来越得到重视的今天，多机房灾备方案被各类企业广泛使用，但是跨机房调用的高耗时可能造成系统的容量降低。如图 8 所示，假设所有服务实例均部署在 A、B 两个异地机房，服务消费者希望优先调用属于同机房的服务提供者，使用 IP 段定义机房的策略灵活性和扩展性不足，服务分组策略可以有效满足这一需求。例如将机房 A 的服务提供者定义为 a 分组，将机房 A 的服务消费者配置成优先调用 a 分组的节点，同时机房 B 的服务也进行类似配置。这样，机房 A 的服务消费者会优先调用机房 A 的服务提供者，避免高耗时的跨机房调用，当 Server1 和 Server2 全部宕机时，机房 A 的服务消费者会把请求自动切换到机房 B 的 Server3 和 Server4 上。

图 9 机房调用场景

业务隔离场景，业务隔离是避免微服务系统雪崩效应的常用策略，当一个服务提供者被多个消费者调用时，个别消费者的流量激增可能导致整个服务提供者集群超负荷运作，从而影响所有消费者的调用。服务治理平台的服务分组功能可以将服务提供者集群划分为一个个独立集合，消费者只调用特定分组的实例，这样每个消费者的调用相互隔离、互不影响，可以有效保证整个系统的高可用性。如图 9 所求，后端服务通过设置 tc、wmp、matrix 分组，可对交易接入、财富销售中心、东方睿等系统分别提供不同服务等级保障，达到业务隔离诉求。

图 10 业务隔离场景

集群容错

当服务提供者无法正常为消费者提供服务时，如连接被拒绝、请求超时、后台服务异常等，服务框架需要进行集群容错，重新进行路由选择和调用，gRPC-Nebula 服务治理框架支持快速失败（Failfast）和失效转移（Failover）两种策略：

快速失败是指如果服务提供者返回异常，消费者不用重试直接报错。这种策略适合一些非核心的服务，可以为重要的核心服务节约宝贵的资源。

失效转移是指当服务调用异常时，重新进行路由选择，查找下一个可用的服务提供者来发起新的调用请求。当调用一个节点连续多次失败或在一段时间内失败率超过限制时，框架认为这个节点当前已不适合再对外提供服务，服务消费者会将其从服务地址列表中剔除，保证一段时间内都不会调用到这个异常节点。这个机制的目的是降低系统对网络抖动的敏感性，不会因为一次偶然的调用失败而调整流量分配，保持服务器负载的稳定性。和服务分组属性一样，连续失败次数和一段时间内失败率的阈值都可以通过配置文件和管理平台配置。

图 11  集群容错配置

流量控制

历史上券商核心系统事故都是由流量冲击引起的，当网络流量瞬间爆发性增长时，对服务器 CPU 和 IO 资源的抢占会造成系统出现瓶颈，服务错误率迅速上升，此时上游或用户的重试行为又进一步加大了网络流量，最终使得服务彻底崩溃且长时间难以恢复，这即是雪崩效应。为了防止雪崩，需要对服务调用过程进行控制，通过一些策略削减流量，保证后台服务接收的请求在可承受的范围内。

gRPC-Nebula 服务治理框架通过设置请求数和连接数限制，动态实现对各服务接口的流控管理。请求数限制即当单位时间内请求数过多时，丢弃多余的请求；连接数限制即控制每个 IP 连接到服务提供者的连接数，在框架内服务间调用通过 gRPC 的 HTTP/2 协议保持长连接，当连接数达到阈值时，服务提供者会拒绝建立新连接的请求。

图 12 流量控制配置

访问保护状态

访问保护状态功能是服务治理平台控制服务端节点上下线的方式，可以用于无损发布和快速摘除故障节点等场景。例如系统上线更新时，服务的关闭或重启会导致一段时间内调用失败率升高，为了避免失败产生，可以通过服务治理平台将待操作实例设置为不可访问，注册中心会通知所有消费者不再调用不可访问节点。待确认服务端实例无调用请求后，运维人员实施更新操作，更新成功后再将实例重新设置为可以访问。更新过程中流量会平滑地从实例移除和返回，不会产生调用失败。

图 13 访问保护流程

图 14  访问保护设置

多注册中心支持

出于安全管控需求，很多企业将网络划分为多个网段，每个网段部署独立的注册中心。GRPC-Nebula 框架支持将服务同时注册到多个注册中心，并且可以将自定义的服务端 IP 端口注册到注册中心，这个特性为了适配多网段间可能存在的 IP 地址映射或代理的场景。

图 15  多注册中心支持

主备服务支持

gRPC-Nebula 框架支持主备服务，能够对实例设置主服务器和备服务器。当主服务器可用时客户端只能调用主服务器，不调用备服务器；当所有主服务器不可用时，客户端自动切换到备服务器进行服务调用。

图 16 主备服务示意图

图 17  主备服务设置

内外部服务

gRPC-Nebula 框架支持同一项目不同类型的 grpc 服务具有不同的可见性。服务提供者实现的接口可以划分为两类服务，对于内部项目间 gRPC 调用服务，此类服务并不对外暴露，因此应该避免外部项目可见；对于项目对外提供的 gRPC 服务则需要允许外部系统可见。

图 18  内外部服务

原生 gRPC 框架优化

断线重连指数退避算法支持

当 gRPC 连接到服务端发生失败时，通常希望不要立即重试 (以避免泛滥的网络流量或大量的服务请求)，而是做某种形式的指数退避算法。参考链接如下：

https://github.com/grpc/grpc/blob/master/doc/connection-backoff.md

但这种形式往往会造成服务端失败后，客户端不断的退化重连时间，长时间会退化成一个非常大的时间，当服务端重新启动成功后，客户端反而长时间不能连接成功，故此 gRPC-Nebula 修改了原生框架，客户端可以自行配置最大的重连时间，规避此类风险。

图 19 退避算法设置

Keepalive 心跳

gRPC 原生逻辑具备 keepalive 心跳机制，客户端心跳默认关闭，服务端心跳 2 小时发送一次，参考链接如下：

https://github.com/grpc/grpc/blob/master/doc/keepalive.md。

但在实际生产网络环境中，防火墙通常设置为 15 分钟就会主动断开无请求的 TCP 连接，证券行业的特点造成了服务请求主要集中在 9:15-15:30 这个时间段，这样在非交易时间会有大量 TCP 连接断开，为此我们修改了 gRPC 框架，使客户端和服务端都可自行配置心跳时间。

图 20 客户端心跳设置

图 21 服务端心跳设置

星辰服务治理平台

建设目标

由于业务的实际需求和技术发展，开发部门和供应商通常会根据需要选择不同的微服务框架，呈现多样化选型。如何管理好这些服务，成为研发和运维部门需要面对的问题。如果可以将这些框架和服务对接到统一的服务治理平台，将可以大大降低协作开发的成本，并提升整体的版本迭代效率，因此东方证券星辰服务治理平台的建设目标包括：

通用治理能力：引入中间层设计，兼容多框架的通用治理能力，采用分发器和治理组件协调工作统一多框架通用治理能力，由分发器下发任务至不同的治理组件，由理组件完成平台纳管多框架，完成分发器下发治理任务。平台自服务：平台本身采用微服务架构及容器平台集成，提供更深度的治理功能，提供平台应用生命周期、组件部署管理、灰度、弹性和统一配置支持。

多框架兼容的应用管理：兼容基于 gRPC、Spring Cloud、Dubbo 三种微服务框架，帮助客户快速部署或迁移微服务应用。

业务服务架构防腐化：通过服务注册中心对服务强弱依赖进行分析，结合运行时服务调用链关系分析，梳理不合理的依赖和调用路径，优化服务化架构，防止代码腐化。

快速故障定界定位：通过服务调用链日志、服务性能 KPI 数据、服务接口日志、运行日志等，实时汇总和分析，实现故障的自动发现、自动分析和在线条件检索，方便运维人员进行故障诊断。

服务微管控：运行态服务治理，包括限流降级、服务迁入迁出、服务超时控制、智能路由、统一配置等，通过一系列细粒度的治理策略，在故障发生时可以多管齐下，在线调整，快速恢复业务。服务生命周期管理：包括服务的上线审批、下线通知，服务的在线升级，以及上线、下线，自动弹性伸缩，资源扩容。

功能模块

星辰服务治理平台包含以下功能模块：

（1）服务治理

星辰服务治理平台支持对 gRPC、Spring Cloud、Dubbo 三种微服务框架进行管理，如图 5 所示，支持查询注册中心维护的服务实例信息，支持通过控制台配置注册中心、访问控制、主备、分组、黑白名单、流量控制、熔断等信息。

图 22 服务治理功能

图 23 服务间调用

（2）服务地图

服务地图将项目与项目、服务与服务之间的调用关系和调用量通过拓扑图的形式进行展示，如图 6 所示。系统架构师可以从服务地图提炼出全公司的核心系统拓扑图，找出不合理的环形调用链；运维人员可以从服务地图掌握核心系统所依赖的上游系统，并给予核心系统同级别的重点保障。当预期面临流量猛增时，服务地图还可用于流量预估，因为从客户端等入口预估流量最准确，进而可以沿着服务地图下沉计算出各个微服务分摊到的流量，协助后台系统制定扩容预案。

图 24 星辰服务治理平台服务地图

（3）链路跟踪

在微服务架构中，一个用户操作涉及到多个微服务的协同才能完成，在业务调用链路上任何一个微服务出现异常或者网络超时，都会导致失败。通过链路跟踪，我们可以很方便的看到每个请求各个环节的耗时以及异常，帮助我们对系统进行优化。星辰的链路跟踪功能基于 Google 的 DApper 论文 [11] 实现，在系统入口接收用户的请求后，会为用户的请求分配一个 TraceID 用来唯一标识调用链。TraceID 会跟随远程调用消息传递到下游服务，直到整个链路的节点都拥有了 TraceID，通过 TraceID 可以串起这个请求的完整调用链路。

图 25  调用链关系

（4）文档中心

文档中心对 ProtoBuf 格式接口定义文件进行自动解析，提供技术人员查询各服务注释信息与接口定义的功能。我们把文档中心看作是一个服务集市，技术人员在实现一个涉及通用模块或第三方应用的功能前，可以像逛集市一样来文档中心查询接口的详细信息。未来我们还将强化文档中心的交互沟通功能，增加问答与评论功能，打通各服务上下游的交流渠道。

图 26  文档中心

（5）统计分析

统计分析模块支持对服务、实例、端点的性能监控，包括响应时间、可用性、吞吐量等；支持数据大屏，全景展示当前所有服务的运行状态；记录用户请求处理时间，分析出被调用服务的性能；记录服务响应时间，并展示响应时间最长的数个服务，即慢服务列表。

图 27  平台统计分析

（6）告警中心

告警中心支持基于监控数据的告警规则设置，并以自定义的方式发出告警通知。

图 28  告警设置

（7）框架统一纳管

为了更好的支持企业架构转型，也便于各业务方系统内部有更多的微服务框架供选择，晨辰服务治理平台同时对多种微服务框架进行了统一纳管，在支持 gRPC 服务的基础上，增加了 dubbox 及 Spring Cloud 框架。

图 29  多框架支持

转型实践

数字化转型

多年来，随着东方证券各类业务的持续发展，数百套业务及支撑系统在线运营，各类应用系统间开始呈现复杂的依赖关系，系统运维的复杂度急剧增加。特别是由于以往系统建设主要由各厂商开发等因素的影响，东方证券内部存在大量的异构业务系统，对外暴露的接口也呈现多种形式，各厂商都有各自私有协议，且存在有 SPX、T2、Web Service、REST、TCP 等各类型异构接口，进一步增加了系统开发、运维的难度。基于这些原因，东方证券从公司战略和技术管理上进行了变革。2018 年初，公司提出了“数字化转型”的战略目标，并将“增强金融科技应用”列入公司的六大发展战略任务之一，这促使我们以更加积极和开放的心态发展科技。

与此同时，东方证券同步在企业技术架构上制定了大中台战略，这也是公司数字化转型中的三个核心战略之一（另两个为：核心自主研发、重构企业技术架构），旨在通过架构转型为公司科技工作的长远发展打下坚实基础。为了推进架构转型工作，2019 年初，东方证券成立了以首席信息官舒宏总担任主任的架构委员会，旨在通过架构委员会重点进行企业架构转型的工作，同时创建了金融科技创新研究院，以整合东方证券及子公司的技术资源、倡导以研究为主导的技术应用为主要任务。

架构标准

为了建设各业务方遵循标准进行开发的能力，让企业架构建设有据可依，东方证券架构委员会制定了架构标准的决策流程及机制，通过架构标准去约束各系统相应开发实践，2019 年 5 月，我们通过服务治理平台接入规范的架构标准，确定了企业技术架构转型的核心框架，各系统采用统一的接口调用方式，要求系统间调用必须使用 gRPC 提供服务，系统内部可以采用 gRPC/dubbo/Spring Cloud 三种框架，支持东方证券 IT 技术架构从传统架构向微服务为核心的现代化面向服务架构全面转型。

图 30  服务治理架构决策

大中台战略

为了实现数字化转型，东方证券制定了三年架构规划，通过架构规划及落地实施，打造行业领先的 IT 架构和一流的 IT 队伍，形成公司科技发展的竞争力，架构规划中有七大重点任务，其中一项是建设强大的业务共享中台，提炼核心业务流程，为前端产品线提供业务共享能力，给前台提供强大的“炮火支援”能力，确保“厚中台，薄应用”的成功落地，。

按照证券行业的领域特点，我们将整个中台领域划分为产品、账户、财富、交易、资产、行情、资讯、日志、认证等中心，而服务治理框架也成为了整个业务中台的核心基础设施。

图 31  东方证券大中台战略

开源共享 / 行业标准

东方证券 gRPC-Nebula[9]，本身就是在站在开源 gRPC 的巨人肩膀之上发展而来，为了更好的反馈社区，2019 年 6 月中旬，东方证券宣布开源 gRPC-Nebula 服务治理框架，开源地址：https://github.com/grpc-nebula，目前社区已建设了社区决策委员会，初期拟设 7 名委员，含 1 名委员会主席，设有专人进行 GitHub 代码的跟踪、维护、解决。同时，委员会会定期组织研讨和常态化沟通、社区技术交流、协调开发力量进行社区开发、社区筹款、审议版本 maintainer 的版本和功能集、进行社区委员会选举等工作。社区将秉持金融科技创新，对外技术输出的原则，致力于成为行业内首家基于 gRPC 可治理 RPC 框架下的开源社区，并获得了 2019 年信通院 OSCAR 尖峰开源技术创新奖（基于社区开源二次开发）及第四届中国优秀云计算开源案例一等奖。

同时整个证券行业长期以来在技术架构领域没有统一标准，各家厂商都有自己相应的技术框架，从而造成了整个行业一直面对的异构化难题，gRPC-Nebula 开源也旨在为整个行业提供参考建议，同时，我们也积极加入了深交所技术产品联盟，推广 gRPC-Nebula 在行业内的使用，希望能达成行业共识，形成统一技术标准，大幅降低行业各系统间对接成本。

实践成果

从 2019 年初开始，东方证券进行服务治理框架研发工作，截止 2020.9 月，gRPC-Nebula 框架 Java 语言共迭代 14 个版本，C++ 语言共迭代 8 个版本，平台迭代了 4 个版本，较好的支撑了业务各类的需求。

同时，东方证券在内部大力推广服务治理框架及平台的使用，截止 2020.9 月，共接入各类应用 46 个，项目 99 个，服务数 369 个，方法数 3125 个，日承载各类请求量已达到数千万级。

从系统维度来看，东方证券服务治理框架已接入内部东方赢家 App、私行 App 通达信网上交易、同花顺机构版、东方睿、东方大脑、智能投顾、大营运平台、业务中台（财富、交易、产品、账户、资产、行情、资讯等）、资产配置等核心系统，从厂商维度来看，微软、恒生、金仕达、新意、顶点、通达信、同花顺等核心厂商及自研团队也已按照架构标准接入服务治理框架及平台，实践成果非常明显。

图 32 服务治理平台实践成果

总    结

本文探讨了企业架构领域的关键技术，并详细介绍了东方证券服务治理项目的建设成果与实践经验。东方证券在企业架构层面制定了大中台战略，旨在通过业务架构转型为公司科技工作的长远发展打下坚实基础。作为大中台战略的核心组成部分，服务治理项目的建设，是公司提高金融科技核心竞争力的重要突破。gRPC-Nebula 框架和星辰服务治理平台已经应用于东方证券业务中台（财富中心、交易中心、账户中心、产品中心等）、东方赢家 App、私行 App 和东方睿机构交易产品线等数十个项目，同时实现了各微服务框架 (gRPC-Nebula/dubbox/Spring Cloud) 的统一纳管，为业务线开发提供了更多的开发框架选择，随着平台生态的不断优化和发展，未来将在内部全面推广，服务于更多产品线和用户，为公司 IT 治理规范和体系化架构建设做出更多贡献。

参考文献

[1]Fowler M, Lewis J. Microservices. Viittattu, 2014, 28: 2015

[2]Fotis Aisopos, Konstantinos Tserpes, Theodora Varvarigou. Resource management in software as a service using the knapsack problem model.  International Journal of Production Economics. 2013 (2)

[3]Thones J. Microservices. Software IEEE, 2015, 32(1): 116-116

[4] 李贞昊. 微服务架构的发展与影响分析. 信息系统工程, 2017(1): 154-155

[5] https://dubbo.io/

[6] https://thrift.apache.org

[7] https://grpc.io/

[8] https://spring.io/projects/spring-cloud/

[9] https://github.com/grpc-nebula

[10]Hunt P,Konar M,Junqueira F P, et a1. ZooKeeper:Wait-free Coordination for Interact-scale Systems[C]// USENIX Annual Technical Conference. 2010, 8: 9.

[11]Sigelman, Benjamin H., et al. DApper, a Large-Scale Distributed Systems Tracing Infrastructure. Technical report, Google, 2010