为什么需要一个服务化框架
- 最开始的Demo
- 就像刚开始自己写一个
JavaWeb
应用时候,对于多个模块的功能,简单分成多个模块与后台连接使用即可
- 就像刚开始自己写一个
- 而随着需求的进一步增加,在上面三个应用中不断拓展新的功能,这就会导致应用的功能越来越复杂,同时应用之间的内聚性也变得很差。
- 这个时候,提出的一种需求就是将应用进一步进行量上的增加
- 这个时候对于系统而言,每一个应用的内聚性上是合理的,但是新的问题又出现了:对于多个应用之间可能存在着使用同样的服务,就会造成代码的重复度高
- 针对这个问题想到的就是将重用的服务单独提取出来一层:
基本的服务化框架组成
从上面不难看出一个完整的服务化框架组成应该需要的部分:
统一的RPC框架
- 对应着应用层调用服务层的框架
- 为什么使用
RPC
而不是直接使用HTTP
接口的原因:
- 首先
RPC
调用是一个长连接,对于一个规模达到一定程度的系统而言,不用再像HTTP
接口使用增加三次握手等,减少了网络的开销 - 在服务注册中心对调用者可以进行监控、下线接口、动态扩展等,不会对调用方产生影响。
- 首先
服务注册中心
- 对应服务层对服务进行注册,可以供应用层进行调用
- 管理平台
- 管理调用服务
其他需要拓展的模块
- 接口管理文档
- 在管理端显示接口详情如:输入参数、输出参数、接口性能
- 监控中心
- 监控中心用于统计出服务质量信息,在上述中与
HTTP
接口调用对比中提到可以对服务进行监控
- 监控中心用于统计出服务质量信息,在上述中与
- 分布式跟踪
- 调用链的模式对服务进行跟踪
- 网关
- 在应用层调用服务层的时候,增加的一层网关系统:
- 限流服务
- 协议转换:外部协议转统一内部协议
- 统一的鉴权服务;
- 服务测试
- 部分介绍:
https://blog.csdn.net/qq_34861102/article/details/80961447
- 在应用层调用服务层的时候,增加的一层网关系统:
- 配置中心
- 对于应用对服务的调用:
- 需要设置重试的次数和超时时间
- 分组的配置
- 限流的限制
- 路由策略和黑白名单
- 对于应用对服务的调用:
- 服务治理
- 服务路由
- 调用授权
- 动态分组
- 调用限流
- 灰度部署
- 配置下发
- 服务降级