服务注册中心的选型和对比
1.Zookpeer
2.Eureka
- Dubbo 作为服务框架的，一般注册中心会选择 zk
- Spring cloud 作为服务框架的，一般服务注册中心会选择 Eureka
- Consul、Nacos，普及型还没那么广泛
- 服务注册发现的原理
- 集群模式
- Eureka，peer-to-peer，部署一个集群，但是集群里每个机器的地位是对等的，各个服务可以向任何一个 Eureka实例服务注册和服务发现，集群里任何一个 Euerka 实例接收到写请求之后，会自动同步给其他所有的 Eureka实例
- ZooKeeper，服务注册和发现的原理，Leader+Follower 两种角色，只有 Leader 可以负责写也就是服务注册，他可以把数据同步给 Follower，读的时候leader/follower 都可以读
- 一致性保障:CP or AP
- CAP，C是一致性，A是可用性，P是分区容错性
- CP，AP
- ZooKeeper是有一个 leader 节点会接收数据，然后同步写其他节点，一旦leader挂了，要重新选举 leader，这个过程里为了保证C，就牺牲了A，不可用一段时间，但是一个leader选举好了，那么就可以继续写数据了，保证一致性
- Eureka是 peer 模式，可能还没同步数据过去，结果自己就死了，此时还是可以继续从别的机器上拉取注册表，但是看到的就不是最新的数据了，但是保证了可用性，强一致，最终一致性
- 服务注册发现的时效性
- zk，时效性更好，注册或者是挂了，一般秒级就能感知到
- eureka，默认配置非常糟糕，服务发现感知要到几十秒，至分钟级别
- 容量
- zk，不适合大规模的服务实例，因为服务上下线的时候，需要瞬间推送数据通知到所有的其他服务实例，所以一旦服务规模太大，到了几千个服务实例的时候，会导致网络带宽被大量占用
- eureka，也很难支撑大规模的服务实例，因为每个eureka实例都要接受所有的请求，实例多了压力太大，扛不住，也很难到几千服务实例
- 之前 dubbo 技术体系都是用 zk当注册中心,spring cloud 技术体系都是用 eureka 当注册中心这两种是运用最广泛的,但是现在很多中小型公司以 spring cloud 居多,所以后面基于 eureka说一下服务注册中心的生产优化
