东方证券：我们如何成功实施微服务

作者丨樊建、舒逸技术琐话 2022-10-08 08:33

微服务架构是近几年受到各行业广泛追捧的技术之一，微服务架构具有轻型化、便捷化、敏捷化等特点，不仅能够适应业务创新和变化的需要，而且易于维护、变更、升级，契合当前证券业务发展的需要。然而向微服务架构转型也面临不少挑战，东方证券通过构建统一的服务治理框架，打造了一个多语言、多协议、可视化、灵活配置的服务管理平台，支持东方证券企业技术架构向以微服务为核心的现代化架构转型。本文将介绍东方证券 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）实时感知服务状态。注册中心与服务建立长连接，通过心跳检测机制，能够周期性地检测服务的健康状态，当服务进程意外终止或服务器宕机时，注册中心能够立刻向服务消费者推送服务下线的通知，实现故障隔离。