去年有个朋友跟我聊天，说他们团队花了两个月把一个 Go 单体拆成 8 个微服务。半年后，又花了三个月改回去。

我问为什么要拆。“CTO 去技术大会回来，说微服务是大势所趋，趁项目还不大，早拆早受益。”

我问为什么改回来。“原来一个人能 debug 全流程，拆完追一个 bug 要翻三个服务的日志；原来数据库一个事务搞定，拆完订单和库存需要分布式事务；Kubernetes 集群倒是买了一年的。”

不是微服务的锅。是他们在三个关键决策点上，每个都选错了。

从单体到微服务，不是一次性的"架构升级"，而是在三个拐点分别做出正确的判断：什么时候拆、拆成什么样、用什么连。搞错任何一个，微服务就从架构工具变成了架构负债。

1. 拐点一：什么时候开始拆

先说结论：大多数团队拆早了。

上面那个 10 人团队就是典型。日活 3 万，QPS 峰值 200，一个 PostgreSQL 跑得好好的。但"微服务"三个字太有吸引力了，谁不想在简历上写"主导了微服务架构改造"呢？

但拆分的本质是把一个进程内的函数调用变成跨网络的服务调用。这个变换有代价：网络延迟、序列化开销、错误处理膨胀、运维复杂度翻倍。你需要足够的收益来覆盖这些成本。

怎么判断"够不够"？我整理了一份 5 问检查清单。注意，这不是精确公式，每个维度的权重在不同场景下差异很大（数据耦合通常比团队结构更关键）。它的价值是帮你不漏检，不是帮你算分：

拆分决策 5 问检查清单

多数 Yes → 拆分收益明确。多数 No → 暂时别动。 实际场景中很少全是 Yes 或全是 No，灰色地带需要你结合业务判断。

用这个清单复盘那个 10 人团队：数据不独立、团队不独立、发布不独立、瓶颈不隔离、故障域不隔离。五个全是 No，根本不应该拆。

同公司另一个 50 人的团队就不一样。交易组 15 人、搜索组 20 人、推荐组 15 人，三个组频繁出现代码合并冲突，推荐系统的每日迭代被交易系统的周发布节奏拖累。拆分后，搜索服务独立扩到 20 个实例，交易服务只需 5 个，资源利用率提升 40%；推荐服务独立发布后，迭代速度从每周 1 次变成每天 2 次。五个维度全部命中，拆分收益立竿见影。

亚马逊 Prime Video 团队在 2023 年将音视频监控服务从 serverless 微服务架构迁移回单进程部署，成本降低了 90%，引发行业热议。本质也是同样的判断：当服务间数据流太紧密时，拆分带来的网络开销超过了架构隔离的收益。

所以关键不是"微服务好不好"，而是这个时候该不该拆。

2. 拐点二：拆成什么样

好，确定要拆了。下一个难题：拆几块？按什么划线？

很多团队的第一反应是"按 API 拆"：用户服务、商品服务、订单服务、库存服务、支付服务、通知服务、搜索服务、推荐服务。一刀下去 8 个。

这是最常见的错误。拆分粒度应该按业务域而非按 API 划分。 “数据一起变的大概率该在一起”，这是 DDD 限界上下文的核心思想。说直白点：如果两块逻辑几乎每次都一起改、一起发布、共享同一张表，那它们就不该分成两个服务。

看一个 Go 代码的对比就明白了。

单体版（为演示简化，生产代码会用数据库事务而非全局变量）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

func PlaceOrder(sku string, qty int, price float64) (order Order, err error) {
    mu.Lock()
    defer mu.Unlock()

    stock, ok := inventory[sku]
    if !ok {
        err = errors.New("商品不存在")
        return
    }
    if stock < qty {
        err = errors.New("库存不足")
        return
    }

    inventory[sku] -= qty
    order = Order{ID: "ord-001", SKU: sku, Qty: qty, Total: float64(qty) * price}
    orders = append(orders, order)
    return
}

15 行核心逻辑，2 个错误检查，一个锁保证一致性。清清爽爽。

拆分版——同样的逻辑，订单服务调库存服务：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

// 订单服务的下单入口
func PlaceOrder(ctx context.Context, invClient *InventoryClient, sku string, qty int, price float64) (order Order, err error) {
    _, err = invClient.DeductStock(ctx, sku, qty)
    if err != nil {
        err = fmt.Errorf("扣库存失败: %w", err)
        return
    }
    order = Order{ID: "ord-001", SKU: sku, Qty: qty, Total: float64(qty) * price}
    return
}

// DeductStock 背后的网络调用——原来一行 inventory[sku] -= qty 搞定的事
func (c *InventoryClient) DeductStock(ctx context.Context, sku string, qty int) (remain int, err error) {
    reqBody := DeductRequest{SKU: sku, Qty: qty}
    data, _ := json.Marshal(reqBody)

    req, _ := http.NewRequestWithContext(ctx, "POST", c.baseURL+"/deduct",
        strings.NewReader(string(data)))
    resp, err := c.httpClient.Do(req)  // 3 秒超时
    if err != nil {
        err = fmt.Errorf("库存服务不可达: %w", err)
        return
    }
    defer resp.Body.Close()

    if resp.StatusCode != http.StatusOK {
        err = fmt.Errorf("库存服务返回异常: status=%d", resp.StatusCode)
        return
    }
    var deductResp DeductResponse
    if err = json.NewDecoder(resp.Body).Decode(&deductResp); err != nil {
        err = fmt.Errorf("解析响应失败: %w", err)
        return
    }
    if !deductResp.Success {
        err = errors.New(deductResp.Error)
        return
    }
    remain = deductResp.Remain
    return
}

原来 inventory[sku] -= qty 一行搞定的事，现在要构造 HTTP 请求、设超时、解析响应、处理 4 层错误。完整对比 [实测 Go 1.26.2]：

核心业务逻辑一行没变。拆分不会让业务代码变好，只会让基础设施代码变多。

那 4 个新增问题更要命：超时控制、重试策略（幂等性）、分布式事务（库存扣了但订单创建失败怎么办？）、服务发现。每一个都够你忙一周。

如果两块逻辑共享数据、同步变更、同一个团队维护、同一个节奏发布，它们就是一个服务，别硬拆。拆微服务和搬家一样，不是把东西从大房子搬到小房子就叫升级，关键是你有没有想清楚哪些东西应该放在一起。

3. 拐点三：用什么连

边界划好了，最后一个决策：服务之间用什么方式通信？

不少团队的做法是所有场景统一用 gRPC。理由很充分：Google 在用，性能好，类型安全。但同一个锤子不适合所有钉子。

回到那个场景：C 团队拆了 5 个服务，所有通信都用 gRPC。结果：

• 用户下单→发短信通知：gRPC 同步调用，短信网关响应 2-3 秒，直接拖累下单接口 P99
• 订单状态变更→通知 4 个下游：gRPC 点对点，需要逐个调用，一个慢全部慢
• 配置变更→全服务广播：gRPC 没有发布/订阅能力，改成轮询，白白浪费资源

协议选型不是"哪个性能好用哪个"，而是"哪个场景用哪个"。

我整理了一个通信选型决策树，核心就三个维度：

1
2
3
4
5
6
7
8

调用方需要立即拿到结果吗？
├─ 是（同步调用）
│  ├─ 需要强类型契约 + 高效序列化 → gRPC
│  └─ 通用场景、调试优先 → HTTP/JSON
└─ 否（异步调用）
   ├─ 消息不能丢 + 顺序消费 → Kafka
   ├─ 消息不能丢 + 简单队列 → NATS JetStream / RabbitMQ
   └─ 消息可丢弃 → NATS Core

用 C 团队的场景走一遍：

• 下单→扣库存：需要立即拿到结果 + 强一致 → gRPC，没毛病
• 下单→发短信：不需要立即拿到结果 + 允许延迟 → NATS/Kafka，异步解耦
• 订单状态→多下游消费：发布/订阅模式 → Kafka，天然多消费者

补一组数据，帮你感受不同通信方式的开销量级差异 [实测 Go 1.26.2, Apple M4 Pro]：

注意：以下三种方式的测量条件不同，不能直接横向比较绝对数值。HTTP 走了完整的本地 TCP 回环，gRPC 行仅测量序列化开销（无网络栈），Channel 是纯进程内通信。这组数据的意义在于帮你理解各层开销的量级，而不是给出协议性能排名。

真正的性能瓶颈几乎不在通信协议本身，而在业务逻辑和数据库查询。选 gRPC 还是 HTTP，看的是类型安全性和代码生成的工程收益，不是 ns 级的延迟差。

选同步还是异步，才是真正影响架构的决策。

还有一个容易忽略的坑：选对了协议，协议细节也会咬你。比如 gRPC 用的 proto3 格式有个 optional 字段陷阱。简单说，如果你定义了一个 bool active = 1 字段但没加 optional 关键字，当发送方把它设为 false 时，proto3 会把它当零值省略掉，接收方拿到的是默认值 false，无法区分"发送方明确设了 false"还是"发送方压根没设"。解法是给字段加上 optional 关键字，Go 会生成 *bool 指针类型，nil 和 false 就能区分了。这种静默出错在微服务通信中尤其危险，因为 Send() 不会报任何错。

三拐点决策速查表

回到开头那个 10 人团队。如果他们用这个框架重新走一遍：

拐点一：5 问检查，全部 No → 不拆。省下两个月开发时间和一年的 K8s 费用。

如果他们非要拆（比如团队长到 50 人了），那：

拐点二：按业务域划分，3 个服务（交易、搜索、推荐），不是 8 个。

拐点三：同步场景用 gRPC，异步通知用消息队列，别所有场景都用同一个协议。

微服务不是终点，是手段。下次有人跟你说"我们该上微服务了”，先把那 5 个问题过一遍。

文中 A、B、C 三个团队为基于常见工程实践构造的模拟场景，不指代真实公司或团队。