微服务核心组件分析

单体服务与微服务

  1. 单体服务的线上服务稳定容易被其他功能模块影响。
  2. 单体服务在进行多个功能模块开发的时候混合进行开发、测试部署。不同功能之间容易影响。

服务拆分方式：

  1. 纵向拆分，从业务角度拆分，按照业务的关联独立程度来决定。独立功能，关联较为深的拆分微服务。
  2. 横向拆分，从公共且独立功能维度拆分。多个公共服务被调用，且依赖资源独立不与其他业务耦合。

微服务框架解决的问题

服务定义

对于单体应用来说，不同功能模块之前相互交互时，通常是以类库的方式来提供各个模块的功能。无论采用哪种通讯协议，是 HTTP 还是 RPC，服务之间的调用都通过接口描述来约定，约定内容包括接口名、接口参数以及接口返回值。

服务管理

  • 服务管理
    • 服务发现
    • 服务订阅

单体应用由于部署在同一个 WAR 包里，接口之间的调用属于进程内的调用。而拆分为微服务独立部署后，服务提供者该如何对外暴露自己的地址，服务调用者该如何查询所需要调用的服务的地址呢？这个时候你就需要一个类似登记处的地方，能够记录每个服务提供者的地址以供服务调用者查询，在微服务架构里，这个地方就是注册中心。

服务监控

通常对于一个服务，我们最关心的是 QPS（调用量）、AvgTime（平均耗时）以及 P999（99.9% 的请求性能在多少毫秒以内）这些指标。这时候你就需要一种通用的监控方案，能够覆盖业务埋点、数据收集、数据处理，最后到数据展示的全链路功能。

服务治理

拆分为微服务架构后，服务的数量变多了，依赖关系也变复杂了。比如一个服务的性能有问题时，依赖的服务都势必会受到影响。可以设定一个调用性能阈值，如果一段时间内一直超过这个值，那么依赖服务的调用可以直接返回，这就是熔断，也是服务治理最常用的手段之一。

故障定位

在单体应用拆分为微服务之后，一次用户调用可能依赖多个服务，每个服务又部署在不同的节点上，如果用户调用出现问题，你需要有一种解决方案能够将一次用户请求进行标记，并在多个依赖的服务系统中继续传递，以便串联所有路径，从而进行故障定位。

微服务框架解决方案

  • 服务管理
    • 服务注册
    • 服务订阅
  • 服务调用
    • 外部调用（网关）
    • 内部调用（ESB）
  • 服务框架
    • 开发框架
    • 远程调用
    • 交互协议
  • 服务治理
    • 配置中心
    • 熔断
    • 负载均衡
  • 服务定义
    • RESTful API（http协议）
    • XML配置（PRC协议）
    • IDL文件（跨语言服务调用）
  • 服务追踪
    • 调用链路
    • 调用记录

Spring Cloud

  • Spring CLoud Netflix
    • zuul
      • 服务路由
      • 服务过滤器
    • eureka
      • 服务注册
      • 服务发现
    • Ribbon
      • 客户端负载均衡
    • 断路器
      • 服务降级调用 Hystrix
      • 控制面板
  • spring cloud config （配置中心）
  • spring boot （开发框架）
  • Spring Cloud Alibaba
    • gateway
    • nacos
    • dubbo/springboot

Spring Cloud Netflix

  • 服务管理 Eureka
    • 服务注册
    • 服务订阅
  • 服务调用
    • 外部调用（网关） Zuul
    • 内部调用（ESB）Feign
  • 服务框架
    • 开发框架 Spring boot
    • 远程调用 Feign
    • 交互协议 Rest协议
  • 服务治理
    • 配置中心 无，可使用spring cloud config （配置中心）
    • 熔断 Hystrix工具
    • 负载均衡 Ribbon客户端负载均衡
  • 服务定义
    • RESTful API（http协议）
  • 服务追踪 SkyWaliking\ELK等框架集成
    • 调用链路
    • 调用记录

netflix

发展前景

  • Service Mesh: Service Mesh 是一种新型的用于处理服务与服务之间通信的技术，尤其适用以云原生应用形式部署的服务，能够保证服务与服务之间调用的可靠性。在实际部署时，Service Mesh 通常以轻量级的网络代理的方式跟应用的代码部署在一起，从而以应用无感知的方式实现服务治理。
  • Docker 能帮助解决服务运行环境可迁移问题的关键，就在于 Docker 镜像的使用上，实际在使用 Docker 镜像的时候往往并不是把业务代码、依赖的软件环境以及操作系统本身直接都打包成一个镜像，而是利用 Docker 镜像的分层机制，在每一层通过编写 Dockerfile 文件来逐层打包镜像。这是因为虽然不同的微服务依赖的软件环境不同，但是还是存在大大小小的相同之处，因此在打包 Docker 镜像的时候，可以分层设计、逐层复用，这样的话可以减少每一层镜像文件的大小。

参考