Spring Cloud Nexflix组件

一、微服务

1.微服务与微服务架构

微服务架构是一种架构模式，提倡将单一应用划分成一组小的服务，每个服务运行在其独立的自己的进程中，服务之间互相协调、互相配合。服务之间采用轻量级的通信机制交互。

微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底的去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度来看就是一种小而独立的处理过程，类似于进程概念，能够自行单独启动或销毁，拥有各自的数据库。

微服务强调的是个体，微服务架构强调的是整体，是把一个个的微服务整合起来，对外暴露，是一个整体。

设计目的

该架构的设计目标是为了肢解业务，使得服务能够独立运行。

微服务设计原则:

• 各司其职。
• 服务高可用和可扩展性。

2.微服务的优缺点

优点

• 每个服务足够内聚，足够小，代码容易理解，更容易聚焦一个指定的业务功能或需求
• 开发简单、开发效率提高，一个服务可能只专门做一件事
• 微服务是松耦合的，每一个都是可以独立更新迭代的，不影响其他的微服务
• 易于被一个开发理解，修改和维护
• 允许开发人员利用融合最新技术
• 可以使用不同的语言进行开发
• 微服务只是业务逻辑的代码，不会和HTML、CSS或其他界面组件混合
• ... ...

缺点

• 微服务增加了系统维护、部署的难度。-- 前期架构需要更多的工作量。
• 分布式的架构维护难度更高。
• 问题跟踪更难。
• 随着微服务的增加数据一致性的问题就凸显，服务之间的通信成本也会增加

-- 由于每个服务单元都是独立的，它们之间需要通过网络接口进行通信。

这意味着存在更多的通信开销，这可能会影响应用程序的性能。

• 更多的测试和监控

-- 由于每个服务单元都是独立的，需要对每个服务单元进行单独的测试和监控。

这需要更多的时间和资源来确保每个服务单元的可靠性和性能。

二、Spring Cloud Netflix

组件名称	组件作用
Eureka	注册中心，服务注册、发现等
Ribbon	负载均衡，多服务时做负载
Fegin	服务间内部调用
Hystrix	熔断器，服务熔断、降级
Zuul	服务网关，所有外部请求经过网关进行过滤转发(路由+过滤+转发)

1.Eureka

负责服务的注册与发现。

服务注册中心，Eureka是Netflix的一个核心模块，是一个基于Rest的服务，用于定位服务，以实现云端中间层服务发现和故障转移。

包含两个部分：

Eureka Server（服务注册服务）：各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。

Eureka Client（Java客户端）：用于简化Eureka Server的交互，同时内置使用轮询负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳（默认周期为30秒）。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除。（默认90秒）。

服务治理的基础角色

服务注册中心: 提供服务注册与发现的能力。

服务提供者: 提供服务的应用，会把自已提供的服务注册到注册中心。

服务消费者: 服务的消费者，从注册中心获取服务列表。

Eureka的自我保护机制

某一个微服务不可用了，Eureka不会立刻清理，依旧会对该微服务的信息进行保存。在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该Eureka Server节点就会自动退出自我保护模式。

设计初衷就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。使用自我保护模式，可以让Eureka集群更加的健壮、稳定。

可以使用 eureka.server.enable-self-preservation=false 禁用自我保护模式。

Eureka和ZooKeeper的区别

CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。

Zookeeper保证的是CP(一致性和分区容错性)，Eureka则是AP(可用性和分区容错性)。

	Eureka在设计优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，
	剩余的节点依赖可以提供注册和查询服务。如何某个Eureka注册失败，则自动切换至其他节点，
	所以只要有一台Eureka还在，就能保证注册服务可用，只是查到的信息可能不是最新的。

Eureka比Zookeeper的优势在?

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

使用到的注解

@EnableEurekaServer // 服务注册与发现中心

@EnableEurekaClient // Eureka的客户端

2.Ribbon

负责客户端调用的负载均衡。

Ribbon是Netflix公司提供的一个基于HTTP和TCP的客户端负载均衡工具。

提供云端负载均衡，有多种负载均衡策略可供选择，可配合服务发现和断路器使用。

使用Ribbon

1. 导入依赖

首先引入Ribbon依赖，Ribbon的使用依赖Eureka。

   <dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-eureka</artifactId>
   </dependency>
   <dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-ribbon</artifactId>
   </dependency>

1. 创建配置类

使用RestTemplate进行Eureka Client(包括服务提供者以及服务消费者，在这里其实是服务消费者使用RestTemplate)之间的通信，为RestTemplate配置类添加@LoadBalanced注解即可。

1. 解决硬编码问题

使用添加@LoadBalanced注解后的RestTemplate调用服务提供者的接口时，可以使用虚拟IP替代真实IP地址。所谓的虚拟IP就是服务提供者在application.properties或yml文件中配置的spring.application.name属性的值。(也就是在Eureka中注册的名字)

以前：

使用Ribbon后

Ribbon和Eureka整合后Consumer可以直接调用服务而不用再关心ip地址和端口号。

Ribbon组件IRule(负载均衡)

-- 负载均衡就是将负担（工作任务，访问请求）进行分摊到多个操作单元（服务器,组件）上进行执行。

默认的是RoundBobinRule（轮询）

使用：配置类中添加负载均衡规则即可

3.Fegin

可以让我们通过定义接口的方式直接调用其他服务的API。

什么是Feign

Feign是一种声明式、模板化的HTTP客户端。

Feign优点

1.feign采用的是基于接口的注解。

2.feign整合了ribbon，具有负载均衡的能力。

3.整合了Hystrix，具有熔断的能力。

使用步骤

导入依赖

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

1. 在启动类上加入注解 @EnableFeignClients

-- 主要是为开启feign接口扫描

1. 在服务提供者 (provider) 的controller层中调用service层获取数据

1. 在 consumer 中创建fegin接口

1. 在consumer中调用方法，实现远程调用

4.Hystrix

负责服务之间远程调用时的容错保护。

简介

Spring Cloud Hystrix 是基于 Netflix 公司的开源组件 Hystrix 实现的，它提供了熔断器功能，能够有效地阻止分布式微服务系统中出现联动故障，以提高微服务系统的弹性。Spring Cloud Hystrix 具有服务降级、服务熔断、线程隔离、请求缓存、请求合并以及实时故障监控等强大功能。

功能

• 保护线程资源：防止单个服务的故障耗尽系统中的所有线程资源。
• 快速失败机制：当某个服务发生了故障，不让服务调用方一直等待，而是直接返回请求失败。
• 提供降级（FallBack）方案：在请求失败后，提供一个设计好的降级方案，通常是一个兜底方法，当请求失败后即调用该方法。
• 防止故障扩散：使用熔断机制，防止故障扩散到其他服务。
• 监控功能：提供熔断器故障监控组件 Hystrix Dashboard，随时监控熔断器的状态。

什么是服务熔断？

Hystrix 是针对微服务分布式系统的熔断保护中间件，服务熔断的作用类似于电路中的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。

什么是服务降级？

服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。

微服务开发的目标是：可以雪落 但是不可以雪崩！

Hystrix 有三种触发降级的策略，分别是

• 熔断触发降级；
• 请求超时触发降级；
• 资源隔离触发降级。

熔断触发降级

1. 断路器的三种状态

• 关闭状态 closed：所有的请求都是正常的!
• 打开状态 open：请求出现降级，直接触发降级策略，不调用远程服务。
• 半开状态 half open：open状态不是永久的打开后会进入休眠(5S) 断路器就会进入半开状态。或者是尝试调用远程服务；

1. 三种状态之间切换的过程

1. 1. “半打开”转换“关闭”：在熔断处于半打开状态时，请求可以达到后端服务，如果累计一定的成功次数后，状态切换到关闭态。
   2. “打开”转换“半打开”：当熔断处于打开状态时，我们会启动一个超时计时器，当计时器超时后，状态切换到半打开态；
   3. “关闭”转换“打开”：当服务调用失败的次数累积到一定的阈值时，服务熔断状态，将从关闭态切换到打开态。

请求超时触发降级

服务调用方配置的接口请求超时时间，请求超时后触发降级策略。

资源隔离触发降级

线程池隔离：针对不同服务通过不同的线程池处理请求，实现资源上的隔离；

信号量隔离：可以达到限流控制并发数的作用。

5.Zuul

API网关，是客户端请求的入口，负责鉴权，路由等功能。

Zuul 是 Netflix提供的网关组件，提供了路由、灰度、监控、限流、安全等服务，Zuul 能够与 Eureka、Ribbon、Hystrix 等组件配合使用。

优点：

• 方便监控。可以在微服务网管手机监控数据并将其推送到外部系统进行分析。
• 方便认证。可在网关进行统一认证，然后在讲请求转发到后端服务。
• 隐藏架构实现细节，提供统一的入口给客户端请求，减少了客户端和每个微服务的交互次数。
• 可以统一处理切面任务，避免每个微服务自己开发，提升效率。
• 高可用高伸缩性的服务、避免单点失效

核心

• 路由：将外部请求转发到具体的微服务实例上
• 过滤：负责将请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础

过滤器

过滤器是Zuul的核心内容，主要分为四种过滤器：

• pre 过滤器：可以在请求被路由之前调用。适用于身份认证的场景，认证通过后再继续执行下面的流程；
• route 过滤器：在路由请求时被调用。适用于灰度发布的场景，在将要路由的时候可以做一些自定义的逻辑；
• post 过滤器：在 route 和 error 过滤器之后被调用。这种过滤器将请求路由到达具体的服务之后执行。适用于添加响应头，记录响应日志等应用场景；
• error 过滤器：处理请求发生错误时被调用。在执行过程中发送错误时会进入 error 过滤器，可以用来统一记录错误信息。

使用到的注解

@EnableZuulProxy //启用网关

Config

用于统一的配置管理，Spring Cloud为微服务架构中的微服务提供集合化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。

当需要改变或添加环境配置时，之前的常规操作，都是需要打包重启服务，才能读取到最新的配置信息，而使用Spring Cloud Config可以进行非常灵活的配置，实时生效。

Config Server:配置中心服务端。

Config Client:配置中心客户端。

涉及到的注解

@EnableConfigServer //启用配置中心