SpringCloud基础知识整理

（SOA：面向服务架构）

微服务开发的缺点：

    1、代码冗余，重复开发；

    问题：

            调用关系错综复杂；

            维护困难

springCloud：springCloud就是一个容器，即注册中心，所有的服务方与调用方都需要在注册中心进行注册。微服务架构的解决方案，是很多组件的集合。

eureka：注册中心，服务的注册与发现；

zuul：网关组件，路由请求，过滤器；

ribbon：负载均衡组件

hystrix：熔断组件

feign：远程调用组件（ribbon hystrix）

微服务的特点：

    单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责。

    微：微服务的服务拆分粒度很小，例如一个用户管理就可以最为一个服务。每个服务虽小，但五脏俱全。

    面向服务：面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技实现，做到与平台和语言无关，也不限定用什么技术实现，只需要提供Rest的接口即可。

    自治：自治是说服务间相互独立，互不干扰。

            团队独立：每个服务都是一个独立的开发团队，人数不能过多，人数不能过多。

            技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉。

            前后端分离：采用前后端分离开发，提供统一Rest接口，后端不在为PC、移动开发不同接口。

            数据库分离：每个服务都使用自己的数据源。

            部署独立：服务间虽然有调用，但要做到服务重启不影响其他服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护。

常见的远程调用方式有如下2种：

    RPC：Remote Produce Call远程过程调用，类似的还有RMI。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型代表。

    Http：http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用http协议，也可以用来进行远程服务调用。缺点是消息封装臃肿，优势是对服务的提供和调用方没有任何的技术限定，自由灵活，更符合微服务的理念。

        现在的热门的Rest风格，就可以通过htp协议来实现。

SpringCloud实现了诸如：配置管理，服务发现，智能路由，负载均衡，熔断器，控制总线，集成状态等等功能。其主要涉及的组件包括：

        Eureka：服务治理组件，包含服务注册中心，服务注册与发现机制的实现。（服务治理，服务注册/发现）

        Zuul：网关组件，提供智能路由，访问过滤功能。

        Ribbon：客户端负载均衡的服务调用组件（客户端负载）

        Feign：服务调用，给予Ribbon和Hystrix的声明式服务调用组件(声明式服务调用)

        Hystrix：容错管理组件，实现断路器模式，帮助服务依赖中出现的延迟和为故障提供强大的容错能力。（熔断、断路器、容错）

eureka配置：

eureka:

    service:

        eviction-interval-timer-in-ms: 5000 # 剔除无效连接的间隔时间

        enable-self-preservation: false # 关闭自我保护状态

服务注册：

    服务提供者在启动时，会检测配置属性中的：eureka.client.register-with-rureka=true参数是否正确，事实上默认就是true。如果值确实为true，则会向EurekaServer中发起一个Rest请求，并携带自己的元数据信息，Eureka Server会把这些信息保存到一个双层Map结构中。

    第一层Map的key就是服务id，一般是配置中的spring.application.name属性。

    第二层Map的key就是服务的实例id。一般host+serviceld+port，例如：localhost：user-service：8081，值则是服务的实例对象，也就是说一个服务，可以同时启动多个不同实例，形成集群。

服务续约：

    在注册服务完成以后，服务提供者会维持一个心跳（定时向EurekaServer发起Rest请求），告诉EurekaServer：“我还活着”。这个称之为服务的续约（renew）；

有两个重要参数可以修改服务续约的行为：

eureka：

    instance：

        lease-expiration-duration-in-seconds：90    #服务失效时间，默认为90秒

        lease-renewal-interval-in-seconds：30    #服务续约（renew）的间隔，默认为30秒

获取服务列表：

    当服务消费者启动时，会检测eureka.client.fetch-registry=true参数的值，如果为true，则会拉取EurekaServer服务的列表只读备份，然后缓存到本地。并且每隔30秒会重新获取并更新数据。可以通过下面的参数来修改：

eureka：

    client：

        registry-fetch-interval-seconds：5

生产环境中，我们不需要修改这个值，但是为了开发的环境下，能够快速的得到服务的最新状态，可以报这个值设置的小一点。

eureka：

    server：

        eviction-interval-time-in-ms：5000 # 服务失效剔除时间，（毫秒值计数）

总结：

eureka：

    注册中心：eureka-server（1、引入启动器，2、配置spring.application.name=eureka-server,3、在引导类上@EnableEurekaServer）

    客户端：service-hi service-ribbon（1、引入启动容器，2、配置spring.application.name  eureka.client.service-url.defaultZone=http://localhost:8762/eureka，3、@EnableDiscoveryClient（启用eureka客户端） ）

解读：

    Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队，加速失败的判定时间。

    用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超时，则会进行降级处理。

        服务降级：优先保证核心服务，而非核心服务不可用或弱可用。

    用户的请求故障时，不会被阻塞，更不会无休止的等待或者看到系统崩溃，至少可以看到一个执行结果（例如返回友好的提示信息）。

    服务降级虽然会导致请求失败，但是不会导致阻塞，而且最多会影响这个依赖服务对应的线程池中的资源，对其它的服务没有响应。

    触发Hystix服务降级的情况：

        线程池已满

        请求超时

hystrix

    降级：

        1、引入hystrix启动器

        2、熔断时间，默认为1s，可以自行设置

        3、在引导类上添加了一个注释：@EnableCircuitBreaker或者组合注解：@SpringBootApplication

        4、定义熔断方法：局部（要和被熔断的返回值和参数列表一致）    全局（返回值类型要和被熔断的方法名一致，参数列表必须为空）

        5、@HystrixCommand（fallbackMethod=“局部熔断方法名”）：声明被熔断的方法

        6、@DefaultProperties（defaultFallback=“全局熔断方法名”）

设置超时：

    Hystix默认超时时长为1秒，可以通过配置修改这个值：

    我们可以通过hystrix.command.default.excution.execution.isolation.thread.timeoutInMilliesconds来设置Hystrix超时时间。该配置没有提示。

hystrix:

    command:

        default:

            excution:

                isolation:

                    thread:

                        timeoutInMilliseconds: 6000 # 设置hystrix的超时时间为6000ms

组合注解：@SpringCloudApplication相当于@SpringBootApplication+@EnableDiscoveryClient+@EnableCircuitBreaker

服务熔断：

熔断原理：

熔断器，也叫断路器，英文单词为：Circuit Breaker

    熔断机制的原理很简单，就像家里的电路熔断器，如果电路发生短路能立即熔断电路，避免发生灾难。在分布式系统中应用这一模式之后，服务调用方可以自己进行判断某些服务反应慢或者存在大量超时的情况时，能够主动熔断，防止整个系统被拖垮。

    不同于电路熔断只能断不能自动重连，Hystrix可以实现弹性容错，当情况好转之后，可以自动重连。这就好比魔术师把鸽子变没了容易，但是真正考验技术的是如何把消失的鸽子在变回来。

    通过断路的方式，可以将后续请求直接拒绝掉，一段时间之后允许部分请求通过，如果调用成功则回到电路闭合状态，否则继续断开。

熔断状态机3个状态：

    Closed：关闭状态，所有请求都可以访问。

    Open：打开状态，所有请求都会被降级。Hystrix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则会触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最低不少于20次。

    Half Open：半开状态，open状态不是永久的，打开之后会进入休眠时间（默认为5s）。随后断路器会自动进入半开状态，此时会释放部分请求通过，若这些请求都是健康的，则会完全关闭断路器，否则继续保持打开，再次进入休眠计时。

默认的熔断触发要求比较高，休眠时间比较短为了测试方便，可以通过配置修改熔断策略：

circuitBreaker.requestVolumeThreshold=10         //触发熔断的最小请求次数    

circuitBreaker.sleepWindowInMilliseconds=10000   //休眠时长，默认是5000毫秒

circuitBreaker.errorThresholdPercentage=50       //触发熔断的失败请求最小占比，默认50%

Feign：（伪装）

    Feign可以把Rest请求进行隐藏，伪装成类似SpingMVC的controller一样。不用在自己拼接url，拼接参数等等操作，一切都交给Feign去做。

    Feign是Netfix开发声明式、模板化的HTTP客户端，其灵感来自Retrofit、JAXRS-2.0以及WebSocket。Feign可以帮助我们更加便捷、优雅的调用HTTP API。

    在SpringCloud中，使用Feign非常简单----创建一个接口，并在接口上添加一些注解，代码就完成了。Feign支持多种注解，例如Feign自带的注解或者JAX-RS注解等。

    SpringCloud对Feign进行了增强，使Feign支持了SpringMVC注解，并整合了Ribbon和Eureka，从而让Feign的使用更加方便。

feign：

    1、引入openFeign启动器

    2、feign.hystrix.enable=true,开启feign的熔断功能

    3、在引导类上@EnableFeignClients

    4、创建一个接口，在接口上添加@FeignClient（value=“服务id”,fallback实现类.class）

    5、在接口中定义一些方法，这些方法的书写方式跟之前的controller类似

Zuul：

    Zuul是NetFlix开源的服务网关，它可以和Eureka、Ribbon、Hystrix等组件配合使用。

    Zuul的核心是一系列的过滤器，这些过滤器可以完成以下功能：

        身份认证与安全：识别每一个资源的验证要求，并拒绝那些与要求不符的请求。

        审查与监控：在边缘位置追踪有意义的数据和统计结果，从而带来精确地生产视图。

        动态路由：动态地将请求路由的不同的后端集群。

        压力与测试：逐渐增加指向集群的流量，以了解性能。

        负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求。

        静态响应处理：在边缘位置直接建立部分响应，从而避免其转发到内部集群。

        多区域弹性：跨越AWS Region进行路由请求，旨在实现ELB（Elastic Load Balancing）使用的多样化，以及让系统的边缘更贴近系统的使用者。

SpringCloud对Zuul进行了整合和增强。目前，Zuul使用的默认HTTP客户端是Apache HTTP Client，也可以使用RestClient或者okhttp3.0kHttpClient。如果想要使用RestClient,可以设置ribbon.restclient.enabled=true；要想使用okhttp3.0kHttpClient，可以设置ribbon.okhttp.enable=true。

Zuul：

        1、引入zuul的启动器

        2、配置：

                方式一：

                zuul.routes.<路由名称>.path=/service-provider/**

                zuul.routes.<路由名称>.url=http://localhost:8762

                方式二：

                zuul.routes.<路由名称>.path=/service-provider/**

                zuul.routes.<路由名称>.serviceId=service-provider

                方式三：

                zuul.routes.服务名=/service-provider/**

                方式四：

                不配置，默认就是服务id开头的路径

        3、@EnableZuulProxy

    

过滤器：

    Zuul作为网关的其中一个重要功能，就是实现请求的鉴权。而这个动作我们往往是通过Zuul提供的过滤器来实现的。

ZuulFilter：

    ZullFilter是过滤器的顶级父类，以下是其中定义的最重要的4个方法：

public abstract ZuulFilter implements IZuulFilter{

    abstract public String filterType();

    abstract public int filterOrder();

    boolean shouldFilter();//来自IZuulFilter

    Object run() throws ZuulException;//IZuulFilter

}

shouldFilter：返回一个Boolean值，判断该过滤器是否需要执行。返回true执行，返回false不执行。

run：过滤器的具体业务逻辑。

FilterType：返回字符串，代表过滤器的类型。包含以下三种：

    pre：请求在被路由之前执行

    route：在路由请求时调用

    post：在route和error过滤器之后调用

    error：处理请求时发生错误调用

filterOrder：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。

    

过滤器正常流程：

    请求到达首先经过pre类型过滤器，而后到达route类型，进行路由，请求就到达真正的服务提供者，执行请求，返回结果后，会到达post过滤器。而后返回响应。