1. Dubbo简介

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案。

Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。Dubbo框架使得使用者可以像调用本地方法一样调用远程方法，而这一切只需要简单的配置。Dubbo完全兼容Spring配置方式注入，也与Spring boot无缝整合。

2. 简单示例

整个Demo项目结构如下：

dubbo 接口可用性 dubbo接口调用方式_xml

2.1 dubbo-api

定义服务接口：

public interface IDemoService {
    String getDemoString();
}

2.2 dubbo-provider

服务提供方，实现服务：

@Service("demoServiceImpl")
public class DemoServiceImpl implements IDemoService {
    @Override
    public String getDemoString() {
        System.out.println("---provider被调用了");
        return "provider被调用了";
    }
}

加载 dubbo 配置，采用config类的方式加载配置文件：

@Configuration
@PropertySource("classpath:dubbo.properties")
@ImportResource({"classpath:dubbo/*.xml"})
public class PropertiesConfig {
}

如开始的图中所示，dubbo文件夹下包含两个xml文件：

  • dubbo.xml：dubbo基础配置
  • dubbo-provider.xml：声明需要暴露的服务接口，<dubbo:service…

2.3 dubbo-consumer

服务消费方，加载配置的方式和服务提供方一致。

  • dubbo-consumer.xml，增加引用远程服务配置，像调用本地方法一样，<dubbo:reference…

构建测试方法：

@RunWith(SpringRunner.class)
@SpringBootTest(classes = DubboConsumerApplication.class)
public class TestConsumer {
    @Resource
    private IDemoService demoService;

    @Test
    public void sayHello() {
        demoService.getDemoString();
    }
}

2.4 启动测试

  1. 先启动zookeeper
  2. 启动provider工程
  3. 启动consumer测试方法，查看输出
    在dubbo-provider的控制台，可以看到：“—provider被调用了”的输出。

详细代码见GayHub上的示例项目。

3. 常见问题记录

3.1 项目结构

  • dubbo-api：提供接口等基础类，不需要运行
  • dubbo-provider：
  • 加载dubbo配置，dubbo.xml，config\PropertiesConfig.java（引入dubbo.properties配置文件及xml文件）
  • 实现接口，定义服务名@Service(“demoServiceImpl”)
  • 声明需要暴露的服务接口，dubbo-provider.xml
  • dubbo-consumer：
  • 加载dubbo配置，和provider一致
  • 定义测试类和方法

3.2 常见问题

项目中软件的版本

初用dubbo时，其版本还是很坑爹的，所以在此记录一下本人使用的版本。括号中日期是Maven仓库里显示的日期。

  • zkServer：3.4.12（1 May, 2018）
  • springboot：2.1.6.RELEASE（Jun, 2019）
  • com.101tec.zkclient：0.11（Oct, 2018）
  • org.apache.zookeeper：3.4.13（Jul, 2018）
  • com.alibaba.dubbo：2.6.0（Jan, 2018）
  • Dubbo-admin： dubbo-admin-2.5.10.war

IP和Port问题

  • zookeeper.connect=localhost:2181
    ，在host文件里面做了映射才可以使用127.0.0.1，
  • 注意端口冲突的问题

4. 使用dubbo-admin

通过dubbo提供的界面查看当前的服务等各种信息，使用步骤如下：

  • 下载dubbo-admin.war包
  • 放到tomcat/webapps目录下，启动tomcat
  • 访问：http://localhost:8080/dubbo-admin/ (默认密码在dubbo-admin\WEB-INF\dubbo.properties中)

可以查看各种信息：

dubbo 接口可用性 dubbo接口调用方式_Spring Cloud_02

5. Dubbo和SpringCloud的异同

  • 底层实现的协议不同
  • Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC通信。
  • SpringCloud是基于Http协议+rest接口调用远程过程的通信，相对来说，Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活。
  • 模块区别
  • Dubbo主要分为服务注册中心，服务提供者，服务消费者，还有管控中心；
  • SpringCloud则是一个完整的分布式一站式框架，他有着一样的服务注册中心，服务提供者，服务消费者，管控台，断路器，分布式配置服务，消息总线，以及服务追踪等
  • 注册中心不同：Spring Cloud 使用的 eureka ；dubbo推荐使用zookeeper
  • Zookeeper：保证了cp(一致性、分区容错性)，但是作为服务注册中心，我们可以容忍注册中心返回的是几分钟以前的注册信息。但是服务中心却必须保证可用性，即服务注册中心对于高可用性的需求高于一致性。对于可用性，zookeeper有一个leader选举方案 。当master主节点宕机与其他节点失去联系时，其他节点会重新进行Leader选举，选出新的master节点。然而选举耗时过长，一般为30~120S，并且整个选举期间，整个zookeeper集群是无法使用的。
  • Eureka：保证了ap(可用性、分区容错性)，eureka每一个节点都是平等的，几个节点宕机不会影响正常节点的工作。剩余的正常节点依旧可以提供服务注册和查询。并且，当客户端向某节点注册服务时，注册失败或者超时，则会自动切换到其他节点。只要有一台eureka节点还正常工作，就能保证注册服务的可用。但是***对于服务信息的同步则不能保证一致性(不能保证强一致性，但是最终一致)***。除此之外，Eureka还有一种自我保护机制，如果在15分钟内85%的节点都没有正常心跳(不可用)那么Eureka就认为客户端与注册中心之间出现了网络故障，此时会出现以下几种情况：
    1、Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
    2、Eureka仍然能够接收新服务的注册和查询请求，但是不会被同步到其他节点上(保证当前节点的可用性)
    3、当网络稳定后，当前实例新注册的服务会被同步到其他节点