微服务之服务治理

首先需要明确，不管是什么事物需要”治理“，那一定是该事物存在一定问题。比如环境治理。那么服务，或者说微服务为什么需要治理？对于服务来说，如果它承担的业务职责简单，那其实治理的必要性不大，因为服务运行过程是相对透明的，即使出现问题也能较快发现、定位、回滚。当服务承担的业务职责变多变大，那随着更多问题的到来，服务治理开始变得必要。服务治理也与技术架构本身息息相关。

微服务系统为什么要服务治理

微服务系统由很多个单一职责的服务单元组成，例如Netflix公司的系统是由600多个微服务构成的，而每一个微服务又有众多实例。由于微服务系统的服务粒度较小，服务数量众多，服务之间的相互依赖成网状，所以微服务系统需要服务注册中心来统一管理微服务实例，方便查看每一个微服务实例的健康状态。

服务治理的目标

高可用

在服务治理下的微服务，只要有一个节点服务正常，就要保证服务的可用性

分布式调用

微服务的节点散落在不同网络环境中，服务治理就需要在复杂的网络中准确的获得服务节点的网络地址。

生命周期管理

微服务把自己交给服务治理进行管理，如同bean交给spring

健康度检查

当服务节点不能正常工作，服务治理可以将其剔除

服务治理的解决方案

服务注册：服务提供方主动自报家门

服务注册是指向服务注册中心注册一个服务实例，服务提供者将自己的服务信息（如服务名、IP地址等）告知服务注册中心。

服务发现：服务消费者拉取注册数据

服务发现是指当服务消费者需要消费另外一个服务时，服务注册中心能够告知服务消费者它所要消费服务的实例信息（如服务名、IP地址等）。通常情况下，一个服务既是服务提供者，也是服务消费者。服务消费者一般使用HTTP协议或者消息组件这种轻量级的通信机制来进行服务消费。

心跳检测、服务续约和服务剔除

服务注册中心会提供服务的健康检查方案，检查被注册的服务是否可用。通常一个服务实例注册后，会定时向服务注册中心提供“心跳”，以表明自己还处于可用的状态。当一个服务实例停止向服务注册中心提供心跳一段时间后，服务注册中心会认为该服务实例不可用，会将该服务实例从服务注册列表中剔除。如果这个被剔除掉的服务实例过一段时间后继续向注册中心提供心跳，那么服务注册中心会将该服务实例重新加入服务注册中心的列表中

服务下线：服务提供方主动发起下线

服务治理的技术选型

	Eureka	Consul	Nacos
一致性	AP	AP	AP/CP
性能	快	慢	快
应用	主流	非主流	稳中有升

注意: 我们现在公司用的nacos主要用的是nacos config

Eureka

下面主要介绍下Eureka。Eureka server和client的搭建这里不做介绍。之前分享zuul网关的代码中已经说过

注意:Eureka是基于CAP定理的AP系统

Eureka 管理界面介绍

Current time：当前的系统时间
Uptime：已经运行了多少时间
Lease expiration enabled：是否启用租约过期，自我保护机制关闭时，该值默认是true，自我保护机制开启之后为false。和自我保护互斥
Renews threshold：每分钟最少续约数，Eureka Server 期望每分钟收到客户端实例续约的总数。
Renews (last min)：最后一分钟的续约数量（不含当前，1分钟更新一次），Eureka Server 最后 1 分钟收到客户端实例续约的总数。

红字提醒

自我保护机制开启

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE

NOT BEING EXPIRED JUST TO BE SAFE.

// 挂掉的服务有可能会被错误的当做UP，（在一定时间内）续约成功的节点个数占已注册总服务的比值，已经低于限定值，因此所有节点都不会过期，服务自保开启

主动关闭了自我保护机制

THE SELF PRESERVATION MODE IS TURNED OFF.THIS MAY NOT PROTECT INSTANCE EXPIRY IN CASE OF NETWORK/OTHER PROBLEMS.

公司内就出现了上面的提示。说明我们部署的server是主动关闭了自我保护机制

自我保护机制

Eureka的自我保护特性主要用于减少在网络分区或者不稳定状况下的不一致性问题

自我保护机制产生的原因

Eureka在运行期间会统计心跳成功的节点。如果15分钟内所有成功续约的节点占所有注册节点85%以下

Eureka Server会将当前的实例注册信息保护起来，同时提示一个警告，一旦进入保护模式，

Eureka Server将会尝试保护其服务注册表中的信息，不再删除服务注册表中的数据。也就是不会注销任何微服务。

上面提到公司是主动关闭了自我保护机制。虽然看不到server的代码可以猜测出公司的配置

Eureka Server端：配置关闭自我保护，并按需配置Eureka Server清理无效节点的时间间隔。

eureka.server.enable-self-preservation# 设为false，关闭自我保护

eureka.server.eviction-interval-timer-in-ms # 清理间隔（单位毫秒，默认是60*1000）

Eureka Client端：配置开启健康检查，并按需配置续约更新时间和到期时间

eureka.instance.lease-renewal-interval-in-seconds# 续约更新时间间隔（默认30秒）

eureka.instance.lease-expiration-duration-in-seconds # 续约到期时间（默认90秒）

首先需要明确，不管是什么事物需要”治理“，那一定是该事物存在一定问题。比如环境治理。那么服务，或者说微服务为什么需要治理？对于服务来说，如果它承担的业务职责简单，那其实治理的必要性不大，因为服务运行过程是相对透明的，即使出现问题也能较快发现、定位、回滚。当服务承担的业务职责变多变大，那随着更多问题的到来，服务治理开始变得必要。服务治理也与技术架构本身息息相关。

### 微服务系统为什么要服务治理

微服务系统由很多个单一职责的服务单元组成，例如Netflix公司的系统是由600多个微服务构成的，而每一个微服务又有众多实例。由于微服务系统的服务粒度较小，服务数量众多，服务之间的相互依赖成网状，所以微服务系统需要服务注册中心来统一管理微服务实例，方便查看每一个微服务实例的健康状态。

### 服务治理的目标

- 高可用

> 在服务治理下的微服务，只要有一个节点服务正常，就要保证服务的可用性

- 分布式调用

> 微服务的节点散落在不同网络环境中，服务治理就需要在复杂的网络中准确的获得服务节点的网络地址。

- 生命周期管理

> 微服务把自己交给服务治理进行管理，如同bean交给spring

- 健康度检查

> 当服务节点不能正常工作，服务治理可以将其剔除

### 服务治理的解决方案

- 服务注册：服务提供方主动自报家门

> 服务注册是指向服务注册中心注册一个服务实例，服务提供者将自己的服务信息（如服务名、IP地址等）告知服务注册中心。

- 服务发现：服务消费者拉取注册数据

> 服务发现是指当服务消费者需要消费另外一个服务时，服务注册中心能够告知服务消费者它所要消费服务的实例信息（如服务名、IP地址等）。通常情况下，一个服务既是服务提供者，也是服务消费者。服务消费者一般使用HTTP协议或者消息组件这种轻量级的通信机制来进行服务消费。

- 心跳检测、服务续约和服务剔除

>  服务注册中心会提供服务的健康检查方案，检查被注册的服务是否可用。通常一个服务实例注册后，会定时向服务注册中心提供“心跳”，以表明自己还处于可用的状态。当一个服务实例停止向服务注册中心提供心跳一段时间后，服务注册中心会认为该服务实例不可用，会将该服务实例从服务注册列表中剔除。如果这个被剔除掉的服务实例过一段时间后继续向注册中心提供心跳，那么服务注册中心会将该服务实例重新加入服务注册中心的列表中

- 服务下线：服务提供方主动发起下线

### 服务治理的技术选型

||Eureka | Consul| Nacos|

---|---|---|---|

一致性 | AP | AP|AP/CP|

性能 | 快 | 慢|快|

应用 | 主流 | 非主流|稳中有升|

> 注意: 我们现在公司用的nacos主要用的是nacos config

### Eureka

> 下面主要介绍下Eureka。Eureka server和client的搭建 这里不做介绍。之前分享zuul网关的代码中已经说过

*注意*:Eureka是基于CAP定理的AP系统

#### Eureka 管理界面介绍

![](https://img2020.cnblogs.com/blog/891580/202005/891580-20200505221732055-519491829.png)

- Current time：当前的系统时间

- Uptime：已经运行了多少时间

- Lease expiration enabled：是否启用租约过期 ，自我保护机制关闭时，该值默认是true， 自我保护机制开启之后为false。和自我保护互斥

- Renews threshold： 每分钟最少续约数，Eureka Server 期望每分钟收到客户端实例续约的总数。

- Renews (last min)： 最后一分钟的续约数量（不含当前，1分钟更新一次），Eureka Server 最后 1 分钟收到客户端实例续约的总数。

#### 红字提醒

- 自我保护机制开启

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE

NOT BEING EXPIRED JUST TO BE SAFE.

// 挂掉的服务有可能会被错误的当做UP，（在一定时间内）续约成功的节点个数占已注册总服务的比值，已经低于限定值，因此所有节点都不会过期，服务自保开启

- 主动关闭了自我保护机制

THE SELF PRESERVATION MODE IS TURNED OFF.THIS MAY NOT PROTECT INSTANCE EXPIRY IN CASE OF NETWORK/OTHER PROBLEMS.



> 公司内就出现了上面的提示。说明我们部署的server是主动关闭了自我保护机制

#### 自我保护机制

Eureka的自我保护特性主要用于减少在网络分区或者不稳定状况下的不一致性问题

自我保护机制产生的原因

Eureka在运行期间会统计心跳成功的节点。如果15分钟内所有成功续约的节点占所有注册节点85%以下

Eureka Server会将当前的实例注册信息保护起来，同时提示一个警告，一旦进入保护模式，

Eureka Server将会尝试保护其服务注册表中的信息，不再删除服务注册表中的数据。也就是不会注销任何微服务。

上面提到公司是主动关闭了自我保护机制。虽然看不到server的代码可以猜测出公司的配置

Eureka Server端：配置关闭自我保护，并按需配置Eureka Server清理无效节点的时间间隔。

eureka.server.enable-self-preservation# 设为false，关闭自我保护

eureka.server.eviction-interval-timer-in-ms # 清理间隔（单位毫秒，默认是60*1000）

 Eureka Client端：配置开启健康检查，并按需配置续约更新时间和到期时间

eureka.instance.lease-renewal-interval-in-seconds# 续约更新时间间隔（默认30秒）

eureka.instance.lease-expiration-duration-in-seconds # 续约到期时间（默认90秒）



看看 公司client 的配置

eureka:

instance:

prefer-ip-address: true

instance-id: \({spring.application.name}:\){spring.client.ipAdress}{server.port}

lease-expiration-duration-in-seconds: 30 #服务过期时间配置,超过这个时间没有接收到心跳EurekaServer就会将这个实例剔除

lease-renewal-interval-in-seconds: 10 #服务刷新时间配置，每隔这个时间会主动心跳一次

看看公司client 的配置

eureka:

  instance:

    prefer-ip-address: true

    instance-id: ${spring.application.name}:${spring.client.ipAdress}:${server.port}

    lease-expiration-duration-in-seconds: 30 #服务过期时间配置,超过这个时间没有接收到心跳EurekaServer就会将这个实例剔除

    lease-renewal-interval-in-seconds: 10 #服务刷新时间配置，每隔这个时间会主动心跳一次