背景
随着业务的发展及用户数的增长，对技术的要求日益提高。原有系统的基础架构已不能很好地支撑业务的诉求，制约了业务的快速创新和敏捷交付。
新基础架构的推出迫在眉睫，需满足下面几个基本诉求：
架构本身方面：高性能、稳定，App 最主要业务为股票交易，对于后台的性能和稳定性要求十分苛刻。
开发方面：框架轻快，支持 DevOps，快速打包，独立部署。
运维方面：支持高效运维，多维度立体化的监控，支持灰度发布等。
微服务架构可以较好满足上述需求，故决定自研微服务开发框架 Owl
系统介绍
自研微服务框架原因
在微服务框架选型阶段调研了当时业界使用较多的两个框架：Spring Cloud 和 Dubbo。
各自存在的不足之处如下：
1.Spring Cloud
使用基于 HTTP 的 RESTful 通信协议，性能比 RPC 低。
接口协议约定比较自由且松散。
各种管理 UI 分散且较为简陋，运维不方便。
2.Dubbo
17 年 Dubbo 处于停滞状态，下半年才重启维护。
其定位为RPC 框架，为微服务生态体系中的一个重要组件，不是一套完整的微服务解决方案，只提供少量的服务治理功能。
仅支持 Java 语言。
两个框架都不能很好满足团队的需求，所以最终决策自研微服务框架。当然也不是从零开始另造轮子，而是借鉴已有的微服务框架设计思想，引入已有的开源软件，在其上面构筑出符合业务需求的微服务框架。
架构
组件说明
配置中心 微服务配置统一管理、版本支持、配置分离，保证服务无状态。
服务中心展示服务状态，服务依赖关系，服务 API 管理，监控展示。
注册中心服务自动注册、自动发现、负载均衡、异常保护、异常通报下发、服务降级。
监控中心基于 Prometheus 协议，实现应用监控、异常上报、功能主动监控。
Owl 微服务基于?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 有以下几个优势：
多语言支持，涵盖了APP使用的开发语言；
社区活跃，生命力强；
支持 IOS、Android，支持 SSL 和自定义鉴权（支持国密），可以简单实现客户端到后台的多路复用、RPC 调用；
配套有相应的开源组件可以使用，最终可以做到全面自主掌控；
只有通信层依赖于 gRPC，所以容易替换；
TARS 与管理平台过于耦合，gRPC 只是负责通信，不与管理平台耦合，这样容易做到已有架构到 gRPC 架构的平滑迁移；
gRPC 通信组件为 Netty，Netty 是现在最流行的通信组件，而 TARS 是腾讯自己写的，腾讯如果不维护就将无法维护；
gRPC 使用 PB 协议，此协议在互联网上广泛使用，生命力强；
支持流 stream，在流的基础上实现了 Server Push，方便做变更通知，不再需要客户端做费力的 Long Pull；
微服务开发框架：
基于 JDK 1.8和 SpringBoot 的基础上进行研发，极大简化开发。具有如下功能：
采用grpc拦截器形式进行权限管理，服务接口授权；
采用令牌池方案，进行服务端并发控制；
采用阿里巴巴 TtlExecutors 线程池技术，管理业务线程，保障线程数据上下文不窜包；
? ? 把rpccontext上下文信息保存在TransmittableThreadLocal当中。在rpccontext上下文存放着负责保存通信调用结果的future。因为具体通信是采用的callExcutor异步执行的。
使用线程池技术，当服务并发量超过服务最大线程数，服务过载快速失败；
采用 opentracing 标准，进行调用链分析埋点；
采用 JDK1.8 CompletableFuture 技术超时管理、 实现高性能异步调用和实现高性能延迟返回；
采用 SpringBoot 动态配置技术，简化数据库、缓存、消息队列访问；
基于 gRPC 流模式技术，实现流模式支持，实现服务推送；
基于 TTL 技术实现跨进程上下文传递；
自研延时加载技术，实现 Slow Start 特性，避免服务启动流量直接打到服务上；
基于netty优雅下线技术以及 JDK 推出钩子技术实现架构优雅下线，避免停服务时有请求未处理完。
注册中心采用 Etcd
注册中心选型对比了 Etcd 和 Zookeeper。
Etcd 为 Zookeeper 的后起之秀，灵感来源于 Zookeeper，在实现上做了较多的改进。
接口轻量化，基于 HTTP，不依赖专有客户端。
使用更加简单的 Raft 来实现一致性。
开发及运维相对 Zookeeper 更加简单。
从技术的发展趋势来看，容器化是大势所趋，当微服务发展到一定程度时，基本都会上 Kubernetes，Kubernetes 也使用 Etcd 作为其核心组件，采用 Etcd 也可以减少后期维护成本。
最终选型了 Etcd 做为服务注册中心。
不仅仅是微服务框架
Owl 不仅仅是一个微服务框架，更是集成了开发常使用的 Java 第三方软件，方便业务开发者的开发。
无论是传统的单体开发还是现代的微服务开发，开发者往往会使用到各种第三方软件（比如 Mybatis、MQ 等），而各种软件都必须开发者做各种大同小异的集成工作或者公共代码的开发。为此 Owl?微服务框架提供了常用的第三方软件的集成，以便
减少开发者的重复工作，提高开发效率。
适配 Owl 配置中心，让其可以通过 Owl 配置中心进行统一的配置，方便运维管理。
已集成的第三方组件如下:
MyBatis
MQ（基于 RocketMQ）
本地、Redis 缓存
分库分表（基于 Sharding-JDBC）
读写分离（基于 Sharding-JDBC）
分布式锁（基于 Redis）
后续会根据业务和社区的需求，不断集成各种第三方软件，如 Elastic-Job等
迁移方案：
无侵入Agent方案设计。利用java agent的原理实现。
采用的是启动时加载方式，
