-
配置集中管理（或发布订阅）
配置集中管理一般都是通过发布订阅方式实现的。
例如，将程序的配置信息都写入到一个数据节点(/configs)下，我们就认为这个节点是配置中心。然后每台机器在启动初始化时，都去该节点下获取到所有的配置信息，并在该节点下注册一个数据变更的watcher监听。一旦数据节点发生变更，所有订阅的客户端就会获取到数据变更通知。新机器加入也是类似。 -
集群管理
集群管理往往有2点：集群的master选举（有些事只能执行一遍，交由master来处理）以及是否有机器退出和加入（集群信息的动态维护）
具体方案：
所有机器都在一个节点/cluster下创建临时顺序节点，序号最小的就是leader。
然后父节点/cluster注册子节点变更的通知。一旦有机器挂掉，那么其对于节点就会被自动删除；随后所有watcher都会收到子节点变更的通知，然后就可以通过getChildren获取到所有子节点以及对于的主机 -
FIFO一类的队列系统
所有客户达都去一个目录/fifo下创建持久的顺序节点，节点中会存储相应消息。创建早的序号小，创建迟的序号大。
消费的时候按照序号一次进行消费，消费完毕后去主动删除节点（创建的节点应当是持久化的，防止出现消息队列的丢失问题）。 -
服务注册与发现（包括DNS解析、负载均衡）
一个服务启动后将其注册为临时节点（可以把节点名定为域名，节点内容中包括服务的ip、port等消息）,那么一旦服务挂了，zk上注册的节点信息就会被删除。
对于服务消费者来说，就是上述的反向过程，基于域名来找到zk节点，并获取ip、port等信息。是否是负载均衡，那么就从一个域名下读取ip\port列表，并根据相应的策略选择一个。
zookeeper和eureka在服务注册与发现上的区别
https://blog.csdn.net/asdfsadfasdfsa/article/details/79178918
https://blog.csdn.net/hxpjava1/article/details/80975021
1）zookeeper
zookeeper会出现一种情况,就是当master节点因为网络故障与其他节点失去联系的时候,剩余节点会重新进行leader选举.问题在于lead选举的时间太长,约30~120s,且选举过程中整个zk集群都是不可用的,这会导致在选举过程中注册服务瘫痪. 在云环境下,由于网络问题导致zk集群失去lead节点是较大概率事件,这会导致相当长的选举时间内服务注册是不可用的.(服务发现应该也是不可用的吧)
这个本质的原因是zk主要用于分布式环境下的一致性协调工具,它是保证CP的。
另外，当由于网络分区导致一部分节点不可用时，对这些zk节点的连接就无法获取到有效的信息了，即使是在这些节点上本身有信息的情况下；甚至于当多数节点都挂掉，此时zk集群会认为整个集群不可用，这就完全丧失了对外提供服务的能力。
而对于服务注册来说，我们可以容忍服务注册中心返回旧的注册信息（一般变更比较少），而不能容忍服务直接down掉不可用。也就是说服务注册的场景实际上对可用性的要求高于一致性。
2）eureka
Eureka一般是从内部进行注册的，也就是要求每个应用上部署一个eureka client，它们都会向eureka server去注册服务信息。
Eureka在设计时就优先保证可用性。Eureke中的server节点是平等的，没有leader一说。当客户端向一个server注册或者发现时连接失败，它就会自动切换到其他节点，只要有一台eureka还在，就能保证服务可用（优先保证可用性），但是此时信息可能是旧的错误信息（不能保证强一致性）。
此外，eureka还提供了一种自我保护状态，当短时间内（15分钟内超出85%的节点都没有正常的心跳，eureka就认为客户端与注册server之间出现了网络故障），此时eureka不会从注册表中移除没有收到心跳而应该过期的服务（类似于保持旧的状态不变），同时它基于当前注册表信息来对外提供服务，但是不再把自身信息同步到其他eureka server中（防止污染）。当网络稳定后，会解除自我保护状态，允许基于心跳来更新注册表和同步到其他eureka server。
因此，即使在网络故障导致部分节点失去联系的情况，它也可以尽可能对外提供旧的服务，而不会像zk那样整个注册服务瘫痪。