用 Nginx/Spring Gateway 玩转绞杀者模式，帮你拆掉老系统

摘要

面对庞大老旧的遗留系统，直接替换既费时又高风险。绞杀者模式（Strangler Fig Pattern）提供了一种“边保留边替换”的方式，帮助团队逐步拆除旧模块，同时上线新能力，实现平滑过渡。本文将结合实际案例，深入介绍绞杀者模式的原理、阶段应用时机以及技术实现方式，最后提供可运行的 Spring Boot + Gateway Demo，供读者快速上手。

引言

在开发过程中，遗留系统就像“技术债”的黑洞，既怕动又不得不动。一旦系统年久失修、耦合严重，很多团队都会陷入“不敢改、改不起”的尴尬境地。

你可能会问：有没有办法 一边让系统继续跑着不崩，一边慢慢替换掉老的模块？

答案就是：绞杀者模式（Strangler Fig Pattern）。

这个名字听起来有点凶残，其实来源很美妙——就像热带树种绞杀榕，它会一点点包围旧树，直到老树被完全替换为新的生命体。

什么是绞杀者模式？

原理解析

绞杀者模式本质上是一种渐进式替换策略，通过将流量引导到“新旧模块共存”的路由架构中，让旧模块逐步退出历史舞台。

核心思路是：

• 先把旧系统包起来（使用反向代理或 API 网关）
• 每次替换一个具体功能或接口
• 新旧逻辑并存一段时间，经过验证后再停用旧逻辑

就像旧城改造，不是全部推倒重建，而是先拆一个片区，建一个片区。

什么时候适合用它？

合适的使用时机

如果你发现你的系统符合以上条件，那么绞杀者模式就非常合适。

技术实现方案

关键技术点

1. 路由切换器：比如 Nginx、Spring Cloud Gateway、Traefik 等
2. 请求判别器：根据 URI、Header、Token 或灰度规则判断走旧逻辑还是新逻辑
3. 流量镜像 & 灰度发布：部分用户先切过去，验证 OK 再全量切

代码示例：Spring Cloud Gateway 实现绞杀模式

假设你有一个旧接口：/api/v1/orders，现在要迁移到新服务 /api/v2/orders。

配置方式（Spring Cloud Gateway）

# application.yml
spring:
  cloud:
    gateway:
      routes:
        - id: legacy-orders
          uri: http://legacy-service
          predicates:
            - Path=/api/v1/orders
          filters:
            - RewritePath=/api/v1/(?<segment>.*), /${segment}

        - id: new-orders
          uri: http://new-order-service
          predicates:
            - Path=/api/v2/orders

控制灰度流量（用 Header 来切换）

- id: smart-orders
  uri: http://new-order-service
  predicates:
    - Path=/api/v1/orders
    - Header=Use-New, true

配合前端或测试用户发带有 Use-New: true 的请求，就会走新服务。

示例模块（Spring Boot）

@RestController
@RequestMapping("/api/v2/orders")
public class NewOrderController {

    @GetMapping
    public ResponseEntity<String> getOrders() {
        return ResponseEntity.ok("来自新服务的订单数据");
    }
}

QA 环节

Q：新旧系统数据不一致怎么办？

A：可以考虑设置读新写旧的双写策略，或者通过数据库同步工具进行临时同步。

Q：每次切流量都需要重新部署吗？

A：如果接入了 LaunchDarkly、Nacos、Spring Cloud Config 等配置中心，可以热更新规则，免部署。

Q：有没有可能永久“新旧共存”？

A：有，但不建议。每个阶段都应该明确一个“淘汰旧逻辑”的时间点，否则绞杀者模式会变成“共存者模式”。

总结

绞杀者模式不是一招定乾坤的“大招”，它更像是“渐进式重构”的操作指引。通过代理网关、开关控制、灰度切流等手段，帮助我们平滑地从老系统过渡到新架构。

关键是要：

• 有清晰的模块切换节奏
• 每一次替换都要可控、可灰度、可回滚
• 保持数据和行为的一致性

在微服务、大前端和 Serverless 趋势下，系统生命周期越来越短。未来，越来越多的团队会采用“可拆卸、易替换”的架构设计，从一开始就留好“绞杀点”，让演进成为常态。