什么时候不应该使用微服务？

Question

什么时候不应该使用微服务？

Accepted Answer

微服务通常是**错误的**起点。一个常见的规则是**"monolith first"**：从一个结构良好的monolith开始，只有当你有具体理由时才提取服务。

## 避免使用微服务的情况

```text
✗ Small team — more services than people to run them
✗ Early-stage product — domain boundaries still shifting
✗ No CI/CD, monitoring, or tracing in place
✗ Low traffic — no real scaling pressure
✗ Simple domain — splitting adds cost, not value
```

## 过早拆分的成本

将进程内方法调用移动到网络调用会增加延迟、故障模式、序列化和部署单元。如果边界错误，你需要付出所有这些代价**并且**还必须跨服务进行重构。

```text
method call        →  microseconds, can't fail
network call       →  milliseconds, can time out, can be down
```

## 更好的方法

```text
Start: modular monolith (clear internal boundaries)
  └─▶ Extract a service ONLY when:
         · it needs independent scaling, OR
         · a separate team needs independent deploys, OR
         · it needs a different tech/SLA
```

## 为什么这很重要

大多数过早采用微服务的团队最终会变得更慢而不是更快，因为他们在需要之前就承担了分布式系统的开销。

首先将边界保留在monolith内部，可以让你以低成本学习领域，然后再沿着正确的接缝拆分。