Spring cloud，Mq

Spring cloud，Mq

什么是Spring Cloud？

    Spring cloud流应用程序启动器是基于Spring Boot的Spring集成应用程序，提供与外部系统的集成。Spring cloud Task，一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用程序

使用Spring Boot开发分布式微服务时，我们面临以下问题

与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。

服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该目录中注册服务，然后能够查找并连接到该目录中的服务。

冗余-分布式系统中的冗余问题。

负载平衡 --负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中央处理单元，或磁盘驱动器的分布。

性能-问题 由于各种运营开销导致的性能问题。

部署复杂性-Devops技能的要求。

服务注册和发现是什么意思？Spring Cloud如何实现？

当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可能会产生问题。 Eureka服务注册和发现可以在这种情况下提供帮助。由于所有服务都在Eureka服务器上注册并通过调用Eureka服务器完成查找，因此无需处理服务地点的任何更改和处理。

负载平衡的意义什么？

在计算中，负载平衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。

什么是Hystrix？它如何实现容错？

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

什么是Hystrix断路器？我们需要它吗？

由于某些原因，employee-consumer公开服务会引发异常。在这种情况下使用Hystrix我们定义了一个回退方法。如果在公开服务中发生异常，则回退方法返回一些默认值。

Feign是受到Retrofit，JAXRS-2.0和WebSocket启发的java客户端联编程序。Feign的第一个目标是将约束分母的复杂性统一到http apis，而不考虑其稳定性。在employee-consumer的例子中，我们使用了employee-producer使用REST模板公开的REST服务。

但是我们必须编写大量代码才能执行以下步骤

使用功能区进行负载平衡。

获取服务实例，然后获取基本URL。

利用REST模板来使用服务。 前面的代码如下

什么是Spring Cloud Bus？我们需要它吗？

考虑以下情况：我们有多个应用程序使用Spring Cloud Config读取属性，而Spring Cloud Config从GIT读取这些属性。

下面的例子中多个员工生产者模块从Employee Config Module获取Eureka注册的财产。

Spring Cloud Bus提供了跨多个实例刷新配置的功能。因此，在上面的示例中，如果我们刷新Employee Producer1，则会自动刷新所有其他必需的模块。如果我们有多个微服务启动并运行，这特别有用。这是通过将所有微服务连接到单个消息代理来实现的。无论何时刷新实例，此事件都会订阅到侦听此代理的所有微服务，并且它们也会刷新。可以通过使用端点/总线/刷新来实现对任何单个实例的刷新。

dubbo 是 基于 RPC 远程 过程调用

cloud 是基于 http  rest api 调用

ribbon和feign区别

Ribbon添加maven依赖 spring-starter-ribbon 使用@RibbonClient(value="服务名称") 使用RestTemplate调用远程服务对应的方法

feign添加maven依赖 spring-starter-feign 服务提供方提供对外接口 调用方使用 在接口上使用@FeignClient("指定服务名")

Ribbon和Feign的区别：

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

1.启动类使用的注解不同，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。

2.服务的指定位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明。

3.调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤相当繁琐。

Feign则是在Ribbon的基础上进行了一次改进，采用接口的方式，将需要调用的其他服务的方法定义成抽象方法即可，

不需要自己构建http请求。不过要注意的是抽象方法的注解、方法签名要和提供服务的方法完全一致。

        维度(SpringCloud)

        服务开发

            SpringBoot

            Spring

            SpringMVC

        服务配置与管理

            Netfilx公司的Archaiusm,阿里的Diamond

        服务注册与发现

            Eureka,ZooKeeper

        服务调用

            Rest,RPC,gRPC

        服务熔断器

            Hystrix

        服务负载均衡

            Ribbon,Nginx

        服务接口调用

            Feign

        消息队列

            Kafka,RabbitMq,ActiveMq

        服务配置中心管理

            SpringCloudConfing

        服务路由(API网关)

            Zuul

        事件消息总线

            SpringCloud Bus

springCloud服务注册中心

    Eureka 服务注册中心

        启动注解类@EnableEurekaServer，表示启用注册中心服务

        #端口号

        server:

          port: 8888

        #Eureka实例名，集群中根据这里相互识别

        eureka:

          instance:

            hostname: eureka

        #客户端

          client:

        #是否开启注册服务，因为这里如果为true表示自己注册自己，而自己就是一个服务注册方，没必要自己注册自己

        register-with-eureka: false

        #是否拉取服务列表，这里我只提供服务给别的服务。

        fetch-registry: false

        #注册中心地址

            service-url:

              defaultZone: http://localhost:8888/eureka/

    注册服务   

    启动注解类@EnableDiscoveryClient，表示注册服务，服务提供者

#端口号

    server:

      port: 8080

    #Eureka实例名，集群中根据这里相互识别

    spring:

      application:

        name: hello-service

    eureka:

    #客户端

      client:

    #注册中心地址

        service-url:

          defaultZone: http://localhost:8888/eureka/

服务注册

    在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册中心登记自己提供的服务，包括服务的主机与端口号、服务版本号、通讯协议等一些附加信息。注册中心按照服务名分类组织服务清单，同时还需要以心跳检测的方式去监测清单中的服务是否可用，若不可用需要从服务清单中剔除，以达到排除故障服务的效果。

服务发现

    在服务治理框架下，服务间的调用不再通过指定具体的实例地址来实现，而是通过服务名发起请求调用实现。

    服务调用方通过服务名从服务注册中心的服务清单中获取服务实例的列表清单，通过指定的负载均衡策略取出一个服务实例位置来进行服务调用。

Eureka服务端

    Eureka服务端，即服务注册中心。它同其他服务注册中心一样，支持高可用配置。依托于强一致性提供良好的服务实例可用性，

    可以应对多种不同的故障场景。

    Eureka服务端支持集群模式部署，当集群中有分片发生故障的时候，Eureka会自动转入自我保护模式。

    它允许在分片发生故障的时候继续提供服务的发现和注册，当故障分配恢复时，集群中的其他分片会把他们的状态再次同步回来。

    集群中的的不同服务注册中心通过异步模式互相复制各自的状态，这也意味着在给定的时间点每个实例关于所有服务的状态可能存在不一致的现象。

Eureka客户端

    Eureka客户端，途中的即服务提供者，主要处理服务的注册和发现。客户端服务通过注册和参数配置的方式，嵌入在客户端应用程序的代码中。

在应用程序启动时，Eureka客户端向服务注册中心注册自身提供的服务，并周期性的发送心跳来更新它的服务租约。同时，

他也能从服务端查询当前注册的服务信息并把它们缓存到本地并周期行的刷新服务状态。

    1.注册，表示服务提供者需要向注册中心注册服务，在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册中心登记自己提供的服务，

包括服务的主机与端口号、服务版本号、通讯协议等一些附加信息。注册中心按照服务名分类组织服务清单，同时还需要以心跳检测的方式去监测清单中的服务

是否可用，若不可用需要从服务清单中剔除，以达到排除故障服务的效果。

　　2.续约，这里类似于心跳检测机制，默认是每隔90秒，服务提供者需要向注册中心进行续约，目的是隔一段时间Service Provider调用接口，

告诉Eureka Server它还活着没挂，不要把它T了。通俗的说就是它们两之间的心跳检测，避免服务提供者被剔除掉

　　3.下线，表示服务提供者断开

构建高可用的注册中心

    Eureka实现高可用原理其实很简单，就是两个Eureka相互注册，你向我注册，我向你注册。

ribbon

ribbon 是一个客户端负载均衡器，可以简单的理解成类似于 nginx的负载均衡模块的功能。

负载均衡算法：

　 1:简单轮询负载均衡（RoundRobin）

    　　 以轮询的方式依次将请求调度不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。

   2:随机负载均衡 （Random）

    　　 随机选择状态为UP的Server

   3:加权响应时间负载均衡 （WeightedResponseTime）

         根据相应时间分配一个weight，相应时间越长，weight越小，被选中的可能性越低。

   4:区域感知轮询负载均衡（ZoneAvoidanceRule）

    　　 复合判断server所在区域的性能和server的可用性选择server

Hystrix请求熔断与服务降级

Hystrix设计原则

　　1.防止单个服务的故障，耗尽整个系统服务的容器（比如tomcat）的线程资源，避免分布式环境里大量级联失败。通过第三方客户端访问（通常是通过网络）依赖服务出现失败、拒绝、超时或短路时执行回退逻辑       2.用快速失败代替排队(每个依赖服务维护一个小的线程池或信号量，当线程池满或信号量满，会立即拒绝服务而不会排队等待)和优雅的服务降级；当依赖服务失效后又恢复正常，快速恢复

3.提供接近实时的监控和警报，从而能够快速发现故障和修复。监控信息包括请求成功，失败（客户端抛出的异常），超时和线程拒绝。如果访问依赖服务的错误百分比超过阈值,断路器会跳闸，此时服务会在一段时间内停止对特定服务的所有请求

4.将所有请求外部系统（或请求依赖服务）封装到HystrixCommand或HystrixObservableCommand对象中，然后这些请求在一个独立的线程中执行。使用隔离技术来限制任何一个依赖的失败对系统的影响。每个依赖服务维护一个小的线程池（或信号量），当线程池满或信号量满，会立即拒绝服务而不会排队等待

Hystrix特性

　　1.请求熔断： 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN).

　　　 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.

　　2.服务降级：Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.告知后面的请求服务不可用了，不要再来了。

　　3.依赖隔离(采用舱壁模式，Docker就是舱壁模式的一种)：在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池.比如说，一个服务调用两外两个服务，你如果调用两个服务都用一个线程池，那么如果一个服务卡在哪里，资源没被释放

　　　后面的请求又来了，导致后面的请求都卡在哪里等待，导致你依赖的A服务把你卡在哪里，耗尽了资源，也导致了你另外一个B服务也不可用了。这时如果依赖隔离，某一个服务调用A B两个服务，如果这时我有100个线程可用，我给A服务分配50个，给B服务分配50个，这样就算A服务挂了我的B服务依然可以用。

　　4.请求缓存：比如一个请求过来请求我userId=1的数据，你后面的请求也过来请求同样的数据，这时我不会继续走原来的那条请求链路了，而是把第一次请求缓存过了，把第一次的请求结果返回给后面的请求。

　　5.请求合并：我依赖于某一个服务，我要调用N次，比如说查数据库的时候，我发了N条请求发了N条SQL然后拿到一堆结果，这时候我们可以把多个请求合并成一个请求，发送一个查询多条数据的SQL的请求，这样我们只需查询一次数据库，提升了效率。

Hystrix流程说明:

    1:每次调用创建一个新的HystrixCommand,把依赖调用封装在run()方法中.

　　2:执行execute()/queue做同步或异步调用.

　　4:判断熔断器(circuit-breaker)是否打开,如果打开跳到步骤8,进行降级策略,如果关闭进入步骤5.

　　5:判断线程池/队列/信号量是否跑满，如果跑满进入降级步骤8,否则继续后续步骤6.

　　6:调用HystrixCommand的run方法.运行依赖逻辑

　　6a:依赖逻辑调用超时,进入步骤8.

　　7:判断逻辑是否调用成功

　　7a:返回成功调用结果

　　7b:调用出错，进入步骤8.

　　8:计算熔断器状态,所有的运行状态(成功, 失败, 拒绝,超时)上报给熔断器，用于统计从而判断熔断器状态.

　　9:getFallback()降级逻辑.以下四种情况将触发getFallback调用：

　　　　(1):run()方法抛出非HystrixBadRequestException异常。

　　　　(2):run()方法调用超时

　　　　(3):熔断器开启拦截调用

　　　　(4):线程池/队列/信号量是否跑满

　　9a:没有实现getFallback的Command将直接抛出异常

　　9b:fallback降级逻辑调用成功直接返回

　　9c:降级逻辑调用失败抛出异常

　　10:返回执行成功结果

启动类中加入@EnableCircuitBreaker注解，表示允许断路器

　//请求熔断注解，当服务出现问题时候会执行fallbackMetho属性的名为helloFallBack的方法

    @HystrixCommand(fallbackMethod = "helloFallBack")

Feign声明式服务调用

Feign具有如下特性：

可插拔的注解支持，包括Feign注解和JAX-RS注解;

支持可插拔的HTTP编码器和解码器;

支持Hystrix和它的Fallback;

支持Ribbon的负载均衡;

支持HTTP请求和响应的压缩。

@FeignClient(value = "hello-service",fallback = FeignFallBack.class)

Feign模块的启动类哪里打上Eureka客户端的注解@EnableDiscoveryClient  Feign客户端的注解@EnableFeignClients

Zuul网关服务

Zuul可以通过加载动态过滤机制，从而实现以下各项功能：

　　1.验证与安全保障: 识别面向各类资源的验证要求并拒绝那些与要求不符的请求。

　　2.审查与监控: 在边缘位置追踪有意义数据及统计结果，从而为我们带来准确的生产状态结论。

　　3.动态路由: 以动态方式根据需要将请求路由至不同后端集群处。

　　4.压力测试: 逐渐增加指向集群的负载流量，从而计算性能水平。

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

　　6.静态响应处理: 在边缘位置直接建立部分响应，从而避免其流入内部集群。

　　7.多区域弹性: 跨越AWS区域进行请求路由，旨在实现ELB使用多样化并保证边缘位置与使用者尽可能接近。

@EnableZuulProxy

拦截类 class TokenFilter extends ZuulFilter

    filterType：返回一个字符串代表过滤器的类型，在zuul中定义了四种不同生命周期的过滤器类型，具体如下：

　　1.pre：可以在请求被路由之前调用，用在路由映射的阶段是寻找路由映射表的

　　2.route：在路由请求时候被调用，具体的路由转发过滤器是在routing路由器具体的请求转发的时候会调用

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

　　4.post：当routing，error运行完后才会调用该过滤器，是在最后阶段的

Config分布式配置管理

常见的配置中心的实现方法有:

　　1.硬编码(缺点:需要修改代码,风险大)

　　2.放在xml等配置文件中,和应用一起打包(缺点:需要重新打包和重启)

　　3.文件系统中(缺点:依赖操作系统等)

　　4.环境变量(缺点:有大量的配置需要人工设置到环境变量中,不便于管理,且依赖平台) 5.云端存储(缺点:与其他应用耦合)

Spring Cloud Config就是云端存储配置信息的,它具有中心化,版本控制,支持动态更新,平台独立,语言独立等特性。其特点是：

　　1.提供服务端和客户端支持(spring cloud config server和spring cloud config client)

　　2.集中式管理分布式环境下的应用配置

　　3.基于Spring环境，无缝与Spring应用集成

　　4.可用于任何语言开发的程序

　　5.默认实现基于git仓库，可以进行版本管理

　　6.可替换自定义实现

    spring cloud config server 作为配置中心的服务端：

　　　　1.拉取配置时更新git仓库副本，保证是最新结果

　　　　2.支持数据结构丰富，yml, json, properties 等

　　　　3.配合 eureke 可实现服务发现，配合 cloud bus 可实现配置推送更新

　　　　4.配置存储基于 git 仓库，可进行版本管理

　　　　5.简单可靠，有丰富的配套方案

　　2.Spring Cloud Config Client 客户端：

　　　　1.Spring Boot项目不需要改动任何代码，加入一个启动配置文件指明使用ConfigServer上哪个配置文件即可

接着在启动类上面加入@EnableConfigServer注解，表示这里是配置中心服务

Bus消息总线

Kafka是基于消息发布/订阅模式实现的消息系统，其主要设计目标如下：

　　1.消息持久化：以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。

　　2.高吞吐：在廉价的商用机器上也能支持单机每秒100K条以上的吞吐量

　　3.分布式：支持消息分区以及分布式消费，并保证分区内的消息顺序

　　4.跨平台：支持不同技术平台的客户端（如：Java、PHP、Python等）

　　5.实时性：支持实时数据处理和离线数据处理

　　6.伸缩性：支持水平扩展

Kafka中涉及的一些基本概念：

　　1.Broker：Kafka集群包含一个或多个服务器，这些服务器被称为Broker。

　　2.Topic：逻辑上同Rabbit的Queue队列相似，每条发布到Kafka集群的消息都必须有一个Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个Broker上，但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）

　　3.Partition：Partition是物理概念上的分区，为了提供系统吞吐率，在物理上每个Topic会分成一个或多个Partition，每个Partition对应一个文件夹（存储对应分区的消息内容和索引文件）。

　　4.Producer：消息生产者，负责生产消息并发送到Kafka Broker。

　　5.Consumer：消息消费者，向Kafka Broker读取消息并处理的客户端。

　　6.Consumer Group：每个Consumer属于一个特定的组（可为每个Consumer指定属于一个组，若不指定则属于默认组），组可以用来实现一条消息被组内多个成员消费等功能。

MQ

消息队列

好处，使用场景，异步，解耦，削峰

缺点，

    系统可用性降低，系统引入的外部依赖越多，越容易挂掉

    系统复杂度提高,保证消息传递的顺序性

    一致性问题，消息失败机制

如何保证消息队列的高可用

RabbitMQ 的高可用性

RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式

单机模式（demo模式）

普通集群模式

（无高可用性），提高吞吐量，每个实例拥有一个queue元数据，

镜像集群模式

（高可用性），每个实例拥有一个queue元数据，元数据间消息同步，优点是实现了高可用，缺点，因为要消息同步所以网络新年消耗也会增加

如何开启镜像集群模式，后台新增策略，镜像集群模式的策略

Kafka 的高可用性

天然的分布式消息队列

0.8之前没有高可用，0.8之后有高可用，副本机制

重复消费

幂等性，通俗点说，就一个数据，或者一个请求，给你重复来多次，你得确保对应的数据是不会改变的，不能出错。

比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update 一下好吧。

比如你是写 Redis，那没问题了，反正每次都是 set，天然幂等性。

比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的 id，类似订单 id 之类的东西，然后你这里消费到了之后，先根据这个 id 去比如 Redis 里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个 id 写 Redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。

比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了，重复数据插入只会报错，不会导致数据库中出现脏数据。

如何保证消息的可靠性传输，如何处理消息丢失的问题

RabbitMQ

生产者弄丢了数据

开启事务，

就是生产者发送数据之前开启 RabbitMQ 事务channel.txSelect，然后发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错，此时就可以回滚事务channel.txRollback，然后重试发送消息；如果收到了消息，那么可以提交事务channel.txCommit。

// 开启事务

channel.txSelect

try {

    // 这里发送消息

} catch (Exception e) {

    channel.txRollback

    // 这里再次重发这条消息

}

// 提交事务

channel.txCommit

RabbitMQ 事务机制（同步）一搞，基本上吞吐量会下来，因为太耗性能。因为是事务机制是同步的

开启 confirm 模式，

在生产者那里设置开启 confirm 模式之后，你每次写的消息都会分配一个唯一的 id，然后如果写入了 RabbitMQ 中，RabbitMQ 会给你回传一个 ack 消息，告诉你说这个消息 ok 了。如果 RabbitMQ 没能处理这个消息，会回调你的一个 nack 接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息 id 的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。

RabbitMQ 弄丢了数据

这个你必须开启 RabbitMQ 的持久化，消息持久化到磁盘，重启后恢复

设置持久化有两个步骤：

创建 queue 的时候将其设置为持久化

这样就可以保证 RabbitMQ 持久化 queue 的元数据，但是它是不会持久化 queue 里的数据的。

第二个是发送消息的时候将消息的 deliveryMode 设置为 2

就是将消息设置为持久化的，此时 RabbitMQ 就会将消息持久化到磁盘上去。

消费端弄丢了数据

这个时候得用 RabbitMQ 提供的 ack 机制，简单来说，就是你必须关闭 RabbitMQ 的自动 ack，可以通过一个 api 来调用就行，然后每次你自己代码里确保处理完的时候，再在程序里 ack 一把。

Kafka

消费端弄丢了数据

自动提交了 offset，关闭offset，得到消息后手动提交offset

Kafka 弄丢了数据