SpringCloud学习记录（未完成）

SpringCloud作为Java语言的微服务框架，它依赖于SpringBoot，有快速开发、持续 交付和容易部署等特点。
SpringCloud的组件非常多，涉及微服务的方方面面，井在开源社区Spring和Netflix、Pivotal两大公司的推动下越来越完善，如今alibaba也加入到其中。

SpringCloud常用组件表

服务的注册和发现。（eureka,nacos,consul）
服务的负载均衡。(ribbon,dubbo)
服务的相互调用。（openFeign,dubbo）
服务的容错。（hystrix，sentinel）
服务网关。（gateway，zuul）
服务配置的统一管理。（config-server,nacos,apollo）
服务消息总线。(bus)
服务安全组件。(security,Oauth2.0)
服务监控。(admin) （jvm）
链路追踪。(sleuth+zipkin)

SpringCloud Eureka

注册发现中心
Eureka是Netflix在线影片公司开源的一个服务注册与发现的组件

Spring Cloud Eureka 和 Zookeeper 的区别

什么是 CAP 原则（面试）
CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾
CAP 原则又称 CAP 定理，指的是在一个分布式系统中， 一致性（Consistency） 可用性（Availability） 分区容错性（Partition tolerance）（这个特性是必须会存在的）

    C: 数据的一致性 （A,B,C 里面的数据是一致的） Zk 注重数据的一致性。 Eureka 不是很注重数据的一致性！
    A: 服务的可用性（若 zk 集群里面的 master 挂了怎么办）Paxos（多数派） 在 zk 里面，若主机挂了，则 zk 集群整体不对外提供服务了，需要选一个新的出来（120s 左右）才能继续对外提供服务！ Eureka 注重服务的可用性，当 Eureka集群只有一台活着，它就能对外提供服务
    P: 分区的容错性（在集群里面的机器，因为网络原因，机房的原因，可能导致数据不会里面同步），它在分布式必须需要实现的特性！
    Zookeeper 注重数据的一致性，CP zk(注册中心，配置文件中心，协调中心)
    Eureka 注重服务的可用性 AP eureka （注册中心）

搭建Eureka服务端环境

server: port: 8761 #服务端端口
spring: application: name: eureka-server #服务名称
启动类添加@EnableEurekaServer注解开启

Eureka概念的理解
服务的注册

当项目启动时（eureka的客户端），就会向eureka-server发送自己的元数据（运行的 ip，端口
port，健康的状态监控等，因为使用的是 http/ResuFul 请求风格），
eureka-server会在自己内部保留这些元数据(内存中)。（有一个服务列表）（restful风格，以http动词的请求方式，完成对url资源的操作）

服务的续约

项目启动成功了，除了向 eureka-server 注册自己成功，还会定时的向 eureka-server
汇报自己，心跳，表示自己还活着。（修改一个时间）

服务的下线

主动下线，当项目关闭时，会给 eureka-server 报告，说明自己要下机了

服务的剔除

被动下线，主动剔除，当项目超过了指定时间没有向 eureka-server 汇报自己，那么 eureka-server 就会认为此
节点死掉了，会把它剔除掉，也不会放流量和请求到此节点了。

Eureka 运作原理的特点

Eureka-server对外提供的是restful 风格的服务，以http动词的形式对url资源进行操作get post put
delete http 服务+特定的请求方式+特定的url地址，
只要利用这些restful我们就能对项目实现注册和发现，只不过eureka 已经帮我们使用 java 语言写了client，让我们的项目只要依赖 client就能实现注册和发现！
只要你会发起Http请求，那你就有可能自己实现服务的注册和发现。不管你是什么语言！

服务注册总结

重要的类：
DiscoveryClient里面的register()方法完后注册的总体构造
AbstractJerseyEurekaHttpClient里面的register()方法具体发送注册请求（post）
InstanceRegistry里面register()方法接受客户端的注册请求
PeerAwareInstanceRegistryImpl里面调用父类的register()方法实现注册
AbstractInstanceRegistry里面的register()方法完成具体的注册保留数据到map集合
保存服务实例数据的集合：
第一个 key是应用名称（全大写）spring.application.name
Value 中的key是应用的实例id eureka.instance.instance-id
Value 中的value是具体的服务节点信息

服务续约总结

续约的本质就是修改了服务节点的最后更新时间

SpringCloud Ribbon

SpringCloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix
Ribbon实现。通过SpringCloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用
主要功能是提供客户端负载均衡算法和服务调用，Ribbon客户端组件提供了一套完善的配置项，比如连接超时，重试等。

负载均衡

英文名称为LoadBalance（LB）lb://（负载均衡协议）,其含义就是指将负载（工作任务）进行平衡、分摊到多个操作单元上进行运行，例如Web服务器、企业核心应用服务器和其它主要任务服务器等，从而协同完成工作任务。负载均衡构建在原有网络结构之上，它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。

Ribbon怎么把 http://provider/hello 路径请求成功的？

想要把上面这个请求执行成功，我们需要以下几步
1. 拦截该请求；
2. 截取主机名称
3. 借助eureka来做服务发现,从服务列表中找到 key 为 provider 的服务实例的集合(服务发现)
4. 根据负载均衡算法拿到一个服务ip和port
5. reConstructURL
6. 发起请求

什么是CAS机制

CAS机制的全称是Compare And Swap，翻译过来就是比较并且交换，CAS机制中有三个变量，内存地址address，旧的预期值oldvalue，要修改的新值newvalue。当进行CAS操作时，首先先检测和比较内存地址和旧的预期值是否一致，如果一致返回true，否则返回false。
CAS操作的就是乐观锁，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。
Java里的CAS是通过调用Unsafe类的native方法，再由C调用CPU底层命令实现的。
CAS的缺点：
1.CPU开销较大
在并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。
2.不能保证代码块的原子性
CAS机制所保证的只是一个变量的原子性操作，而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新，就不得不使用Synchronized了。
3.ABA问题
假设有一个变量 A ，经修改后变为B，然后又修改为 A，实际已经修改过了，但 CAS 可能无法感知，造成了不合理的值修改操作。
解决方案是：使用版本号，在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么A－B－A 就会变成1A-2B－3A
CAS的优点:
在一般情况下，性能优先于锁的使用。

Ribbon总结：

Ribbon 是客户端实现负载均衡的远程调用组件，用法简单
Ribbon 源码核心：
ILoadBalancer 接口：起到承上启下的作用
1. 承上：从 eureka 拉取服务列表（做服务发现）
2. 启下：使用 IRule 算法实现客户端调用的负载均衡 (做负载均衡)

SpringCloud OpenFeign

Feign是声明性(注解)Web服务客户端。它使编写Web服务客户端更加容易。
要使用Feign，请创建一个接口并对其进行注解。它具有可插入注解支持，包括Feign注解和JAX-RS注解。Feign还支持可插拔编码器和解码器。SpringCloud添加了对SpringMVC注解的支持，并支持使用HttpMessageConverters，SpringWeb中默认使用的注解。SpringCloud集成了Ribbon和Eureka以及SpringCloud
LoadBalancer，以在使用Feign时提供负载平衡的http 客户端

Feign对接口的注解：

     入口的注解 开启Feign
        @EnableFeignClients

  value里面写需要调用的应用名称
        @FeignClient(value = "order-service")
        public interface UserOrderFeign {

   //需要哪个controller就写它的方法签名
            @GetMapping("doOrder")
            public String doOrder();
   }

   Feign的默认超时时间是1秒，超过1s就超时报错
    Feign是一个远程调用的组件 (接口，注解) http调用的Feign集成了ribbon,ribbon里面集成了eureka
    所以要修改超时时间就是要修改ribbon的超时时间
    ribbon:
      ReadTimeout:3000  给3s超时时间
      ConnectTimeout:3000 链接服务的超时时间

OpenFeign总结：
1.OpenFeign的作用？

OpenFeign主要基于接口和注解实现了远程调用

2.OpenFeign 用过吗？它是如何运作的？

在主启动类上加上@EnableFeignClients注解后，启动会进行包扫描，把所有加了@FeignClient(value=”xxx-service”)注解的接口进行创建代理对象通过代理对象，使用ribbon做了负载均衡和远程调用

3.如何创建的代理对象？

当项目在启动时，先扫描，然后拿到标记了@FeignClient注解的接口信息，由ReflectiveFeign类的newInstance方法创建了代理对象JDK代理

4.OpenFeign到底是用什么做的远程调用？

使用的是HttpURLConnection（java.net）

5.OpenFeign怎么和ribbon 整合的？

在代理对象执行调用的时候

SpringCloud Hystrix

熔断器，也叫断路器！（正常情况下 断路器是关的 只有出了问题才打开）用来保护微服务不雪崩的方法。思想和我们上面画的拦截器一样。
Hystrix是Netflix公司开源的一个项目，它提供了熔断器功能，能够阻止分布式系统中出现 联动故障。
Hystrix 是通过隔离服务的访问点阻止联动故障的，并提供了故障的解决方案，从 而提高了整个分布式系统的弹性

什么是服务雪崩？

1.当用户访问A的一个接口，A的tomcat会给用户分配一个线程， 支持用户访问
2.A发现要完成用户的操作，需要访问B服务，A去访问B
3.B的tomcat会给A分配一个线程，支持A的访问
4.B发现需要完成A的操作，必须访问C服务,但是C挂了,B在访问C之前不知道C挂了，B去访问，直到超时，才知道C无法访问
结果:因为C不可用，导致B的线程不能及时回收，从而导致A的线程也无法及时回收，导致整个服务链里面的线程池没有线程可用了。
此时再有用户访问A,那么tomcat直接报503，服务不可用，本质就是线程没有及时回收

服务雪崩怎么解决？

1.修改调用的超时时长（不推荐）

将服务间的调用超时时长改小，这样就可以让线程及时回收，保证服务可用
优点：非常简单，也可以有效的解决服务雪崩
缺点：不够灵活，有的服务需要更长的时间去处理（写库，整理数据）

2.设置拦截器

实现Hystrix步骤
1.添加 Hystrix 的依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

2.创建 OrderServiceHystrix 实现 OrderServiceFeign接口（代替方案）

@Component
        public class OrderServiceHystrix implements OrderServiceFeign {
        @Override
        public String doOrder() {
            System.out.println("调用下单服务失败，我走 hystrix 了");
               return "我是 hystrix 的 doOrder，说明下单失败了";
            }
        }

3.修改 OrderServiceFeign 增加一个 fallback属性

@FeignClient(value = "provider-order-service",fallback = OrderServiceHystrix.class)

4.修改配置文件

   feign:
        hystrix:
            enabled: true #开启断路器的使用