一个完整的服务化框架

为什么需要一个服务化框架

• 最开始的Demo
  
  • 就像刚开始自己写一个JavaWeb应用时候，对于多个模块的功能，简单分成多个模块与后台连接使用即可
    
• 而随着需求的进一步增加，在上面三个应用中不断拓展新的功能，这就会导致应用的功能越来越复杂，同时应用之间的内聚性也变得很差。
• 这个时候，提出的一种需求就是将应用进一步进行量上的增加
  
• 这个时候对于系统而言，每一个应用的内聚性上是合理的，但是新的问题又出现了：对于多个应用之间可能存在着使用同样的服务，就会造成代码的重复度高
• 针对这个问题想到的就是将重用的服务单独提取出来一层：
  

---

基本的服务化框架组成

从上面不难看出一个完整的服务化框架组成应该需要的部分：

• 统一的RPC框架

  • 对应着应用层调用服务层的框架
  • 为什么使用RPC而不是直接使用HTTP接口的原因：
    
    • 首先RPC调用是一个长连接，对于一个规模达到一定程度的系统而言，不用再像HTTP接口使用增加三次握手等，减少了网络的开销
    • 在服务注册中心对调用者可以进行监控、下线接口、动态扩展等，不会对调用方产生影响。

• 服务注册中心

  • 对应服务层对服务进行注册，可以供应用层进行调用
• 管理平台
  
  • 管理调用服务

---

其他需要拓展的模块

• 接口管理文档
  
  • 在管理端显示接口详情如：输入参数、输出参数、接口性能
• 监控中心
  
  • 监控中心用于统计出服务质量信息，在上述中与HTTP接口调用对比中提到可以对服务进行监控
• 分布式跟踪
  
  • 调用链的模式对服务进行跟踪
• 网关
  
  • 在应用层调用服务层的时候，增加的一层网关系统：
    
    • 限流服务
    • 协议转换：外部协议转统一内部协议
    • 统一的鉴权服务；
    • 服务测试
    • 部分介绍：
      https://blog.csdn.net/qq_34861102/article/details/80961447
• 配置中心
  
  • 对于应用对服务的调用：
    
    • 需要设置重试的次数和超时时间
    • 分组的配置
    • 限流的限制
    • 路由策略和黑白名单
• 服务治理
  
  • 服务路由
  • 调用授权
  • 动态分组
  • 调用限流
  • 灰度部署
  • 配置下发
  • 服务降级