|服务化框架构成

最基本的服务框架

基本的服务化框架包括如下模块：统一的RPC框架，服务注册中心，管理平台。

有了这三个模块，就能实现基本的服务化。下面对三个模块进行具体分析。

RPC框架选型

为什么一定要是统一的RPC框架，而不是随便啥框架，这里主要是为了技术对齐，减少开发人员的学习成本，减少团队间沟通成本。

好，那么选择一个RPC框架，我们都需要考量什么东西呢？

这里我总结下：

代码规范：例如是对已有代码透明，还是代码生成；
通讯协议：例如是TCP还是HTTP；
序列化协议：例如是二进制还是文本，是否需要跨语言，性能；
IO模型：异步/同步，阻塞/非阻塞；
负载均衡：客户端软负载，代理模式，服务端负载。

另外如果是从开源里面选择，那么我们还需要考量：

成熟度：包括学习成本，社区热度，文档数，是否有团队维护，稳定性（盲目追求的不一定是最适合）；
可扩展性：是否有SPI支持扩展，是否支持上下兼容；
跨语言：是否支持跨语言；
性能：要想作为RPC框架，性能一般都不会太差 [滑稽脸]。

下面是常见的一些开源框架的比较，大家可以看一下。

thrift

RESTful

dubbo

gRPC

代码规范	基于Thrift的IDL生成代码	基于JAX-RS规范	无代码入侵	基于.Proto生成代码
通讯协议	TCP	HTTP	TCP	HTTP/2
序列化协议	thrift	JSON	多协议支持，默认hessian	protobuf
IO框架	Thrift自带	Servlet容器	Netty3	Netty4
负载均衡	无	无	客户端软负载	无
跨语言	多种语言	多种语言	Java	多种语言
可扩展性	一般	好	好	差

Ps：SOAP，RMI，Hessian，ICE就不列举了。

选型小结：

如果需要与前端交互的，适合短链接、跨语言的RPC框架，例如RESTful、gRPC等；
如果纯粹后台交互的，适合长链接、序列化为二进制的RPC框架，例如thrift、dubbo等更高效；
如果是小公司，新公司从头开始推广服务化框架的，可以选择规范化的RPC框架，例如thrift、RESTful、gRPC；
如果是已有大量业务代码的再推广服务框架的，那么最好选择无代码入侵的RPC框架，例如dubbo、RESTful。

注册中心选型

注册中心相当于是服务提供者和服务调用者之间的引路人，在服务治理中的作用极为重要。

选择注册中心基本要考量：

服务注册：接收注册信息的方式；
服务订阅：返回订阅信息的方式，推还是拉；
状态检测：检测服务端存活状态。

重点提一下这个状态检测，因为这个要是检测不准确会误判，导致严重后果，例如Zookeeper根据服务端注册的临时节点进行状态检测，如果服务端和Zookeeper之间的网络闪断，导致Zookeeper认为服务端已经死了，从而摘掉这个节点；但是其实客户端和服务端直接的网络是好的，这样就有可能把节点全部摘掉，导致无可用节点。

如果是从开源里面选择，那么还需要考量：

成熟度：包括学习成本，社区热度，文档数（盲目追求的不一定是最适合）；
维护成本：注册中心维护；
数据解构：是否能快速定位结果，是否能遍历；
性能和稳定性；
CAP原则：CP（关注一致性）还是AP（关注可用性）。

下面是常见的一些使用开源项目做注册中心的比较，大家可以看一下。

ZooKeeper

etcd

Consul

Eureka

一致性	强一致性paxos	强一致性Raft	强一致性Raft	弱一致性
数据结构	Tree	K/V	K/V	K/V
通讯协议	TCP	HTTP、gRPC	HTTP、DNS	HTTP
客户端	ZKClient	/	/	Eureka-client
CAP原则	CP	CP	CP	AP

Ps：Redis和MySQL没有列举。

选型小结：

规模小选择CP，RPC框架可以直接接入数据源；
规模大选择AP， RPC框架不可以直接接入数据源；
存在跨机房，跨地域的尽量不要选有强一致性协议的注册中心；
RPC框架必须要有注册中心不可用的容灾策略；
服务状态检测十分重要。

简易管理端

管理端没啥特殊要求，最起码能看到服务提供者和调用者即可。

|完善的服务化框架

如果需要一个完善的服务化框架，那么必须增加外部模块，常见的模块如下图：

接口文档管理

提供一个接口文档管理以及接口查询的入口，可以是一个公共的WIKI，也可以是独立的系统，等等。

这里可以定义接口的文档，包括接口描述，方法定义，字段定义。可以定义接口的SLA，包括支持的并发数，tp99多少，建议配置是什么。还有就是接口的负责人等一些查询的入口。

配置中心

提供一个配置管理的地方，这里说的配置主要指的是服务相关的一些配置。

配置包括分组配置、路由策略、黑白名单、降级开关、限流信息、超时时间、重试次数等等，任何可以动态变更的所有数据。

这样服务提供者和服务调用者可以不需要重启自己的应用，直接进行配置的变更。

配置中心可以独立于注册中心，也可以和注册中心合并。

监控中心

监控服务关注接口维度，实例（例如所在JVM实例）维度的数据。RPC框架可以定时上报调用次数，耗时，异常等信息。监控中心可以统计出服务质量信息，也可以进行监控报警。

分布式跟踪

区别于监控中心，以调用链的模式对服务进行。RPC框架作为分布式跟踪系统的一个天然埋点，可以很好的进行一个数据输出。

服务治理（重点）

我这边列了常见的服务治理功能，例如：

服务路由：

权重：例如机器配置高的权重高，机器配置低的权重低；
IP路由：例如某几台机器只能调某几台机器；
分组路由：例如自动根据配置调某个分组；
参数路由：例如根据方法名进行读写分类，或者根据参数走不同的节点；
机房路由：例如只走同机房，或者同机房优先。

调用授权：

应用授权：只有授权后的应用才能调这组服务
token：只有token对的调这组服务
黑白名单：只有名单允许的才能调这组服务

动态分组：

服务端切分组：可以根据分组的情况，对服务提供者进行一个动态的分组调度；
客户端切分组：可以对调用者进行一个分组调度。

调用限流：

服务端限流：服务端基于令牌桶或者漏桶模型进行限流；
客户端限流：根据客户端的标识，进行调用次数限流。

灰度部署：

灰度上线：先启动，验证后在提供服务；
预发标识：表示该服务为预发布服务；
接口测试：方便的提供接口自动化功能测试功能。

配置下发：

服务配置；
全局配置。

服务降级：

Mock：出现异常或者测试情况下，返回Mock数据；
熔断：客户端超时或者服务端超时；
拒绝服务：服务端压力大时，自动拒绝服务，保护自己。

网关

RPC框架大部分场景都是自己调用的，什么时候会需要一个网关呢？

网关可以提供如下功能：

统一的鉴权服务；
限流服务；
协议转换：外部协议转统一内部协议；
Mock：服务测试，降级等；
其它一些统一处理逻辑（例如请求解析，响应包装）。

服务注册中心Plus

需要逻辑处理能力，例如对数据进行筛选过滤整合，计算服务路由等功能

同时还需要有与RPC框架交互的功能。

管理端Plus

管理端除了之前的简单服务管理功能外，还需要提供配置信息展示，监控信息展示，各种维度的数据展示。也就是下面提到的服务治理功能，都可以在管理端进行管理。另外，常见的服务治理功能，我们都可以作为开放服务供开发人员进行一个调用。

http://mp.weixin.qq.com/s?__biz=MzIwODA4NjMwNA==&mid=2652898121&idx=1&sn=5463a399a324cd48114a85b0bc0e984f&chksm=8cdcd706bbab5e10707e1be071f24a1338e000c9e796a40f66716a205df2ac69868eea66d763&mpshare=1&scene=23&srcid=12220hyf5Y3Hp84IjQUnQsmP#rd

服务化框架技术选型