zk和eureka

转载 记录
zk在用于服务发现的问题
zk将数据一致性作为自己设计的首要目标，从而不保证服务的可用性，因为当节点crash后，需要
进行leader的选举，在这个期间内，zk服务是不可用的。
对于服务的注册发现来说，对数据一致性并没有很大的需求，因为就算获取到不可用的服务，也会返回相应的
错误response，但是如果从注册中心中获取不到服务，就会是一个很大的问题。zk的leader选举时间有非常长，
所以用于服务发现，不是一个很好选择

eureka的思考
eureka是按照AP的设计目标去实现的，当节点宕机后，并不会影响服务的获取和注册，client会从别的节点中获取服务信息，
同时当eureka的服务端发现85%以上的服务都没有心跳的话，它就会认为自己的网络出了问题，就不会从服务列表中删除这些失去心跳的服务，同时eureka的客户端也会缓存服务信息。eureka对于服务注册发现来说是非常好的选择。
但是在这段保护期间内实例出现问题，则客户端很容易拿到已经不存在的服务实例，会出现调用失败的情况。
针对这种情况，客户端必须要有容错机制，比如可以使用请求重试、断路器机制，

eureka的自我保护机制
eureka.server.enable-self-preservation=false 关闭保护机制，确保注册中心可以将不可用的实例正确剔除。

多个服务中心中，一个服务中心从另一个服务中心获取所有的实例，然后判断实例是否已经注册。