Spring Cloud介绍

一、SpringCloud总体概述

 

 

 

Cloud Foundry Service Broker：通用service集成进入Cloud Foundry

 

Cluster：服务集群

 

Consul：注册中心

 

Security：安全认证

 

Stream：消息队列

 

Stream App Starters：Spring Cloud Stream Application Starters是独立的可执行应用程序，可通过Apache Kafka和RabbitMQ等消息传递中间件进行通信

 

Connectors：简化了云平台（如Cloud Foundry和Heroku）中连接服务和获取操作环境感知的过程，尤其适用于Spring应用程序

 

CLI：允许使用命令行、.yml配置文件和Groovy脚本快速自动配置和部署标准Spring Cloud服务

 

Contract：Spring Cloud Contract 为通过CDC（Customer Driven Contracts）开发基于JVM的应用提供了支持。它为TDD（测试驱动开发）提供了一种新的测试方式 - 基于接口。

 

Config：配置中心

 

Netflix：Netflix

 

Bus：消息总线

 

Cloud Foundry：云开发平台

 

Sleuth：链路追踪

 

DataFlow：针对各种数据集成和处理场景的一系列预构建流和任务/批处理启动器应用程序

 

Task：Tasks是Spring Cloud Data Flow中的一个基础项目，允许用户将几乎任何Spring Boot应用程序作为一个短期任务执行。

 

Task App Starters：Spring Cloud Task Applications可与Spring Cloud Data Flow一起使用，以创建，部署和编排短期数据微服务。

 

Starters：启动器

 

 

 

主流实现：

 

　

 

Netflix

 

阿里

 

其它

 

注册中心

 

Eureka

 

Nacos

 

Zookeeper、Consul、Etcd

 

负载均衡

 

Ribbon

 

Dubbo(未来)

 

spring-cloud-loadbalancer

 

声明式调用

 

　

 

　

 

spring-cloud-openfeign

 

服务保障（熔断器）

 

Hystrix

 

Sentinel

 

Resilience4j

 

网关

 

Zuul1

 

暂无

 

Spring Cloud Gateway

 

配置中心

 

　

 

spring-cloud-alibaba-nacos-config

 

spring-cloud-config、Apollo

 

链路追踪

 

Ribbon

 

Dubbo(未来)

 

spring-cloud-loadbalancer

 

消息队列

 

　

 

　

 

　

 

 

 

回到顶部

二、注册中心

在 Spring Cloud 中，能够使用的注册中心，还是比较多的，如下：

 

(1)spring-cloud-netflix-eureka-server和spring-cloud-netflix-eureka-client，基于 Eureka 实现。

 

(2)spring-cloud-alibaba-nacos-discovery，基于Nacos实现。

 

(3)spring-cloud-zookeeper-discovery，基于 Zookeeper 实现。

 

以上都是基于spring-cloud-commons的discovery的DiscoveryClient接口，实现统一的客户端的注册发现。

 

    注意：在分布式系统领域有个著名的CAP理论（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个）；zk看重CP，Eureka在意AP。例如：zk中有master和follower区别，当进入选举模式时，就无法正常对外提供服务。但Eureka中，集群是对等的，地位是相同的，虽不能保证一致性，但至少可以提供注册服务。

 

 

 

以Eureka为例说明注册中心：

 

作用：实现服务治理（服务注册与发现）

 

简介：Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。

 

由两个组件组成：Eureka 服务端和 Eureka 客户端。Eureka 服务端，用作服务注册中心，支持集群部署。

 

Eureka 客户端，是一个 Java 客户端，用来处理服务注册与发现。

 

在应用启动时，Eureka 客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。

 

原理图：

 

 

 

 

 

 

 

回到顶部

三、负载均衡

随着业务的发展，单台服务无法支撑访问的需要，于是搭建多个服务形成集群。那么随之要解决的是，每次请求，调用哪个服务，也就是需要进行负载均衡。

 

目前负载均衡有两种模式：

 

客户端模式

 

服务端模式

 

在 Spring Cloud 中，我们使用前者，即客户端模式。

 

以Ribbon为例：

 

作用：主要提供客户侧的软件负载均衡算法。

 

简介：Spring Cloud Ribbon 是一个基于 HTTP 和 TCP 的客户端负载均衡工具，它基于 Netflix Ribbon 实现。通过 Spring Cloud 的封装，可以让我们轻松地将面向服务的 REST 模版请求自动转换成客户端负载均衡的服务调用。

 

 

 

 

 

 

 

 

 

 

 

Ribbon 原理，整体步骤如下：

 

首先，Ribbon 会从 Eureka Client 里获取到对应的服务列表。

 

然后，Ribbon 使用负载均衡算法获得使用的服务。

 

最后，Ribbon 调用对应的服务。

 

 

 

回到顶部

四、声明式调用

在SpringCloud中，目前使用的声明式调用组件，只有spring-cloud-openfeign，基于Feign 实现（Dubbo 的 Service API 接口，也是一种声明式调用的体现）。

 

注意：Feign 并非一定要在 Spring Cloud 下使用，单独使用也是没问题的。

 

Feign使用步骤：

 

首先，如果你对某个接口定义了@FeignClient注解，Feign 就会针对这个接口创建一个动态代理。

 

接着你要是调用那个接口，本质就是会调用 Feign 创建的动态代理，这是核心中的核心。

 

Feign的动态代理会根据你在接口上的@RequestMapping等注解，来动态构造出你要请求的服务的地址。

 

最后针对这个地址，发起请求、解析响应。

 

 

 

原理图：

 

 

 

Feign 和 Ribbon 的区别：

 

Ribbon 和 Feign 都是用来调用其他服务的，不过方式不同。

 

（1）启动类用的注解不同。

 

Ribbon 使用的是@RibbonClient

 

Feign 使用的是@EnableFeignClients。

 

（2）服务的指定位置不同。

 

Ribbon 是在@RibbonClient注解上设置。

 

Feign 则是在定义声明方法的接口中用@FeignClient注解上设置。

 

（3）调使用方式不同。

 

Ribbon 需要自己构建 Http 请求，模拟 Http 请求而后用 RestTemplate 发送给其余服务，步骤相当繁琐。

 

Feign 采使用接口的方式，将需要调使用的其余服务的方法定义成声明方法就可，不需要自己构建 Http 请求。不过要注意的是声明方法的注解、方法签名要和提供服务的方法完全一致。

 

 

 

 Feign 是和 Ribbon、Eureka 整合：

 

 

 

 

 

 首先，用户调用 Feign 创建的动态代理。

 

然后，Feign 调用 Ribbon 发起调用流程。

 

首先，Ribbon 会从 Eureka Client 里获取到对应的服务列表。

 

然后，Ribbon 使用负载均衡算法获得使用的服务。

 

最后，Ribbon 调用对应的服务，（最后，Ribbon 调用 Feign ）而 Feign 调用 HTTP 库最终调用使用的服务。

 

回到顶部

五、服务保障

在 Spring Cloud 中，能够使用的服务保证，如下：

 

spring-cloud-netflix-hystrix，基于 Hystrix 实现。

 

Resilience4j

 

spring-cloud-alibaba-sentinel，基于 Sentinel 实现。

 

为什么要使用服务保障

 

在微服务架构中，我们将业务拆分成一个个的服务，服务与服务之间可以相互调用（RPC）。为了保证其高可用，单个服务又必须集群部署。由于网络原因或者自身的原因，服务并不能保证服务的 100% 可用，如果单个服务出现问题，调用这个服务就会出现网络延迟，此时若有大量的网络涌入，会形成任务累积，导致服务瘫痪，甚至导致服务“雪崩”。为了解决这个问题，就出现断路器模型。

 

 

 

 

 

 通过 HystrixCircuitBreaker 实现。

 

HystrixCircuitBreaker 有三种状态 ：

 

(1)CLOSED：关闭 (2)OPEN：打开 (3)HALF_OPEN：半开

 

HystrixCircuitBreaker 状态变迁如下图 ：

 

 

 

 

 

 

 

红线 ：初始时，断路器处于 CLOSED 状态，链路处于健康状态。当满足如下条件，断路器从 CLOSED 变成 OPEN 状态：周期( 可配，HystrixCommandProperties.default_metricsRollingStatisticalWindow = 10000 ms )内，总请求数超过一定量( 可配，HystrixCommandProperties.circuitBreakerRequestVolumeThreshold = 20 ) 。

 

错误请求占总请求数超过一定比例( 可配，HystrixCommandProperties.circuitBreakerErrorThresholdPercentage = 50% ) 。

 

绿线 ：断路器处于 OPEN 状态，命令执行时，若当前时间超过断路器开启时间一定时间( HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds = 5000 ms )，断路器变成 HALF_OPEN 状态，尝试调用正常逻辑，根据执行是否成功，打开或关闭熔断器【蓝线】。

 

 

 

以Hystrix为例：

 

作用：断路器，保护系统，控制故障范围。

 

简介：Hystrix 是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的故障时，停止级联故障并在复杂的分布式系统中实现弹性。

 

Hystrix 原理，整体如下图：

 

 

 

 

 

 

 

回到顶部

六、网关服务

在 Spring Cloud 中，能够使用的网关服务，主要是两个，如下：

 

spring-cloud-netflix-zuul ，基于 Zuul1 实现。

 

Netflix 最新开源的网关服务是 Zuul2 ，基于响应式的网关服务。

 

spring-cloud-gateway，基于 Spring Webflux 实现。

 

网关服务，可以实现的功能：

 

动态路由

 

灰度发布

 

健康检查

 

限流

 

熔断

 

认证: 如数支持 HMAC, JWT, Basic, OAuth 2.0 等常用协议

 

鉴权: 权限控制，IP 黑白名单，同样是 OpenResty 的特性

 

可用性

 

高性能

 

作用：API 网关，路由，负载均衡等多种作用