微服务是被逼出来的：Uber架构演进与单体拆分实践

先问一个问题：你所在团队的微服务架构，是架构师在会议室里设计出来的，还是被业务增长和团队规模硬生生逼出来的？

这个问题的答案，直接决定了一场微服务改造会走向成功还是陷入混乱。很多团队把微服务当成银弹，先画架构图、再拆服务、再上容器，结果半年后陷入服务间调用混乱、分布式事务失控、线上问题难排查的泥潭。而 Uber 前 CTO 在公开分享中传达过一个非常扎心的判断：Uber 的微服务不是设计出来的，是被增长逼出来的。

Uber 的工程量级和普通公司完全不同，但它的演进路径有极强的参考价值。它没有在最开始就规划一张完美的微服务架构图，而是先让业务跑起来，等单体架构的痛点真实出现后，才一步步拆分服务、补齐基础设施。这篇文章会拆解 Uber 的微服务演进逻辑，分析单体架构在什么临界点上必须拆、拆完之后又付出了哪些分布式代价，以及这些经验对普通团队到底意味着什么。

文章会以工程实践为主线，最后给出一个单体重构为微服务的最小示例，包含服务拆分、服务间调用、网关路由、幂等处理等完整代码，帮助你理解微服务改造的真实成本。

1. 为什么说微服务不是设计出来的

先下判断：微服务架构是组织规模、业务复杂度和协作效率倒逼出来的结果，不是架构师先验设计的产物。

大多数团队对微服务的认知误区是：先定技术选型，再画架构图，然后照着图把单体拆掉。这种“设计驱动”的做法，听起来很专业，但往往忽视了微服务架构的真正成因——公司的业务增长和团队结构已经变得让单体架构无法承受了。

Uber 的路径恰好相反。从公开资料和它后续开源的基础设施项目看，Uber 是先遇到了单体架构的瓶颈，再为了活下去而不断拆分、不断补充中间件和平台能力。这个顺序很重要：先有痛点，再上工具，而不是先有工具，再造痛点。

这里有一个更底层的规律，叫康威定律。它说的是：系统的架构，会最终趋同于组织的沟通结构。如果团队是一个大杂烩，大家一起维护同一个代码库，那系统就是单体；如果团队被拆成了支付组、订单组、用户组，各自对服务负责，那架构自然就会走向微服务。Uber 的微服务化，本质上不是在追随技术潮流，而是在给快速扩张的工程组织“松绑”。

所以，普通团队在决定要不要微服务之前，应该问自己的第一个问题不是“微服务好不好”，而是“我的组织现在是不是已经被一个单体代码库堵死了”。

2. Uber 单体时期的真实困境

很多资料喜欢直接讲 Uber 拥有几千个微服务的盛况，但很少聊它从单体走向微服务的过程中，到底被什么痛点击中了。从 Uber 公开的技术分享和开源项目来看，有几个困境是最核心的：

2.1 单体后端无法支撑移动端的高频聚合请求

Uber 的核心产品是移动客户端。用户打开 App 后，一个界面往往需要同时获取用户信息、车辆位置、计价规则、路线规划、营销活动等多份数据。在单体架构下，这些数据都在一个应用里，直接在内存中查询即可，响应速度还可以接受。但当业务规模上来后，单体内所有模块共用同一套数据库连接池、同一份线程池、同一块内存，任何一个模块的慢查询或异常热点，都会把整个应用拖垮。

2.2 部署和发布的耦合越来越严重

单体代码库一旦达到几十万甚至上百万行，就会出现一种很常见的现象：一个 10 人的后端团队，每次发布都要等所有模块的代码合并测试完毕才能一起上线。支付模块的改动明明只影响支付，却要拉着派单、计费、用户模块一起回归。发布窗口越来越长，线上 Bug 的修复速度也越来越慢。

2.3 故障爆炸半径太大

单体时代最常见的线上事故是：某个模块内存泄漏或死锁，直接把整个进程打挂，然后全站不可用。Uber 作为一个出行平台，调度、支付、计费等功能一旦同时不可用，影响是灾难性的。微服务拆分后的一个核心收益，就是缩小故障爆炸半径——支付服务挂了，至少用户还能看到地图和车辆。

2.4 团队协作成本几何级上升

当几百个工程师在同一份代码库里工作，代码冲突、分支管理、权限控制都变成了巨大的管理成本。Uber 选择微服务，也是为了让每个团队能够独立演进自己的服务，拥有自己的代码仓库、发布节奏和线上运维责任。

从这些困境可以看出来，Uber 的微服务化不是“架构创新”，而是生存需求。它的服务拆分，与业务增长曲线、团队扩张节奏是同步发生的。

3. 从单体到微服务的核心演进过程

Uber 从单体走向微服务，并不是一蹴而就的。从公开材料和开源项目来看，它大致经历了几个阶段，这些阶段对普通团队非常有借鉴意义。

3.1 第一阶段：先加一层 API 网关

移动端和后端之间的耦合，是 Uber 最早优化的问题之一。客户端如果直接调用后端各个模块的接口，那么后端任何一次模块拆分、数据库迁移，都可能要求客户端同步发版。这在移动互联网时代是致命的。

Uber 的做法是在客户端和后端之间加一个 API 网关层。网关负责接收客户端的请求，然后根据业务需要，把请求路由到后端的多个服务，最后聚合成一个响应返回给客户端。对客户端来说，它只认网关这一层，后端怎么拆分、怎么演变，客户端完全无感。

这个思路到今天仍然是微服务架构的标配。画一张标准的微服务架构图，第一层通常就是接入层网关，下面才是业务服务层和基础平台层。网关的出现，是单体走向微服务的第一步，它先把“外部集成”和“内部拆分”解耦了。

3.2 第二阶段：按业务边界拆分服务

网关层稳定后，Uber 开始按业务模块拆分服务。派单、调度、计价、支付、用户、计费、消息通知等边界清晰的模块，逐步从单体中剥离出来，变成独立部署的服务。

这个阶段最大的挑战不是代码拆分，而是数据库拆分。单体时代，所有模块共享一个数据库，一个事务就能完成订单创建和库存扣减。拆分之后，每个服务有了自己的数据库，跨服务的数据一致性就成了全新的问题。

3.3 第三阶段：补齐微服务基础设施

服务数量一多，基础设施就成了瓶颈。Uber 陆续开源了多个与微服务基础设施相关的项目，比如：

• TChannel：一个用于服务间通信的 RPC 框架，支持多路复用和请求路由。
• ringpop：一个一致性哈希应用层协议，用于服务发现和节点协调。
• Cadence：一个分布式工作流引擎，用于编排跨服务的业务流程，后来演化为知名的 Temporal。

从这些开源项目中可以看到，Uber 在微服务化过程中最关注的三件事是：服务间通信、服务发现、跨服务业务流程编排。

这也对应了微服务落地中的三大基础能力：

一、服务间通信：拆完之后，服务之间怎么高效、可靠地调用？二、服务发现：服务实例的 IP 和端口动态变化，调用方怎么找到它？三、工作流编排：一个业务流程跨越多个服务，怎么保证最终一致？

很多团队拆服务时只关注代码拆分，忽略这三项基础设施，结果服务拆完根本无法顺畅联调。Uber 的经验是：基础设施的投入必须跟服务拆分的节奏同步，甚至提前半步。

4. 微服务不是银弹：拆完之后要付的代价

微服务拆分的收益听上去很美好：独立部署、独立扩展、技术栈灵活、团队自治。但拆完之后，所有单体时代被“本地事务”掩盖的问题，都会以更复杂的形式暴露出来。

4.1 事务边界消失

单体应用里，一个业务操作可以依赖数据库的本地事务，保证 ACID。比如创建订单时，扣减库存和保存订单两个操作放在同一个事务里，要么全部成功，要么全部回滚。

拆成微服务后，订单服务和库存服务各自拥有独立的数据库，本地事务不再生效。此时要保证数据一致性，只能选择分布式事务方案，比如两阶段提交、TCC、Saga、本地消息表等。这些方案各有优缺点，但都比单体时代复杂得多。

用一个最小场景说明：

// 文件：monolith/OrderService.java // 单体时代，一个事务搞定订单创建和库存扣减 @Service public class OrderService { private final UserService userService; private final InventoryService inventoryService; private final OrderRepository orderRepository; @Transactional public Long createOrder(OrderRequest request) { // 1. 校验用户 User user = userService.findById(request.getUserId()); if (user == null) { throw new BizException("用户不存在"); } // 2. 扣减库存 boolean ok = inventoryService.deduct(request.getSkuId(), request.getCount()); if (!ok) { throw new BizException("库存不足"); } // 3. 保存订单 Order order = Order.create(request); orderRepository.save(order); return order.getId(); } }

这段代码在单体架构里没有任何问题，@Transactional保证了三个操作要么全部成功、要么全部回滚。但拆成微服务后，userService、inventoryService变成了远程调用，本地事务管不到远程服务。如果订单保存成功但库存扣减失败，或者库存扣减成功但订单保存失败，就需要额外的补偿机制来处理。

4.2 一次请求变成多次网络调用

单体时代，创建订单的接口内部是内存调用，耗时通常以毫秒计。拆成微服务后，订单服务要依次调用用户服务、库存服务，每一次调用都涉及网络传输、序列化、连接建立。如果其中一个服务超时，整个请求的响应时间就可能飙升到秒级。

微服务架构对接口性能的要求更高，因为调用链每多一层，时延就多一份不确定性。

4.3 排查问题更难

单体应用打日志、查错误，直接看一个应用的日志即可。微服务架构下，一个请求会穿越多个服务，每个服务都有自己的日志文件。如果没有链路追踪系统，排查一次线上故障可能要翻十几个服务的日志。

这也是为什么链路追踪（如 Zipkin、Jaeger）会成为微服务基础架构的标配。链路追踪之于微服务，就像地图导航之于一座陌生城市——没有它，你很难确定自己是在哪一条路上走丢的。

5. 跨服务业务流程编排：从 Cadence 到工作流引擎选型

微服务化之后，单纯靠接口调用来维护跨服务业务流程，很快会触及天花板。Uber 开源 Cadence（也就是后来的 Temporal），就是为了解决跨服务业务编排的问题。

这里要分清两类工作流引擎的定位差异：

一类是面向 BPMN 图形化流程的引擎，比如 Activiti、Flowable。这类引擎适合审批流、OA 流程等以“人工任务”为核心的场景，流程定义可视化程度高，运维和业务人员容易理解。

另一类是面向长时运行、可恢复的编程式工作流引擎，比如 Temporal、Cadence。这类引擎更适合跨服务的业务规则编排，开发者用代码定义工作流，工作流可以长时间运行、自动重试、状态持久化，出现故障后能恢复到中断位置重新执行。

Uber 的支付、派单、对账等核心流程，对可靠性要求极高，不适合用 BPMN 描述，更适合用编程式工作流把各个服务串起来。

5.1 工作流引擎在微服务中的典型场景

以订单流程为例，跨服务创建一个订单，可能需要执行一组动作：

// 一个简化的工作流编排示例，示意跨服务业务如何通过工作流引擎串联 func OrderWorkflow(ctx workflow.Context, orderID string) error { // 1. 扣减库存 err := workflow.ExecuteActivity(ctx, DeductInventory, orderID).Get(ctx, nil) if err != nil { return err } // 2. 创建订单 err = workflow.ExecuteActivity(ctx, CreateOrder, orderID).Get(ctx, nil) if err != nil { // 补偿逻辑：库存还回去 _ = workflow.ExecuteActivity(ctx, RestoreInventory, orderID).Get(ctx, nil) return err } // 3. 发送通知 err = workflow.ExecuteActivity(ctx, SendNotification, orderID).Get(ctx, nil) if err != nil { // 通知失败不阻断主流程，记录日志即可 workflow.GetLogger(ctx).Info("notification failed", "orderID", orderID) return nil } return nil }

工作流引擎把“业务规则”和“服务调用细节”分离了。服务只负责执行单个动作，工作流负责编排这些动作的顺序、重试策略和补偿逻辑。这样，跨服务业务流程的可靠性就从“靠代码自觉”提升到了“靠平台保证”。

5.2 关于“Activiti + 自定义查询 + 微服务”的真实痛点

如果你用 Activiti 或 Flowable 做微服务下的流程编排，最痛苦的问题之一就是自定义查询。原因在于，流程引擎的数据和业务服务的数据是分库的。

比如订单服务负责业务数据，流程引擎服务负责流程数据。你想查询“某个订单当前处于什么环节、审批到谁了”，就要把订单数据和流程数据关联起来。但两个库之间没有直接 SQL 可用，最常见的手段有两种：

第一种是冗余字段：在流程启动时，把订单 ID、业务类型、当前节点等核心字段写入流程引擎的流程变量中。查询时直接从流程变量表里过滤，避免跨库 join。

第二种是数据同步：把流程数据同步到业务服务的查询库中，用 CQRS 的思路做读模型。流程引擎写流程数据，通过消息队列或事件机制，把流程状态同步到业务库的查询表里。

这里要提醒的是：Activiti 这类 BPMN 引擎，擅长的是“人参与审批”的流程；而对于服务之间的自动编排，Temporal、Cadence 这类编程式工作流更合适。选型前一定要先搞清楚业务场景属于哪一类，否则会把流程引擎用得很别扭。

6. 普通团队要不要拆微服务：先看信号，再看工具

Uber 的微服务演进经验，很容易被误读成“大厂都拆了，我们也拆”。但一个关键的事实是：Uber 是拥有千万级日活的平台，它的服务拆分是增长倒逼的。如果你的业务规模远没有到这个量级，盲目拆服务只会增加成本。

6.1 可以考虑拆分的信号

如果团队遇到下面几个问题，才值得认真评估微服务化：

信号一：部署耦合严重。代码库足够大，任何一个小功能改动都要全量回归、全量发布，发布窗口越来越长。

信号二：团队协作效率下降。同一个代码库多个团队维护，代码冲突频繁，合并一次 PR 要等很久，线上问题修复权益难以分配。

信号三：故障爆炸半径不可控。一个模块的小故障，会拖垮整个应用，所有业务全部不可用。

信号四：性能瓶颈集中在单体的某个局部。例如某个模块的 CPU 密集计算拖慢了整体响应时间，但无法单独扩容。

6.2 不建议拆分的情况

如果团队只有几万日活、后端团队不到 20 人、代码库规模在几十万行以下，那么单体架构很可能仍然是最优解。这时候微服务带来的分布式事务、服务发现、链路追踪、部署复杂度，会以更快的速度消耗团队的精力。

市面上很多微服务脚手架，比如若依微服务 Plus这类国产开源项目，能帮助你快速跑通 Nacos 注册中心、Spring Cloud Gateway、Sentinel 限流等基础组件。但脚手架解决的是“骨架”问题，解决不了“该不该拆、按什么边界拆”的决策问题。先用脚手架跑通一套，不等于你的业务就适合微服务。

6.3 拆分的粒度判断

微服务拆分粒度，是微服务面试中最高频的问题之一。Uber 的经验是：粒度不是越细越好，而是以“独立团队能够自主交付”为下限。一个服务如果小到任何一个改动都要跨服务协调，那它就是过度拆分。

实际工程中，更推荐按业务能力拆分，而不是按数据表拆分。比如一个“订单服务”应该从创建订单、查询订单、修改订单的完整链路去考虑，而不是把“订单表”的每一个增删改查都拆成单独的服务。

7. 最小示例：单体重构为微服务要改哪些地方

为了说清楚微服务改造的真实成本，我用一个简化的订单场景演示核心改动。这个示例不代表 Uber 的真实代码，但能反映拆分过程中的通用改造模式。

假设我们最初有一个单体应用，订单创建逻辑已经在第 4 节展示过。现在按业务边界拆成三个服务：

• order-service：订单服务，负责订单创建和订单查询。
• user-service：用户服务，负责用户信息校验。
• inventory-service：库存服务，负责库存扣减。

7.1 拆分后的订单服务接口

订单服务不再直接依赖 UserService 和 InventoryService 的实现类，而是通过远程调用获取数据。使用 OpenFeign 作为服务间调用框架：

// 文件：order-service/src/main/java/com/demo/order/client/InventoryClient.java @FeignClient(name = "inventory-service", path = "/api/inventory") public interface InventoryClient { @PostMapping("/deduct") DeductResult deduct(@RequestBody DeductRequest request); }

// 文件：order-service/src/main/java/com/demo/order/client/UserClient.java @FeignClient(name = "user-service", path = "/api/user") public interface UserClient { @GetMapping("/{userId}") UserInfo getUser(@PathVariable("userId") Long userId); }

7.2 服务注册发现配置

每个服务需要把自己的地址注册到注册中心。这里使用 Nacos 作为注册中心，配置示意如下：

# 文件：order-service/src/main/resources/application.yml spring: application: name: order-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848 server: port: 8081

inventory-service 和 user-service 也需要同样的配置，只是服务名和端口不同。

7.3 API 网关路由配置

客户端统一访问网关，网关按路径把请求转发到不同服务。这里使用 Spring Cloud Gateway：

# 文件：gateway-service/src/main/resources/application.yml spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path=/api/order/** - id: user-service uri: lb://user-service predicates: - Path=/api/user/** - id: inventory-service uri: lb://inventory-service predicates: - Path=/api/inventory/**

lb://表示从注册中心按服务名做负载均衡。客户端请求/api/order/create时，网关自动转发给 order-service 实例。

7.4 幂等处理

微服务下，网络超时可能导致客户端重试，或者消息队列重复消费。如果同一个创建订单请求被执行两次，就会产生两条订单记录，这是非常典型的微服务问题。

解决方案之一是给每个请求一个全局唯一的业务 ID，在订单表中用唯一索引兜底：

// 文件：order-service/src/main/java/com/demo/order/service/OrderService.java public boolean tryCreateOrder(String bizId, OrderDO order) { try { order.setBizId(bizId); orderMapper.insert(order); return true; } catch (DuplicateKeyException e) { // 唯一键冲突，说明该请求已经处理过 return false; } }

7.5 运行验证

将三个业务服务和网关服务全部启动后，注册中心可以看到四个服务实例。然后请求网关接口：

curl -X POST "http://localhost:8080/api/order/create" \ -H "Content-Type: application/json" \ -d '{"bizId":"20240601001","userId":1001,"skuId":888,"count":2}'

正常返回订单 ID，说明 order-service 成功创建了订单；同时 inventory-service 的数据库里，对应的 sku 库存被扣减。如果重复请求同一个bizId，第二次请求会被幂等逻辑拦截，返回已处理标识。

这个最小示例告诉我们：微服务改造不只是把代码拆开，还要同时解决注册中心、服务发现、网关路由、负载均衡、幂等、跨服务调用等一系列工程问题。这才是微服务落地的真实成本。

8. 微服务常见问题与排查思路

微服务化之后，很多问题的表象相似，但根因完全不同。以表格形式整理高频问题：

这些问题的共同特征是：大多数不是某一个服务内的问题，而是服务与服务的“缝隙”问题。这也是微服务排障最核心的挑战。

9. 最佳实践与工程建议

从 Uber 的演进经历中，可以提炼出几条对普通团队真正有用的工程建议。

9.1 先解决基础设施，再拆服务

服务拆分之前，至少先完成三件事：服务注册发现组件选型、配置中心选型、链路追踪选型。否则服务拆出去之后，联调和排障都会变得极其困难。Uber 的演进过程中，网关、RPC 框架、工作流引擎是伴随拆分逐步补齐的，但这些都是提前半步在铺垫。

9.2 数据库拆分要谨慎

数据库拆分是微服务化中最危险的一步。建议优先级从低到高：先不做物理分库，用模块边界约束代码；再通过读写分离缓解压力；最后才是对核心业务库做物理拆分。分库之后，原本一次 join 可以解决的查询，就变成了服务聚合调用或 CQRS 读模型。

9.3 每个服务都要有明确的负责人

微服务的数量一旦超过团队数量，就会出现“三个和尚没水喝”的现象。每个服务必须有明确的 Owner 团队，负责它的代码质量、发布、监控和告警响应。没有 Owner 的服务，迟早变成无人维护的僵尸服务。

9.4 接口幂等是硬要求

微服务下，网络超时重试、消息重复消费、用户重复提交都是常态。所有写接口都应该设计成幂等的。最推荐的方式是：调用方生成全局唯一业务 ID，服务方用唯一索引或状态机保证重复请求不产生副作用。

9.5 契约测试大于端到端测试

微服务架构下，端到端测试成本极高。推荐在服务间接口层做契约测试，保证提供方和消费方对接口的约定一致。Spring Cloud Contract 和 Pact 都是成熟方案。这比搭一套完整测试环境更高效。

9.6 面试角度的三个高频问题

常常有读者问微服务面试怎么准备。结合这篇文章的内容，至少有三个问题是必准备的：

第一个：微服务拆分的边界是什么？回答思路：按业务能力拆分，以团队自治和独立部署为下限，不要按数据表粒度拆。

第二个：服务发现有哪几种方式？回答思路：客户端发现和服务端发现。服务端发现最常见的就是网关模式，客户端把请求交给网关，网关从注册中心查询可用实例。

第三个：分布式事务怎么实现？回答思路：可以提 2PC、TCC、Saga、本地消息表。实际生产中更推荐最终一致性的方案，如 Saga 模式或基于消息队列的事务消息。

10. 总结：架构是演进的，不是画出来的

回到文章开头的问题：微服务是设计出来的，还是被逼出来的？

从 Uber 的工程演进来看，答案是后者。它的微服务并不是某个架构团队在一张白纸上画出来的完美蓝图，而是在业务增长、团队扩张、单体架构难以忍受之后，一步步“生长”出来的。正是这种被逼出来的演进，让微服务架构的每一步都有真实痛点支撑，也因此更稳固。

对于普通团队，最重要的启示是：不要为了微服务而微服务。当你还在纠结要不要拆的时候，不如先回到业务现实，看看自己是否已经面临部署耦合、故障爆炸半径、团队协作效率这几个问题的真实压力。如果没有压力，单体架构依然是最高的效率保障；如果有压力，也不要指望一套脚手架就能解决所有问题，基础设施和组织结构的配套投入，才是微服务改造真正的成本。

Uber 的前车之鉴告诉我们，微服务不是终点，而是业务复杂度达到一定阈值后的自然演化。架构决策永远是在为业务服务，而不是反过来让业务迁就架构。记住这一点，比学会任何一门微服务框架都更重要。