从微服务到 Serverless：Koupleless 模块化架构让老系统也能渐进式演进

Mon, 29 Jun 2026 14:00:00 +0800

一、“推倒重来"的代价

当一个运行了三五年的单体应用越来越臃肿，团队的第一反应往往是：拆微服务。

这个决策在 PPT 上永远正确——独立部署、独立演进、技术异构、弹性伸缩。但真正落地时，“大爆炸式"的拆分迁移几乎都会撞上同一面墙：

依赖地狱：单体内部的方法调用盘根错节，一个订单模块可能直接引用了库存、用户、风控等七八个子包的内部类。要把它们拆成独立服务，首先要解决的不是业务逻辑，而是几千个编译错误的依赖解耦。
数据一致性断层：原来同一个数据库事务能保证的 ACID，拆成跨服务调用后变成最终一致性，需要引入 Saga、TCC 或消息队列，改造成本远超预期。
运维复杂度陡增：从 1 个 JAR 包变成 30 个容器，CI/CD 流水线、服务发现、配置中心、链路追踪、分布式日志——每一项都是新的基础设施投入。
团队阵痛：开发习惯被强制改变，联调从 IDE 内断点调试变成了跨环境远程调用，排障从看一个日志文件变成了串起十几条 Trace。

更致命的是，很多系统在拆分之后发现，业务量根本撑不起这么多微服务。三五个人的团队维护着三十个服务，每个服务的流量连一台最小规格的容器都填不满，资源浪费和运维负担远超拆分带来的收益。

问题出在哪里？不是微服务本身不好，而是**“要么全拆，要么不拆"的二元思维**过于粗暴。架构演进应该有中间态。

二、Koupleless 是什么

Koupleless（原名 Koorun）是一套模块化架构框架，源自蚂蚁集团内部的 SOFAArk 技术体系，2023 年正式开源并捐赠给社区。它的核心理念用一句话概括：

在同一个 JVM 进程内，让多个业务模块共享一个基座应用运行，模块之间类隔离、可独立部署，同时保持极低的技术栈侵入性。

拆开来看，Koupleless 的架构分两层：

基座（Base App）

基座是一个标准的 Spring Boot 应用（也支持其他 Java 框架），负责提供：

公共基础设施：数据库连接池、缓存客户端、消息队列 Producer、RPC 框架、日志配置
通用业务 SDK：用户鉴权、权限校验、风控规则引擎
模块生命周期管理：安装、卸载、热更新

模块（Biz Module）

每个业务模块是一个独立的 JAR/WAR 包，打包为 Koupleless 定义的 Biz Bundle 格式。模块有自己的 Spring 上下文，可以使用 @Controller、@Service 等注解，但不启动独立的 JVM 进程。

关键技术实现依赖 SOFAArk 的类加载隔离机制：每个模块拥有独立的 ClassLoader，模块之间的类默认不可见，只有显式声明的接口才会通过基座进行跨模块通信。这从根本上解决了传统 OSGi 或 Fat JAR 方案中类冲突的顽疾。

三、共享基座的工程优势

模块运行在共享基座之上，带来三个直接的工程收益：

启动速度极快

传统 Spring Boot 微服务启动时需要初始化整个 Spring 上下文、加载所有 Bean、建立数据库连接。一个中等规模的服务冷启动通常需要 30~~90 秒。而 Koupleless 模块只需要初始化自身特有的 Bean，基座中已有的连接池、中间件客户端直接复用，**模块安装通常在 3~~10 秒内完成**。

这意味着：

开发阶段热部署几乎无感
模块的滚动更新对请求零影响
在弹性伸缩场景下，新模块可以秒级上线承接流量

资源利用率高

30 个微服务 = 30 个 JVM 进程 = 30 份 Metaspace、30 份线程池、30 份连接池。在 Koupleless 架构下，它们可以共享同一个 JVM，内存和 CPU 的利用率大幅提升。对于中小型业务系统，这意味着用原来 1/3 的机器资源跑完同样的业务量。

对存量代码侵入极低

基座本身就是一个标准的 Spring Boot 项目。迁移的第一步不是拆分，而是把现有单体应用直接作为基座，然后逐步将需要独立演进的业务模块抽离为 Biz Bundle。这个过程不需要重写代码，不需要引入新的 RPC 框架，模块间的调用仍然是本地方法调用。

四、三阶段演进路径

Koupleless 最大的架构价值不在于它本身有多"先进”，而在于它填补了单体和微服务之间的空白地带，让演进路径变成三个阶段而非一步到位：

第一阶段：单体应用（现状）

所有业务逻辑打包在一个部署单元中，通过 Maven 多模块组织代码，但运行时是一个整体。这是大多数中小团队的现状，没什么不好——在业务复杂度可控的前提下，单体是最简单的架构。

第二阶段：模块化单体（Modular Monolith）

引入 Koupleless 基座，将需要独立演进的领域（如营销、支付、报表）抽离为独立模块。此时：

代码层面：模块有独立的 Git 仓库、独立的 CI 流水线，团队可以独立开发
运行时：所有模块共享同一个 JVM，模块间调用仍是本地方法调用，无需网络开销
部署层面：模块可以单独发布和热更新，不需要整体重启

这个阶段的价值在于解耦了开发节奏而不引入运维复杂度。三个团队可以在同一个系统里各自迭代自己的模块，发布互不影响，但运维只需要管理一个应用。

第三阶段：微服务 / Serverless

当某个模块的业务量增长到需要独立扩缩容，或者需要跨语言、跨团队完全独立治理时，再将其从模块升级为独立微服务。由于模块已经具备了清晰的边界和独立的代码仓库，这个升级是水到渠成的重构而非"推倒重来”。

更进一步的演进方向是 Serverless：将模块打包为函数粒度的计算单元，交给 FaaS 平台按需调度。Koupleless 的秒级启动特性天然适配这个方向——一个模块从代码到可服务状态的转换足够快，就可以被视为一个"函数”。

1
2


单体应用 ──→ 模块化单体 ──→ 微服务/Serverless
 (现状) (Koupleless) (按需升级)

五、实战迁移示例

以一个电商平台的订单系统为例，演示如何从单体逐步迁移到模块化架构。

步骤 1：将现有应用改造为基座

原始单体应用是一个标准的 Spring Boot 项目，包含订单、库存、促销、物流四个业务域。第一步是将其声明为 Koupleless 基座：

1
2
3
4
5


<!-- pom.xml 中引入 Koupleless 基座依赖 -->
<dependency>
 <groupId>com.alipay.sofa.koupleless</groupId>
 <artifactId>koupleless-base-starter</artifactId>
</dependency>

原有代码不需要做任何修改，应用照常启动运行。

步骤 2：抽离第一个模块——促销引擎

促销逻辑变化最频繁（每周都有新活动），是最适合优先独立演进的模块。将 promotion 相关的代码迁移到一个独立的 Maven 项目中，打包为 Biz Bundle：

1
2
3
4
5


<!-- 促销模块 pom.xml -->
<dependency>
 <groupId>com.alipay.sofa.koupleless</groupId>
 <artifactId>koupleless-module-starter</artifactId>
</dependency>

模块中声明的 @RestController 会自动注册到基座的 DispatcherServlet 中，模块中的 @Service 可以调用基座提供的公共能力（如数据库访问、缓存、消息发送），也可以被其他模块通过基座暴露的接口调用。

步骤 3：模块独立部署与热更新

促销模块有自己的 Git 仓库和 CI 流水线。当需要发布新版本时，只需将 Biz Bundle 上传到基座的模块管理接口：

1
2


curl -X POST http://base-app:8080/api/module/install \
 -F "file=@promotion-bundle-2.1.0.jar"

基座在 5 秒内完成旧模块卸载和新模块安装，全程无停机。

步骤 4：按需升级为微服务

当促销模块的流量增长到需要独立扩缩容时（例如大促期间），将其从模块升级为独立微服务。由于模块已经具备独立的代码仓库、清晰的 API 边界和独立的测试用例，这个升级主要是将模块间调用从本地方法改为 RPC，工作量可控。

六、对比：传统微服务 vs Koupleless 模块化

对比维度	传统微服务拆分	Koupleless 模块化
迁移策略	大爆炸式或分批拆服务	渐进式，先模块化再按需升级
运行时模型	每个服务独立 JVM/容器	多模块共享基座 JVM
模块间通信	HTTP/gRPC 远程调用	本地方法调用（同 JVM）
启动速度	30~90 秒/服务	模块 3~10 秒，基座一次性启动
资源消耗	N 个服务 = N 份 JVM 开销	共享基座，内存和线程池复用
运维复杂度	高（服务发现、网关、链路追踪全套）	低（模块级管理，运维单应用）
独立部署	完全独立	模块独立热更新，基座统一管理
独立扩缩容	天然支持	需升级为微服务后支持
数据一致性	需引入分布式事务方案	同库同事务，无需额外方案
适用团队规模	大团队（多 Squad）	中小团队（1~5 个业务组）
技术栈限制	异构友好（多语言）	Java 生态为主

七、什么时候用，什么时候不用

Koupleless 模块化架构不是万金油，它有明确的适用边界。

适合使用的场景

存量 Java 单体应用需要演进，但团队规模和业务量尚不足以支撑完整微服务化
业务模块变更频率差异大，部分模块（如营销、报表）需要独立发布节奏
资源预算有限，不希望为少量服务维护一整套微服务基础设施
需要秒级热更新能力，如插件化系统、多租户 SaaS 平台中租户级定制
团队正在探索 Serverless 方向，需要一个过渡性的架构形态

不适合使用的场景

需要多语言异构：Koupleless 基于 JVM 类加载隔离，模块必须是 Java/Kotlin 等 JVM 语言
已经运行良好的微服务体系：如果现有微服务运维成熟、团队习惯了分布式开发，没有必要回退到模块化单体
超大规模流量场景：当单个 JVM 进程无法承载所有模块的流量时，必须走向微服务的独立扩缩容
强隔离需求：模块共享 JVM 意味着一个模块的 OOM 或死锁可能影响基座和其他模块，对故障隔离要求极高的场景需要慎重评估

架构演进的本质是在复杂度和灵活性之间寻找当前阶段的最优解。Koupleless 的价值不是替代微服务，而是提供了一条从单体出发、经过模块化中间态、最终按需走向微服务或 Serverless 的渐进式路径。对于那些被"不拆就死"的叙事裹挟、却又不具备全面微服务化条件的团队来说，这条路径可能比推倒重来务实得多。

Koupleless on 文艺技术笔记