国信证券开源自研的微服务开发框架 Zebra
作者：互联网
作者 | 邓启翔，陈培新 Zebra 为国信证券自主研发的一个高性能微服务开发框架，应用于国信证券金太阳 App 各个业务的后端，已稳定运行 2 年多。
发展历程如下：
2017.10 - 2018.04：完成首版本的设计与开发。
2018.04 - 至今：应用于国信证券金太阳 App 后端；同时持续优化框架。
2019.12：发布第一个开源版本。
2019.12 - 后续：计划在国信证券内部推广使用，并持续将代码贡献到开源社区中。
1 背景
随着国信证券业务的发展及用户数的增长，对技术的要求日益提高。原有系统的基础架构已不能很好地支撑业务的诉求，制约了业务的快速创新和敏捷交付。
新基础架构的推出迫在眉睫，需满足下面几个基本诉求：
架构本身方面：高性能、稳定，券商 App 最主要业务为股票交易，对于后台的性能和稳定性要求十分苛刻。
开发方面：框架轻快，支持 DevOps，快速打包，独立部署。
运维方面：支持高效运维，多维度立体化的监控，支持灰度发布等。
微服务架构可以较好满足上述需求。
2015 年为微服务的元年，到 2017 已有两年多，在互联网有较多的应用，相关的基础组件也较为成熟，新架构采用微服务可谓水到渠成。
2 系统介绍 自研微服务框架原因
在微服务框架选型阶段调研了当时业界使用较多的两个框架：Spring Cloud 和 Dubbo。
各自存在的不足之处如下：
1.Spring Cloud
使用基于 HTTP 的 RESTful 通信协议，性能比 RPC 低。
接口协议约定比较自由且松散。
各种管理 UI 分散且较为简陋，运维不方便。
2.Dubbo
17 年 Dubbo 处于停滞状态，下半年才重启维护。
其定位为 RPC 框架，为微服务生态体系中的一个重要组件，不是一套完整的微服务解决方案，只提供少量的服务治理功能。
仅支持 Java 语言。
两个框架都不能很好满足国信证券的需求，所以最终决策自研微服务框架。当然也不是从零开始另造轮子，而是借鉴已有的微服务框架设计思想，引入已有的开源软件，在其上面构筑出符合国信证券需求的微服务框架。
架构 架构图
组件说明
| 组件 | 说明 |
|---|---|
| 配置中心 | 微服务配置统一管理、版本支持、配置分离，保证服务无状态。 |
| 服务中心 | 展示服务状态，服务依赖关系，服务 API 管理，监控展示。 |
| 注册中心 | 服务自动注册、自动发现、负载均衡、异常保护、异常通报下发、服务降级。 |
| 监控中心 | 基于 Prometheus 协议，实现应用监控、异常上报、功能主动监控。 |
| Zebra 微服务 | 基于 SpringBoot，极大地简化开发工作 微服务通信协议采用高性能的 gPRC 使用阿里巴巴的 Sentinel 做流量控制 |
| API 网关 | 通过服务中心界面配置路由，对外暴露 HTTP 端口，路由后自动转换为内部 gRPC 调用。 |
关键组件 通信协议采用 gRPC
由于性能的原因，通信协议一开始就确定使用 RPC，而非 HTTP + RESTful。
在对比了谷歌 gRPC、阿里 Dubbo 和腾讯 TARS 之后，最终确定使用 gPRC 作为底层 RPC 框架。
gRPC 由 Google 开发。使用最新的网络传输协议 HTTP2，通过使用流的单个 TCP 连接来实现低延迟和多路复用请求。与 REST over HTTP / 1.1 相比，gRPC 非常快速和灵活。
选用 gRPC，因为 gRPC 有以下几个优势：
多语言支持，涵盖了国信金太阳使用的开发语言；
社区活跃，生命力强；
支持 IOS、Android，支持 SSL 和自定义鉴权（支持国密），可以简单实现客户端到后台的多路复用、RPC 调用；配套有相应的开源组件可以使用，最终可以做到全面自主掌控；
只有通信层依赖于 gRPC，所以容易替换；
TARS 与管理平台过于耦合，gRPC 只是负责通信，不与管理平台耦合，这样容易做到已有架构到 gRPC 架构的平滑迁移；
gRPC 通信组件为 Netty，Netty 是现在最流行的通信组件，而 TARS 是腾讯自己写的，腾讯如果不维护就将无法维护；
gRPC 使用 PB 协议，此协议在互联网上广泛使用，生命力强；
支持流 stream，在流的基础上实现了 Server Push，方便做变更通知，不再需要客户端做费力的 Long Pull；
注册中心采用 Etcd
注册中心选型对比了 Etcd 和 Zookeeper。
Etcd 为 Zookeeper 的后起之秀，灵感来源于 Zookeeper，在实现上做了较多的改进。
接口轻量化，基于 HTTP，不依赖专有客户端。
使用更加简单的 Raft 来实现一致性。
开发及运维相对 Zookeeper 更加简单。
从技术的发展趋势来看，容器化是大势所趋，当微服务发展到一定程度时，基本都会上 Kubernetes，Kubernetes 也使用 Etcd 作为其核心组件，采用 Etcd 也可以减少后期维护成本。
最终选型了 Etcd 做为服务注册中心。
集中管理界面
通过服务中心将各个管理界面统一集成，方便运维操作。
不仅仅是微服务框架
Zebra 不仅仅是一个微服务框架，更是集成了开发常使用的 Java 第三方软件，方便业务开发者的开发。
无论是传统的单体开发还是现代的微服务开发，开发者往往会使用到各种第三方软件（比如 Mybatis、MQ 等），而各种软件都必须开发者做各种大同小异的集成工作或者公共代码的开发。为此 Zebra 微服务框架提供了常用的第三方软件的集成，以便减少开发者的重复工作，提高开发效率，适配 Zebra 配置中心，让其可以通过 Zebra 配置中心进行统一的配置，方便运维管理。
已集成的第三方组件如下:
MyBatis
MQ（基于 RocketMQ）
本地、Redis 缓存
分库分表（基于 Sharding-JDBC）
读写分离（基于 Sharding-JDBC）
分布式锁（基于 Redis）
后续会根据业务和社区的需求，不断集成各种第三方软件，如 Elastic-Job（计划 2020 年提供）等。
3 应用效果
Zebra 已应用于国信证券金太阳的交易、理财、资讯、业务办理和首页等业务，上线的微服务数量 30+ 个，稳定运行 2 年多。
4 开源
当前代码已开源，欢迎大家使用和贡献代码 :-)
代码地址：
https://gitee.com/gszebra/zebra
文档地址：
https://www.kancloud.cn/gszebra/zebra_doc/content
5作者介绍
邓启翔，国信证券 Zebra 微服务技术负责人，具有多年网络框架和分布式系统架构设计及研发经验，对微服务有深刻理解。曾就职于平安、汇添富基金，资深架构师。
陈培新，国信证券软件工程师，2019 年加入国信证券参与 Zebra 微服务研发。2012 至 2019 年就职于华为，先后参与电信领域 OSS 系统、编排中台的设计与研发工作。Java 资深工程师，目前专注于微服务领域的设计与开发。
标签：服务,框架,gRPC,组件,国信,Zebra,源自,研的 来源： https://blog.51cto.com/u_15127556/2716734