聊聊代码复用

大家好，我是老吕，今天聊聊代码复用。

减少重复代码，对重复代码进行抽象、下沉，遵守设计原则，应用设计模式，都有一个共同的目的：发现变化，封装变化，提高代码的可复用性，减少需求变化影响的范围，使软件、系统、云服务、网站等能够可控的修改与升级，具有更长的生命周期。

代码复用的级别或者复杂度

级别1：复制粘帖

如果只有一个地方用这段代码，也无可厚非，当有两个以上地方用的时候就需要考虑封装成函数了。

级别2：函数复用

函数、函数库 是在面向过程语言里的叫法，在Java这种面向对象的编程语言中对应的就是没有状态的对象，里面只有方法。往往是一些逻辑比较简单的工具类，并且往往是静态类。

级别3：类（对象）复用

同时具备状态和行为，可以完成稍微复杂的数据结构与算法，比如一个List集合数据结构的实现。

对象封装了具体操作和相关状态。客户代码只需要知道对象可以实现特定的功能操作即可，具体的操作是如何实现的，则由对象来负责。

级别4：模块/服务复用

对于复杂的功能，往往涉及的操作和状态都比较多，需要多个类相互协作才能完成。多个类就构成了模块。

模块内部的实现往往是复杂的，甚至可能带有注解，甚至需要访问外部系统，比如Redis、DB、MQ等。

下面重点讲一下在微服务架构中，模块/服务复用的实现方式。

模块/服务复用复用的实现方式

我所了解的模块共享复用有三种实现方式，我们需要按不同的需求对号入座，架构才能更加优雅。

1、普通JAR包

1）简单的场景不需要和Spring集成的场景

比如：Guava类库、Apache Commons 组件等

2）需要和Spring集成的场景

Dubbo、MyBatis、Hibernate等框架，这种情况需要比较多的繁琐配置。

（xml，Annotation、configuration、DubboScan扫描配置等）

2、Starter  JAR包

SpringBoot提供了starter机制，用来解决和Spring集成时配置复杂的问题。

原理是基于META-INF下的spring.factories 文件对需要初始化的框架进行自动配置。

1）开源框架的starter

2）共享业务模块的starter

我觉得这种方式非常优雅，解决了1） 包扫描路径的问题，不再需要业务方指定各种特定的扫描路径了（比如你给某个类加了@Component注解，那么在普通的jar中是无法自动融入Spring容器的，但是在starter中依靠特定注解可以轻松解决，对业务方无感知）  2）统一了配置文件，解决了繁多的配置文件路径和名称问题，配置环境变量变得很简单，读取也很简单。

3、RPC

在前面的两种方式中，都是将代码下载到本地和业务系统部署在一起运行，共用JVM，都属于本地调用，确实能达到复用代码的目的，当然像开源框架这种或者自己写的框架扩展功能之类的场景也只能部署到本地才能起作用。

但是像更复杂的业务模块功能的共享还是用RPC的方式更合适，比如：基础服务，公共业务服务，特定业务服务，这也是分布式系统的基础，也是目前微服务架构中的做法。

但是也有一些老项目在改造成微服务的过程中不彻底，仅仅是做了应用层的微服务化，但是DB并没有分开，也就是多个微服务共享一个数据库。

并且他们还不想在微服务之间进行RPC通信，比如两个微服务都要直接访问某个table，那么这种情况下如何复用代码呢？你肯定会说这么做本来就是不对的，真正的微服务架构中 每个微服务都有自己独立的数据库，其它服务不能直接访问别的微服务的数据表，必须通过RPC接口来访问。

但是现实中确实有这种需求，他们既想复用代码，又不希望发生RPC，这种情况怎么办呢？

办法是有的，还是回到JAR包共享的模式，通过引入JAR包来共享代码，比如我们将公共服务打包到一个JAR中，里面包含了 service层、mapper层、mapper  xml资源，还加了很多Spring、Mybatis 注解。

你可能会问这样直接一个JAR包通过POM引过去可以正常运行吗？可以被Spring扫描到吗？可以融入Spring容器吗？

当然是不行的，所以这种情况更适合starter  JAR包的形式，通过starter实现自动配置，是可以正常运行的。

总结

共享实现方式 \优缺点	普通JAR包	Starter JAR包	RPC
优点	打包简单	简化了 调用方的繁琐配置，系统集成更优雅	简化了调用方的配置，面向RPC编程即可
缺点	解决不了复杂场景	打包更复杂，需要编写自动配置类	RPC通信性能损耗，独立资源部署，分布式事务
适用场景	不需要初始化，不需要Spring扫描，不需要环境变量的基础类库JAR	具有业务功能的，需要初始化的，需要配置环境变量，带注解的，需要被扫描的，比较复杂的框架或者业务模块	具有复杂业务功能，依赖三方系统（DB、Redis、MQ等），业务独立的功能模块