10、Spring Cloud学习笔记

架构演进
集中式架构 --> 垂直拆分 --> 分布式服务–> SOA面向服务架构 --> 微服务架构

SOA：Service Oriented Architecture(面向服务的架构)，使用了ESB组件，ESB自身实现复杂；应用服务粒度较大，所有服务之间的通信都经过ESB会降低通信速度；部署、测试ESB比较麻烦。

微服务架构基于SOA思想，可以把微服务当做去除了ESB的SOA。与使用ESB的SOA架构相比，微服务架构没有使用ESB，有服务治理注册中心且业务粒度小。

微服务架构特点：
单一职责
服务粒度小
面向服务（对外暴露REST api）
服务之间相互独立

服务间的远程调用有两种方式
RPC：基于socket，速度快，效率高。如webservice、dubbo
Http：基于TCP，封装比较臃肿；对服务和调用方没有任何技术、语言的限定，自由灵活。如RESTful，Spring Cloud

有三种http客户端工具类包都可以方便的进行http服务调用
httpClient
okHttp
JDK原生的URLConnection

spring 提供了RestTemplate的工具类对上述的3种http客户端工具类进行了封装（默认使用URLConnection），可在spring项目中使用RestTemplate进行服务调用。

分布式服务必然要面临如下问题：（SpringCloud可以解决这些问题）
服务管理
如何自动注册和发现
如何实现状态监管
如何实现动态路由
服务如何实现负载均衡
服务如何解决容灾问题
服务如何实现统一配置










Eureka负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。同时，服务提供方与Eureka之间通过“心跳”机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服务列表中剔除。这就实现了服务的自动注册、发现、状态监控。

Eureka是服务注册中心，只服务注册；自身并不提供服务也不消费服务。可以搭建web工程使用Eureka，可以使用Spring Boot方式搭建。

EurekaServer可以部署成一个集群，形成高可用的Eureka中心。多个Eureka Server之间会互相注册为服务，当服务提供者注册到Eureka Server集群中的某个节点时，该节点会把服务的信息同步给集群中的每个节点，从而实现数据同步。因此，无论客户端访问到Eureka Server集群中的任意一个节点，都可以获取到完整的服务列表信息。

服务提供者要向EurekaServer注册服务，并且完成服务续约等工作。服务提供者在启动时，会检测配置属性中的： eureka.client.register-with-erueka=true 参数是否正确，事实上默认就是true。如果值确实为true，则会向EurekaServer发起一个Rest请求，并携带自己的元数据信息，Eureka Server会把这些信息保存到一个双层Map结构中。
第一层Map的Key就是服务id，一般是配置中的 spring.application.name 属性
第二层Map的key是服务的实例id。一般host+ serviceId + port，例如： localhost:user-service:8081
值则是服务的实例对象，也就是说一个服务，可以同时启动多个不同实例，形成集群。默认注册时值使用的是主机名或者localhost，如果想用ip进行注册，可以在 服务提供者配置文件中添加eureka.instance.prefer-ip-address和eureka.instance.prefer-ip-address配置。

在注册服务完成以后，服务提供者会维持一个心跳（定时向EurekaServer发起Rest请求），称为服务的续约（renew）。有两个重要参数可以修改服务续约的行为；可以在 服务提供者配置文件中配置lease-expiration-duration-in-seconds和lease-renewal-interval-in-seconds
eureka.instance.lease-renewal-interval-in-seconds：服务续约(renew)的间隔，默认为30秒
eureka.instance.lease-expiration-duration-in-seconds：服务失效时间，默认值90秒

当服务消费者启动时，会检测 eureka.client.fetch-registry=true 参数的值，如果为true，则会从Eureka Server服务的列表拉取只读备份，然后缓存在本地。并且每隔30秒会重新拉取并更新数据。可以在服务消费者配置文件中配置eureka.client.registry-fetch-interval-seconds惨树修改间隔时间。

在Eureka Server服务端可以配置失效剔除和自我保护：
eureka.server.enable-self-preservation配置成false可以关闭自我保护
eureka.server.eviction-interval-timer-in-ms可以配置服务剔除时间










Ribbon是Netflix开发的负载均衡器，提供了轮询、随机两种负载均衡算法（默认是轮询），可以实现从地址列表中使用负载均衡算法获取地址进行服务调用。
负载均衡Ribbon是不支持下划线，所以提供服务的微服务名称不要包含下划线。
Eureka中已经集成了Ribbon，我们无需引入关于Ribbon的新依赖。










Hystrix 是在微服务系统中提供保护机制的组件，和Eureka、Ribbon一样也是由netflflix公司开发。是开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。

在微服务中，服务间调用关系错综复杂，一个请求可能需要调用多个微服务接口才能实现，形成非常复杂的调用链路。如果某个微服务出现异常，请求就会被阻塞，用户请求不会得到响应，导致tomcat的这个线程不会释放，越来越多的用户请求到来，导致越来越多的线程会阻塞。服务器支持的线程和并发数有限，如果请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。

Hystrix解决雪崩问题的手段
线程隔离：用户请求不直接访问服务，而是使用线程池中空闲的线程访问服务，加速失败判断时间。
服务降级：及时返回服务调用失败的结果，让线程不因为等待服务而阻塞。

因为@SpringBootApplication、@EnableDiscoveryClient、@EnableCircuitBreaker三个注解经常使用，所以有@SpringCloudApplication注解直接替代他们。

在服务熔断中，使用的熔断器，也叫断路器，其英文单词为：Circuit Breaker。在分布式系统中应用服务熔断后，服务调用方可以自己进行判断哪些服务反应慢或存在大量超时，可以针对这些服务进行主动熔断，防止整个系统被拖垮。Hystrix的服务熔断机制，可以实现弹性容错，当服务请求情况好转之后，可以自动重连。通过断路的方式，将后续请求直接拒绝，一段时间（默认5秒）之后允许部分请求通过，如果调用成功则回到断路器关闭状态，否则继续打开，拒绝请求的服务。
Hystrix的熔断状态机模型如下：











Feign中文翻译为伪装，可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样。不用再自己拼接url和参数等操作，一切都可以交给Feign去做。Feign会自动根据参数拼接http请求地址。

使用FeignClient的时候，如果参数中带有@PathVariable形式的参数，则要用value=""标明对应的参数,否则会抛出IllegalStateException异常。

负载均衡、服务熔断、请求压缩、日志级别都可以通过配置项在Feign中开启使用。

Feign中本身已经集成了Ribbon依赖和自动配置，因此不需要额外引入依赖，也不需要再注册RestTemplate对象。

Feign默认也集成了Hystrix，默认情况下是关闭的，需要开启。

Feign 支持对请求和响应进行GZIP压缩，以减少通信过程中的性能损耗。










Spring Cloud Gateway是Spring官网基于Spring 5.0、 Spring Boot 2.0、Project Reactor等技术开发的网关服务。其基本功能：安全、监控／埋点、限流等。为微服务架构提供了简单、有效且统一的API路由管理方式。是替代Netflflix Zuul的一套解决方案。

Spring Cloud Gateway组件的核心是一系列的过滤器，通过这些过滤器可以将客户端发送的请求转发（路由）到对应的微服务，是加在整个微服务最前沿的防火墙和代理器，隐藏微服务结点IP端口信息，从而加强安全保护。其核心功能是：过滤和路由

Spring Cloud Gateway本身也是一个微服务，需要注册到Eureka服务注册中心。

不管是来自于客户端（PC或移动端）的请求，还是服务内部调用，一切对服务的请求都可经过网关，然后再由网关来实现 鉴权、动态路由等等操作。

在配置文件中加入如下配置

spring:
    cloud:
        gateway:
            routes:
                - id: user-service-route
                  uri: lb://user-service        //lb表示从eureka中获取具体服务
                  predicates:
                    - Path=/user/**

将路径中包含有 /user/** 开头的请求，代理到http://127.0.0.1:9091

Gateway作为网关的其中一个重要功能，就是实现请求的鉴权。而这个动作往往是通过网关提供的过滤器来实现的。Gateway自带过滤器有几十个，常见的如下：

Gateway实现方式上，有两种过滤器；
局部过滤器：通过 spring.cloud.gateway.routes.filters 配置在具体路由下，只作用在当前路由上；自带的过滤器都可以配置或者自定义按照自带过滤器的方式。如果配 置spring.cloud.gateway.default-filters 上会对所有路由生效也算是全局的过滤器；但是这些过滤器的实现上都是要实现GatewayFilterFactory接口。
全局过滤器：不需要在配置文件中配置，作用在所有的路由上；实现 GlobalFilter 接口即可。

自定义过滤器命名应该为***GatewayFilterFactory

Gateway中默认就已经集成了Ribbon负载均衡和Hystrix熔断机制。

在js请求访问中，如果访问的地址与当前服务器的域名、ip或者端口号不一致则称为跨域请求。若不解决则不能获取到对应地址的返回结果。可以在网关服务器中通过配置解决，允许哪些服务是可以跨域请求的；

spring:
    cloud:
        gateway:
            globalcors:
                corsConfigurations:
                    '[/**]':
                        allowedOrigins:
                            - "http://docs.spring.io"
                        allowedMethods:
                            - GET

在分布式系统中，由于服务数量非常多，配置文件分散在不同的微服务项目中，管理不方便。为了方便配置文件集中管理，需要分布式配置中心组件。在Spring Cloud中，提供了Spring Cloud Confifig，它支持配置文件放在配置服务的本地，也支持放在远程Git仓库。

配置中心本质上也是一个微服务，同样需要注册到Eureka服务注册中心










对于Git仓库中配置文件的修改并不会及时更新到用户微服务，只有重启用户微服务才能生效。如果想在不重启微服务的情况下更新配置，可以使用Spring Cloud Bus来实现配置的自动更新。
Spring Cloud Bus底层是基于RabbitMQ实现的，默认使用本地的消息队列服务，所以需要提前启动本地RabbitMQ服务

Spring Cloud的整体应用：