已经用微服务了还用引入模块化开发？

POM模块化引入和RPC调用解决的是两个完全不同维度的问题。它们不是“二选一”的替代关系而是“分层协作”的互补关系。你之所以会有这个疑问可能是因为把“代码的组织方式模块化”和“进程间的通信方式RPC”搞混了。让我们把这个问题拆开来看1. POM模块化解决的是“代码复用”和“编译期依赖”在微服务架构中即使每个服务都是独立部署的进程它们之间依然存在大量需要共享的代码。如果不使用POM模块化即Maven多模块你通常会面临以下问题接口定义契约重复服务A要调用服务B服务B的接口签名DTO类、枚举如果只在B项目里写一遍服务A就需要硬编码字符串去调用或者复制粘贴一份代码。这会导致每维护一份副本就多一分腐化的风险。实体类与工具类通用的异常类、BaseEntity、工具类如StringUtils、RedisUtil、常量池。如果没有模块化每个服务都要自己写一份或者通过拷贝代码来共享维护成本极高。POM模块化的做法通常是将项目拆分为xxx-api模块存放接口声明Java Interface、DTO数据传输对象、枚举、Feign Client接口如果你用Spring Cloud。xxx-service模块存放业务逻辑、数据库操作等。xxx-common模块存放公共工具类。作用服务A通过POM引入服务B的api模块仅仅是为了引入那些定义好的DTO类和Feign接口而不是为了引入服务B的业务逻辑实现。2. RPC调用解决的是“运行时”的“网络通信”RPC如Dubbo、gRPC或者Spring Cloud中的Feign/OpenFeign解决的是进程间通信IPC的问题。微服务虽然拆开了但它们需要互相说话。RPC框架的作用是屏蔽网络编程的复杂性让你感觉像是在调用本地方法一样去调用另一个服务器上的方法。3. 为什么两者必须结合使用如果你“不用POM模块化引入”而想直接使用RPC调用你会遇到以下几种极其痛苦的场景场景一接口定义漂移服务A要调用服务B。如果不引入服务B的api模块开发者通常会在服务A里硬编码服务B的接口路径和参数类型。例如String url userId;后果当服务B的接口路径从/user/detail改成/user/info或者参数名改了服务A编译期不会报错只有在运行时才会报错404或反序列化失败。在微服务规模扩大后这种“硬编码”和“拷贝DTO”会让架构变得极其脆弱。场景二重复定义与不一致如果每个调用方都自己定义一份被调用方的DTO服务B修改了UserDTO增加了字段age删除了字段name。服务A自己拷贝的那份旧UserDTO没有变。调用时RPC框架进行反序列化会出现字段丢失、类型转换错误甚至因为Serizlization ID不匹配直接报错。场景三Feign/Dubbo Interface 无法共享在Spring Cloud Alibaba或原生Spring Cloud生态中Feign Client 或 Dubbo 的接口定义通常就是一个普通的Java接口。正确的做法把这个接口写在xxx-api模块里。服务B实现它服务A引入它并调用。没有模块化的做法服务A如果要调用服务B需要重新写一遍Feign Client的定义或者通过配置类动态拼URL。这样一旦接口签名变化所有调用方都得手动修改容易遗漏。4. 你的困惑可能来自于“过度依赖”你可能看到有些项目里一个服务引入了另一个服务的api模块导致引入了很多不必要的传递依赖甚至造成了耦合过重——修改一个接口所有依赖方都需要重新打包部署。但这不是模块化本身的错而是模块拆分粒度的问题。正确的微服务模块化实践应该是轻量级API包xxx-api模块应该只包含接口定义和DTO绝对不能包含业务逻辑、数据库驱动、具体的实现类。版本管理API模块应该独立版本号。当接口变更不兼容时升级大版本兼容性修改时升级小版本。调用方可以选择是否升级版本。解耦服务A引入服务B的api模块仅代表“我知道怎么和你说话”不代表“我必须和你绑定在一起”。总结不用POM模块化引入只用RPC调用本质上是在进行原始的手工HTTP调用拼接URL、手动封装JSON、手动处理异常。POM模块化解决的是编译期的类型安全、契约统一和代码复用。它确保在写代码时如果接口参数写错了IDE会直接报红线。RPC解决的是运行期的网络传输、负载均衡和服务发现。在成熟的微服务项目中两者是黄金搭档用POM模块化api包来定义契约用RPC框架来实现契约的远程执行。缺少了模块化引入你的微服务就会退回到“通过文档手动同步接口”的原始状态那正是微服务诞生之前SOA架构乃至更早时期开发人员所面临的痛点。