SpringCloud相关重难点解析

什么是微服务：微服务是一种经过良好架构设计的分布式架构方案 。它提倡将单一的应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程内，服务之间相互协调，相互配置，为用户提供最终价值。

微服务的架构特征：

单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责

自治：团队独立、技术独立、数据独立，独立部署和交付

面向服务：服务提供统一标准的接口，与语言和技术无关

隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

单体架构：简单方便，高度耦合，扩展性差，适合小型项目。例如：学生管理系统

分布式架构：松耦合，扩展性好，但架构复杂，难度大。适合大型互联网项目，例如：京东、淘宝

微服务：一种良好的分布式架构方案

①优点：拆分粒度更小、服务更独立、耦合度更低

②缺点：架构非常复杂，运维、监控、部署难度提高

Spring Cloud是微服务架构的一站式解决方案，集成了各种优秀微服务功能组件

Spring Cloud和Spring Boot关系：

Spring Boot专注于快速方便的开发单个个体微服务。Spring Cloud是关注全局的微服务协调治理框架，他将Spring Boot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供：配置管理，服务器发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等集成服务。

Spring Boot可以离开Spring Cloud独立使用，开发项目，但是Spring Cloud离不开Spring Boot，属于依赖关系。

Spring Boot专注于快速方便的开发单个个体微服务，Spring Cloud关注全局的服务治理框架。
SpringCloud和Dubbo的区别：springcloud抛弃了Dobbo的rpc通信，采用的是基于HTTP的Rest方式。后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更加灵活，服务提供方和调用方的依赖只依靠协议，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。解决问题的领域不一样：Dubbo的定位是一款RPC框架，SpringCloud的目标是微服务架构下的一站式解决方案。

Eureka服务注册与发现

Eureka是Netflix的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移，服务注册与发现对于微服务来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务了，而不需要修改服务调用的配置文件，功能类似于Dubbo的注册中心，比如Zookeeper。

Eureka的基本架构：SpringColud封装了NetFilx公司开发的Eureka模块来实现服务注册和发现；采用CS的架构设计，EurekaServer作为服务注册功能的服务器，他是服务注册中心；而系统中的其他微服务，使用EurekaServer的客户端连接到EurekaServer并维持心跳连接。这样系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行，SpringCloud的其他模块就可以通过EurekaServer来发现系统中的其他微服务，并执行相关的逻辑。

Eureka Server：提供服务的注册与发现

Service Provider：将自身服务注册到Eureka中，从而使消费方能够找到

Service Consumer：服务消费方从Eureka中获取注册服务列表，从而找到消费服务。

Eureka自我保护机制：某个时刻某一个微服务不可用了，Eureka不会立刻清理，依旧会对该服务的信息进行保存。默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务的心跳，EurekaServer将会注销该实例（默认90S）。但是当网络分区故障发生时，微服务与Eureka之间无法正常通行，以上行为可能变得非常危险，因为微服务本身是健康的，此时本不应该注销这个服务。Eureka通过自我保护机制来解决这个问题，当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据。当网络故障恢复后，改EurekaServer节点会自动退出自我保护模式。

自我保护模式是一种应对网络异常的安全保护措施，不盲目注销任何健康的微服务。

CAP：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，根据CAP原理，将NoSQL数据库分成了满足CA原则满足CP原则和满足AP原则三大类：

CA:单点集群，满足一致性，可用性的系统，通常可扩展性较差；

CP：满足一致性，分区容错性的系统，通常性能不是特别高；

AP：满足可用性，分区容错性的系统，通常可能一致性要求低一些。

作为服务注册中心，Eureka比Zookeeper好在哪里：

一个分布式系统不可能同时满足C（一致性）、A（可用性）、P（容错性）

由于分区容错性在分布式系统中不是必须要保证的，因此我们只能在A和C之间进行权衡，Zookeeper保证的是CP，Eureka保证的是AP。

当向注册中心查询服务列表时，我们可以容忍中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求高于一致性。

Zookeeper保证的是CP：对于zk会出现这样一种情况，当master节点因为网络故障与其他失去联系时，剩余节点就会重新进行leader选举。问题在于，选举leader的时间太长，30—120S，且选举期间整个ZK集群都是不可用的，这就导致在期间服务瘫痪。在云部署的环境下，因为网络问题使得ZK集群失去master节点是较大概率会发生的事件，虽然服务最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证的是AP

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务的可用性，只不过查不到的信息可能不是最新的，除此之外，Eureka还有一种自我保护机制，如果15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点依然可用）
3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点中

因此Eureka可以很好的应对网络故障导致的部分节点失去联系的情况，而不会像Zookeeper那样使整个注册服务瘫痪。

Ribbon：Spring Cloud Ribbon 是基于Netflix Ribbon实现的一套客户端负载均衡工具。简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。Ribbon的客户端组件提供一系列完整的配置项如：连接超时、重试等等。简单来说，就是在配置文件中列出文件中列出LoadBalancer后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。

Ribbon作用：LB，即负载均衡在微服务或者分布式集群中经常用的一种应用；

负载均衡简单的说就是将用户的请求平摊的分配到多个服务器上，从而达到系统的HA（高可用）；常见的负载均衡软件有Nginx，Lvs等；Dubbo、SpringCloud中均给我们提供了负载均衡，SpringCloud的负载均衡算法可以自定义。

负载均衡的简单分类：

集中式LB：即在服务的消费方和提供方之间使用独立的LB设施，如Nginx：反向代理服务器，由该设施负责把访问请求通过某种策略转发至服务的提供方。

进程式LB：将LB逻辑集成到消费方，消费方从服务注册中心获取哪些地址可用，然后通过自己再从这些地址中选出一个合适的服务器，Ribbon就属于一个进程LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址。

Feign负载均衡：feign是声明式的web service客户端，它让微服务之间的调用变得简单了，类似controller调用service，Spring Cloud集成了Ribbon和Eureka，可以使用Feign时提供负载均衡的http客户端。

只需要创建一个接口，然后添加注解即可。

Feign，主要是社区，大家都习惯面向接口编程，调用微服务访问两种方法1微服务名字（ribbon）2接口和注解

Feign作用：使得编写Java HTTP客户端变得更容易，前面在使用Ribbon+RestTemplate时，利用RestTemplate对RestTemplate对HTTP请求的封装处理，形成了一套模板化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端来包装这些依赖服务调用。所以Feign在此基础上做了进一步封装，由他来帮助我们定义和实现依赖服务接口的定义，在Feign的实现下，我们只需要创建一个接口并使用注解的方式来配置它（类似于以前dao接口上标注Mapper注解现在是一个微服务接口上面标注一个Feign注解即可）即可完成对服务提供方的接口绑定，简化了使用Spring Cloud Ribbon时，自动封装服务调用客户端的开发量。Feign（接口方式）集成了Ribbon（url方式），不用关心IP和端口号。

服务雪崩：多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务这就是所谓的“扇出”、如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。

什么是Hystrix：Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等。Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务的失败，避免级联故障，以提高分布式系统的弹性。

“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方法返回一个服务预期的，可处理的备选响应，而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证服务的调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中蔓延，乃至雪崩。

服务熔断：熔断机制是对应雪崩效应的一种微服务链路保护机制

当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阀值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。