Dubbo简介

一、架构发展过程

首先，我们先来看看上面的架构发展的线路图：单一应用架构 --> 垂直应用架构 --> 分布式服务架构 --> 流动计算架构 。

单一应用架构

　　在一些中小型的传统软件公司中，一个 产品/项目 的所有的代码都在一个工程里，工程下面有多个不同的模块。在部署的时候，将整个工程打包然后放到服务器 Tomcat 下来运行。然后，为了所谓的“高可用”，会使用一台负载均衡服务器（比如Nginx），然后将应用部署到两到三台服务器上。至于系统的依赖可能只有一个，就是类似于 MySQL、Oracle 这类的关系型数据库，会单独部署在一台服务器上，让系统来使用。就如下面这个图：

对于这种单一应用的架构，随着业务量的增长，虽然也可以进行扩展，但是扩展的每台服务器上都部署了所有的功能，假如只需要扩展交易能力而其他模块的功能不需要扩展呢？这种单一架构的系统就没办法解决，所以后面就出现了垂直应用架构。

从研发团队人数的发展来看，这种架构模式也是越来越不靠谱的。如果研发团队有几十人甚至上百人一起研发这个系统，业务逻辑复杂，功能模块多达几十上百个，大家都在一个工程内写代码，大量的冲突以及代码的合并都会让人崩溃。而且测试也会非常痛苦，比如某个功能模块要上线了，就必须得把整个单块系统所有的功能都回归测试一遍才敢上线。因为大家的代码都在一个工程里，都是耦合在一起的，你修改了代码，必须全部测试一遍才能保证系统正常。

垂直应用架构

　　随着业务量的增加，单一应用的架构就越来越不适合了，这时候就诞生了垂直应用架构，将整个系统拆成好几个单独的应用，提升了效率，扩容的时候也能够对对应的业务进行精准的扩容。

这种垂直应用架构的模式虽然将每个模块都拆分开了，但是每个模块内部还是有非常多的功能，比如说用户中心当中可能会有：注册、登录、密码校验等等功能，密码校验可能会比注册和登录使用频繁得多，这个时候我们是否要考虑将每一个模块的单体功能再进行拆分，然后就变成了下面这个样子：

当拆分得越来越多，达到几十上百甚至上千个的时候，这种垂直应用架构就不能很好的支撑系统的运行，所以就出现了分布式服务架构。

分布式服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。用于提高业务复用及整合的分布式调用是关键。

二、分布式&集群&RPC

分布式：一个电商系统，用户模块部署在 Server1, 订单模块部署在 Server2, 促销模块部署在 Server3, 商品模块部署在 Server4，他们之间通过远程rpc实现服务调用，这就叫分布式。强调的是不同功能模块，单独部署在不同的 Server 上，所有 Server 加起来是一个完整的系统。

集群：更多强调的是灾备，一个电商系统，完整的部署在Server1上一个，完整的部署在Server2上一个，Server1宕机后，Server2仍然可以正常提供请求服务，这叫集群。同样对于某一功能模块，比如用户模块部署在 Server1上，同样部署在 Server2上，也叫做集群。分布式系统的每个功能模块节点，都可以用多机做成集群。

RPC：Remote Procedure Call，远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。举个例子说明：两台服务器 A、B，分别部署不同的应用 a 和 b。当A服务器上的应用 a 想要调用B服务器上的应用 b 提供的方法的时候，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义传达调用的数据，这个时候就出现了一个远程服务调用的概念。

常见RPC框架：

• dubbo：Alibaba开发的一个RPC框架，远程接口基于Java Interface, 依托于Spring框架。
• gPRC：是由Google公司开源的高性能RPC框架。是一个高性能、开源和通用的 RPC 框架，面向移动和 HTTP/2 设计。目前提供 C、Java 和 Go 语言版本
• thrift：Apache的一个项目(http://thrift.apache.org)，前身是Facebook开发的一个RPC框架，采用thrift作为IDL (Interface description language)。
• brpc：一个基于protobuf接口的RPC框架，在百度内部称为“baidu-rpc”，它囊括了百度内部所有RPC协议，并支持多种第三方协议，从目前的性能测试数据来看，brpc的性能领跑于其他同类RPC产品。

三、Dubbo架构

Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

节点角色说明

调用关系说明

1. 服务容器负责启动，加载，运行服务提供者。
2. 服务提供者在启动时，向注册中心注册自己提供的服务。
3. 服务消费者在启动时，向注册中心订阅自己所需的服务。
4. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

Dubbo的特点：

连通性

• 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
• 监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示
• 服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销
• 服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销
• 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
• 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
• 注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
• 注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

健壮性

• 监控中心宕掉不影响使用，只是丢失部分采样数据
• 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
• 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
• 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
• 服务提供者无状态，任意一台宕掉后，不影响使用
• 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

伸缩性

• 注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心
• 服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者

升级性

当服务集群规模进一步扩大，带动IT治理结构进一步升级，需要实现动态部署，进行流动计算，现有分布式服务架构不会带来阻力。下图是未来可能的一种架构：

节点角色说明

四、Zookeeper

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

Dubbo的注册、订阅、通知等功能不是由 Dubbo本身来实现的，而是借助于这些存储媒介来实现的。

ZooKeeper的特性

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

五、Dubbo环境搭建

1、Zookeeper

下载

https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/

安装

解压安装包，然后将 conf 目录下的 zoo_sample.cfg 改为 zoo.cfg 即可。

启动

进入 Zookeeper 安装目录下的 bin 目录，执行以下命令

./zkServer.sh start

连接

./zkCli.sh -server IP:端口

2、引入依赖

compile(‘com.alibaba:dubbo:2.6.6‘)
compile(‘io.netty:netty-all:4.1.34.Final‘)
compile(‘org.apache.zookeeper:zookeeper:3.4.14‘)
compile(‘org.apache.curator:curator-framework:2.13.0‘)
compile(‘org.apache.curator:curator-recipes:2.13.0‘)

3、创建三个工程

dubbo-order-iface

创建两个实体类 Order 和 RegMsg，以及一个对外提供的接口 IOrderService

@Getter
@Setter
@ToString
public class Order implements Serializable {
  private String orderId;
  private Integer amount;
  private String orderInfo;
}

Order

@Getter
@Setter
@ToString
public class RegMsg implements Serializable {

  private String errorNo;
  private String errorMsg;

  public RegMsg(String errorNo, String errorMsg) {
    this.errorNo = errorNo;
    this.errorMsg = errorMsg;
  }
}

RegMsg

这两个实体类必须实现 Serializable，因为它要在不同的进程之间传输，需要进行序列化和反序列化

public interface IOrderService {

  RegMsg creatOrder(Order order);
}

IOrderService

注意：该工程需单独打包，发到中央仓库，供服务提供方和消费方使用（其他工程可以以 jar 包的方式引入）

dubbo-order-provider（服务提供者）

服务提供者实现 IOrderService 接口

public class OrderServiceImpl implements IOrderService {

  @Override
  public RegMsg creatOrder(Order order) {
    System.out.println("OrderServiceImpl -> create order： " + order);
    return new RegMsg("200","create order success!!");
  }
}

OrderServiceImpl

用 Spring 配置声明暴露服务

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
       xsi:schemaLocation="http://www.springframework.org/schema/beans        http://www.springframework.org/schema/beans/spring-beans-4.3.xsd        http://dubbo.apache.org/schema/dubbo        http://dubbo.apache.org/schema/dubbo/dubbo.xsd">

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

    <!-- 使用zookeeper注册中心暴露服务地址 -->
    <dubbo:registry address="zookeeper://192.168.182.128:2181" />

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

    <!-- 和本地bean一样实现服务 -->
    <bean id="orderService" class="com.dubbo.order.provider.service.OrderServiceImpl" />

    <!-- 声明需要暴露的服务接口 -->
    <dubbo:service interface="com.dubbo.order.iface.service.IOrderService" ref="orderService" />

</beans>

provider.xml

加载 Spring 配置

public class ProviderApp {

  public static void main(String[] args) {

    ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("provider.xml");
    context.start();

    try {
      // 按任意键退出
      System.in.read();
    } catch (IOException e) {
      e.printStackTrace();
    }
  }
}

ProviderApp

dubbo-order-consumer（服务消费者）

通过 Spring 配置引用远程服务

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
       http://dubbo.apache.org/schema/dubbo
       http://dubbo.apache.org/schema/dubbo/dubbo.xsd">

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

    <!-- 使用zookeeper注册中心暴露发现服务地址 -->
    <dubbo:registry address="zookeeper://192.168.182.128:2181" />

    <!-- 生成远程服务代理，可以和本地bean一样使用demoService -->
    <dubbo:reference id="orderService" interface="com.dubbo.order.iface.service.IOrderService" />
</beans>

consumer.xml

加载Spring配置，并调用远程服务

public class ConsumerApp {

  public static void main(String[] args) throws Exception {
    ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("consumer.xml");
    context.start();

    // 获取远程服务代理
    IOrderService orderService = context.getBean("orderService", IOrderService.class);

    Order order = new Order();
    order.setOrderId("1");
    order.setAmount(1024);
    order.setOrderInfo("dubbo create order");

    // 执行远程方法
    RegMsg regMsg = orderService.creatOrder(order);
    // 显示调用结果
    System.out.println("regMsg = " + regMsg);
  }
}

ConsumerApp

原文地址：https://www.cnblogs.com/L-Test/p/11689567.html