dubbo调用service后返回对象null_最佳实践 -- Dubbo 服务化进程的一点思考

最近主要负责公司的 dubbo 服务改造。在改造过程中，涉及到很多核心系统的编码。改造的系统涉及到核心系统，并且改造的系统一多，难免会产生一点胡思乱想。下面我就分享一下我在项目改造过程中的一点胡乱的想法。需要对大家有帮助：

1、统一的打包方式

对于之前项目中使用 restful 进行交互，项目的发布就没有版本这个概念。但在使用 dubbo 服务化就依赖版本这个概念。在项目中我们打包的方式和项目的版本的是相互绑定的。

这对于运维来说其实是一种负担。每次修改版本的时候都开发修改 build 脚本。而且运维也需要在CI/CD 的脚本也需要修改。

<build>
		<finalName>fintech-notice-client</finalName>
		<resources>
			<resource>
				<directory>${project.basedir}/src/main/resources</directory>
				<excludes>
					<exclude>**/env/**/*.properties</exclude>
				</excludes>
			</resource>
		</resources>
		<plugins>
			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
			</plugin>
		</plugins>
	</build>

在运行的的 pom.xml 文件 的 build 标签添加 finalName 指定你需要发布项目的名称。打包以后就会生成 fintech-receipt-client.jar文件。这样发布就不需要依赖版本这个概念了。

2、统一的版本管理

下面是我理解的我们项目的依赖图：

在项目中，我们定义版本的方式都是各个项目中都定义一个版本号比如：

xxx-client ：定义版本 1.0.0

xxx-service：定义版本 1.0.0

… 等等

在我的思维里，编码过程中，重复就是不好的。需要项目的依赖需要统一的版本管理。其实在我们的项目中，也有一个最顶级的项目父 POM。但是它没有发挥出它应有的作用。在这里我们需要一个 maven 的插件flatten-maven-plugin：

<build>
	<plugins>
		<plugin>
			<groupId>org.codehaus.mojo</groupId>
			<artifactId>flatten-maven-plugin</artifactId>
			<version>1.0.0</version>
			<configuration>
			</configuration>
			<executions>
				<execution>
					<id>flatten</id>
					<phase>process-resources</phase>
					<goals>
						<goal>flatten</goal>
					</goals>
				</execution>
			</executions>
		</plugin>
	</plugins>
</build>

它的作用就是统一的包管理。只需要在项目父 POM 中如下定义：

它的子项目中只需要如下定义就可以了:

这个主要是在查看 dubbo 源码的时候，发现它的包管理是基于此。哈哈，拿来主义。

3、最小化项目上传

服务化就涉及到 Jar 包依赖，并且我们项目的 Jar 包依赖是需要上传到 maven