一、简介
注册中心
注册中心是服务发现的核心。它保存了各个可用服务实例的网络地址（IP Address和Port）。服务注册中心必须要有高可用性和实时更新功能。 Netflix Eureka 就是一个服务注册中心。它提供了服务注册和查询服务信息的REST API。
服务通过使用POST请求注册自己的IP Address和Port。每30秒（默认）发送一个PUT请求刷新注册信息。通过DELETE请求注销服务。客户端通过GET请求获取可用的服务实例信息。
服务中心又称注册中心，管理各种服务功能包括服务的注册、发现、熔断、负载、降级等，比如dubbo admin后台的各种功能。
有了服务中心调用关系会有什么变化，画几个简图来帮忙理解
项目A调用项目B
有了服务中心之后，任何一个服务都不能直接去掉用，都需要通过服务中心来调用
项目A调用项目B，项目B在调用项目C
这时候调用的步骤就会为两步：第一步，项目A首先从服务中心请求项目B服务器，然后项目B在从服务中心请求项目C服务。
Netflix
以下介绍来自于百度百科：
Netflix是一家美国公司，在美国、加拿大提供互联网随选流媒体播放，定制DVD、蓝光光碟在线出租业务。该公司成立于1997年，总部位于加利福尼亚州洛斯盖图，1999年开始订阅服务。2009年，该公司可提供多达10万部DVD电影，并有1千万的订户。2007年2月25日，Netflix宣布已经售出第10亿份DVD。HIS一份报告中表示，2011年Netflix网络电影销量占据美国用户在线电影总销量的45%。
我第一次看到这个单词的时候，是在各种美剧或者电影的开头，Netflix拍摄的代表性的美剧有《纸牌屋》、《毒枭》、《怪奇物语》。后来研究springcloud的时候发现了Netflix公司，就在想它们是不是同一家公司，经过核对github上面邮件后缀判定确实是同一家公司，其实springcloud的微服务就基于Netflix公司的开源产品来做的。
Netflix的开源框架组件已经在Netflix的大规模分布式微服务环境中经过多年的生产实战验证，正逐步被社区接受为构造微服务框架的标准组件。Spring Cloud开源产品，主要是基于对Netflix开源组件的进一步封装，方便Spring开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说，充分利用或参考借鉴Netflix的开源微服务组件(或Spring Cloud)，在此基础上进行必要的企业定制，无疑是通向微服务架构的捷径。
Eureka
按照官方介绍：
Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers.
Eureka 是一个基于 REST 的服务，主要在 AWS 云中使用, 定位服务来进行中间层服务器的负载均衡和故障转移。
Spring Cloud 封装了 Netflix 公司开发的 Eureka 模块来实现服务注册和发现。Eureka 采用了 C-S 的设计架构。Eureka Server 作为服务注册功能的服务器，它是服务注册中心。而系统中的其他微服务，使用 Eureka 的客户端连接到 Eureka Server，并维持心跳连接。这样系统的维护人员就可以通过 Eureka Server 来监控系统中各个微服务是否正常运行。Spring Cloud 的一些其他模块（比如Zuul）就可以通过 Eureka Server 来发现系统中的其他微服务，并执行相关的逻辑。
Eureka由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。Netflix在其生产环境中使用的是另外的客户端，它提供基于流量、资源利用率以及出错状态的加权负载均衡。
上图简要描述了Eureka的基本架构，由3个角色组成：
1、Eureka Server
- 提供服务注册和发现
2、Application Service
- 服务提供方
- 将自身服务注册到Eureka，从而使服务消费方能够找到
3、Application Client
- 服务消费方
- 从Eureka获取注册服务列表，从而能够消费服务
二、实现注册中心的不同技术
Spring cloud的服务注册及发现支持eureka、Zookeeper和Consul。
三种技术实现是根据CAP理论（三种特性：Consistency（一致性） 、Availability（可用性）、Partition tolerance（分区容错性），在分布式设计中只能选其二）的取舍进行设计的，具体特性如下：
- eureka 是按照AP原则设计,作为分布式场景下的服务发现的产品较为合适，服务发现场景的可用性优先级较高，一致性并不是特别致命。各个服务可以单独提供服务，不需要发起选举；
- zookeeper 是按照CP原则设计，牺牲可用性，在服务发现场景并没太大优势，需要选举，在选举过程中服务不可用；
- Consul 是按照CA原则设计，为保证数据一致性，需要发起选举，在选举过程中服务不可用。
三、实践演练
1、Eureka Server(单服务版)
spring cloud内部已经做好了底层封装，我们只需要按照官方文档进行相应配置即可完成，so easy。
1、老生常谈，先上pom依赖
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency> </dependencies>
2.按顺序来该boot配置优先的配置文件上场啦，配置文件
spring:
application:
name: spring-cloud-eureka
server:
port: 8097
eureka:
client:
register-with-eureka: false #表示是否将自己注册到Eureka Server，默认为true。
fetch-registry: false #表示是否从Eureka Server获取注册信息，默认为true
serviceUrl:
defaultZone: http://xjy1:${server.port}/eureka/ #设置与Eureka Server交互的地址，查询服务和注册服务都需要依赖这个地址。默认是http://localhost:8761/eureka ；多个地址可使用 , 分隔
instance:
hostname: xjy1 #eureka 服务端实例名称
简单解释下（虽然上面注释写的很清楚了，但我觉得还是有必要说下==），eureka.client.register-with-eureka这个东西啊，其实很好理解，eureka本身自己就是个注册中心了，你觉得有必要向自己注册自己嘛（这里只针对单服务版），其他就不多说来了
还有个地方强调下：eureka.instance.hostname这个我配的是自定义的，这个上面说了，是注册中心交互地址用的，要想让自定义的生效，必须去host文件配置，具体怎么配自行百度吧，不会的可留言或加群我来给你解答哈~
3.启动类添加注解@EnableEurekaServer
@SpringBootApplication @EnableEurekaServer public class CloudApplication { public static void main(String[] args) { SpringApplication.run(CloudApplication.class, args); } }
这没啥说的，按规矩办事儿
一切准备妥当后，启动服务吧，启动后访问 http://localhost:8097就可以看到注册中心的页面了，当然目前一个服务都没注册进来
2、Eureka Server(集群版)
既然都是cloud分布式了，单服务算什么名堂，万一哪天注册中心挂了，我去，整个天估计都塌了，依赖的服务全都等着挂吧，所以本着高可用，理应随时处于可以提供服务的状态。为了维持其可用性，使用集群是很好的解决方案。Eureka通过互相注册的方式来实现高可用的部署，所以我们只需要将Eureke Server配置其他可用的serviceUrl就能实现高可用部署。
双节点（要玩就玩大的）三节点注册中心
1、首先我们上面做的那些不要丢还是有用滴，可以复制出来一份（当然你也可以在那上面改，如果不嫌乱的话，^_^），复制完后，我们只需要改配置文件即可
---
spring:
application:
name: spring-cloud-eureka
profiles: xjy1
server:
port: 8097
##表示是否将自己注册到Eureka Server，默认为true。
#eureka:
# client:
# register-with-eureka: false
##表示是否从Eureka Server获取注册信息，默认为true
#eureka:
# client:
# fetch-registry: false
eureka:
instance:
hostname: xjy1
#设置与Eureka Server交互的地址，查询服务和注册服务都需要依赖这个地址。
#默认是http://localhost:8761/eureka ；多个地址可使用 , 分隔
client:
serviceUrl:
defaultZone: http://xjy2:8098/eureka/,http://xjy3:8099/eureka/
---
spring:
application:
name: spring-cloud-eureka
profiles: xjy2
server:
port: 8098
eureka:
instance:
hostname: xjy2
client:
serviceUrl:
defaultZone: http://xjy1:8097/eureka/,http://xjy3:8099/eureka/
---
spring:
application:
name: spring-cloud-eureka
profiles: xjy3
server:
port: 8099
eureka:
instance:
hostname: xjy3
client:
serviceUrl:
defaultZone: http://xjy2:8098/eureka/,http://xjy1:8097/eureka/
简单讲下，这里我因为我们是多节点了，所以就要相互注册发现嘛，不然多节点有个锤子用，谁也不认识谁，你说是不是~~
可能会有同学对上面的 --- 符号不是很理解，简单说下同一个配置文件，如果见到 ---- 符号，下面就可以认为是一个新的配置文件了，也就是说，我们把三个配置文件写到了一个里面，而实际上他就是三个（好吧，有点乱）
反正你就认为他是三个配置文件，当然这样的话，就不能直接启动main方法了，怎么启动往下看~
2、我觉得还是有必要说下怎么配置host转换了（就是上面配的xjy1xjy2xjy3）这些
首先找到host文件，正常都是在C:WindowsSystem32driversetc这下面会有个host文件（别问了，就是不带后缀）
然后编辑器打开，末尾加上下面的
127.0.0.1 xjy1
127.0.0.1 xjy2
127.0.0.1 xjy3
3、项目打成jar，启动
上面说了不能直接启动，必须打成jar包，然后命令启动
启动三个服务形成集群注册中心，启动命令： java -jar eureka-center-cluster-0.0.1-SNAPSHOT.jar --spring.profiles.active=xjy1 java -jar eureka-center-cluster-0.0.1-SNAPSHOT.jar --spring.profiles.active=xjy2 java -jar eureka-center-cluster-0.0.1-SNAPSHOT.jar --spring.profiles.active=xjy3
依次启动完成后，浏览器输入：http://localhost:8097/ 效果图
根据图可以看出xjy1的注册中心DS Replicas已经有了xjy2xjy3的相关配置信息，并且出现在available-replicas中。我们手动停止xjy2来观察，发现xjy2就会移动到unavailable-replicas一栏中，表示xjy2不可用。
到此三节点的配置已经完成。
eureka集群使用
在生产中我们可能需要三台或者大于三台的注册中心来保证服务的稳定性，配置的原理其实都一样，将注册中心分别指向其它的注册中心。
这里只介绍三台集群的配置情况，其实和三节点的注册中心类似，每台注册中心分别又指向其它节点即可，使用application.yml来配置。
四、问题分析
注册中心数据同步实现原理
E、F、G 为注册中心Server；
c1、c2、c3、c4是注册在注册中心的client；
E向F注册，F向G注册，G向E注册。
说明：isReplication(是否是复制的标识) R表示注册 C表示复制
- c1、c2、c3都注册在E上，c3、c4都在注册在F上，没有直接注册到G上的client
- Eureka 同步过程，E将直接相关的注册信息复制到F，F将同步c1、c2的注册信息；F则将c3、c4发送到G；G没有直接相关的注册信息，没有信息复制给E。
- 若c2与E的注册发生异常，则c2将从，E的信息列表中cancel，并且在下一次信息同步的时候将该信息同步给F，F中c2 是复制信息，因此，也执行该cancel操作。
五、Eureka 比 Zookeeper 好在哪里
传统关系型数据库 ACID
A：原子性：事务里面的所有操作，要么全部做完，要么都不做，只要有一个失败，整个事务都失败，需要回滚
C：一致性：以转账案例为例，假设有五个账户，每个账户余额是100元，那么五个账户总额是500元，如果在这个5个账户之间同时发生多个转账，无论并发多少个，比如在A与B账户之间转账5元，在C与D账户之间转账10元，在B与E之间转账15元，五个账户总额也应该还是500元，这就是保护性和不变性
I：隔离性：并发的事务之间互不影响
D：持久性：事务一旦提交，数据将永久保存在数据库上
NoSQL 数据库 CAP
C：强一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
A：可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
P：分区容错性：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。（在分布式环境下，这个 p ，一定要实现）
zookeeper 保证 CP
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的信息，但不能接受服务直接 down 掉不可用。也就是说服务注册的可用性要高于一致性
当时 zk 会出现这么一个情况，当 mastr 节点因网络故障和其他节点失去联系时，剩余节点会重新进行选举。问题在于，选举时间比较长，30s~120s，且选举期间，整个 zk 是不可用的。这就导致了在选举期间，注册服务的瘫痪。在云部署的环境下，因网络问题使 zk 集群时区 master 节点是交大概率会发生的事情，虽然服务能够最终恢复，但是漫长的选举时间导致的注册服务长期不可用是不能容忍的。
Eureka 保证 AP
Eureka 明白这一点，因此在设计时，就优先保证可用性.Eureka 各个节点是平等的，几个节点挂掉不会影响正常工作，只要有一台 Eureka 存在，就可以保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka 还有一种自我保护机制，如果在 15 分钟内超过 85% 的节点没有正常的心跳，那么 Eureka 就会认为客户端与注册中心出现了故障，此时会出现以下几种情况：
1、Eureka 不再从注册列表中移出因长时间没收到心跳而应该过期的服务
2、Eureka 仍然能够接受新服务的注册和查询要求，但是不会被同步到其他节点上（即保证当前节点依然可用）
3、当网络稳定时，当前实例新的注册信息会被同步到其他节点中
结论
Eureka 可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像 zookeeper 那样使整个注册服务瘫痪
六、案例源码
连接点不动时请复制粘贴此链接：https://github.com/oIdmonk/springcloud-xjy
代码基于boot2.1.9.RELEASE版本，cloudGreenwich.SR3版本
参考：
Spring Cloud构建微服务架构（六）高可用服务注册中心