1、常用注册中心
1）、zookeeper：高一致性（多个节点的数据保持一致）；
2）、eureka：高可用（系统不能访问的时间很少）；
3）、consul：上诉两个方案的折中。
高可用：消灭单点故障、可靠性交迭、故障探测。
集中管理：用注册中心来管理服务。（例 Eureka）
去集中管理：每一个服务实例，都有一个副本。（可参考git的本地仓库，算是一个副本）
2、Eureka 服务发现/注册
1)、Eureka Server：提供服务注册和发现。管理所有注册服务、以及其实例信息和状态。（维护一个注册表）
激活：@EnableEurekaServer.
服务同步原理：多个注册中心之间，通过异步模式(一个定时线程，互相发送注册表)（所以每个固定时间点的各个节点，可能状态是有细微的区别）。当收到一个注册请求时，一个注册中心会将注册信息发送到其他注册中心，实现注册中心的服务同步。
自我保护原理：当注册的服务，心跳失败的服务比例占85%+，就会触发注册中心的自我保护机制，让当前还存活的实例不会过期。（保证高可用A）但是服务消费者很容易拿到失败的实例。所以客户端需要有容错机制，比如限流断路器等。
本地调试时可暂时关闭注册中心自我保护机制。
配置文件属性：
eureka.client.register-with-eureka：flase，不向自己注册自己。
eureka.client.fetch-registry：不去检索（拉取服务），只维护实例清单。
2)、Eureka Client：为当前服务提供注册、同步、查找服务以及其实例信息或状态等能力。
激活：@EnableEurekaClient （写死绑定 Eureka）或者 @EnableDiscoveryClient （建议该种注解） 。
服务注册原理：Client 启动的时候发送 REST 请求的方式，将自己注册到注册中心上，同时带上一些自身服务的一些元数据信息。注册中心收到 REST 请求后，将元数据信息存在一个双层 Map中，第一层的 key 是服务名，第二层的 key 是具体服务的实例名（IP 地址）。
实例名配置：实例名是 InstanceInfo 中的 instanceId 参数，是区分同一服务不同实例的唯一标识。原生实现是采用主机名作为默认值，所以在同一主机无法启动多个相同的服务实例。
服务续约原理：Client 会维护一个心跳来持续告诉注册中心它还 “活着”，防止注册中心“剔除任务”将该 Client 实例从注册列表里删除。有两个参数可以调整，一个是续约任务的间隔时间（默认30秒），一个是定义服务的失效时间（默认90秒）。
获取服务原理：从服务端查询当前注册的服务信息列表，并且缓存到本地（默认30秒），并周期性地刷新服务状态。
服务下线原理：当一个 Client 进行正常的关闭操作时，触发一个下线的 REST 请求给注册中心，注册中心接收到请求，将该服务状态置为下线。或者未正常关闭，但是服务停止，注册中心在启动的时候创建一个定时任务，默认每个一段时间（默认60秒），将当前清单中超时（默认90秒）没有续约的任务剔除出去。
Client 还需要获取一个 Eureka Server 的 URL 列表。（Region 和 Zone 来实现，一对多的关系。）先根据 EurekaClientConfig 获取1个 region，再根据1个 region 获取多个 zone，再根据参数算法确定加载哪一个 Zone 配置的 serviceUrls。
Ribbon 实现服务调用时，对于 Zone 的设置在负载均衡实现区域亲和特效。Ribbon 默认会优先访问同客户端处于一个 Zone 中的服务端实例，没有才访问其他 Zone 实例。通过 Zone 熟悉的定义，配合实际部署的物理结构，可以有效地设计出对区域性故障的容错集群。
配置文件属性：
eureka.client.serverUrl.defaultZone=http://IP:端口/eureka：注册到哪个注册中心。
3、高可用服务治理
CAP：C一致性，A高可用，P分区容错性（数据在时限内不能达成一致性，就分区了。所以就必须在A和C之间取舍）。
配置手段：多注册中心主机、注册中心 DNS、广播。
1）、高可用注册中心：多个注册中心之间，互相注册。服务注册时，注册到多个注册中心里。
一个 Client 向一个注册中心注册自己的服务后，通过注册中心之间的同步，当挂了一个注册中心节点时，可以在其他注册中心节点访问 Client，达到高可用的目的。
参考：《SpringCloud 实战》