Spring Cloud 基础整理

背景

简单说，spring cloud在微服务的技术领域，不是重复造轮子，而是把当前、微服务开发比较成熟的组件，都集成到spring中，而集成的方式，采用了springboot约定大于配置的理念，使得集成的过程简单，后期使用也简单。

因为springboot借着自动装配和启动依赖两个核心，提供了开箱即用风格，可以大量减少配置。但springboot只是快速的单个微服务开发，或单体应用的开发，真正要实现微服务架构的开发，还是需要在外继续封，从而最终形成了Spring Cloud。

Spring Cloud 微服务技术的集成

Spring Cloud用Spring Boot的方式集成的微服务技术，集成得最多的就是netfix公司的各项微服务技术。包括：

• 服务发现-Eureka
• 服务调用-Feign
• 熔断器-Hystrix
• 网关-Zuul

再结合spring cloud自身的组件一起提供了微服务解决方案

• 分布式配置-spring cloud config
• 消息总线-spring cloud bus

Spring Cloud 基本应用

搭建eureka服务器

就是pom加依赖，配置信息，再加EnableEurekaServer注解即可。

由于自己就是eureka服务器，所以不需要注册到eureka服务器，更不需要从eureka服务器获取注册信息。

注意EnableEurekaServer注解。

搭建eureka客户端

同样就是pom加依赖，配置信息，再加EnableEurekaClient注解即可。

1, 引入依赖

2，用注解配置启动类

3，yml中添加配置

服务之间的相互调用

 1，需要开启服务发现。

2，调用使用feign, A 服务调用B服务，A中添加依赖

A中添加这样的接口

注解里的名字和B里面的yml配置的一样。

A中的启动类加上注意的标签

被请求的b，在spring框架整合eureka的时候，就自己做了负载均衡。

熔断

一种防止雪崩的机制。

雪崩

雪崩，就是级联失败。

出现的步骤：

• 服务提供者不可用
• 重试加大流量
• 服务调用者不可用

重试的原因包括：

• 在服务提供者不可用后, 用户由于忍受不了界面上长时间的等待,而不断刷新页面甚至提交表单.        
• 服务调用端的会存在大量服务异常后的重试逻辑. 

这些重试都会进一步加大请求流量.当服务调用者使用同步调用时, 会产生大量的等待线程占用系统资源. 一旦线程资源被耗尽,服务调用的服务也将处于不可用状态, 于是服务雪崩效应产生了.

最后, 服务调用者不可用 产生的主要原因是:同步等待造成的资源耗尽

熔断防止雪崩

防止的方式，当检测到依赖服务失败的时候，将调用转向另外一个分支，在那个分支可以友善处理失败，使得调用方不会一直等待已经失效的依赖服务，并不断累积等待所耗的资源，导致调用方也挂掉，恶性循环，出现级联失败。

实现方式就是给feign client接口写实现类，里面写这样的代码：

并且在feign client接口的FeignClient注解里，将fallback属性指向实现类。

把以下类容加入配置：

如果依赖服务的访问恢复正常，spring cloud会自动检测到恢复，不需要重启。自动。

网关ZUUL 

背景

各个微服务的端口是不一样的，客户端访问的时候，没有必要把每个端口都配一下，而且端口还要变。有了网关后，只需要维护一个网关的地址的信息，具体微服务的跳转，交给网关。

总结起来：

• 隐藏通信细节
• 解决跨越和认证

认证的时候，注意header 认证信息丢失的问题，header 认证信息需要在转发的时候，重新填上。

网关作用的简单理解：

基本应用

网关也是euraka的client，和eureka管辖下的其他微服务没有啥本质区别。需要引入以下包

在配置文件里进行zuul的网关配置，主要是路径和具体微服务的对应关系。（当然作为eureka client的配置也要加上）：

 

启动类要配置@EnableZuulProxy.

网关过滤器 

关于第一个：

关于最后一个

该过滤器类要用@Component注解。

过滤器的常见应用就是转发header信息

主要：如果要在过滤器里面验证header里的token，则需要放行以下：

防止连服务发现都实现不了。

注意options关键字。

同时对请求登录接口的请求也要放行：

搭建配置中心

项目会变得更复杂，但是后期运维成本会降低。所以将配置放在一个中心位置，便于修改和热部署。

采用spring cloud config，最后的配置是放在git中。

搭建配置中心微服务

还是引入依赖，编写配置项，加注解

注意@EnableConfigServer注解。

同时配置中心微服务仍然受eureka管辖。但是eureka的配置也可以放配置中心，由配置中心微服务去获取。

搭建配置中心服务器的客服端

引入依赖，编写配置项，即可

注意：

• bootstrap.yml的执行优先级比application.yml高，先执行。
• bootstrap存放的是系统级别的不经常变的操作，application存放的是应用级别，里面的配置容易随需求而变动。
• bootstrap.yml里，去请求uri指向的配置中心微服务，获取{label}分支上名叫 {name}-{profile}这个配置文件

Spring Cloud Bus

基于以下背景：

1，配置改了的时候，服务不会反映出配置的更改，除非重启。

2，需要配置改的时候，自动让服务来一次重新编译。

3，所以需要每个微服务监听配置的修改。

4，也需要配置中心服务器能监听到更改，并且想MQ里认出一个消息。

实际应用

pom依赖

一个是需要使用BUS，一个是需要使用MQ

最后暴露出来的总线地址是需要人工去访问的，就是人工发现了 配置中心有更新，手动访问这个总线地址，就可以把消息扔到MQ上。

也就是说，谁在配置中心改了配置，谁就给 配置中心服务器，按上述总线地址发一个请求：

其他微服务：

多引入一个用于监听的依赖。

MQ的配置和配置中心服务器的一样。

在controller上加一个@RefreshScope注解 。