6 月中旬,东方证券宣布开源其基于 gRPC 框架开发的微服务框架 gRPC-Nebula。据了解,gRPC-Nebula 框架具有服务自动注册、服务发现、链路跟踪、服务治理等特性,为证券行业自身所特有的痛点提供了解决方案。InfoQ 编辑采访了东方证券首席架构师樊建,了解了 gRPC-Nebula 框架开源背后的故事与考量。
请樊总简单介绍下东方证券目前企业 IT 架构的整体规划,以及目前您的工作重心主要在哪些方面?
东方证券目前在企业 IT 架构方面做了一个三年规划;
首先,是把组织和系统横向打通,提升研发效率;
第二,建设稳态与敏态融合的基础设施,为应用赋能;
第三,打造大中台体系,建设共享中台及能力中心,这也是目前业界的一个趋势与方向;
第四,把目前零散的技术架构建设成体系化的技术架构,给业务提供整体的技术支撑。
最后,在自研的产品线上做出比较大的突破,打造出具有业界知名度的交易产品。
目前我工作上的重心主要有以下几点:一是推进能力中心、大中台的建设;另外体系化的技术架构建设也是我工作中的核心之一,除此之外我还负责一部分自研交易产品的建设,这三大部分是我最近一段时间工作的重心。
在大中台体系建设方面,为了改变以往后台系统响应慢及各业务系统重复建设,无法快速支持产品线的敏捷迭代的问题,同时也为了沉淀核心业务知识,东方证券根据自身的业务需求和难点,规划了一些迫切需要建设的能力中心(或者叫业务中台),目前东方证券已经规划了有数十个业务中台,正在建设的主要有有行情中心、账户中心、交易接入中心、财富销售中心、推送中心、认证中心、资讯中心,后续还会建设交易汇总中心、资金存管中心、估值,资产配置等中心。
与其他金融行业相比,证券行业目前在服务治理领域面临哪些痛点与挑战?
券商行业痛点都类似,就是由传统厂商组成的核心系统。比如说东方证券集中交易是金仕达架构、CRM 是顶点架构,场外是恒生架构,网上交易是同花顺、通信达架构;账户系统是新意架构;APP 是互联网 + 恒生架构,总体来说都是由各大厂商组成的异构系统。
内部新业务要对接这么多系统是非常痛苦的过程,因为 SPX、T2、Rest 等多种类型的接口形式各异,给新业务接入带来很大的困扰。同时新业务对服务有着形式各异的需求,异步 / 同步 / 流式推送等。每个传统厂商都有自己的技术架构,根据自身的业务特点来设定架构,从整体层面上不会通盘考虑企业架构所需要面对的难题。
同时内部这么多复杂的异构系统,无法从企业架构层面查看服务调用量、访问延时、错误率等信息,目前都是由各个系统建设各自运维工具来达到单个系统内的视角。从以往经验来看,券商核心系统事故往都是由流量冲击造成,不管是网关还是核心交易的流量控制目前都没有很好的手段。
自研系统也面对着很多的困惑,每个技术人员、每个项目组肯定会根据自己的技术倾向做技术选型,而业务团队本身应该更关注业务层面,但企业内部还无法提供统一的技术架构,所以必须要自己做选型,就必然关注业务本身关联不大的技术型事务,增加很多额外工作量。所以,自研业务往往也面对这样的现实情况,这也是目前问题的关键。
请樊总简单介绍下 gRPC-Nebula 微服务框架的一些基本情况。
Nebula 基于原生的 gRPC 框架做了很多服务治理的功能开发,相当于使 gRPC 从一个简单的 RPC 框架变成了微服务框架。项目从 2018 年 7 月开始建设,2019 年 1 月份一期上线,开发周期 5 个月,今年 6 月份选择开源,时间不到一年。
gRPC 本身对于研发团队是一个新的技术方向,对源代码的熟悉、与业界的交流也都是近一年才开始;另外 gRPC 框架本身并不具有微服务特性,技术框架、注册中心的选型,服务治理的特性开发也都经历了非常多的讨论和取舍;同时微服务框架对于整个券商来说也是新生事物,都会有个逐步接受的过程。
目前 gRPC-Nebula 经过了哪些迭代和升级?gRPC-Nebula 基于 gRPC 做了怎样的改进?
gRPC-Nebula 最早是基于 gRPC1.12 版本做的开发,目前开源的版本基于 1.17.2 版本,业务方面对 Nebula 也提出了很多需求,光是针对 1.12 版本就经过了 6 个版本的迭代优化。
主要有 5 大方面改进:
服务自动注册与发现:采用 zookeeper 为注册中心,服务与注册中心之间保持长连接,具有心跳检测机制,能够周期性的检查服务的状态,确保服务可用性状态一致性,可处理服务进程意外终止,服务器宕机等场景。
服务调用负载均衡:对于多实例的服务的调用,提供对多个服务实例的负载均衡调度,实现负载按照预期的调度算法进行调度执行。
服务流量控制:通过设置请求数或连接数上限,动态实现对各服务接口的流控管理。
服务黑白名单机制:通过设置服务端实例的黑名单、白名单,动态实现请求流程的转移以及服务端实例的访问控制。
服务调用异常处理:当客户端调用服务实例连续多次出错时,框架会自动进行服务实例切换。
目前 gRPC-Nebula 开发框架在东方证券内部应用情况如何?
行情中心、日志中心、交易接受中心、运营平台等,7 到 8 个能力中心、产品线在应用,下一步计划内部进行大规模的推广,会使其成为内部的架构标准。
为什么东方证券要研发基于 gRPC 的开发框架,而不选用业界其他成熟方案,例如 springcloud、dubbo 等?
从去年开始,我们通过跟业界主流的框架进行对比,根据企业自身的特点做出选型。
1、Dubbo
Dubbo 是由阿里开源的框架,互联网企业、券商部分也都在用,是相对比较成熟的框架,具有了很多服务治理的特性。但问题是目前社区中开始重新运作,原来是处于停滞的状态,并且开发语言仅仅体现于 JAVA 层次、跨语言特性支持的不是很好,这是目前 Dubbo 的问题。
2、Thrift
Thrift是 Facebook 开发的框架,目前由 Apache 基金会运作,效率也比较高,但是问题是社区不是很繁荣,另外使用门槛比较高,在使用上对开发效率会有比较明显的下降,同时也不具有良好的服务治理特性。
3、gRPC
目前 gRPC 在券商行业内已经开始进行了尝试,在互联网行业都有相对较广泛的应用,其是由 Google 开源,基于 Netty、http2 等技术的核心开源技术框架。有着许多的特性,并且社区发展很繁荣,很好的特性就是跨语言,这是 gRPC 目前的态势。但是 gRPC 也有自身存在的问题,gRPC 没有像 Dubbo 完善的服务治理功能,其只是传统的直连模式,不具备服务治理特性。
整体上与其它框架对比来说,gRPC 还是能达到目前在性能、技术层面的企业核心诉求。最终选择 gRPC 框架的核心因素主要是其解决跨语言通信的难点,目前券商行业网上交易通达信、同花顺都是 C++ 的架构,核心交易基本上也是 C++ 的架构,但是自研系统大部分是 JAVA 系统,gRPC 能有效解决 C++ 和 JAVA 之间的调用问题。
同时 gRPC 的社区相对比较繁荣,目前券商内部有不少家已经在调研 gRPC,同时 gRPC 还具有异步消息、安全特性等功能,从去年开始我们在 gRPC 框架上进行了自研工作,本质上是让 gRPC 具有服务治理特性,引入了服务注册中心,在框架层面进行了改造,实现容量控制、黑白名单、负载均衡等一系列具有服务治理特性的功能。
谈谈 gRPC-Nebula 的整体架构,与其他的一些 RPC 框架相比,优势是什么?
相对于原生 grpc 框架,gRPC-Nebula 主要是引入了注册中心,Java、C++ 嵌入了服务注册发现功能、黑白名单、链接 / 流量控制等安全方面的功能;同时开发了服务治理平台,对服务进行统一管控;结合 APM 系统,利用 kafka 进行整体调用链的信息收集,并使用 MySQL 数据库存储元数据,在治理平台上进行各类数据展示。
性能:与 Dubbo 及原生 gRPC 框架相对 ,gRPC-Nebula 性能差距不大,大概损耗 1% 到 2% 左右。
优势:跨语言,具有服务治理、微服务的特性。
为什么要将 gRPC-Nebula 开源?开源以后的迭代、维护方面有什么计划?
证券行业具有其特殊的行业属性,目前很多券商都在搞大中台战略,但其承接层面更多的是厂商的解决方案。我们希望通过开源 gRPC-Nebula 框架,让行业形成一个生态圈,这样技术厂商、业务厂商和券商一起加入,可以使得行业技术架构比较统一,提升整个行业在业务开发、技术架构层面复用的能力。同时也展示东方证券在数字化转型上的决心和态度。
我们目前成立了 gRPC-Nebula 社区,希望通过社区的运作,解决维护方面的顾虑, 同时我们建设了社区决策委员会,主要由东方证券、博云和行业专家组成,初期拟设 7 名委员,含 1 名委员会主席,设有专人进行 GitHub 代码的跟踪、维护、解决,同时委员会会定期组织研讨和常态化沟通、社区技术交流、协调开发力量进行社区开发、社区筹款、审议版本 maintainer 的版本路标和功能集、社区委员会选举等工作,最终希望通过社区的良性运转,将 gRPC-Nebula 融入整个 CNCF gRPC 的生态圈。
东方证券内部除了 gRPC-Nebula 以外,还有哪些自研的工具?
随着自研的深入,目前东方证券内部也有非常多的自研工具及产品,如异常交易、经纪业务监控、基金绩效归因等,我们会在做好充分准备工作的基础之上,逐步将跟业务属性相关不大的内部工具进行开源,努力成为金融科技开放技术领域的一个重要参与者和贡献者!
gRPC-Nebula 项目地址:
https://github.com/grpc-nebula/grpc-nebula
评论 1 条评论