SpringCloud总结

SpringCloud核心思想

SpringCloud是一套基于Springboot框架的微服务解决方案，它融合了市面上较好的微服务中间件或者集成框架进来，从而简化了代码开发

Spring Cloud 包含了微服务架构的方方面面。
约定优于配置，基于注解，没有配置文件。
轻量级组件，Spring Cloud 整合的组件大多比较轻量级，且都是各自领域的佼佼者。
开发简便，Spring Cloud 对各个组件进行了大量的封装，从而简化了开发。
开发灵活，Spring Cloud 的组件都是解耦的，开发人员可以灵活按需选择组件。

SpringCloud五大常用组件

服务发现 - Netflix Eureka

Eureka的主要功能是实现服务治理与发现，由两个组件组成：Eureka服务端和Eureka客户端
Eureka服务端用作服务注册中心。支持集群部署。
Eureka客户端是一个java客户端，用来处理服务注册与发现。
在应用启动时，Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。

Eureka 组件

Eureka是Netflix开发的服务发现框架，本身是一个基于REST的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。

1、Eureka Server

Eureka Server提供服务注册服务，各节点启动后，会在eureka server中注册自己的信息，Eureka Server 内部有二层缓存机制来维护整个注册表，Eureka Server会提供注册表，当客服端发现自己本地没有缓存注册表就会从eureka server获取最新的注册表，同时，客户端通过注册、心跳机制和 Eureka Server 同步当前客户端的状态

2、Eureka Client

Eureka Client是一个java客户端，它的内部具备一个使用轮询负载算法的负载均衡器。在应用启动后，客户端会向server端发送心跳，默认间隔是30秒，如果server在多个心跳周期内没有接收到某个服务的心跳，server就会从服务注册表将这个服务节点移除，默认是90秒，同时，client会从server拉取，更新，缓存服务注册表，因此当所有的 Eureka Server 节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者，但是当服务有更改的时候会出现信息不一致。

服务注册

当Eureka客户端向Eureka Server注册时，它提供自身的元数据，比如IP地址、端口，运行状况指示符URL，主页等，并且只有当项目刚启动时才会向erueka注册，所以在这样的机制下erueka提供了自我服务保护机制，如果在erueka客服端和服务都是正常的情况下，出现网络通讯等问题，服务端剔除了客户端，当恢复正常是，客户端不会再次注册。

erueka自我保护机制

自我保护工作机制：如果 Eureka Server 在 15 分钟内有超过 85% 的 Eureka Client 都没有正常的发送心跳过来（单机模式时 尤为明显），那么 Eureka Server 就认为注册中心与客户端出现了网络故障，Eureka Server 自动进入自我保护机制。

如何开启与关闭自我保护：
Eureka Server 自我保护模式默认已经开启，如果需要关闭，则在 Eureka Server 端的全局配置文件可以使用如下属性：

eureka:
  server:
      enable-self-preservation: false #关闭自我保护机制，实际生产环境时建议不要关闭
      eviction-interval-timer-in-ms: 5000 #扫描服务间隔
1
2
3
4

自我保护机制的触发条件

当每分钟心跳次数( renewsLastMin ) 小于 numberOfRenewsPerMinThreshold 时
并且开启自动保护模式开关( eureka.server.enable-self-preservation = true ) 时
触发自我保护机制，不再自动过期租约
numberOfRenewsPerMinThreshold = expectedNumberOfRenewsPerMin * 续租百分比( eureka.server.renewalPercentThreshold, 默认0.85 )
expectedNumberOfRenewsPerMin = 当前注册的应用实例数 x 2

为什么乘以 2：
默认情况下，注册的应用实例每半分钟续租一次，那么一分钟心跳两次，因此 x 2 。
服务实例数：10个，期望每分钟续约数：10 * 2=20，期望阈值：20*0.85=17，自我保护在注册的应用实例少于17时触发。

服务续约

Eureka客户会每隔30秒发送一次心跳来续约。 通过续约来告知Eureka Server该Eureka客户仍然存在，没有出现问题。 正常情况下，如果Eureka Server在90秒没有收到Eureka客户的续约，它会将实例从其注册表中删除。 建议不要更改续约间隔

服务下线

Eureka客户端在程序关闭时向Eureka服务器发送取消请求。 发送请求后，该客户端实例信息将从服务器的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容：
DiscoveryManager.getInstance().shutdownComponent()

获取注册列表信息

Eureka客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与Eureka客户端的缓存信息不同， Eureka客户端自动处理。如果由于某种原因导致注册列表信息不能及时匹配，Eureka客户端则会重新获取整个注册表信息。 Eureka服务器缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka客户端和Eureka 服务器可以使用JSON / XML格式进行通讯。在默认的情况下Eureka客户端使用压缩JSON格式来获取注册列表的信息

服务剔除

在默认的情况下，当Eureka客户端连续90秒没有向Eureka服务器发送服务续约，即心跳，Eureka服务器会将该服务实例从服务注册列表删除，即服务剔除

负载均衡 - Netflix Ribbon / Feign

Ribbon

Ribbon的基本用法是注入一个RestTemplate，并使用@LoadBalanced注解标注RestTemplate，从而使RestTemplate具备负载均衡的能力。

RestTemplate在发送请求的时候会被ClientHttpRequestInterceptor拦截，LoadBalancerInterceptor是ClientHttpRequestInterceptor的实现类，它的作用就是用于RestTemplate的负载均衡，LoadBalancerInterceptor将负载均衡的核心逻辑交给了loadBalancer

@LoadBalanced注解是属于Spring，而不是Ribbon的，Spring在初始化容器的时候，如果检测到Bean被@LoadBalanced注解，Spring会为其设置LoadBalancerInterceptor的拦截器。

当RestTemplate发起一个请求，请求就会被LoadBalancerInterceptor拦截，实际由loadBalancer发起

@Override
public ClientHttpResponse intercept(final HttpRequest request, final byte[] body,
      final ClientHttpRequestExecution execution) throws IOException {
   final URI originalUri = request.getURI();
   String serviceName = originalUri.getHost();
   Assert.state(serviceName != null, "Request URI does not contain a valid hostname: " + originalUri);
   return this.loadBalancer.execute(serviceName, requestFactory.createRequest(request, body, execution));
}

1
2
3
4
5
6
7
8
9

Feign

使用过ribbon的可能都会有一个想法就是它远程调用特别繁琐，步骤多，而feign其实就是在ribbon基础上进行了一次改进，是一个使用起来更加方便的 HTTP 客户端。

feign采用接口的方式， 只需要创建一个接口，然后在上面添加注解即可 ，将需要调用的其他服务的方法定义成抽象方法即可， 不需要自己构建http请求，然后就像是调用自身工程的方法调用，而感觉不到是调用远程方法，使得编写 客户端变得非常容易。

断路器 - Netflix Hystrix

Hystrix是一个容错组件，实现了超时机制和断路器模式，hystrix提供了熔断和降级。

为什么需要断路器
在分布式架构中，一个应用依赖多个服务是非常常见的，如果其中一个依赖由于延迟过高发生阻塞，调用该依赖服务的线程就会阻塞，如果相关业务的QPS较高，就可能产生大量阻塞，从而导致该应用/服务由于服务器资源被耗尽而拖垮。
另外，故障也会在应用之间传递，如果故障服务的上游依赖较多，可能会引起服务的雪崩效应。就跟数据瘫痪，会引起依赖该数据库的应用瘫痪是一样的道理。
每个请求都占用了系统的CPU、内存、网络等资源，如果该应用的QPS较高，那么该应用所以的服务资源会被快速消耗完毕，直至应用死掉。如果这个出问题的依赖（Dependency I），不止这一个应用，亦或是受影响的应用上层也有更多的依赖，那就会带来我们前面所提到的服务雪崩效应。 所以，为了应对以上问题，就需要有支持服务隔离、熔断等操作的工具。

Hystrix 如何解决级联故障/防止服务雪崩：
1、Hystrix将请求的逻辑进行封装，相关逻辑会在独立的线程中执行
2、Hystrix有自动超时策略，如果外部请求超过阈值，Hystrix会以超时来处理
3、Hystrix会为每个依赖维护一个线程池，当线程满载，不会进行线程排队，会直接终止操作
4、Hystrix有熔断机制： 在依赖服务失效比例超过阈值时，手动或者自动地切断服务一段时间 。

Ribbon + Hystrix：

@Service
public class TestService {

    @Autowired
    private RestTemplate restTemplate;

	//通过注解指定对应方法
    @HystrixCommand(fallbackMethod = "indexError")
    public Object index() {
 		return restTemplate.getForObject("http://testservice", String.class);
    }

    public Object plus(int numA, int numB) {
        String url = String.format("http://testservice/plus?numA=%s&numB=%s", numA, numB);
 		return restTemplate.getForObject(url, String.class);
    }

    public Object indexError() {
 		return "{\"code\": 999,\"message\": \"服务断路\"}";
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Feign + Hystrix：
一种是直接指定对应的回滚类
@FeignClient(value = “testservice”, fallback = TestServiceHystrix.class)

一种是指定工厂

@Component
public class TestFeignFallbackFactory implements FallbackFactory<TestFeign> {
	@Override
	public TestFeign create(Throwable throwable) {
		TestFeignFallbackImpl testFeignFallback = new TestFeignFallbackImpl();
		testFeignFallback .setCause(throwable);
		return testFeignFallback ;
	}
}

1
2
3
4
5
6
7
8
9
10

服务网关 - Netflix Zuul / Gateway

Zuul

简介

zuul是微服务网关，也是一个微服务，所以同样需要注册到注册中心。整个体系中网关都是最靠前列的，所有的门户请求第一个都是经过网关，然后通过网关进行路由，访问到对应的服务节点。
网关本身并不是必要的，当微服务量级很高的时候或者对于服务管理有搞要求是推荐使用。

作用

1、统一入口：为全部微服务提供一个唯一的入口，网关起到外部和内部隔离的作用，保障了后台服务的安全性
2、鉴权校验：识别每个请求的权限，拒绝不符合要求的请求
3、动态路由：动态的将请求路由到不同的后端集群中
4、减少客户端与服务端的耦合：服务可以独立发展，通过网关层来做映射

使用

@EnableZuulProxy
这个注解会在Eureka注册中心中注册当前服务。并发现其他的服务
网关配置方式有多种，默认、URL、服务名称、排除|忽略、前缀。网关配置没有优劣好坏，应该在不同的情况下选择合适的配置方案

Zuul本身大部分功能是由过滤器组成的，可以用来过滤代理请求，包括提供额外功能逻辑。如：权限验证，日志记录等
Zuul 提供的过滤器是一个父类。父类是 ZuulFilter。通过父类中定义的抽象方法 filterType，来决定当前的 Filter 种类是什么。有前置过滤、路由后过滤、后置过滤、异常过滤

前置过滤：是请求进入 Zuul 之后，立刻执行的过滤逻辑
路由后过滤：是请求进入 Zuul 之后，并 Zuul 实现了请求路由后执行的过滤逻辑，路由后过滤，是在远程服务调用之前过滤的逻辑
后置过滤：远程服务调用结束后执行的过滤逻辑
异常过滤：是任意一个过滤器发生异常或远程服务调用无结果反馈的时候执行的过滤逻辑。无结果反馈，就是远程服务调用超时

在 springcloud 中，Zuul 启动器中包含了 Hystrix 相关依赖，在 Zuul 网关工程中，默认是提供了 Hystrix Dashboard 服务监控数据的，但是不会提供监控面板的界面展示。可以说，在 springcloud 中，zuul 和 Hystrix 是无缝结合的

Zuul同样支持全局限流和局部限流等功能
使用全局限流配置，zuul 会对代理的所有服务提供限流保护
使用局部限流配置，zuul 仅针对配置的服务提供限流保护

重点：zuul已经停止维护了，所以SpringCloud重新孵化出了替代品Gateway

Gateway

简介

Spring Cloud Gateway 是Spring Cloud的一个全新的API网关项目，目的是为了替换掉Zuul1，它基于Spring5.0 + SpringBoot2.0 + WebFlux（基于性能的Reactor模式响应式通信框架Netty，异步阻塞模型）等技术开发，性能于Zuul，官方测试，Spring Cloud GateWay是Zuul的1.6倍 ，旨在为微服务架构提供种简单有效的统的API路由管理式。
同时可以与Spring Cloud Discovery Client（如Eureka）、Ribbon、Hystrix等组件配合使用，实现路由转发、负载均衡、熔断、鉴权、路径重写、志监控等
Gateway还内置了限流过滤器，实现了限流的功能。
设计优雅，容易拓展

分布式配置 - Spring Cloud Config

简介

SpringCloud Config 是一个解决分布式系统配置管理的方案。它主要分为server和client两个部分，server提供配置文件的存储和接口，client 端通过接口获取数据、并依据此数据初始化自己的应用。
目前 springcloud config 的使用主要是通过 git/svn 方式做一个配置中心，然后每个服务从其中获取自身配置所需的参数

springcloud config 支持本地参数配置的获取。
spring.profiles.active=native：表示从本地读取配置
spring.cloud.config.server.native.searchLocations = file:D:/xxx :读取指定的配置文件