dubbo面试问题

为什么用微服务；

为什么zookeeper能作为注册中心；

使用分布式碰到的bug，

zookeeper有集群吗？怎么实现的；

zookeeper宕机还能访问吗；

服务失效踢出zookeeper中临时节点的原理；

dubbo集群负载均衡策略

zookeeper持久化节点和临时节点，注册中心怎么与服务方保持心跳的

dubbo和springCloud区别，dubbo是做什么的。dubbo解决了什么难题，内部用了什么协议。

现在市面上比较成熟的分布式框架有两种，要么采用dubbo，要么采用Spring cloud，至于他们两个的区别，这个网上都有，主要的一点就是如果使用dubbo，像这些服务的降级限流熔断，监控，链路跟踪等等，只能说自己搞，dubbo没有集成，阿里支付宝用的dubbo，淘宝用的Spring cloud

 

怎么进行服务注册发现 zk实现具体说说

dubbo的负载均衡怎么做，讲一下具体代码实现。

dubbo的服务容错怎么做，怎么知道服务器宕机了 zk的心跳机制维持服务器连接

 

1 面试题：Dubbo中zookeeper做注册中心，如果注册中心集群都挂掉，发布者和订阅者之间还能通信么？
可以的，启动dubbo时，消费者会从zk拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用

注册中心对等集群，任意一台宕掉后，会自动切换到另一台
注册中心全部宕掉，服务提供者和消费者仍可以通过本地缓存通讯
服务提供者无状态，任一台 宕机后，不影响使用
服务提供者全部宕机，服务消费者会无法使用，并无限次重连等待服务者恢复
2 dubbo连接注册中心和直连的区别
在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，
点对点直联方式，将以服务接口为单位，忽略注册中心的提供者列表，

服务注册中心，动态的注册和发现服务，使服务的位置透明，并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover， 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外，注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

3、Dubbo在安全机制方面是如何解决的
Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方。

 怎么进行服务注册发现 zk实现具体说说

注册，即将服务节点写入到 ZooKeeper 中对应 app_id 和 cluster 的目录下，写入成功则视为服务启动成功；发现，即通过 ZooKeeper 的 watch 原语监听对方 app_id 和 cluster 之下的实例节点，发现更新则写入到本地文件系统缓存，供客户的的连接池取用。

原文：https://blog.csdn.net/luwei42768/article/details/54847427