把组织和系统横向打通，提升研发效率； 建设稳态与敏态融合的基础设施，为应用赋能； 打造大中台体系，建设共享中台及能力中心，这也是目前业界的一个趋势与方向； 把目前零散的技术架构建设成体系化的技术架构，给业务提供整体的技术支撑
https://mp.weixin.qq.com/s/uiNpvqIOQFvyospRg3lm4Q
东方证券正式开源其微服务框架gRPC-Nebula
东方证券目前在企业 IT 架构方面做了一个三年规划；
-
首先，是把组织和系统横向打通，提升研发效率；
-
第二，建设稳态与敏态融合的基础设施，为应用赋能；
-
第三，打造大中台体系，建设共享中台及能力中心，这也是目前业界的一个趋势与方向；
-
第四，把目前零散的技术架构建设成体系化的技术架构，给业务提供整体的技术支撑。
-
最后，在自研的产品线上做出比较大的突破，打造出具有业界知名度的交易产品。
目前我工作上的重心主要有以下几点：一是推进能力中心、大中台的建设；另外体系化的技术架构建设也是我工作中的核心之一，除此之外我还负责一部分自研交易产品的建设，这三大部分是我最近一段时间工作的重心。
在大中台体系建设方面，为了改变以往后台系统响应慢及各业务系统重复建设，无法快速支持产品线的敏捷迭代的问题，同时也为了沉淀核心业务知识，东方证券根据自身的业务需求和难点，规划了一些迫切需要建设的能力中心（或者叫业务中台），目前东方证券已经规划了有数十个业务中台，正在建设的主要有有行情中心、账户中心、交易接入中心、财富销售中心、推送中心、认证中心、资讯中心，后续还会建设交易汇总中心、资金存管中心、估值，资产配置等中心。
与其他金融行业相比，证券行业目前在服务治理领域面临哪些痛点与挑战？券商行业痛点都类似，就是由传统厂商组成的核心系统。比如说东方证券集中交易是金仕达架构、CRM 是顶点架构，场外是恒生架构，网上交易是同花顺、通信达架构；账户系统是新意架构；APP 是互联网 + 恒生架构，总体来说都是由各大厂商组成的异构系统。
内部新业务要对接这么多系统是非常痛苦的过程，因为 SPX、T2、Rest 等多种类型的接口形式各异，给新业务接入带来很大的困扰。同时新业务对服务有着形式各异的需求，异步 / 同步 / 流式推送等。每个传统厂商都有自己的技术架构，根据自身的业务特点来设定架构，从整体层面上不会通盘考虑企业架构所需要面对的难题。
同时内部这么多复杂的异构系统，无法从企业架构层面查看服务调用量、访问延时、错误率等信息，目前都是由各个系统建设各自运维工具来达到单个系统内的视角。从以往经验来看，券商核心系统事故往都是由流量冲击造成，不管是网关还是核心交易的流量控制目前都没有很好的手段。
自研系统也面对着很多的困惑，每个技术人员、每个项目组肯定会根据自己的技术倾向做技术选型，而业务团队本身应该更关注业务层面，但企业内部还无法提供统一的技术架构，所以必须要自己做选型，就必然关注业务本身关联不大的技术型事务，增加很多额外工作量。所以，自研业务往往也面对这样的现实情况，这也是目前问题的关键。
请樊总简单介绍下 gRPC-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 为注册中心，服务与注册中心之间保持长连接，具有心跳检测机制，能够周期性的检查服务的状态，确保服务可用性状态一致性，可处理服务进程意外终止，服务器宕机等场景。
-
服务调用负载均衡：对于多实例的服务的调用，提供对多个服务实例的负载均衡调度，实现负载按照预期的调度算法进行调度执行。
-
服务流量控制：通过设置请求数或连接数上限，动态实现对各服务接口的流控管理。
-
服务黑白名单机制：通过设置服务端实例的黑名单、白名单，动态实现请求流程的转移以及服务端实例的访问控制。
-
服务调用异常处理：当客户端调用服务实例连续多次出错时，框架会自动进行服务实例切换。
行情中心、日志中心、交易接受中心、运营平台等，7 到 8 个能力中心、产品线在应用，下一步计划内部进行大规模的推广，会使其成为内部的架构标准。
为什么东方证券要研发基于 gRPC 的开发框架，而不选用业界其他成熟方案，例如 springcloud、dubbo 等？从去年开始，我们通过跟业界主流的框架进行对比，根据企业自身的特点做出选型。
1、DubboDubbo 是由阿里开源的框架，互联网企业、券商部分也都在用，是相对比较成熟的框架，具有了很多服务治理的特性。但问题是目前社区中开始重新运作，原来是处于停滞的状态，并且开发语言仅仅体现于 JAVA 层次、跨语言特性支持的不是很好，这是目前 Dubbo 的问题。
2、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
