服务治理之Eureka--基本介绍_eureka 实现服务治理是什么意思

CAP

CAP原则指的是：在一个分布式系统中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性）三者不可兼得，只能得其中两者。

• Consistency（一致性）：所有节点在同一时刻，所有的数据完全一致
• Availability（可用性）：部分节点发生故障后，集群还能够继续响应客户端请求
• Partition tolerance（分区容错性）：即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。

CAP如何权衡？

• CA without P：强调数据一致性和高可用，如果没有P，代表不需要分区，则可以保证CA，但丢失了系统的扩展性。
• CP without A：强调数据一致性和分区，而分区会导致数据同步的时间无限延长。一旦发生某些节点故障，就会导致请求不可用。很多传统的数据库分布式事务都属于这种模式，还有银行业务。
• AP without C：强调高可用和分区，一旦某些节点发生故障，为了高可用，每个节点只能用本地数据提供服务，AP最大的不足就是会导致数据的不一致性。现在众多的NoSQL都属于此类

总的来说，目前大多数互联网集群规模越来越大，基本都是保证AP，舍弃C（能够保证最终一致性），尽管有些地方影响用户体验，但至少不会影响用户正常操作流程。

ACID

在CA的时候可以保证ACID，分别表示：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）

BASE

在AP的时候可以保证BASE，BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果

• Basically Available（基本可用）：在分布式系统发生故障时，允许损失部分可用性，如响应时间由原本的50ms降到100ms
• Soft state（软状态）：允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性。即允许不同节点的数据副本之间进行数据同步的过程存在延时
• Eventually consistent（最终一致性）：系统中所有数据的副本在一定时间的同步后，最终都能够达到一个一致的状态

什么是Eureka？

Eureka服务治理技术的一种实现。
服务治理可以说是微服务架构中最为核心和基础的模块，它主要用来实现各个微服务实例的自动化注册和服务发现

为什么需要Eureka？

在没有使用服务治理的时候，服务是运行在一个固定的IP+端口上，如果服务A要调用服务B，则直接通过地址进行调用。但是，在虚拟化的容器环境中，IP和端口是频繁变化的，那么服务地址就是在动态变化。因此就有了服务治理的概念，也就有了Eureka

Eureka拥有哪些能力（服务治理机制）？

Eureka主要拥有如下核心功能：

• 服务注册功能：服务提供者或服务消费者在启动的时候通过发送REST请求的方式将自己注册到Eureka Server上，同时带上了自身服务的一些元数据信息（包含ip、port、url等信息），Eureka Server在收到这个请求后将元数据信息存储在一个双层Map结构中，第一层的key是服务名，第二层的key是具体服务的实例名

• 服务续约功能：注册的服务会定期向注册中心发送一个心跳来告诉Eureka Server自己还活着，避免被Eureka Server剔除服务列表

   #  这个参数是定义服务续约的调用间隔时间，【默认为30秒】。
   eureka.instance.lease-renewal-interval-in-seconds= 30
   # 这个参数是定义服务失效时间，【默认为90秒】。
   eureka.instance.lease-expiration-duration-in-seconds= 90 
  1
  2
  3
  4

• 服务同步功能：多个服务中心之间相互注册为服务，通过服务同步，其中某个服务提供者的服务信息就可以通过这任意一台服务注册中心的中获取到。

• 服务获取功能：获取当前服务列表，该缓存清单默认是30秒更新一次。

  # 这个参数用来修改缓存清单更新的时间间隔，时间单位为秒。
   eureka.client.registry-fetch-interval-seconds= 30 
  1
  2

• 服务调用功能：服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息（ip、port、url等），服务消费者可以根据需要调用哪个实例

• 服务下线功能：当服务提供者或消费者下线会主动发送一个下线请求到服务端

• 服务剔除功能： 当某个服务提供者出现网络故障、内存溢出等各种原因而不能正常工作，服务中心并未收到 “服务下线” 的请求。为了能及时将这些无法提供服务的实例剔除，Eureka Server在启动的时候会创建一个定时任务，默认是60秒一次，将没有续约也就是没有发送”心跳“的服务剔除出去。

• 服务的自我保护
  在开发的时候，我们是直接停止进程，因此不会向注册中心发送下线消息，所以经常收到一些红色警告信息：
  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.

  自我保护机制的工作机制是如果在15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka Server就认为客户端与注册中心出现了网络故障，Eureka Server自动进入自我保护机制，在启动自我保护后行为如下：

  1. Eureka Server不再从服务列表中剔除因为长时间没有收到心跳而应该剔除的服务
  2. Eureka Server能够继续接受新服务的注册和查询请求，但不会被同步到其它节点上，保证当前节点依然可用
  3. 当网络恢复后，当前Eureka Server的服务列表会被同步到其它节点中

  # 可以通过这个配置设置为false来关闭自我保护机制，默认识开启的，且建议在生产环境开启自我保护
  eureka.server.enable-self-preservation= false
  1
  2

  因为有自我保护机制，因此Eureka Server在网络故障导致部分节点失联的情况下还是可以正常工作，而不会像zookeeper那样，如果有一半节点不可用将导致整个集群瘫痪。

五种服务治理技术对比

总结

在微服务中理解CAP原则很重要，可以发现zookeeper、mysql、oracle等都是只能得其二，不可三者兼得。之后对服务治理机制做了详细的介绍并对比了市面上常见的五种服务治理框架的特点，通过本文的介绍可以帮助了解服务治理背后的基本思路。

参考

• 分布式系统的CAP理论