1. 课程导论：API弃用场景概述、租户隔离的重要性、蓝绿部署与滚动升级的基本概念
1.1 API弃用场景概述
在云原生微服务架构中，API版本迭代与旧版本下线是不可避免的运维动作。API弃用（API Deprecation）并非简单的代码删除，而是一个涉及兼容性、流量调度、数据一致性的复杂过程。常见的触发场景包括：
- 协议升级：从RESTful v1迁移至gRPC或GraphQL，旧端点需逐步关闭。
- 字段重构：请求/响应体中的字段名变更或废弃，需保留旧字段兼容期。
- 安全加固：移除不安全的认证方式（如明文传输），强制使用OAuth 2.1。
- 第三方依赖退役：上游服务停止支持，迫使下游API同步调整。
常见误区：很多团队将API弃用等同于“直接下线旧版本”，忽略了租户侧未迁移的流量，导致生产中断。正确的做法是设置弃用窗口期，并在窗口期内通过灰度策略逐步切断流量。
1.2 租户隔离的重要性
在SaaS或多租户平台中，不同租户（客户、组织、项目）共享同一套基础设施。API弃用期间，若缺乏租户隔离机制，一次升级可能同时影响所有租户，造成“爆炸半径”过大。租户隔离的核心目标包括：
| 隔离维度 | 说明 | 典型实现 |
|---|---|---|
| 数据隔离 | 每个租户的数据存储独立，避免弃用期间数据污染 | Schema-per-tenant、Database-per-tenant |
| 流量隔离 | 弃用窗口期内，仅影响指定租户的流量 | 租户级路由、Sidecar代理、标签路由 |
| 配置隔离 | 不同租户可拥有独立的弃用策略与时间窗口 | 租户级Feature Flag、动态配置中心 |
| 监控隔离 | 弃用期间可单独追踪每个租户的错误率与延迟 | 租户标签、多维监控仪表盘 |
最佳实践：在API网关层（如Kong、APISIX、Envoy）实现租户标识提取与路由策略，将弃用逻辑与业务代码解耦。这样即使弃用策略变更，也无需重新部署微服务。
1.3 蓝绿部署与滚动升级的基本概念
在API弃用场景下，我们需要一种零停机的方式将流量从旧版本API迁移到新版本。蓝绿部署与滚动升级是两种最常用的策略，它们各有适用场景与风险点。
1.3.1 蓝绿部署（Blue-Green Deployment）
维护两套完全独立的环境：蓝环境（当前生产环境）与绿环境（新版本环境）。通过负载均衡器一次性切换流量。适用于租户数量较少、API变更较大的场景。
1.3.2 滚动升级（Rolling Update）
逐步替换旧版本实例，每次替换一小部分（如10%的Pod），直到所有实例都更新为新版本。适用于租户数量大、API变更较小的场景，但需要精细的租户亲和性控制，避免同一租户的请求在升级过程中被路由到不同版本的实例。
1.4 策略对比与选型建议
| 对比维度 | 蓝绿部署 | 滚动升级 |
|---|---|---|
| 资源消耗 | 高（需双倍资源） | 低（仅需少量额外资源） |
| 切换速度 | 快（秒级切换） | 慢（分钟级逐步替换） |
| 回滚速度 | 快（切回蓝环境即可） | 慢（需反向滚动） |
| 租户隔离粒度 | 粗（全量切换，无法按租户灰度） | 细（可结合租户亲和性实现灰度） |
| 适用场景 | API重大变更、租户数量少、可接受双倍成本 | API小版本迭代、租户数量大、需精细化灰度 |
课程核心观点：在API弃用场景下，租户隔离是保障服务连续性的基石。蓝绿部署与滚动升级并非互斥，而是可以组合使用——例如先通过蓝绿部署完成基础设施切换，再通过滚动升级逐步验证租户兼容性。后续章节将深入讲解这两种策略在Kubernetes环境下的具体实现、故障模式与排查方法。