一套代码两种运行我给微服务框架加了「单体模式」微服务和单体吵了很多年。微服务的优势大家都清楚模块独立、可以单独扩缩容、团队边界清晰。但它有代价——要有注册中心、要处理服务发现、要面对分布式事务小团队运维起来是真累。单体的优势也明显一个进程跑起来就行本地事务随便用部署简单。但代码一大就难拆慢慢变成大泥球。所以很多项目其实处在一个尴尬的位置想做微服务又怕拆完合不回来想老老实实写单体又担心以后规模大了要重构。我的思路是同一个代码库两种模式都能跑。平时当微服务跑需要的时候一个开关切回单体业务代码一行不改。这篇文章讲讲这个框架怎么实现以及过程中踩的几个坑。核心思路接口即契约框架是 Maven 多模块每个功能域拆成两个模块xxx-api契约层。放着 Feign 接口和 DTO不写实现。xxx-service实现层。业务逻辑、Controller、启动入口。关键是这个契约接口FeignClient(nameuser-service)publicinterfaceUserClient{GetMapping(/user/{id})UserDTOgetById(PathVariable(id)Longid);}调用方只依赖 api 模块注入这个接口AutowiredprivateUserClientuserClient;微服务模式下userClient是 Feign 生成的代理走 HTTP 调远程单体模式下它直接注入本进程里的UserClientImpl变成普通方法调用。两种模式调用方的代码一个字都不用改。app.mode一个属性切换整个模式切换靠一个配置app:mode:mono# 或者 micro这个属性自动推导两件事Feign 开关用ConditionalOnProperty控制一个 Feign 配置类micro才注册 Feign 代理。Nacos 开关在 common 里写了个EnvironmentPostProcessorSpring Boot 官方扩展点读到mono就自动把spring.cloud.nacos.discovery.enabled置为 false。单体模式因此不需要装 Nacos一条java -jar就能跑。解决了哪些问题跨模块调用两种模式零改动。这是框架最重要的承诺。order 调 user微服务走 HTTP单体走本地方法代码一样。单体聚合新模块 加一行依赖。想把新模块放进单体只在app-monolith/pom.xml加一行dependency。组件扫描已经覆盖com.enty下所有包入口类的排除规则也自动把各模块的 Application 挡在外面剩下的全靠 Spring 自动装配。异常处理统一。common里一个RestControllerAdvice全局异常处理两种模式都生效。单体里所有 Controller 在同一个上下文这一个 Handler 全部接住。数据库两种模式怎么摆。微服务各自连各自的库单体合成一个库靠表名前缀order_t_xxx、user_t_xxx避免撞名。这也是为什么建表一定要带模块前缀——不然合并的时候全是冲突。踩过的坑这部分是我觉得最值得分享的。Spring MVC 不会从接口继承注解。一开始我把GetMapping只写在 Feign 接口上让 Controller 实现它。结果 404映射一个都没有。查了半天才发现 Spring MVC 不认接口方法上的映射注解必须在自己类的实现方法上再标一遍。这也是为什么接口注解只服务 FeignController 的注解要单独写。EnableFeignClients放错位置。之前把它放在微服务的入口类上。结果单体聚合时入口类被组件扫描扫到了EnableFeignClients的副作用把 Feign 代理也带进了单体跟本地实现冲突跨模块调用全变 HTTP 然后 503。修复把它挪到一个条件配置类里同时让单体扫描时排除*Application入口类。关于「嵌套 fat jar」的虚惊。一开始单体 404我怀疑是-service被打成了 fat jar、被单体嵌套后类加载不出来折腾半天加了 classifier。后来把 classifier 去掉实测发现 Spring Boot 2.7 的加载器其实能加载嵌套 boot jar 里的类——当时 404 的真正原因是注解没写对跟打包方式没关系。教训是排错别急着把锅甩给看起来可疑的机制先复现再验证。依赖去重。每个 service 都依赖 common单体把 service 都引进来common 会不会重复不会。Maven 对同坐标同版本的依赖只保留一份这是多模块聚合能成立的前提。目录结构root-pom ├── common # 公共统一返回、全局异常、模式开关 ├── user │ ├── user-api # 契约 │ └── user-service # 实现微服务 user ├── order │ ├── order-api │ └── order-service # 实现Feign 调用 user └── app-monolith # 单体聚合快速开始# 单体模式不需要 Nacosjava-jarapp-monolith/target/app-monolith-1.0.0.jar# 微服务模式先启动 Nacosjava-jaruser/user-service/target/user-service-1.0.0.jarjava-jarorder/order-service/target/order-service-1.0.0.jar局限说清楚这套东西的边界跨库事务单体模式如果保留多库跨模块写入依然需要分布式事务。想要本地事务的红利就得合并成单库。这是取舍不是银弹。切换不是零成本代码是零改动但数据、配置、运维是按模式准备的。频繁来回切数据会不一致。生产环境慎用这个框架更适合中小项目、需要快速演示、或者团队还想保留拆分可能性的场景。代码在 https://github.com/EntyCoder/Enty-framework欢迎交流。 一个 Spring 配置，在微服务和单体之间自由切换
一套代码两种运行我给微服务框架加了「单体模式」微服务和单体吵了很多年。微服务的优势大家都清楚模块独立、可以单独扩缩容、团队边界清晰。但它有代价——要有注册中心、要处理服务发现、要面对分布式事务小团队运维起来是真累。单体的优势也明显一个进程跑起来就行本地事务随便用部署简单。但代码一大就难拆慢慢变成大泥球。所以很多项目其实处在一个尴尬的位置想做微服务又怕拆完合不回来想老老实实写单体又担心以后规模大了要重构。我的思路是同一个代码库两种模式都能跑。平时当微服务跑需要的时候一个开关切回单体业务代码一行不改。这篇文章讲讲这个框架怎么实现以及过程中踩的几个坑。核心思路接口即契约框架是 Maven 多模块每个功能域拆成两个模块xxx-api契约层。放着 Feign 接口和 DTO不写实现。xxx-service实现层。业务逻辑、Controller、启动入口。关键是这个契约接口FeignClient(nameuser-service)publicinterfaceUserClient{GetMapping(/user/{id})UserDTOgetById(PathVariable(id)Longid);}调用方只依赖 api 模块注入这个接口AutowiredprivateUserClientuserClient;微服务模式下userClient是 Feign 生成的代理走 HTTP 调远程单体模式下它直接注入本进程里的UserClientImpl变成普通方法调用。两种模式调用方的代码一个字都不用改。app.mode一个属性切换整个模式切换靠一个配置app:mode:mono# 或者 micro这个属性自动推导两件事Feign 开关用ConditionalOnProperty控制一个 Feign 配置类micro才注册 Feign 代理。Nacos 开关在 common 里写了个EnvironmentPostProcessorSpring Boot 官方扩展点读到mono就自动把spring.cloud.nacos.discovery.enabled置为 false。单体模式因此不需要装 Nacos一条java -jar就能跑。解决了哪些问题跨模块调用两种模式零改动。这是框架最重要的承诺。order 调 user微服务走 HTTP单体走本地方法代码一样。单体聚合新模块 加一行依赖。想把新模块放进单体只在app-monolith/pom.xml加一行dependency。组件扫描已经覆盖com.enty下所有包入口类的排除规则也自动把各模块的 Application 挡在外面剩下的全靠 Spring 自动装配。异常处理统一。common里一个RestControllerAdvice全局异常处理两种模式都生效。单体里所有 Controller 在同一个上下文这一个 Handler 全部接住。数据库两种模式怎么摆。微服务各自连各自的库单体合成一个库靠表名前缀order_t_xxx、user_t_xxx避免撞名。这也是为什么建表一定要带模块前缀——不然合并的时候全是冲突。踩过的坑这部分是我觉得最值得分享的。Spring MVC 不会从接口继承注解。一开始我把GetMapping只写在 Feign 接口上让 Controller 实现它。结果 404映射一个都没有。查了半天才发现 Spring MVC 不认接口方法上的映射注解必须在自己类的实现方法上再标一遍。这也是为什么接口注解只服务 FeignController 的注解要单独写。EnableFeignClients放错位置。之前把它放在微服务的入口类上。结果单体聚合时入口类被组件扫描扫到了EnableFeignClients的副作用把 Feign 代理也带进了单体跟本地实现冲突跨模块调用全变 HTTP 然后 503。修复把它挪到一个条件配置类里同时让单体扫描时排除*Application入口类。关于「嵌套 fat jar」的虚惊。一开始单体 404我怀疑是-service被打成了 fat jar、被单体嵌套后类加载不出来折腾半天加了 classifier。后来把 classifier 去掉实测发现 Spring Boot 2.7 的加载器其实能加载嵌套 boot jar 里的类——当时 404 的真正原因是注解没写对跟打包方式没关系。教训是排错别急着把锅甩给看起来可疑的机制先复现再验证。依赖去重。每个 service 都依赖 common单体把 service 都引进来common 会不会重复不会。Maven 对同坐标同版本的依赖只保留一份这是多模块聚合能成立的前提。目录结构root-pom ├── common # 公共统一返回、全局异常、模式开关 ├── user │ ├── user-api # 契约 │ └── user-service # 实现微服务 user ├── order │ ├── order-api │ └── order-service # 实现Feign 调用 user └── app-monolith # 单体聚合快速开始# 单体模式不需要 Nacosjava-jarapp-monolith/target/app-monolith-1.0.0.jar# 微服务模式先启动 Nacosjava-jaruser/user-service/target/user-service-1.0.0.jarjava-jarorder/order-service/target/order-service-1.0.0.jar局限说清楚这套东西的边界跨库事务单体模式如果保留多库跨模块写入依然需要分布式事务。想要本地事务的红利就得合并成单库。这是取舍不是银弹。切换不是零成本代码是零改动但数据、配置、运维是按模式准备的。频繁来回切数据会不一致。生产环境慎用这个框架更适合中小项目、需要快速演示、或者团队还想保留拆分可能性的场景。代码在 https://github.com/EntyCoder/Enty-framework欢迎交流。