SpringCloud总结

1、什么是微服务？

微服务的核心就是将传统的一站式应用，根据业务拆分成一个一个独立的服务，彻底地去耦合，每个微服务提供单个业务功能的服务，相当于一种小而独立的处理过程，类似于进程的概念，能够单独启动或销毁。

2、SpringCloud和SpringBoot的关系

• SpringBoot专注于快速方便地开发单个个体微服务。（微观角度）
• SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来。（宏观角度）
• SpringBoot可以单独使用来开发项目，而SpringCloud必须依赖于SpringBoot。

3、SpringCloud和Dubbo的区别？

	Dubbo	SpringCloud
服务注册中心	Zookeeper	Spring Cloud Netflix Eureka
服务调用方式	RPC	REST API
服务监控	Dubbo-monitor	Spring Boot Admin
断路器	不完善	Spring Cloud Netflix Hystrix
服务网关	无	Spring Cloud Netflix Zuul
分布式配置	无	Spring Cloud Config
服务跟踪	无	Spring Cloud Sleuth
消息总线	无	Spring Cloud Bus
数据流	无	Spring Cloud Stream
批量任务	无	Spring Cloud Task

最大的区别：SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的Rest方式。Rest牺牲了服务调用的性能，但灵活性比RPC更高，对于不同的系统，只要遵守HTTP协议，就可以进行通信，不再受到语言级别的限制。

4、Eureka服务注册中心

• （1）Eureka的原理与作用：

Eureka是SpringCloud的服务注册中心。
Eureka采用C/S架构，会有一个微服务作为Eureka Server，用于接收其他微服务的登记注册，其他的微服务作为Eureka Client，将自己注册在Eureka Server。
Eureka Server通过心跳检测每个微服务是否存活，每个微服务（Eureka Client）也可以定期从Eureka Server获取当前所有的微服务列表。

• （2）Eureka Server不需要注册进自己的服务列表，并且不需要拉取服务列表
  
• （3）微服务注册进Eureka Server
  
• （4）Eureka的自我保护机制

某一时刻某个微服务不可用了，Eureka不会立刻将其清除掉，依旧会对该微服务的信息进行保存，并且会弹出Emergency警告。宁可错误的微服务注册信息，也不会盲目注销任何可能健康的微服务。自我保护机制可以让Eureka集群更加健壮、稳定。

• （5）配置Eureka集群

Eureka Server有可能会挂掉，导致服务不能进行注册和发现，可以通过配置Eureka集群来解决这个问题，即使一个Eureka
Server挂掉了，还是可以照样工作，这是一种高可用的解决方案。 方法：配置多个Eureka Server，将每个Eureka Server注册进其他的Eureka Server的服务列表，将每个Eureka Client注册进所有的Eureka Server的服务列表。

• （6）Eureka比Zookeeper好在哪里？

  Zookeeper保证的是CP，而Eureka保证的是AP。

CAP理论是分布式系统中对数据的管理而形成一套理论知识，CAP是设计分布式系统所必须考虑的架构问题。对于CAP本身可以解释如下：

Consistency(一致性)： 数据一致更新，所有数据变动都是同步的
Availability(可用性)： 好的响应性能
Partition tolerance(分区耐受性)： 可靠性
CAP原理认为，一个提供数据服务的存储系统无法同时完美的满足一致性（Consistency）、数据可用性（Availability）、分区耐受性（Partition Tolerance）这三个条件，而只能满足其中的两个，而对于分布式系统来说，P时必须要满足的，C和A只能选择一个。
对于大型的网站来说，由于访问量特别大，所以要保证系统不能瘫痪，一般会选择AP型系统架构

5、Ribbon负载均衡

• （1）Ribbon的原理与作用

负载均衡LB（load balance）包括集中式LB和进程内LB。
--------集中式LB是指在服务消费者和服务提供者之间有一个独立的LB，集中式LB又分为基于硬件的LB（如F5）和基于软件的LB（如nginx）。
--------进程内LB也被称为软负载，或客户端负载方案，是在服务提供方部署LB，需要一个服务注册表配合支持。Spring Cloud Ribbon就属于进程内LB，是基于Netflix Ribbon实现的一套客户端负载均衡工具。可以依托于Eureka提供的服务注册表实现负载均衡。

• （2）Ribbon的开启方法

  首先，部署同一种服务的多个实例，这些实例要设置不同的端口，但是具有相同的application.name，可以连接不同的数据库。
  
  
  
  
  然后，在服务消费方（客户端）开启负载均衡@LoadBalanced
  
  然后，加上@EnableEurekaClient注解让客户端可以在注册中心拉取服务列表，但是本身并不注册进Eureka
  
  最后，通过application.name访问微服务

• （3）更改负载均衡算法

Spring Cloud Ribbon默认采用轮询的负载均衡算法，它也提供了多种负载均衡算法的实现类，这些类都实现了IRule接口。

我们可以通过在配置类中注册Bean的方式更换负载均衡算法

也可以通过继承AbstractLoadBalancerRule（implements IRule）抽象类来实现自定义的负载均衡算法。

6、Feign服务调用

• Feign的原理与作用

Feign集成了Ribbon，利用ribbon维护服务列表，通过轮询实现客户端的负载均衡。而与Ribbon不同的是，通过Feign只需要定义服务绑定接口并且以声明式的方法，优雅而简单地实现了服务调用。

7、Hystrix断路器

• （1）Hystrix的原理与作用

在分布式系统中，服务与服务之间依赖错综复杂，一种不可避免的情况就是某些服务将会出现失败。Hystrix是一个库，它提供了服务与服务之间的容错功能，主要体现在延迟容错和容错，从而做到控制分布式系统中的联动故障。Hystrix通过隔离服务的访问点，阻止联动故障，并提供故障的解决方案，从而提高了这个分布式系统的弹性。

• （2）服务熔断

当某个服务出现故障（服务宕机）或者引起异常（比如要查询的数据在数据库中不存在），这个时候直接熔断整个服务，同时会向调用方返回一个符合预期的、可处理的备选响应（Fallback），而不是长时间的等待或者抛出没有处理过的异常信息，这就是服务的熔断。

• （3）服务降级

服务降级是从整体负荷考虑，当整体资源不够用时（访问量特别大的情况），会将一些访问量较小的服务关掉，不再提供对该服务的访问，当有客户端再来访问该服务时，会触发自己准备的一个本地的fallback回调，也不是一直等待下去。服务降级保证了系统整体的可用性。

• (4)HystrixDashBoard

HystrixDashBoard是Hystrix提供的服务监控机制，它提供了一个图形化界面，可以清晰地观察每个微服务的访问量和可用性。
使用HystrixDashBoard需要创建一个微服务并在启动类上加@EnableHystrixDashboard注解作为一个监控服务，并且要在被监控的微服务中引入actuator的依赖，以告诉监控中心当前服务是可以被监控的。

8、Zuul网关

Zuul是SpringCloud的网关，提供了 代理 + 路由 + 过滤 三大功能。

• 代理功能是将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的信息，即以后的微服务访问都是通过Zuul跳转后获得
• 路由功能负责将外部请求转发到具体的微服务实例上，是实现外部统一访问入口的基础。
• 过滤功能负责对请求的处理过程进行干预，实现请求校验、服务聚合等功能的基础。

使用方法：

• （1）创建网关微服务，启动类上开启zuul功能
  
• （2）将网关微服务注册进Eureka Server
  
• （3）添加路由配置
  

9、 Config分布式配置中心

SpringCloud Config和Eureka一样，也分为服务端和客户端。
服务端称为分布式配置中心，是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口。
客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。