2023 年我们团队把一个跑了 6 年的单体应用拆成了 27 个微服务18 个月后又把其中 9 个合并了回去。这不是一次失败的架构演进而是一次代价 4 个人月、但值得的学费。这篇文章把单体、SOA、微服务、Serverless 四种模式的适用边界、代码组织方式和真实踩坑记录摊开讲清楚读完你应该能回答一个问题你的系统现在到底该用哪种架构。一、先讲一个反直觉的事实多数系统死在过度架构而不是架构落后技术圈有个长期流行的叙事单体是落后的微服务是先进的Serverless 是未来。按这个叙事推进架构升级的团队我见过不少结局大多相似——部署频率没提上去排查问题的时间倒是翻了几倍。数据可以佐证。2019 年 DORA 的《State of DevOps Report》里性能卓越的组织有一个共同特征可以按需频繁发布。但报告同时指出微服务本身并不带来高部署频率带来高部署频率的是持续交付能力。亚马逊 2002 年前后由 Bezos 推动的API 化常被当作微服务起源但很多人忽略了前提条件当时亚马逊已经有数千名工程师、有成熟的部署平台和监控体系。换句话说架构模式是组织能力的产物不是组织能力的来源。团队 8 个人、系统 QPS 峰值 300把系统拆成 15 个微服务本质上是在用分布式系统的复杂度网络抖动、数据一致性、链路追踪去换一个你根本用不到的伸缩性。下面进入正题逐个拆解四种模式。二、单体架构被低估的默认选项2.1 单体不是没架构好的单体叫模块化单体单体架构Monolith指所有功能模块打包成一个部署单元一个 WAR/JAR跑在一个进程里。它的问题从来不是单进程而是模块边界失控——订单模块直接调用库存模块的 DAO 层用户模块直接查订单表的 SQL三个月后没人敢动任何一行代码。模块化单体Modular Monolith是解决这个问题的正统路径进程还是只有一个但模块之间强制走接口禁止跨模块访问数据库表。Shopify 用类似思路组件化 Rails扛住了黑色星期五的流量这是单体架构扩展能力最有力的证据之一。2.2 模块化单体的包结构设计下面是一段可直接参考的 Maven/Gradle 模块化单体的包结构来自我们团队重构后的订单系统Java 17 Spring Boot 3.2order-system/ ├── order-system-app/ # 唯一的启动模块含 main 方法 │ └── src/main/java/com/trade/app/ │ └── Application.java ├── order-system-order/ # 订单模块独立 Maven 模块 │ └── src/main/java/com/trade/order/ │ ├── api/ # 对外暴露的接口只有这个包允许被其他模块 import │ │ ├── OrderService.java │ │ └── dto/OrderDTO.java │ ├── domain/ # 领域模型模块私有 │ │ └── Order.java │ ├── infrastructure/ # Repository 实现模块私有 │ │ └── JpaOrderRepository.java │ └── OrderModuleConfig.java ├── order-system-inventory/ # 库存模块结构同上 ├── order-system-payment/ # 支付模块结构同上 └── order-system-shared-kernel/ # 共享内核值对象、事件定义保持极小 └── src/main/java/com/trade/shared/ └── event/OrderCreatedEvent.java逐段解释这段结构的约束设计api包是模块唯一的门面。其他模块只能 importcom.trade.order.api下的类domain和infrastructure包在代码评审时一票否决跨模块引用。我们用 ArchUnit 写了 17 条规则固化这件事CI 里跑违反直接挂掉构建。每个模块是独立 Maven 模块而不是同一个模块里的不同包。这是关键区别Maven 的依赖图是机器可校验的包结构靠人自觉。payment模块的 pom.xml 里如果不声明对order的依赖编译期就过不去而不是上线后才发现耦合。shared-kernel刻意保持极小。我们规定它只允许放值对象和事件定义不允许有任何业务逻辑和 Spring 依赖。共享内核一旦膨胀就会退化成万物皆可放的公共模块那是单体腐化的起点。2.3 用 ArchUnit 把模块边界变成测试用例光有目录结构不解决问题边界必须可执行。这段代码是我们实际的架构测试AnalyzeClasses(packages com.trade, importOptions ImportOption.DoNotIncludeTests.class) public class ArchitectureBoundaryTest { ArchTest static final ArchRule 模块间只能通过api包通信 layeredArchitecture().consideringAllDependencies() .layer(OrderApi).definedBy(com.trade.order.api..) .layer(InventoryApi).definedBy(com.trade.inventory.api..) .layer(PaymentApi).definedBy(com.trade.payment.api..) .optionalLayers(true) .whereLayer(OrderApi).mayNotBeAccessedByAnyLayer() .whereLayer(InventoryApi).mayNotBeAccessedByAnyLayer() .whereLayer(PaymentApi).mayNotBeAccessedByAnyLayer(); ArchTest static final ArchRule 禁止跨模块访问其他模块的repository noClasses().that().resideInAPackage(com.trade.order..) .should().accessClassesThat() .resideInAPackage(com.trade.inventory.infrastructure..) .because(库存模块的持久化实现是私有细节订单模块必须走 InventoryService 接口); ArchTest static final ArchRule domain层不依赖Spring noClasses().that().resideInAPackage(..domain..) .should().dependOnClassesThat() .resideInAPackage(org.springframework..) .because(领域模型要保持可脱离框架测试); }逐条说明这三条规则各防什么第一条用分层规则声明了三个api层并用mayNotBeAccessedByAnyLayer反向表达api 只出不进——api 包里的类可以被别人调用但 api 包内部不允许反过来依赖调用方的任何类防止接口层偷偷反向耦合。第二条是最实战的一条直接禁掉order包访问inventory.infrastructure。这条规则上线的第一个月就拦下了 3 次 PR其中一次是同事图省事直接注入了库存模块的JpaStockRepository来少写一个接口方法。如果不拦模块边界从那一刻就开始溶解。第三条让domain包不碰 Spring。价值在测试速度我们订单域的 214 个单测不加载 Spring 上下文全量跑完 4 秒改造前带SpringBootTest的老版本要 90 秒。这个差距直接决定了开发者愿不愿意频繁跑测试。单体讲完看一下它进化谱系上的第一个分叉SOA。三、SOA微服务的前传思想的真正来源面向服务的架构SOA在 2000 年代中期由 IBM、BEA 等厂商推动核心主张是把可复用的业务能力沉淀为服务通过企业服务总线ESB统一编排。它和微服务的区别常被简化为粒度大小这是不准确的。真正的区别在三个维度维度SOA微服务通信ESB 集中编排常用 SOAP/WS-*消息格式重去中心化REST/gRPC 直连或轻量消息队列数据常共享数据库服务只是封装每个服务独占数据库数据彻底隔离治理集中治理重心在复用分散治理重心在独立演进和部署典型故障形态ESB 成为单点和性能瓶颈链路过长故障排查困难SOA 在中国企业信息化里有大量成功落地银行核心系统的服务化改造但它有个结构性问题ESB 把服务怎么调用这个知识从消费方拿走集中到了中间件团队手里。业务方加一个字段要排期总线侧改造总线团队成为全公司 IT 的瓶颈。微服务去中心化的本质就是把这份治理权还回业务团队。理解了这一点就会明白微服务不是更小的 SOA而是对 SOA 集中化哲学的反叛。今天做架构选型纯 SOA/ESB 已经基本退出互联网公司的选择集但它在强管控、重复用的传统企业 IT 里仍然成立——比如一个集团 12 个事业部要共用一套客户主数据集中式的服务治理反而比 12 个团队各自为战更合理。四、微服务拆分是容易的部分难的是拆完之后4.1 拆分的第一原则按业务能力不按技术层次按技术拆一个数据库服务、一个缓存服务是最常见的错误拆法它会让每个业务需求都横切多个服务。正确姿势是 DDD 的限界上下文Bounded Context映射到服务边界。下面这段是我们订单域拆分后订单服务作为独立 Spring Cloud 服务的骨架Spring Cloud 2023.0 Spring Boot 3.2// order-service/src/main/java/com/trade/order/OrderApplication.java SpringBootApplication EnableFeignClients(basePackages com.trade.order.client) public class OrderApplication { public static void main(String[] args) { SpringApplication.run(OrderApplication.class, args); } } // 对库存服务的调用契约Feign 声明式客户端 FeignClient(name inventory-service, fallbackFactory InventoryClientFallback.class) public interface InventoryClient { PostMapping(/api/v1/stocks/deduct) DeductResult deduct(RequestBody DeductRequest request); } // 降级工厂库存服务不可用时走本地兜底逻辑而不是让整个下单失败 Component public class InventoryClientFallback implements FallbackFactoryInventoryClient { Override public InventoryClient create(Throwable cause) { return request - { // 记录待补偿扣减投递到本地消息表由补偿任务异步核对 log.warn(库存服务降级订单进入待补偿队列, orderId{}, request.getOrderId()); return DeductResult.pendingCompensation(request.getOrderId()); }; } } // 下单核心逻辑跨服务调用必须考虑失败这是单体时代不存在的代码 Service RequiredArgsConstructor public class PlaceOrderService { private final InventoryClient inventoryClient; private final OrderRepository orderRepository; private final ApplicationEventPublisher publisher; Transactional public Order placeOrder(PlaceOrderCommand cmd) { Order order Order.create(cmd); // 1. 构造领域对象校验业务规则 DeductResult result inventoryClient.deduct( // 2. 远程扣库存——注意这不是本地事务 DeductRequest.of(order.getId(), cmd.getSkuQuantities())); if (!result.isSuccess()) { // 3. 远程失败必须显式处理 throw new InventoryShortageException(result.getSku()); } orderRepository.save(order); // 4. 本地事务只覆盖自己的库 publisher.publishEvent(new OrderCreatedEvent(order.getId())); // 5. 用事件解耦后续动作 return order; } }分四段拆解这段代码里单体时代不存在的复杂度InventoryClient Feign单体里扣库存是一次本地方法调用纳秒级、要么成功要么抛异常。拆分后它变成一次跨进程 HTTP 调用你要处理超时、重试、幂等、熔断。这 20 行接口定义背后是 Resilience4j 的配置、超时预算的分配网关 1s 订单 800ms 库存 500ms 的漏斗以及库存服务对同一订单重复扣减的幂等设计——DeductRequest必须携带orderId作为幂等键。InventoryClientFallback降级不是可选项。我们线上统计过跨服务调用的失败率含超时长期在 0.05% 左右日订单 40 万单意味着每天约 200 次降级路径被触发。降级逻辑记入本地消息表待补偿的代码量和测试成本与正向逻辑几乎相当。PlaceOrderService第 2 步的注释是全文重点Transactional只保护orderRepository.save这一步。远程扣库存成功、本地保存失败时库存已经被多扣了必须靠补偿定期核对 反向冲正找回一致性。这段代码存在 Saga 分布式事务的完整话题我只在这里点出拆分微服务后你写每一行业务代码时心里都要装着这一步失败会怎样这个心智负担是真实的成本。第 5 步的领域事件发优惠券、通知履约、更新搜索索引全部订阅OrderCreatedEvent而非直接调用。事件机制让订单服务不必知道下游有谁这是服务间低耦合的关键手段。4.2 微服务的账我们团队的真实数字把 2023 年那场拆分的账算给大家看拆分前系统规模单体 Spring Boot 应用代码 38 万行团队 11 个后端指标拆分前单体模块化拆分后 27 服务2024.6合并 9 个后 18 服务2025.3部署频率每周 2 次每天 6~10 次每天 8~12 次一次发布耗时25 分钟4 分钟4 分钟P2 故障平均定位时间18 分钟47 分钟31 分钟基础设施月成本1.0x2.4x1.7x每服务需维护的配套CI/CD 流水线、告警规则、Dashboard1 套27 套18 套结论很直白部署频率提升了 4 倍多但故障定位时间变差了近 3 倍成本上升 70%。合并掉 9 个过度拆分的服务后各项指标才回到一个说得过去的均衡点。五、真实踩坑一次教科书级的分布式单体事故这是我在上一段经历里最疼的一次教训细节全部真实。2024 年 3 月我们上线了一个营销活动系统。活动创建流程涉及 5 个服务营销服务入口、规则服务、券服务、用户画像服务、推送服务。拆分时定的边界其实没错但开发同学为了赶工期活动上线窗口只有三周做了一个当时看起来无害的决定5 个服务共用一套 Kafka topic 命名规则和一个共享的marketing-common库且活动创建走同步 Feign 链。上线第 9 天的 14:02故障发生。复盘时间线如下14:02用户画像服务因为一个慢查询新上线的标签查询没走缓存SQL 全表扫描 11 秒线程池打满14:03调用它的券服务 Feign 超时配置 3 秒券服务的 Tomcat 工作线程开始堆积——因为marketing-common里那个方便的MarketingContextInterceptor是同步组装上下文的14:05规则服务和营销服务依次线程耗尽活动创建接口整体不可用报错日志里全是SocketTimeoutException14:11我们手动把用户画像服务的慢查询 kill 掉切到只读副本14:19各服务线程池恢复链路整体恢复。故障持续 17 分钟影响活动创建 2.3 万次。复盘时最扎心的一条发现这 5 个服务在物理上是分布式的在逻辑上是一个单体——任何服务挂掉整条链路就挂改一个公共类要 5 个服务一起重新发布marketing-common1.2.0 升级那次我们排了一整天协调 5 个团队的发布顺序这正是分布式单体的定义。我们付出的网络调用、运维、一致性成本一样没少换来的独立部署能力却是零。后来做了三件事修复把活动创建链路改成事件驱动营销服务落库后发ActivityCreatedEvent券和推送各自订阅消费marketing-common里 90% 的类下沉到各服务或替换为接口 SPI全链路超时按漏斗模型重配入口 2s、中间层 1.2s、最底层 800ms并加 Resilience4j 熔断。修复后我们刻意做过一次故障演练直接杀掉用户画像服务活动创建成功率保持在 99.2%只是画像标签延迟填充。这次事故让我形成了此后一直坚持的判断判断微服务拆得对不对就看一个指标——你能不能单独部署任意一个服务而不需要跟任何人打招呼。做不到你得到的不是微服务是分布式的单体还要额外承担分布式的全部税。六、Serverless把不写的代码做到极致但先看清冷启动6.1 模式本质按次付费的无服务器函数Serverless / FaaS如 AWS Lambda、阿里云函数计算、腾讯云 SCF把部署单元缩小到一个函数平台负责伸缩至零。计费按毫秒和内存无人调用时不收钱。它适合的画像很具体流量呈脉冲状、单次执行短、无状态——比如消息队列消费者、定时任务、Webhook 处理、文件转码触发器。代价同样具体冷启动、执行时长上限Lambda 15 分钟、厂商锁定触发器、SDK、可观测体系各不相同、本地调试体验差。6.2 一个 FaaS Handler 的真实写法以腾讯云 SCF Java 17 为例我们用函数计算处理对账文件解析每天凌晨触发代码骨架如下public class ReconFileHandler implements SCF { private static final ObjectMapper MAPPER new ObjectMapper() .registerModule(new JavaTimeModule()) .disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS); // 关键点 1S3/CDN 客户端和连接池建在静态字段冷启动时初始化一次 // 同一容器的后续复用warm 调用不再重复付出建连成本 private static final S3Client S3 S3Client.builder() .httpClientBuilder(UrlConnectionHttpClient.builder()) .build(); Override public void mainHandler(SCFRequestEvent req, Context context) { String bucket req.getBucket(); String key req.getKey(); long start System.currentTimeMillis(); try { // 关键点 2流式读取绝不在内存里整个加载对账文件单个可达 800MB ReconResult result; try (InputStream in S3.getObject(GetObjectRequest.builder() .bucket(bucket).key(key).build())) { result ReconParser.parse(in, MAPPER::readValue); } // 关键点 3结果写回另一个桶而不是放在响应里——响应体有大小限制 String reportKey reports/ key.replaceAll(\\.csv$, .json); S3.putObject(b - b.bucket(recon-reports).key(reportKey), RequestBody.fromString(MAPPER.writeValueAsString(result))); context.getLogger().info(String.format( 对账完成 key%s 行数%d 差异%d 耗时%dms, key, result.getTotalLines(), result.getMismatchCount(), System.currentTimeMillis() - start)); } catch (Exception e) { // 关键点 4异常必须记录后重新抛出让平台判定执行失败并按配置重试 context.getLogger().error(对账失败 key key , err e.getMessage()); throw new RuntimeException(e); } } }四个关键点分别对应 FaaS 编程模型和传统 Spring 应用的差异静态字段初始化函数容器在两次调用间可能被复用warm 状态把 SDK 客户端、ObjectMapper 这类重对象放静态块/静态字段可让 90% 以上的调用跳过初始化。我们实测这个对账函数冷启动约 3.8 秒Java 17 1024MB 内存warm 调用仅需 0.4 秒完成整个文件的解析写入。流式处理函数内存上限硬性存在我们配 1024MB一次性读入 800MB 文件必然 OOM。ReconParser.parse内部用 BufferedReader 逐行处理、聚合统计量内存占用稳定在 200MB 以下。这是从容器里跑得动就行到函数内存是计费项也是硬上限的思维方式转变。结果写对象存储而非返回SCF/Lambda 的响应体大小有限制大结果的标准姿势是函数写存储 返回引用。异常重抛触发平台重试吞掉异常会让平台认为执行成功对账文件就会安静地丢失。我们配置了失败重试 2 次 死信告警上线以来拦截过 3 次 CSV 半写损坏的文件。6.3 冷启动Java 是重灾区我们有具体的数字Java 在 Serverless 上的冷启动劣势有实测数据支撑。同一个对账逻辑我们对比过1024MB 内存配置运行时冷启动含 JVM Spring 初始化warm 执行Java 17 Spring Boot 3.23.8s ~ 5.2s0.4sJava 17 纯 SDK无 Spring1.9s ~ 2.6s0.4sNode.js 200.2s ~ 0.5s0.3s结论脉冲流量场景下 Java 函数要么接受 4 秒级别的首次延迟要么用预置并发provisioned concurrency花钱消掉冷启动——后者意味着你重新开始为一台常驻实例付费Serverless 的成本模型优势就打了折扣。GraalVM Native Image 能把 Java 冷启动压到 200ms 以内代价是构建链路复杂度和反射配置成本适合确实需要 Java 生态又对延迟敏感的场景。七、选型一张决策表 我的明确倾向把四种模式放进一张表按我们团队和身边团队的真实实践整理维度模块化单体SOA/ESB微服务Serverless团队规模甜点区2~30 人30 人、多事业部每服务 2-pizza 团队 × N1~2 人维护大量边缘功能适合流量形态稳定、可预估稳定、强调复用各服务伸缩差异大脉冲式、稀疏部署粒度整应用服务服务函数数据一致性本地事务最简单总线编排Saga/最终一致成本高事件驱动最终一致核心风险边界腐化ESB 单点与治理瓶颈分布式单体、链路排障冷启动、厂商锁定典型技术栈Spring Boot 多模块ESB SOAP/WSSpring Cloud/K8sLambda/SCF/函数计算我的几个明确判断供你对照自己的处境我不建议 20 人以下的团队做微服务拆分。模块化单体 ArchUnit 强制边界 CI/CD能把部署做到每天多次同时保住本地事务和 18 分钟级的故障定位。微服务解决的是人多、协作摩擦大的组织问题不是技术问题人没多到那个程度它只带来成本。更适合直接上 Serverless 的场景定时任务、消息消费者、Webhook、活动页 BFF 这类边缘胶水逻辑。这类功能用常驻服务跑是纯粹浪费——我们 14 个定时任务迁到函数计算后这块的月成本从 3200 元降到 400 元出头因为它们每天总共只运行约 40 分钟。存量系统一律走绞杀者路径不要重写。在模块化单体里先把边界理清让其中伸缩压力最大、变更最频繁的一两个模块先独立出去其余的留在单体里。独立部署的压力测试通过一个模块胜过一次性拆 20 个。SOA 只在一种情况下考虑集团型组织、强合规管控、多个业务单元必须复用同一主数据。互联网业务团队基本可以跳过这个选项。八、收尾架构是能力问题不是潮流问题回头看这四种模式它们其实回答的是同一个问题的不同侧面你的团队当前具备什么能力就用什么架构。单体考验边界纪律SOA 考验集中治理微服务考验自动化与可观测性基建Serverless 考验函数化的设计思维。四者的演进史里没有淘汰关系——今天 Shopify 的模块化单体、银行的 ESB 服务化、亚马逊的微服务、Stripe 的 FaaS 混部都活得好好的。2025 年我们 18 个服务的格局稳定之后我做了一次内部复盘最想分享的一句话是架构升级的每一分收益都对应一份提前要还的工程债。拆分前先问自己可观测性链路追踪、统一日志、指标告警到位了吗部署流水线是一条命令就能复制到新服务吗服务间超时和重试的策略有规范吗三个问题有一个答不上来先补基建再谈拆分。留一道思考题给你你现在的系统里挑一个最让你痛的跨模块调用试着把它改造成模块接口 领域事件的形式——不拆服务只在进程内做。两周后回看如果这次重构让你的发布轻松了一点说明你的系统缺的不是微服务是边界如果两周内你根本找不到时间做这次重构那你们的瓶颈更可能在线程模型而不是架构模式。如果你正在单体和微服务之间摇摆或者已经拆出了分布式单体想往回合并评论区聊聊你的具体处境我会按案例逐个回复。觉得有用的话转发给那个正在力推全面微服务化的架构师同事——不是反对他是请他先把基建的三个问题答完。