【Dubbo基础知识】

​Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架，现已成为 Apache 基金会孵化项目。

本质上是一个Jar包,分布式框架,一个远程服务调用的分布式框架。

 

包含:

远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

 

 

以前服务都在一个服务器上，调用方法直接就自然而然调用了，现在因为需求增多拆分了这么多个，部署在不同的服务器上

Dubbo的优势

1.采用透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。

2.软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

3. 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

 

dubbo架构

 

节点：

Provider（生产者）: 暴露服务的服务提供方。

Consumer（消费者）: 调用远程服务的服务消费方。

 

Registry（注册中心）: 服务注册与发现的注册中心。dubbo推荐的是zookeeper。什么是zookeeper？zookeeper是用于分布式中一致性处理的框架。简单的讲，zookeeper就是个中介，卖楼的（生产者）把楼盘信息放在中介（注册中心）那里，想买楼的（消费者）去中介那里获得楼盘资源清单。还不够，我们还需要个监控中心（干嘛用的？当然是监控用的，调用失败怎么办？挂了怎么办？）：Monitor: 统计服务的调用次调和调用时间的监控中心。（不画图了）

然后，Provider放在容器里运行，就叫做Container服务运行容器。（不画图了）

最终dubbo架构，如图（从0开始）：

 

 

 

从0. 服务容器负责启动，加载，运行服务提供者。

1. 服务提供者（生产者）在启动时，向注册中心注册自己提供的服务。

2. 服务消费者在启动时，向注册中心订阅自己所需的服务。

3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心

Dubbo主要的配置项有哪些，作用是什么？

provider配置

<!-- 提供方应用信息，用于计算依赖关系 -->
<dubbo:application name="hello-world-app" />

<!-- 使用multicast广播注册中心暴露服务地址 -->
<dubbo:registry address="multicast://224.5.6.7:1234" />

<!-- 用dubbo协议在20880端口暴露服务 -->
<dubbo:protocol name="dubbo" port="20880" />

<!-- 声明需要暴露的服务接口 -->
<dubbo:service interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" />

<!-- 和本地bean一样实现服务 -->
<bean id="demoService" class="com.alibaba.dubbo.demo.provider.DemoServiceImpl" />

consumer配置

<!-- 消费方应用名，用于计算依赖关系，不是匹配条件，不要与提供方一样 -->
<dubbo:application name="consumer-of-helloworld-app" />

<!-- 使用multicast广播注册中心暴露发现服务地址 -->
<dubbo:registry address="multicast://224.5.6.7:1234" />

<!-- 生成远程服务代理，可以和本地bean一样使用demoService -->
<dubbo:reference id="demoService" interface="com.alibaba.dubbo.demo.DemoService" />

3.2 为何 dubbo 服务提供者节点使用 zk 临时节点

zk 临时节点将会在 zk 客户端断开后，自动删除。dubbo 服务提供者正常下线，其会主动删除 zk 服务节点。

如果服务异常宕机，zk 服务节点就不能正常删除，这就导致失效的服务一直存在 ZK 上，消费者还会调用该失效节点，导致消费者报错。通过 zk 临时节点特性，让 zk 服务端主动删除失效节点，从而下线失效服务。

四、doSubscribe: 服务动态发现的原理

4.1 订阅基本原理

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

dubbo zk 注册中心采用是事件通知与客户端拉取方式。服务第一次订阅的时候将会拉取对应目录下全量数据，然后在订阅的节点注册一个 watcher。一旦目录节点下发生任何数据变化，zk 将会通过 watcher 通知客户端。客户端接到通知，将会重新拉取该目录下全量数据，并重新注册 watcher。利用这个模式，dubbo 服务就可以就做到服务的动态发现。

4.2 源码解析

讲完订阅的基本原理，接着深入源码。

doSubscribe 方法需要传入两个参数，一个为 URL 实例，另一个为 NotifyListener，变更事件的监听器。 方法内部会根据 URL 接口类型分成两部分逻辑，全量订阅服务与部分类别订阅服务。

doSubscribe 方法整体源码逻辑：

    public void doSubscribe(final URL url, final NotifyListener listener) {

        if (Constants.ANY_VALUE.equals(url.getServiceInterface())) {

// 全量订阅逻辑

        } else {

// 部分类别订阅逻辑

        }

    }

服务治理中心(dubbo-admin)，需要订阅 service 全量接口，用以感知每个服务的状态，所以订阅之前将会把 service 设置成 *，处理所有service。

服务消费者或服务提供者将会走部分类别订阅服务，下面我们以消费者视角，深入后续源码。

文章刚开头讲道了 zk 目录节点存在四种类型，这里将会根据 根据 URL 中 category值，决定订阅节点路径。

服务提供者 URL 中 category值默认为 configurators，而消费者 URL 中category值默认为 providers,configurators,routers。如果 category类别值为 *，将会订阅四种类别路径，否则将会只订阅 providers类型的路径。

toCategoriesPath 源码如下：

    private String[] toCategoriesPath(URL url) {

        String[] categories;

// 如果类别为 *，订阅四种类型的全量数据

        if (Constants.ANY_VALUE.equals(url.getParameter(Constants.CATEGORY_KEY))) {

            categories = new String[]{Constants.PROVIDERS_CATEGORY, Constants.CONSUMERS_CATEGORY,

                    Constants.ROUTERS_CATEGORY, Constants.CONFIGURATORS_CATEGORY};

        } else {

            categories = url.getParameter(Constants.CATEGORY_KEY, new String[]{Constants.DEFAULT_CATEGORY});

        }

// 返回路径数组

        String[] paths = new String[categories.length];

        for (int i = 0; i < categories.length; i++) {

            paths[i] = toServicePath(url) + Constants.PATH_SEPARATOR + categories[i];

        }

        return paths;

    }

接着循环路径数组，循环内将会缓存节点监听器，用以提高性能。

    // 循环路径数组

    for (String path : toCategoriesPath(url)) {

        ConcurrentMap<NotifyListener, ChildListener> listeners = zkListeners.get(url);

        // listeners  缓存为空，创建缓存

        if (listeners == null) {

            zkListeners.putIfAbsent(url, new ConcurrentHashMap<>());

            listeners = zkListeners.get(url);

        }

        ChildListener zkListener = listeners.get(listener);

        // zkListener  缓存为空则创建缓存

        if (zkListener == null) {

            listeners.putIfAbsent(listener, (parentPath, currentChilds) -> ZookeeperRegistry.this.notify(url, listener, toUrlsWithEmpty(url, parentPath, currentChilds)));

            zkListener = listeners.get(listener);

        }

        // 创建订阅节点

        zkClient.create(path, false);

        // 使用 ZK 客户端订阅节点

        List<String> children = zkClient.addChildListener(path, zkListener);

        if (children != null) {

            // 存储全量需要通知的 URL

            urls.addAll(toUrlsWithEmpty(url, path, children));

        }

    }

    // 回调 NotifyListener

    notify(url, listener, urls);

最终将会使用 CuratorClient.getChildren().usingWatcher(listener).forPath(path) 在 ZK 节点注册 watcher，并获取目录节点下所有子节点数据。

这里 watcher 使用 Curator 接口 CuratorWatcher，一旦 ZK 节点发生会变化，将会回调 CuratorWatcher#process 方法。

CuratorWatcher#process 方法源码如下：

        public void process(WatchedEvent event) throws Exception {

            if (childListener != null) {

                String path = event.getPath() == null ? "" : event.getPath();

                childListener.childChanged(path,

                       // 重新设置 watcher，并获取节点下所有子节点

                        StringUtils.isNotEmpty(path)

                                ? client.getChildren().usingWatcher(this).forPath(path)

                                : Collections.<String>emptyList());

            }

        }