为什么需要服务注册中心

随着大数据和云计算时代的到来，任何独立的程序都可以运行在多个计算机上。并且随着业务的发展，访问用户量的增加，开发人员或小组的增加，系统会被拆分成多个功能模块。拆分后每个功能模块可以作为一个独立的子系统提供其职责范围内的功能。而多个子系统中，由于职责不同并且会存在相互调用，同时可能每个子系统还需要多个实例部署在多台服务器或者镜像中，导致了子系统间的相互调用形成了一个错综复杂的网状结构。

1. 单体应用：

2. 多系统架构：

对于微服务之间错综复杂的调用关系，通过服务中心来管理，可以让每个服务之间不用关心如何调用的问题，专注于自己的业务功能实现。

Eureka应用场景中的一些概念

微服务

Spring Cloud提供了微服务解决的一整套方案，而Eureka是其重要组件，所以先要了解什么是“微服务”。在大型系统架构中，会拆分多个子系统。这些系统往往都有这几个功能：提供接口，调用接口，以及该子系统自身的业务功能。这样的一个子系统就称为一个“微服务”。（可以理解为一个子系统的代码所实现的功能）

实例

每个服务都会部署到多个机器（或镜像）中，这些多个部署的应用就是实例。（可以理解为一套子系统代码被部署到了多个机器上）

Eureka的管理

• 服务需要有一个统一的名称（或服务ID）并且是唯一标识，以便于接口调用时各个接口的区分。并且需要将其注册到Eureka Server中，其他服务调用该接口时，也是根据这个唯一标识来获取。
• 服务下有多个实例，每个实例也有一个自己的唯一实例ID。
  

eureka如何管理服务调用

eureka系统调用图：

• 在Eureka Client启动的时候，将自身的服务的信息发送到Eureka Server。然后进行2调用当前服务器节点中的其他服务信息，保存到Eureka Client中。当服务间相互调用其它服务时，在Eureka Client中获取服务信息（如服务地址，端口等）后，进行第3步，根据信息直接调用服务。（注：服务的调用通过http(s)调用）
• 当某个服务仅需要调用其他服务，自身不提供服务调用时。在Eureka Client启动后会拉取Eureka Server的其他服务信息，需要调用时，在Eureka Client的本地缓存中获取信息，调用服务。
• Eureka Client通过向Eureka Serve发送心跳（默认每30秒）来续约服务的。 如果客户端持续不能续约，那么，它将在大约90秒内从服务器注册表中删除。 注册信息和续订被复制到集群中的Eureka Serve所有节点。 以此来确保当前服务还“活着”，可以被调用。
• 来自任何区域的Eureka Client都可以查找注册表信息（每30秒发生一次），以此来确保调用到的服务是“活的”。并且当某个服务被更新或者新加进来，也可以调用到新的服务。

通过官方文档深入了解：

us-east-1c、us-east-1d、us-east-1e这些代表了一个可用区region，我们可以理解为不同机架、不同机房等地域上的隔离。每一个region都部署一套Eureka Server，保证内部访问的速度和稳定性。而跨region则保证了集群的高可用。实现异地灾备或者应用双活。

1. Eureka Server：

   • 提供服务注册：各个微服务启动时，会通过Eureka Client向Eureka Server进行注册自己的信息（例如服务信息和网络信息），Eureka Server会存储该服务的信息。
   • 提供服务信息提供：服务消费者在调用服务时，本地Eureka Client没有的情况下，会到Eureka Server拉取信息。
   • 提供服务管理：通过Eureka Client的Cancel、心跳监控、renew等方式来维护该服务提供的信息以确保该服务可用以及服务的更新。
   • 信息同步：每个Eureka Server同时也是Eureka Client，多个Eureka Server之间通过P2P复制的方式完成服务注册表的同步。同步时，被同步信息不会同步出去。也就是说有3个Eureka Server，Server1有新的服务信息时，同步到Server2后，Server2和Server3同步时，Server2不会把从Server1那里同步到的信息同步给Server3，只能由Server1自己同步给Server3。

2. Eureka Client

   • Eureka Client是一个Java客户端，用于简化与Eureka Server的交互。并且管理当前微服务，同时为当前的微服务提供服务提供者信息。
   • Eureka Client会拉取、更新和缓存Eureka Server中的信息。即使所有的 Eureka Server节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者。
   • Eureka Client在微服务启动后，会周期性地向Eureka Server发送心跳（默认周期为30秒）以续约自己的信息。如果Eureka Server在一定时间内没有接收到某个微服务节点的心跳，Eureka Server将会注销该微服务节点（默认90秒）。
   • Eureka Client包含服务提供者Applicaton Service和服务消费者 Application Client
     • Applicaton Service：服务提供者，提供服务给别个调用。
     • Application Client：服务消费者，调用别个提供的服务。

3. Register：服务注册：

   • 当Eureka客户端向Eureka Server注册时，它提供自身的元数据，比如IP地址、端口，运行状况指示符URL，主页等。

4. Renew：服务续约：

   • Eureka Client会每隔30秒发送一次心跳来续约。 通过续约来告知Eureka Server该Eureka客户仍然存在，没有出现问题。 正常情况下，如果Eureka Server在90秒没有收到Eureka客户的续约，它会将实例从其注册表中删除。 建议不要更改续约间隔。

5. Fetch Registries：获取注册列表信息

   • Eureka客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与Eureka客户端的缓存信息不同， Eureka客户端自动处理。如果由于某种原因导致注册列表信息不能及时匹配，Eureka客户端则会重新获取整个注册表信息。 Eureka服务器缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka客户端和Eureka 服务器可以使用JSON / XML格式进行通讯。在默认的情况下Eureka客户端使用压缩JSON格式来获取注册列表的信息。

6. Cancel：服务下线

   • Eureka客户端在程序关闭时向Eureka服务器发送取消请求。 发送请求后，该客户端实例信息将从服务器的实例注册表中删除

7. Eviction 服务剔除

   • 在默认的情况下，当Eureka客户端连续90秒没有向Eureka服务器发送服务续约，即心跳，Eureka服务器会将该服务实例从服务注册列表删除，即服务剔除。

Eureka与zookeeper的区别在哪里

在SpringCloud中，使用Eureka作为服务注册中心，而在dubbo中，则使用zookeeper作为服务注册中心。二者的区别在于对分布式领域的CAP定理的实现上。

首先简单说一下CAP定理的基本原理：

CAP定理的三个要素：C：数据一致性。A：服务可用性。P：分区容错性（服务对网络分区故障的容错性）。

在任何一个分布式系统中，只能实现CAP定理中的两个。

CAP理论也就是说在分布式存储系统中，最多只能实现以上两点。而由于当前网络延迟故障会导致丢包等问题，所以我们分区容错性是必须实现的。也就是NoSqL数据库P肯定要有，我们只能在一致性和可用性中进行选择，没有Nosql数据库能同时保证三点。

所以，Eureka和Zookeeper在CAP定理实现中，Eureka（保证AP），Zookeeper（保证CP）。

Zookeeper的设计理念就是分布式协调服务，保证数据（配置数据，状态数据）在多个服务系统之间保证一致性，这也不难看出Zookeeper是属于CP特性（Zookeeper的核心算法是Zab，保证分布式系统下，数据如何在多个服务之间保证数据同步）。Eureka是吸取Zookeeper问题的经验，先保证可用性。

参考文献-1：https://www.jianshu.com/p/2fa691d4a00a
参考文献-2：https://blog.csdn.net/java_xth/article/details/82621776