如何设计一个完善可用的服务框架

上一篇博客整理了一些关于服务框架基础知识的内容，这篇博客，从实际的生产需要出发，谈谈一个完善可用的服务框架，需要包含哪些功能。。。

PS：部分内容参考自《京东基础架构建设之路》

一个完善可用的RPC服务框架，需要包含以下几点：

框架组成	具体功能说明
服务注册中心	服务框架基础知识
管理端	接口管理+配置中心
统一的RPC框架	监控中心+分布式追踪+服务治理+网关

 

管理端

1、接口管理

提供统一的接口管理和查询入口，比如公共wiki或者类似swagger之类的系统。

功能：定义接口，包括接口描述、方法定义、字段定义甚至接口支持的最大并发数等信息。

2、配置中心

提供统一的配置管理，这里主要指服务端的一些相关配置。

功能：分组配置、路由策略、黑白名单、降级限流开关、timeout、重试次数可动态变化的参数。

优点：服务提供者和调用者不需重启服务即可进行配置的变更。

例子：携程开源的Apollo配置管理中心，或阿里开源的Nacos，目前在业内被多家互联网及银行金融类企业采用。

 

RPC框架

一、监控中心

1、监控服务主要关注接口维度和工程实例维度的数据，比如：JVM、内存、CPU、I/O等；

2、通过定时任务，上报不同接口的调用次数、耗时、异常信息以及相关服务的新建连接数、最大连接数、吞吐量等信息；

3、通过可视化等方式，实时展示相关服务的状态，健康检查、监控预警等；

 

二、分布式追踪

与监控中心有所区别的是，全链路追踪主要是以调用链的模式对服务进行调用关系的跟踪和分析，一般通过埋点、agent探针等方式进行追踪的数据输出；

例子：全链路工具Skywalking，就是一个开源的调用链模式的追踪分析工具，UI图如下：

更多参考：Skywalking分布式追踪系统

 

三、服务治理

1、服务路由

权重：机器配置高的权重高，配置低的权重低；还有根据服务的重要程度分配权重等；

IP路由：比如某些特定地址的机器只能访问配置的几台特定机器；

参数路由：比如根据方法名进行读写分类，或根据参数不同访问不同的节点；

2、调用授权

应用授权：只有授权后的应用才可以调用某一组服务；

token：只有token校验通过才可以调用对应的服务；

黑白名单：黑名单用户无法访问某些服务，白名单用户可以不用鉴权既可访问服务；

3、调用限流

服务端限流：服务端根据漏斗模型或者服务的最大处理能力进行限流措施，设置初始值以及根据访问流量变化，同等步长递增，最大访问量为某个安全阈值即可；

客户端限流：根据客户端身份标识，比如不同会员等级，进行调用次数及是否优先提供服务的限流；

4、上线发布

灰度发布：一种平滑的上线发布方式，再次基础上可以进行A/B测试。

蓝绿发布：V1 版本称为蓝组，V2 版本称为绿组，发布时通过 LB 一次性将流量从蓝组直接切换到绿组。特点是全量切换，升级切换和回退速度快。

更多关于发布上线模式的内容，可参考这里：灰度发布、滚动发布、蓝绿发布到底有什么区别？

5、限流降级

Mock：当服务不可用、异常等情况下返回配置好的数据，一般在测试场景使用率较高。

限流：通过在网关入口设定最大访问阈值等方式，控制流入系统服务的请求，保证服务的正常可用。

降级：根据分配的服务权重，在系统压力超过一定阈值时降低权重较低的服务权重，保证核心重要服务的可用性。

熔断：设定timeout参数，当流入数据超过设定阈值，使其超时，重置连接，保证服务的可用性。

 

四、网关

网关为业务的接入层，RPC框架大部分情况下是内部调用，而网关可以提供以下功能：

统一的鉴权服务；

限流服务；

协议转换：将外部访问的请求协议转换为内部统一的可处理的协议；

Mock：为测试提供服务、降级处理等；

其他：比如请求内容解析、请求封装；

 

PS：服务框架属于基础架构范畴的中间件技术，需要保持适度的前瞻性；结合自己的现状以及未来几年的发展规划，进行技术选型，最好的是最适合自己的！

 

以为即为完善可用的服务框架相关知识，具体实践请自行探索或参考其他资料。。。