服务化框架技术选型实践_技术资料_物联网_中国计算网——工业互联网一站式服务平台—

还有就是接口的负责人等一些查询的入口。

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

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

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

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

监控服务关注接口维度，实例（例如所在JVM实例）维度的数据。

RPC框架可以定时上报调用次数，耗时，异常等信息。

监控中心可以统计出服务质量信息，也可以进行监控报警。

区别于监控中心，以调用链的模式对服务进行。

RPC框架作为分布式跟踪系统的一个天然埋点，可以很好的进行一个数据输出。

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

服务路由：
1. 权重：例如机器配置高的权重高，机器配置低的权重低
  IP路由：例如某几台机器只能调某几台机器
2. 分组路由：例如自动根据配置调某个分组
3. 参数路由：例如根据方法名进行读写分类，或者根据参数走不同的节点
4. 机房路由：例如只走同机房，或者同机房优先
调用授权：
1. 应用授权：只有授权后的应用才能调这组服务
2. token：只有token对的调这组服务
3. 黑白名单：只有名单允许的才能调这组服务
动态分组：
1. 服务端切分组：可以根据分组的情况，对服务提供者进行一个动态的分组调度
2. 客户端切分组：可以对调用者进行一个分组调度
调用限流：
1. 服务端限流：服务端基于令牌桶或者漏桶模型进行限流
2. 客户端限流：根据客户端的标识，进行调用次数限流
灰度部署：
1. 灰度上线：先启动，验证后在提供服务
2. 预发标识：表示该服务为预发布服务
3. 接口测试：方便的提供接口自动化功能测试功能
配置下发：
1. 服务配置
2. 全局配置
服务降级：
1. Mock：出现异常或者测试情况下，返回Mock数据
2. 熔断：客户端超时或者服务端超时
3. 拒绝服务：服务端压力大时，自动拒绝服务，保护自己

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

网关可以提供如下功能：

其它一些统一处理逻辑（例如请求解析，响应包装）

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

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

管理端除了之前的简单服务管理功能外，还需要提供配置信息展示，监控信息展示，各种维度的数据展示。

也就是下面提到的服务治理功能，都可以在管理端进行管理。

另外，常见的服务治理功能，我们都可以作为开放服务供开发人员进行一个调用。

2012年初，京东从.NET转Java。各个部门，各个业务线都没有一个统一的服务化框架，有的是dubbo，有的是WebService，有的是Hessian等等。

同时各个业务系统自己有非常多的业务代码。通过统计接口规模在1K左右，服务节点在50K左右，机器规模在8K左右，机房比较少拓扑简单。

所以当时的愿景和目标比较明确：

OK，结合我们的情况和上面的一些选型小结，我们当时的选择如下：

RPC框架：基于dubbo2.3.2做配置扩展，以及功能扩展包括rest（resteasy）、webservice（cxf）、kryo/thrift序列化、调用压缩等
注册中心：Zookeeper，RPC框架直接接入数据源
监控中心：监控服务+HBase
管理平台：读取Zookeeper做管理平台，提供基本的上下线、黑白名单等功能

于2012年4月上线，最大规模时，接口数3K，接入最大IP数20K。

随着京东业务的不断快速增长，接口、机器数也呈数量级增长。