大数据的同学，Java架构，分布式架构，Eureka源码解析
Eureka，peer-to-peer架构，master-slave
小集群部署，每个节点收到的注册、心跳所有的信息，都必须向其他节点都进行同步，有很大的问题，他在进行同步的时候，采取的是完全的一个异步同步的机制，不管什么2PC，异步慢慢同步就可以了
时效性是很差的，eureka，这个技术不适合大公司，大厂的场景去使用
现在第二个问题，为什么zk的leader和follower只能是三五台机器，小集群部署？因为你想，假设你有1个leader + 20个follower，21台机器，你觉得靠谱吗？不靠谱，因为follower要参与到ZAB的写请求过半ack里去
如果你有20个follower，一个写请求出去，要起码等待10台以上的Follower返回ack，才能发送commit，才能告诉你写请求成功了，性能是极差的
所以zk的这个ZAB协议就决定了一般其实就是1个leader + 2个follower的小集群就够了，写请求是无法扩展的，读请求如果量大，可以加observer机器，最终就是适合读多写少的场景
主要就是用于分布式系统的一些协调工作
这也就让大家知道了，很多互联网公司里，不少系统乱用zk，以为zk可以承载高并发写，结果每秒几万写请求下去，zk的leader机器直接可能就挂掉了，扛不住那么大的请求量，zk一旦挂掉，连带的kafka等系统会全部挂掉
zk适合读多写少的，zk集群挂掉了
leader写入压力过大， 最终导致集群挂掉了，对一个公司的技术平台是有重大打击的，hbase、kafka之类的一些技术都是强依赖zk的，dubbo + zk去做服务框架的话，有上万甚至几十瓦的服务实例的时候
大量的服务的上线、注册、心跳的压力，达到了每秒几万，甚至上十万，zk的单个leader写入是扛不住那么大的压力的
一般适合写比较少
读比较多，observer节点去线性扩展他的高并发读的能力