微服务治理演进：从 Netflix OSS 到 Service Mesh

Sun, 17 May 2026 00:00:00 +0000

微服务架构的流行带来了一个悖论：系统被拆分成更小的单元以降低复杂度，但服务之间的通信却创造了一个更复杂的分布式系统。如何治理这个「服务间的混沌」，是过去十年基础架构领域最重要的课题之一。

第一阶段：蛮荒时代（2014 之前）

在微服务概念刚刚兴起的时候，服务治理几乎等于「手写一切」：

服务 A 调用服务 B：

1. 自己实现服务发现（查 ZooKeeper / Nginx upstream）
2. 自己实现负载均衡（轮询 / 随机）
3. 自己实现重试（try-catch + 循环）
4. 自己实现超时（设置 HTTP timeout）
5. 自己实现熔断（状态机 + 计数器）

每一个服务的开发者都要重复实现这些逻辑，而且不同团队的实现质量参差不齐

这个阶段的核心问题是：治理逻辑和业务逻辑耦合在应用代码中。每一次修改治理策略（比如调整超时时间），都需要修改业务代码、重新编译、重新部署。

第二阶段：SDK 时代（2014-2017）

Netflix 开源了一整套微服务治理工具（Netflix OSS），标志着微服务治理进入 SDK 时代：

Netflix OSS 全家桶：

Eureka    → 服务注册与发现
Ribbon    → 客户端负载均衡
Hystrix   → 熔断器
Feign     → 声明式 HTTP 客户端
Zuul      → API 网关
Archaius  → 动态配置

Spring Cloud 在此基础上做了封装，让 Java 开发者可以用注解的方式快速接入：

@FeignClient(name = "user-service", fallback = UserServiceFallback.class)
public interface UserServiceClient {
    @GetMapping("/users/{id}")
    User getUser(@PathVariable("id") Long id);
}

@Component
public class UserServiceFallback implements UserServiceClient {
    @Override
    public User getUser(Long id) {
        return User.defaultUser();  // 熔断降级
    }
}

SDK 模式的问题

Netflix OSS 解决了「重复造轮子」的问题，但它引入了新的痛点：

Istio on 架构视界

微服务治理演进：从 Netflix OSS 到 Service Mesh

第一阶段：蛮荒时代（2014 之前）

第二阶段：SDK 时代（2014-2017）

SDK 模式的问题