spring与dubbo整合的一个问题大佬求解答_springbootdubbo

很难受，不知不觉期末要到了，中间件技术的大作业也马上要到ddl了，于是打算学习一下Dubbo，做个大作业。

一、Dubbo是什么

一款分布式服务框架

高性能和透明化的RPC远程服务调用方案

SOA服务治理方案

消费者的Dubbo配置

创建一个maven项目

该项目必须包含相应的Service接口以及model对象，并且代码与服务的

dubbo的问题是因为他的官网关了 对应的xsd无法获取到

对于 eclipse 来说这个文件只能改为从本地读取才能正常

修改方法是提取dubbojar META-INF 中的dubboxsd文件到随意一个目录，建议放Eclipse目录下就好

打开Eclipse的Window - preferences 选择 XMLCatalog

右边user specified entries 下add两条记录

Location选择你的dubboxsd文件

key type选Namespace name

key填入>

然后再add一条

Location选择你的dubboxsd文件

key type选schema location

key填入>

（这部分记得要复制，一般人为了省事直接在后面加上xsd，其实少了/dubbo/ 这个目录）

ok保存以后刷新你的项目 过一会儿dubbo相关的错误就没了

补充刷新方法：eclipse工具栏的 project - clean 选择所有或者单独你用到的工程

ok之后等项目重新build

截图有点问题~ 截了两次 不过这个不是重点 无所谓了

MyEclipse可能位置不同，我没有这个ide 自行搜索对应的位置吧 XML Catalog

dubbo的问题如果解决了，我要求的不多 点个“给力”就好~ 谢了

filter其实是一种责任链模式，每个filter只负责完成自己职责的部分，解除耦合，这种设计模式很利于扩展。
大家可能对Dubbo的filter不太熟悉，但是应该都写过Servlet的filter，让我们先来回顾一下Servlet的Filter：

我们重写doFilter，在chaindoFilter(request, response) 前后做一些切面的工作，比如防XSS攻击、CROS跨域请求处理、记录相关日志等，调用逻辑可以用下图来概括：

类似于Servlet中的filter，Dubbo也可以通过扩展filter来增强功能，Dubbo服务提供方和服务消费方均支持调用过程拦截，并且Dubbo 自身的大多功能均基于此扩展点实现，下面例举部分filter：
EchoFilter -> 用于provider的回声测试，检测服务是否正常
ContextFilter -> 用于provider接收RpcContext的参数
ConsumerContextFilter -> 用于consumer传递RpcContext的参数
ExecuteLimitFilter -> 用于provider的限流
ActiveLimitFilter -> 用于consumer的限流
ExceptionFilter -> 用于provider对异常进行封装
GenericFilter -> 用于provider的泛化调用，可用于集成通用服务测试框架或为其他语言调用服务提供Restful接口的支持
AccessLogFilter -> 用于provider 的access log记录
ClassLoaderFilter -> 用于provider切换当前的ClassLoader
MonitorFilter -> 用于dubbo monitor模块对consumer和provider进行监控

Dubbo filter的调用逻辑可以用下图来概括：

那么Dubbo是怎么将多个filter串起来的呢？
答案就位于ProtocolFilterWrapper这个类的buildInvokerChain方法。

看明白这里首先要理解Dubbo的SPI扩展点机制，List<Filter> filters = ExtensionLoadergetExtensionLoader(Filterclass)getActivateExtension(invokergetUrl(), key, group);这一行是获取Filter接口的所有被标注为@Activate的扩展点，然后基于回调让前一个filter调用后一个filter从而串成一个调用链，调用的先后顺序是由每个filter定义的order属性决定的（不声明默认为0），order值越小则调用优先级越高。

了解了Dubbo filter的作用和原理，那让我们来看看如何扩展：
Maven 项目结构：

src
  |-main
    |-java
      |-com
        |-xxx
           |-XxxFilterjava (实现Filter接口)

Dubbo自身的过滤器配置都放在resources/META-INF/dubbo/internal下，我们扩展的过滤器一版放在resources/META-INF/dubbo/下：
     |-resources
      |-META-INF
        |-dubbo
          |-comalibabadubborpcFilter (纯文本文件，内容为：xxx=comxxxXxxFilter)

XxxFilterjava：

META-INF/dubbo/comalibabadubborpcFilter：

xxx=comxxxXxxFilter

我司生产环境中利用Dubbo filter扩展来记录服务调用日志和服务调用链追踪。

1服务调用日志记录：
服务调用日志记录分为provider日志和consumer日志两部分，provider日志记录的是当前工程作为provider的服务提供日志，consumer日志记录的是当前工程作为consumer的服务消费日志，以下是部分consumer日志内容：

日志会记录每一次调用的consumer的ip、端口、调用时间、provider的ip、端口、接口请求的时间、调用的方法、调用耗时、调用结果（成功或失败，失败则打印异常）、方法入参（可选）、返回值（可选）等。
由于每次调用的入参和返回值的内容比较多，所以方法入参和返回值是否打印都是可以配置的，filter会根据当前配置的日志等级去打印。

2调用链追踪：
Dubbo Filter结合brave + zipkin实现RPC调用链追踪和梳理项目间的依赖关系，filter中用brave向zipkin服务器异步发送>maven会根据模块的版本号(pom文件中的version)中是否带有-SNAPSHOT来判断是快照版本还是正式版本。
deploy发布
传统的web项目一般会有一个api模块，用于发布对外的RPC接口，如Dubbo。这个时候一般通过发布jar包，提供maven坐标的方式，让别人引入你的依赖。这个时候可以直接通过maven deploy命令直接发布快照版本到私服。
像IDEA这种集成环境，可以通过简单的点击直接发布。
同时需要注意，maven基于 POM文件中的 version来确定你将要发布的 SNAPSHOT还是 release。所以不能瞎命名，容易把不稳定的 jar包发布到 release仓库。
Release命令发布
比较复杂的是通过 mvn release:prepare和 mvn release:perform来发布，这种发布会自动升级版本，不用手动维护POM文件中的version版本。
流程：
发版之前需要保证本地文件提交，否则会导致发版失败 =>发版前要commit
发版之前需要保证本地成功执行 mvn checkstyle:checkstyle，否则会导致发版失败(可选)
发版之前需要保证mvn仓库无重复版本，git上无重复的Tag，否则会导致发版失败
要清楚本地tag和远程tag
发布之前需要保证本地成功执行mvn clean install -Dmaventestskip=true，否则会导致发版失败，而且有效性只有一次，修改代码后需要重新执行该命令。
发版命令：
mvn release:prepare -Darguments="-DskipTests" 预准备
mvn release:perform -Darguments="-DskipTests" 发布
mvn release:rollback -Darguments="-DskipTests" 回滚命令
关于上面三条命令的更详细解释：
release:prepare这条命令主要是做打包前的准备：
输入对应的release需要打包的版本等信息，如果不输入有默认的内容
将需要记录和准备的内容缓存到pomxml目录下的releaseproperties文件中
在本地和远程库的GIT中打上对应版本的tag
在准备过程中还会run 单元测试等phase，如果没有异常的话可以继续最后一步。如果git还没有commit或单元测试失败会导致prepare失败，这时候你就需要到下面一个命令了。
release:rollback
如果在准备阶段发生错误，或者需要修改某些地方的话。就需要到这个命令了，这个命令执行以后会做以下这些事
删除线上git库tag，但是本地库tag没有被删除，需要手动使用git tag -d XXX进行删除。如果不将本地库中的tag删除将会导致prepare失败。
删除之前缓存在pomxml统一目录下的配置
release:perform
如果确认无误了以后，就可以执行perform命令了。这个命令干了以下这些事：
验证代码合法性
将你之前的10-SNAPSHOT改为11-SNAPSHOT
将10版本deploy至scm配置的nexus release库中
jar打包上传至nexus库
恭喜，你已经把你的10-SNAPSHOT成功的打包成10的release版本了。同时你会发现你的pomxml文件会自动的变成11-SNAPSHOT版本。虽然这一系列 *** 作都可以通过手动完成。但是有这个工具的存在，免去了很多步骤。
QA
实际发包过程中，会遇到一些报错，这个时候通过执行 rollback外加删除远程和本地的 tag基本可以解决问题。

dubbo：跨系统通信。比如：两个系统，一个系统A作客户端，一个系统B作服务器， 服务器B把自己的接口定义提供给客户端A，客户端A将接口定义在spring中的bean。客户端A可直接使用这个bean，就好像这些接口的实现（即服务器B的代码）也是在自己的代码里一样。客户端A和服务器B在启动的时候都会把自己的机器IP注册到zookeeper上，客户端A会把zk上的服务端ip拉到磁盘上，并记录哪些ip提供哪些服务（服务端启动时暴露给zk），然后客户端根据ip调用服务端的服务。
dubbo需要将服务器B（提供方）的接口类打成包，服务器B（提供方）去实现，客户端A（消费方）去调用。
maven依赖：在一个多module的maven项目中，maven子模块间提供依赖实现调用。比如，模块A调用模块B，将模块B打包成jar，引入到模块A中（相当于模块A拥有了模块B），实则模块A和模块B是在同一项目中运行。而dubbo的提供者和消费者是两个独立的服务（A只是调用B，并未拥有B）。

Dubbo有很长一段时间的发展史，2018年的时候不知道为什么阿里暂更了一年，之后又重新开始更新。之前一直是阿里在维护，后面阿里把它捐给了Apache基金会，由Apache来维护，26x之前，maven中的包名都是alibaba，270之后包名改成了apache，其中整合入系统中有一些差异；发展史:

Dubbo的原理什么的以及它的组成这里就不扯了，直接说说dubbo的项目结构吧。
基本的Dubbo项目组成分为三个部分：

接口层这里自定义了接口，实现部分由服务提供层来实现。建议将model也放在接口层中，接口层中对dubbo没有相关依赖，在这里pom就不提供了。

就算把github中代码clone到本地，还是会因为各种历史原因（阿里淘汰）没有进行对应的更新。
因此，在maven中进行配置时，需要考虑到当前环境和tomcat版本的问题。
如果是JAVA 17，基本上都是支持的，如果到18，就要进行变更。
如果tomcat是80的话，也要进行变更。
众所周知，tomcat8里面要能跑，基本上spring要能上4。
好了不多说，现在对最主要的
dubbo-admin和dubbo-master进行pom变更，如下：
1、webx的依赖改为316版；
<dependency>
<groupId>comalibabacitrus</groupId>
<artifactId>citrus-webx-all</artifactId>
<version>316</version>
</dependency>
2、添加velocity的依赖，我用了17；
<dependency>
<groupId>orgapachevelocity</groupId>
<artifactId>velocity</artifactId>
<version>17</version>
</dependency>
3、对依赖项dubbo添加exclusion，避免引入旧spring
<dependency>
<groupId>comalibaba</groupId>
<artifactId>dubbo</artifactId>
<version>${projectparentversion}</version>
<exclusions>
<exclusion>
<groupId>orgspringframework</groupId>
<artifactId>spring</artifactId>
</exclusion>
</exclusions>
</dependency>
4、webx已有spring 3以上的依赖，因此注释掉dubbo-admin里面的spring依赖
<!--<dependency>-->
<!--<groupId>orgspringframework</groupId>-->
<!--<artifactId>spring</artifactId>-->
<!--</dependency>-->
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
修改完毕后重新build工程，update source和包更新即可看到新鲜出炉的war包。

---