在上一节的代码中，我们让消费者直接连接提供者的端口号，如果提供者现在是个集群的状况，消费者如何知道新增的服务地址和ip呢？有的小伙伴可能会修改消费者的远程调用地址，那么这样确实可以解决问题，但是这种方式过于耦合，并且服务也会不定期的重启、扩容，地址和端口号可能又要变，这样对消费者来说太痛苦了，而且当提供者被多个消费者调用时候，那工作量就不是一般的大了，万一再出现提供者挂掉的情况，消费者方还需要增加健壮性的代码，对开发人员来说也是一种折磨。
所以为了解决上述问题，就诞生了注册中心的概念，提供者在启动时将自己的信息注册到注册中心，注册中心就知道提供者在那些服务器上部署了。消费者进行消费的时候，去注册中心拉取注册表，这样就间接的获取到提供者的信息了，这个过程也叫服务发现。
对于很多消费者调用同一个提供者的问题可以采用负载均衡，使不同的消费者分别访问不同的提供者。
所以只要有了第三方注册表，以上的问题就可以被解决。
在学习Eureka之前，我们首先要了解CAP定理。
CAP定理是指，在一个分布式系统中Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。
分布式系统中多个主机之间是否能保持数据一致的特性。（当系统数据发生更新操作后，各个主机的数据仍然处于一致的状态）
系统提供的服务必须一直处于可用的状态。（用户的每一个请求，系统可以在有限时间内对用户进行响应）
分布式系统在遇到任何网络分区故障时仍能保证对外提供满足一致性和可用性的服务。
对于分布式系统，网络环境相对是不可控的，出现网络分区是不可避免的，因此系统必须具备分区容错性。但系统不能同时保证一致性与可用性——要么 CP，要么 AP。ps：目前没有任何框架同时满足CAP，或许在未来的6、7、8、9、10G时代，超远距离的两端服务同步数据无限接近于0延时，或许可以实现真正的CAP。
在了解了CAP定理后，我们继续来学习Eureka。Eureka是Netflix开发的服务发现框架，本身基于 REST的服务，用于定位运行在 AWS（Amazon Web Services，亚马逊网络服务，亚马逊云）域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。SpringCloud将它集成在其子项目spring-cloud-netflix中，实现 SpringCloud 的服务发现功能。
Eureka 就是一个专门用于服务发现的服务器，一些服务注册到该服务器，而另一些服务通过该服务器查找其所要调用执行的服务。可以充当服务发现服务器的组件很多，例如Zookeeper、Consul、Eureka、Nacos等。
Eureka体系架构
服务注册到Eureka并且30s发送一次心跳，如果客户端在一段时间里没有进行心跳续约，90s后会从注册表中被踢出去。客户端可以从任意zone中获取到注册信息到本地服务进行引入调用。（30s发生一次）Eureka将AP高可用做到了极致，但他不能保证数据的一致性。 Eureka与Zookeeper都可以充当服务中心。
Eureka中的每一个server都是平等的，Zookeeper的server中是存在leader的。
二者对于CAP原则的支持不同，Eureka支持AP，Zookeeper支持CP。
在Euraka的GitHub上，宣布Eureka 2.x闭源，原文截图如下：
通过截图可以看到Euraka 2.0 版本的开源工作已经停止，如果开发者继续使用作为 2.x 分支上现有工作 repo 一部分发布的代码库和工件，则将自负风险。但是Erueka 1.x还是Netflix服务发现系统的核心部分并没有闭源，也就是说Erueka仍然可以使用。点击下方阅读原文，查看上一篇
