我们现在来做dubbo和springboot整合：

我们先来创建一个springboot项目：

然后把serviceimpl层拷贝过来。

 

 因为我们这个也需要用到公用接口和实体类，所以还是需要导入一下这个依赖：

同样的我们也需要创建一个服务的消费者：

消费者我们选用web的方式。

然后我们同样导入这个公用的interface依赖。

 同样向上面那样复制消费者的实现。

这里我们改动一下。

这样我们就可以把数据以json的格式返回到页面上了。

 同样我们这里现在也要配置，不然不配置肯定是失败的。

步骤都差不多。

导入的依赖不同，配置文件写法不同，这里用注解的方式。

然后我们去配置文件中做相关配置：

 

然后我们要给我们的userservice配上两个重要的注解。

注意这里的service是dubbo下的注解。

我们去启动一下。

我们就看到了我们的服务。

在消费者里我们同样要引dubbo-springboot-starter依赖。

 然后我们还是要来写配置文件：

我们使用这个注解。可以从注册中心中拿到这个服务。

同样加上这个注解。

给它加上端口号。

然后我们启动消费者服务。

 

我们可以查到它。

我们就查到了这个内容。

其实主要就是三大步，pom引入依赖，编写配置文件，使用注解。

我们的覆盖优先级上面的高于下面的。

那我们就来试一下：

 

然后我们去启动一下：

我们发现使用的是20881.

 

我们现在把它注释掉，再去重新启动。

它就变成20882了。

 然后现在我们来配置虚拟机参数：

所以我们可以发现我们的优先级，虚拟机参数最高，然后是application配置，最后是dubbo配置。

 

我们现在来直接启动消费者：

它会进行报错，因为我们没有启动提供者，就直接启动消费者了，这样报错，程序终止。

 

我们配置了这个以后，我们再去启动一下我们的服务：

虽然会报错，但是它会进行输出，只有遇到需要调用service时才会报错，而不是一开始就报错。

但是我们这是在一个接口去配置，但是如果有多个接口，每一个都去配置会比较麻烦，所以这里我们还可以这么来写：

 

可以直接这样去配置，让所有的消费者都不检查。

 参照文档，注册中心registry也可以做这个配置。

超时&配置覆盖关系：

 我们可以配置超时，因为有的时候我们的消费者在调用提供者的方法时，可能会出现网络不佳的情况，所以我们这里可以去给它配置我们的超时时间。

然后我们人为的让服务提供者去睡上4秒。

再去启动提供者和消费者：

我们现在不去设置超时，去启动测试一下：

 

它会进行报错。

我们的超时默认是1000毫秒。

我们现在把超时设置为5000毫秒：

我们就运行完成了。

我们知道我们的reference是单独给每个接口进行配置的，那么我们也可以进行统一配置：

我们 还可以在reference里配置我们的method，这样可以具体到接口里的某一个方法。这里我们也给它配置一个超时设置，那么我们运行时会执行哪个超时设置呢？

我们发现报错了。也就是我们精确的设置的优先级会高于我们整体的设置。

这是它们的优先级级别，1是优先级最高，3是优先级最低。

<!--声明需要调用的远程服务的接口；生成远程服务代理  -->
<!--
  1）、精确优先 (方法级优先，接口级次之，全局配置再次之)
  2）、消费者设置优先(如果级别一样，则消费方优先，提供方次之)
-->

 

我们现在再来做一个操作：

消费者：

提供者：

那我们现在是消费者优先还是精确优先呢？

 

我们发现出错了，所以可以看出来是在同等精确级别下，消费者优先。

重试次数：

我们给方法里加一段输出语句。

我们的提供方是配置了超时的：

我们在消费者里去配置重试次数：

现在我们能看到一共有3个提供者。

然后我们去启动消费者：

报错。

我们的提供者1试了一次。

提供者2也试了一次。

提供者3试了2次。

一共也重试了4次，并且它不会一棵树上吊死。一个不行，就再去找其它的。

注：

 

我们现在写了一个老版本。

我们再去为这个接口去写一个新的版本：

 

我们现在相当于一个接口，我们有了两个版本 。那么我们就可以在provider.xml里去配置出来：

 

我们这样就在我们的xml文件里配置了两个service接口。

 然后我们就可以在consumer中去配置：

我们可以指定我们用提供者里的哪个版本的接口。

那我们去启动一下看看：

 

我们也可以启动新版本：

 

 当然我们还可以配置随机调用接口版本：

本地存根：

 我们现在来创建一个本地的存根：

 接下来我们要在消费者的xml中进行一个配置：

 然后我们在存根中加一个输出语句，运行时看看是否走了我们的存根：

 然后我们去运行一下：

我们发现我们使用了存根。

然后我们正常应该把存根放到我们的提供者下面，因为我们正常是在消费者调用服务之前进行一些其它的操作才会使用存根。

 与SpringBoot整合的三种方式：

我们之前呢，使用的是xml的方式去做一些dubbo中的配置，我们有些可以直接利用注解完成：

比如我们可以用这种方式去做超时处理。

但是有些配置我们光依赖注解是没法去完成的：

比如我们这种精确到方法中的。

 SpringBoot和dubbo整合的三种方式：

1.导入dubbo-starter，在application.properties配置属性，使用@Service[暴露服务],使用@Reference[引用服务]

这种方式我们使用@EnableDubbo注解

 就可以开启基于注解的dubbo功能。

那么我们现在来说第二种方式：

这种方式我们来保留dubbo的xml文件的方式：

我们把之前的xml文件复制过来：

 

那么我们这种方式就不需要我们的application文件了。

 

我们直接用之前学的xml的方式就可以了。

然后我们再启动一下我们的提供者（boot版本）：

 这个方法我们保留dubbo.xml配置文件。

导入dubbo-starter，使用@ImportResource导入dubbo的配置文件即可：

当然我们还有第三种方式：

使用注解api的方式：

将每一个注解手动创建到容器中：

我们看到有application标签。

那就把它以类的方式注入springboot:

 

 

有注册中心标签，也把它以类的形式注入：

 

 

还有通信规则，那我们把通信规则也以类的方式注入出来：

 

 

我们还有服务标签，那么我们把它也配置出来：

 

我们如果还想用其它标签，那么我们也可以去把其它标签进行配置相关的配置类即可。

 让dubbo来扫描其它的组件。

启动类上配置相关的注解。

 

运行以后也没有什么问题。

我们的dubbo的主要使用的配置基本上就都有学习到了。