作者回复: 关于问题1/2：在一个zone内(可以理解为一个机房内)，eureka集群是需要高可用部署的，eureka支持(peer to peer)对等同步协议，一般在一个zone内至少部署三台组成高可用集群(ereuka高可用部署方式类似Zookeer，用3、5、7这种奇数台方式部署)。因为eureka是高可用部署，所以一般认为是不会全挂的，如果一个zone内的eureka真的全挂了，那么就要靠跨zone(相当于跨机房)的高可用，也就是client要切换到其它zone去访问其它zone里头的eureka集群了。也就是像你说的，在每个zone内都要部署eureka集群，并且每个zone内的ribbon client都要知道其它zone的eureka服务地址信息（配置项：eureka.client.availabilityZones），甚至还可以定义一些出问题时优先选择哪个Zone的优先策略，具体可以参考文档： https://cloud.spring.io/spring-cloud-static/spring-cloud-netflix/1.3.5.RELEASE/multi/multi_spring-cloud-ribbon.html 的6.4节Using Ribbon with Eureka 关于问题3:同zone的client肯定是优先调本zone内的Eureka和服务，出问题才会fallback到其它zone，配置项参考上面文档。如果要深入，建议参考Ribbon相关源码。

作者回复: Eureka服务器集群是设计成peer 2 peer高可用部署的，一般需要部署3台以上，且部署数量是奇数台。如果只是一个(或少数)Eureka服务器down，集群仍然可用，重启以后，peer之间会同步服务实例信息，可以恢复。如果大部分或者全部Eureka服务器down，那么所有实例数据丢失，需重启和重新注册后方能恢复。

作者回复: 请参考Netflix eureka的文档：https://github.com/Netflix/eureka/wiki/Understanding-Eureka-Peer-to-Peer-Communication “Eureka servers communicate with one another using the same mechanism used between the Eureka client and the server as described here.” Eureka server之间相互通讯的机制，和Eureka client和server之间通讯的机制相同。 也就是说server之间也用client做服务注册发现，以及数据同步。

作者回复: 课程里头有较详细优劣说明，简单讲，客户端软负载性能好（少一跳），但多语言支持成本高，要为每种语言开发客户端，集中式负载有性能开销和单点问题，也有运维开销，但客户端简单，多语言无关。

作者回复: 都可以，各有利弊，老的那套比较成熟稳定，但是长期可能不维护了，新的那套是未来方向，但是需要踩坑的地方会多一点。我个人会倾向采用新技术，当然你需要综合评估。