不知名程序员

1、dubbo是什么？（what）

说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）
其核心部分包含:

    1. 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
    1. 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
    1. 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

2、为什么使用dubbo？（why）

在互联网的发展过程中，在以前，我们只需要一个服务器，将程序全部打包好就可以，但是，随着流量的增大，常规的垂直应用架构已无法应对，所以，架构就发生了演变。更确切的说dubbo更好的为微服务架构体系做通信基础

3、dubbo和spring cloud有什么优缺点？（how）

  • 背景区别 :
    Dubbo是来源于 阿里团队 ，SpringCloud是来源于 Spring团队 ，Spring广泛遍布全球各种企业开发中，可以确保SpringCloud的后续更新维护，Dubbo虽然来自国内顶尖的阿里团队,但是曾经被阿里弃用停更，后来阿里又低调重启维护。

  • 定位区别：
    Dubbo 是 SOA 时代的产物，它的关注点主要在于 服务的调用，流量分发、流量监控和熔断 。而 Spring Cloud 诞生于微服务架构时代，考虑的是 微服务治理的方方面面 ，另外由于依托了 Spirng、Spirng Boot 的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态。
    双方都有各自的优缺点,可根据市场行情或公司需求进行自选.

  • 模块区别：
    > Dubbo 主要分为 服务注册中心，服务提供者，服务消费者，还有管控中心
    > SpringCloud 则是一个完整的分布式一站式框架，他有着一样的服务注册中心，服务提供者，服务消费者，
    管控台，断路器，分布式配置服务，消息总线，以及服务追踪等；

  • 性能区别：
    > Dubbo 的每次测试除去网络波动之外，都表现非常稳定
    > Spring Cloud在第一次最慢，之后越来越快，连续测试4次以上单次测试性能超过dubbo ;Spring Cloud-zuul在第一次最慢，之后也表现越来越快，连续4次以上测试 单次性能与dubbo相近，相差在0.02ms内

4、dubbo的层级架构

image.png

5、dubbo的一次完整调用

  • 服务消费方(dubbo-consumer)发布请求
  • 请求(request)编码
  • 服务提供方(dubbo-provider)解码请求
  • 服务提供方调用服务
  • 服务提供方返回调用结果(response)服务提供方调用指定服务后，会将调用结果封装到 Response 对象中，并将该对象返回给服务消费方。服务提供方也是通过 NettyChannel 的 send 方法将 Response 对象返回。
  • 服务消费方接收调用结果

6、dubbo的负载均衡策略，怎么修改dubbo负载均衡策略实现某些业务？

1.随机模式。按权重设置随机概率。在一个截面上碰撞的概率较高，但调用越大分布越均匀
2.轮询模式。按公约后的权重设置轮询比例。但存在响应慢的服务提供者会累积请求
3.最少活跃调用数。响应快的提供者接受越多请求，响应慢的接受越少请求
4.一致hash。根据服务提供者ip设置hash环，携带相同的参数总是发送的同一个服务提供者，若服务挂了，则会基于虚拟节点平摊到其他提供者上

7、dubbo的服务发现流程

  • Provider(提供者)绑定指定端口并启动服务
  • 指供者连接注册中心，并发本机IP、端口、应用信息和提供服务信息发送至注册中心存储
  • Consumer(消费者），连接注册中心 ，并发送应用信息、所求服务信息至注册中心
  • 注册中心根据 消费 者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。
  • Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。
  • Provider 状态变更会实时通知注册中心、在由注册中心实时推送至Consumer

8、dubbo的异常包装怎么做？

dubbo将异常包装成runtimeException跑到web层，然后用全局铺货器进行dubbo异常的铺货并封装对应异常返回

9、dubbo与zk的关系，不用zk能实现dubbo调用么？zk集群的选举问题

Dubbo的将注册中心进行抽象，是得它可以外接不同的存储媒介给注册中心提供服务，有ZooKeeper，Memcached，Redis等。 引入了ZooKeeper作为存储媒介，也就把ZooKeeper的特性引进来。首先是负载均衡，单注册中心的承载能力是有限的，在流量达到一定程度的时 候就需要分流，负载均衡就是为了分流而存在的，一个ZooKeeper群配合相应的Web应用就可以很容易达到负载均衡；资源同步，单单有负载均衡还不 够，节点之间的数据和资源需要同步，ZooKeeper集群就天然具备有这样的功能；命名服务，将树状结构用于维护全局的服务地址列表，服务提供者在启动 的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布。 其他特性还有Mast选举，分布式锁
不用zk dubbo也能正常调用 zk只是为了方便dubbo的服务注册与发现的统一管控 只是一种媒介

10、dubbo monitor的实现，存储了哪些东西？

调用之前，记录调用开始时间、并发数，之后进行调用，最后进行统计数据收集：

  • 获取计算各种统计数据（调用消耗时间、调用成功/错误数等）
  • 使用MonitorFactory获取Monitor
  • 将统计数据构造成url
  • 使用Monitor收集这些统计数据

11、dubbo怎么兼容旧版本？

可以用版本号（version）过渡，多个不同版本的服务注册到注册中心，版本号不同的服务相互间不引用。这个和服务分组的概念有一点类似。

12、dubbo怎么进行服务降级？

可以通过 dubbo:reference 中设置 mock=”return null”。mock 的值也可以修改为
true，然后再跟接口同一个路径下实现一个 Mock 类，命名规则是 “接口名称+Mock”
后缀。然后在 Mock 类里实现自己的降级逻辑。