55 lines
3.4 KiB
Markdown
Executable File
55 lines
3.4 KiB
Markdown
Executable File
|
||
非常常见的一个技术面试题，但凡只要是聊到分布式这块，一定会问问你，**Dubbo，Spring Cloud，服务注册中心**，你们当时是怎么选型和调研的，你们最终是选择了哪块技术呢？你选择这块技术的原因和理由是什么呢？
|
||
|
||
**Eureka、ZooKeeper**
|
||
|
||
**Dubbo**作为服务框架的，一般注册中心会选择zk
|
||
|
||
**Spring Cloud**作为服务框架的，**一般服务注册中心会选择Eureka**
|
||
|
||
**Consul、Nacos，**普及型还没那么广泛，我会在面试训练营课程里增加对应的内容，给大家去进行补充
|
||
|
||
#### (1)服务注册发现的原理
|
||
|
||
集群模式
|
||
|
||
|
||
**Eureka，peer-to-pee**r，部署一个集群，**但是集群里每个机器的地位是对等的，各个服务可以向任何一个Eureka实例服务注册和服务发现，集群里任何一个Euerka实例接收到写请求之后，会自动同步给其他所有的Eureka实例**
|
||
|
||
|
||
**ZooKeeper，服务注册和发现的原理，Leader + Follower两种角色，只有Leader可以负责写也就是服务注册，他可以把数据同步给Follower，读的时候leader/follower都可以读**
|
||
|
||
#### (2)一致性保障：CP or AP
|
||
|
||
**CAP，C是一致性，A是可用性，P是分区容错性**
|
||
|
||
**CP，AP**
|
||
|
||
**ZooKeeper是有一个leader节点会接收数据， 然后同步写其他节点，一旦leader挂了，要重新选举leader，这个过程里为了保证C，就牺牲了A，不可用一段时间，但是一个leader选举好了，那么就可以继续写数据了，保证一致性**
|
||
|
||
Eureka是peer模式，可能还没同步数据过去，结果自己就死了，此时还是可以继续从别的机器上拉取注册表，但是看到的就不是最新的数据了，但是保证了可用性，强一致，最终一致性
|
||
|
||
（3）服务注册发现的时效性
|
||
|
||
zk，时效性更好，注册或者是挂了，一般秒级就能感知到
|
||
|
||
eureka，默认配置非常糟糕，服务发现感知要到几十秒，甚至分钟级别，上线一个新的服务实例，到其他人可以发现他，极端情况下，可能要1分钟的时间，ribbon去获取每个服务上缓存的eureka的注册表进行负载均衡
|
||
|
||
服务故障，隔60秒才去检查心跳，发现这个服务上一次心跳是在60秒之前，隔60秒去检查心跳，超过90秒没有心跳，才会认为他死了，2分钟都过去
|
||
|
||
30秒，才会更新缓存，30秒，其他服务才会来拉取最新的注册表
|
||
|
||
三分钟都过去了，如果你的服务实例挂掉了，此时别人感知到，可能要两三分钟的时间，一两分钟的时间，很漫长
|
||
|
||
#### (4)容量
|
||
|
||
zk，不适合大规模的服务实例，因为服务上下线的时候，需要瞬间推送数据通知到所有的其他服务实例，所以一旦服务规模太大，到了几千个服务实例的时候，会导致网络带宽被大量占用
|
||
|
||
eureka，也很难支撑大规模的服务实例，因为每个eureka实例都要接受所有的请求，实例多了压力太大，扛不住，也很难到几千服务实例
|
||
|
||
之前dubbo技术体系都是用zk当注册中心，spring cloud技术体系都是用eureka当注册中心这两种是运用最广泛的，但是现在很多中小型公司以spring cloud居多，所以后面基于eureka说一下服务注册中心的生产优化
|
||
|
||
（5）多机房、多数据中心、健康检查
|
||
|
||
|