基本工作流程：

上图中角色说明：

工作原理分 10 层：
第一层：service 层，接口层，给服务提供者和消费者来实现的（留给开发人员来实现）； 第二层：config 层，配置层，主要是对 Dubbo 进行各种配置的，Dubbo 相关配置；
· 第三层：proxy 层，服务代理层，透明生成客户端的 stub 和服务单的 skeleton，调用的是接 口，实现类没有，所以得生成代理，代理之间再进行网络通讯、负责均衡等；
第四层： registry 层，服务注册层，负责服务的注册与发现；



第五层：cluster 层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一 个服务；
第六层：monitor 层，监控层，对 rpc 接口的调用次数和调用时间进行监控； 第七层：protocol 层，远程调用层，封装 rpc 调用；
第八层： exchange 层，信息交换层，封装请求响应模式，同步转异步；
第九层：transport 层，网络传输层，抽象 mina 和 netty 为统一接口；
第十层：serialize 层，数据序列化层。
这是个很坑爹的面试题，但是很多面试官又喜欢问，你真的要背么？你能背那还是不错的，我建议 不要背，你就想想 Dubbo 服务调用过程中应该会涉及到哪些技术，把这些技术串起来就 OK 了。

Memcached 协议、 Redis 协议、 Rest 协议。
上图基本上把序列化的方式也罗列出来了。
详细请参考： Dubbo 官网 ：

可以。因为刚开始初始化的时候， consumer 会将需要的所有提供者的地址等信息拉取到本地缓 存，所以注册中心挂了可以继续通信。但是 provider 挂了，那就没法调用了。

服务订阅通常有 pull 和 push 两种方式：
pull 模式需要客户端定时向注册中心拉取配置；
push 模式采用注册中心主动推送数据给客户端。

Dubbo ZooKeeper 注册中心采用是事件通知与客户端拉取方式。服务第一次订阅的时候将会拉取 对应目录下全量数据，然后在订阅的节点注册一个 watcher。一旦目录节点下发生任何数据变化， ZooKeeper 将会通过 watcher 通知客户端。客户端接到通知，将会重新拉取该目录下全量数据， 并重新注册 watcher。利用这个模式，Dubbo 服务就可以做到服务的动态发现。
注意：ZooKeeper 提供了“心跳检测”功能，它会定时向各个服务提供者发送一个请求（实际上建立 的是一个 socket 长连接），如果长期没有响应，服务中心就认为该服务提供者已经“挂了” ，并将其 剔除。

随机（默认）：随机来
轮训：一个一个来
活跃度：机器活跃度来负载
一致性 hash：落到同一台机器上

provider 宕机重试以后，请求会分到其他的 provider 上，默认两次，可以手动设置重试次数，建 议把写操作重试次数设置成 0。

失败自动恢复会在调用失败后，返回一个空结果给服务消费者。并通过定时任务对失败的调用进行 重试，适合执行消息通知等操作。

快速失败只会进行一次调用，失败后立即抛出异常。适用于幂等操作、写操作，类似于 failover cluster 模式中重试次数设置为 0 的情况。

失败安全是指，当调用过程中出现异常时，仅会打印异常，而不会抛出异常。适用于写入审计日志 等操作。

并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多
服务资源。可通过 forks="2" 来设置最大并行数。

广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志 等本地资源信息。

默认使用 javassist 动态字节码生成，创建代理类，但是可以通过 SPI 扩展机制配置自己的动态代理
策略。

通信方式、注册中心、监控、断路器，其余像 Spring 分布 式配置、服务网关肯定得知道。
通信方式
Dubbo 使用的是 RPC 通信；Spring Cloud 使用的是 HTTP RestFul 方式。
注册中心
Dubbo 使用 ZooKeeper（官方推荐），还有 Redis、 Multicast、Simple 注册中心，但不推荐。；
Spring Cloud 使用的是 Spring Cloud Netflix Eureka。
监控
Dubbo 使用的是 Dubbo-monitor ；Spring Cloud 使用的是 Spring Boot admin。
断路器
Dubbo 在断路器这方面还不完善，Spring Cloud 使用的是 Spring Cloud Netflix Hystrix。
分布式配置、网关服务、服务跟踪、消息总线、批量任务等。
Dubbo 目前可以说还是空白，而 Spring Cloud 都有相应的组件来支撑。

zookeeper用来注册服务和进行负载均衡，哪一个服务由哪一个机器来提供必需让调用者知道，简 单来说就是ip地址和服务名称的对应关系。当然也可以通过硬编码的方式把这种对应关系在调用方 业务代码中实现，但是如果提供服务的机器挂掉调用者无法知晓，如果不更改代码会继续请求挂掉 的机器提供服务。zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务对应关系 从列表中删除。至于支持高并发，简单来说就是横向扩展，在不更改代码的情况通过添加机器来提 高运算能力。通过添加新的机器向zookeeper注册服务，服务的提供者多了能服务的客户就多了。

是管理中间层的工具，在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度，dubbo 提供一个框架解决这个问题。 注意这里的dubbo只是一个框架，至于你架子上放什么是完全取决于 你的，就像一个汽车骨架，你需要配你的轮子引擎。这个框架中要完成调度必须要有一个分布式的 注册中心，储存所有服务的元数据，你可以用zk，也可以用别的，只是大家都用zk。

Dubbo 的将注册中心进行抽象，它可以外接不同的存储媒介给注册中心提供服务，有 ZooKeeper ，Memcached ，Redis 等。

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