企业官网建设流程全解析

简介：SaaS 平台架构正成为传统软件厂商转型的方向，而 AWS 提供了完整的实施路径。这份 PPT 面向云计算架构师、SaaS 产品经理与技术决策者，以解决方案视角系统梳理了在 AWS 上设计 SaaS 平台的核心模块，包括身份管理与租户隔离、Silo、Bridge、Pool 三种多租户模式的关键取舍、应用分层与数据隔离方式，以及基于 CloudWatch、CloudTrail、Config 的监控运维和基于标签、API 计费与统一视图的租户计量方案；同时延伸到 DevOps 敏捷交付、大数据分析、物联网和人工智能服务集成，帮助读者理解云原生 SaaS 的全景。资源为单个 PPTX 文件，大小约 1.21MB，内容紧凑、图文结合，适合作为架构选型、方案评审和团队内部培训的参考资料。目前已有 143 人浏览/学习，读者可快速从这套架构梳理中掌握 AWS SaaS 的设计要点、模式权衡与业务扩展路径，减少前期调研和试错成本。

1. 从“租户隔离”到“账单归属”：AWS SaaS 架构的真正分水岭

SaaS 平台架构在 AWS 上落地，最容易犯的错误不是选错服务，而是把“多租户”理解成了“多套环境”。一套租户一套 VPC、一套数据库、一套 EKS 集群，看似隔离彻底，实际上运维成本随租户数量线性增长，很快会把毛利率吃掉。反过来说，全池化共享虽然资源利用率高，但一个租户的慢查询或暴力请求会拖垮所有人，SLA 没法交代。

业界对 AWS SaaS 平台架构的共识是：按“租户模型”分层决策，而不是按“环境”复制。控制面共享、数据面按合规和性能要求选择隔离级别，计费维度独立于技术隔离维度。这条思路能同时解决三个问题——新租户上线速度、单租户资源爆炸半径、以及月底成本分摊时财务和研发不吵架。

这篇文章面向的是要亲自搭平台、或者要给已有系统做 SaaS 化改造的工程师。下面按一条完整落地路径展开：先定租户模型和 AWS 服务选型，再做身份与数据面隔离，然后把计费与成本归属做进架构里，最后补控制面扩展和排错技巧。内容全部基于可直接执行的 AWS 服务展开，不涉及任何第三方代理或网络穿透方案。

2. 多租户模型选型：先定隔离粒度，再谈 AWS 服务映射

2.1 共享与隔离的光谱：三种基础模型

SaaS 多租户架构不存在唯一的正确答案，只有基于业务约束的取舍。AWS 官方在 SaaS 架构白皮书里把租户模型分成三层：池化（Pool）、桥接（Bridge）、隔离（Silo）。这个分法不抽象，直接对应你能接受的故障爆炸半径和运维复杂度。

池化模型是所有租户共享同一套应用实例和数据库，用租户 ID 做逻辑隔离。优点是资源利用率最高、新租户上线几乎零成本；缺点是任何一个租户的异常查询、热点 Key、全表扫描都可能影响全局。桥接模型是部分资源共享、部分资源独享，比如应用层共享但数据库按租户分 Schema，或者反过来。隔离模型是每个租户一套独立资源栈，隔离最彻底但成本最高，通常只留给金融、医疗或对数据驻留有硬性要求的租户。

选型时我会先画一张表，把每个租户维度的合规要求、性能基线和预算上限列出来，然后按“能否接受与别人共享物理资源”来归类。这不是一次性决策——同一个平台里，免费版租户走池化、企业版租户走隔离，完全可以并存。

比如：免费版放在共享 ECS 自动扩缩容组里，数据库用共享 RDS PostgreSQL 实例加 Row Level Security。企业版用独立 EKS 命名空间加独立 Aurora 集群。这样既不牺牲免费用户的体验，也不让大客户为小客户的问题买单。

2.2 AWS 服务与控制面/数据面映射

架构上要把“控制面”和“数据面”拆开思考。控制面负责租户生命周期管理：注册、开通、配置下发、计费采集；数据面负责业务请求处理：API 调用、数据读写、文件存取。两者在 AWS 上的服务选型完全不同。

控制面我一般用 API Gateway + Lambda + Step Functions 编排。一个新租户注册进来，Step Functions 依次执行：创建租户记录、初始化数据库 Schema、创建或绑定资源、发放初始配置。这套流程天然异步、可重试、可观测。数据面则根据第 2.1 节的模型选择：池化租户走共享 ECS 服务，隔离租户走独立 ECS 服务或 App Runner。

一个常被忽略的点是：数据面服务的自动扩缩容策略必须与租户模型绑定。池化模式下，扩缩容看的是整体请求量和平均延迟，用 Application Auto Scaling 按 CPU 和请求数组合扩缩。隔离模式下，每个租户的服务要单独配置最小实例数，避免冷启动延迟影响客户体验。

2.2.1 租户上下文如何穿透到 AWS 资源层级

租户上下文不只是一个数据库字段。在 AWS 上，它要穿透到 IAM 策略、KMS 密钥、CloudWatch 日志组、S3 桶前缀等各个层级。常见做法是：API Gateway 在请求进入时校验 JWT，从 Token 的custom:tenant_id声明中提取租户标识，写入请求头x-tenant-id，下游服务统一从这个头读取。

# Lambda 授权器：从 JWT 提取租户上下文并注入请求头 def lambda_handler(event, context): # event 是 API Gateway 传入的授权请求 method_arn = event['methodArn'] token = event['authorizationToken'] # 解码 JWT，提取租户 ID 和用户角色 # 生产环境请用 AWS Cognito 的 verify 接口或自管 JWKS claims = decode_jwt(token) tenant_id = claims.get('custom:tenant_id') # 生成 IAM 策略，限定该租户只能访问自己的资源前缀 policy = { 'Version': '2012-10-17', 'Statement': [{ 'Action': 'execute-api:Invoke', 'Effect': 'Allow', 'Resource': f'{method_arn}/*/*/{tenant_id}/*' }] } return { 'principalId': claims['sub'], 'policyDocument': policy, 'context': { 'tenantId': tenant_id, 'userId': claims['sub'] } }

这段代码的逻辑是：把租户 ID 注入 IAM 策略的 Resource ARN 中，API Gateway 会将路径参数传给下游，并注入context里的tenantId。这样每个租户的请求只能触达自己前缀下的资源路径，即使拿到了别人的 API URL，也无法越权访问。

参数说明：method_arn来自 API Gateway 的事件结构，格式为arn:aws:execute-api:region:account-id:api-id/stage/method/path；custom:tenant_id是 Cognito 用户池自定义属性的标准写法，注册租户管理员账号时通过 AdminCreateUser 写入。这套机制能把租户身份从应用代码里彻底剥离，下沉到基础设施层。

3. 身份体系与数据面隔离：Cognito 池化、DynamoDB 分区键与 RDS Schema 方案

3.1 Cognito 多租户身份：一个用户池还是多个用户池

SaaS 平台最纠结的问题之一是：所有租户共用一个 Cognito User Pool，还是每个租户一个 Pool？两个方案都有实践者，但适用场景完全不同。

共用用户池的好处是运维简单，一个 Pool 管所有用户，Lambda trigger 统一配置。但坏处也很明显：用户名天然全局唯一，两个租户想要同样的用户名（比如 admin@company.com）就会冲突；密码策略、MFA 配置也只能全局生效，无法按租户定制。每租户独立用户池则相反，隔离彻底、支持每租户独立的安全策略，但 Cognito 服务配额（默认每个 AWS 账号最多 1000 个 User Pool）会成为硬上限。

我的建议是：默认共用 Pool，按租户做分组隔离，仅当客户明确要求独立身份存储时才创建独立 Pool。共用 Pool 下，用 Cognito Group 映射租户 ID，用户在注册时通过custom:tenant_id属性标记归属。登录后从 ID Token 的cognito:groups声明读取角色，从custom:tenant_id读取租户归属。

3.1.1 用 Pre Token Generation Trigger 注入租户上下文

Cognito 的 Pre Token Generation Lambda Trigger 是 SaaS 架构的关键钩子。它可以动态修改 ID Token 和 Access Token 的内容，把租户角色和权限声明注入 Token，下游服务无需查数据库就能完成鉴权和租户路由。

# 每次签发/刷新 Token 时触发，动态注入租户角色 import json def lambda_handler(event, context): # event 结构中包含 request.userAttributes 和 groupConfiguration user_attrs = event['request']['userAttributes'] tenant_id = user_attrs.get('custom:tenant_id', 'unknown') # 根据用户在租户内的角色，生成自定义 claims # 这里可以从 DynamoDB 读取租户级角色映射，避免硬编码 claims_to_add = { 'tenant_id': tenant_id, 'tenant_role': user_attrs.get('custom:tenant_role', 'member'), 'tenant_plan': get_plan_from_tenant(tenant_id) # 从订阅表查询套餐类型 } # 覆写 ID Token 的 claims event['response']['claimsOverrideDetails'] = { 'claimsToAddOrOverride': claims_to_add, 'groupOverrideDetails': { 'groupsToOverride': [f"tenant_{tenant_id}_{claims_to_add['tenant_role']}"] } } return event

说明：claimsOverrideDetails里添加的 claim 会出现在 ID Token 和 Access Token 中，API Gateway 的 Lambda 授权器可以直接读取。groupsToOverride可以动态生成租户级角色分组，IAM 策略可以基于这个动态分组做资源授权。注意get_plan_from_tenant要做缓存，这个 Trigger 每次刷新 Token 都会触发，如果每次都查数据库，高并发登录时会成为瓶颈。我一般用 ElastiCache Redis 做 5 分钟 TTL 缓存。

3.2 数据面隔离的三种落地方式

3.2.1 DynamoDB：单表 + 分区键设计

如果业务以键值读取为主，DynamoDB 是最合适的 SaaS 数据面。核心设计原则：用分区键承载租户 ID，用排序键承载业务主体 ID。这样 AWS 会自动把不同租户的数据分布到不同分区，查询天然隔离。

这套设计的陷阱在于：单租户数据量过大时，分区键会出现热分区。AWS 对单分区的吞吐有上限（默认 3000 RCU / 1000 WCU 左右），一个租户的数据量达到这个量级，吞吐就会受限。解决办法是引入“大租户换键”策略：当租户的数据量超过阈值（比如 5GB），将其拆分为多个逻辑分片，分区键变为tenant_id#shard_0、tenant_id#shard_1。

3.2.2 RDS PostgreSQL：每租户 Schema 还是 Row Level Security

关系型数据库的 SaaS 化比 NoSQL 复杂得多，因为表结构、索引、外键都牵扯其中。两种主流方案是“每租户 Schema”和“共享 Schema + RLS”。

每租户 Schema 是把同一个建表脚本在每个租户的 Schema 下各执行一次。好处是数据物理隔离、备份恢复可按租户独立操作、SQL 层面完全隔离；坏处是连接数管理困难——一个 PostgreSQL 实例能支撑的连接数是有限的，几百个 Schema 就需要几百个连接。解法是用 PgBouncer 做连接池，用set search_path在不同租户间切换。这套方案适合企业级 SaaS，租户数量在几十到几百这个量级。

共享 Schema + RLS 是所有租户共用同一套表，通过tenant_id列和一个数据库政策函数自动过滤行级可见性。适合租户数量上千的场景，运维最简单，但 DBA 对性能调优的难度会上升——因为所有租户的数据挤在同一张表里，索引和统计信息互相干扰。

-- 每租户 Schema 的连接路由示例 -- PgBouncer 按 database 路由，每个租户一个逻辑数据库名 -- 应用侧连接串示例： -- postgresql://user:pass@pgbouncer.example.com:6432/saas_t_001 -- 在 PgBouncer 配置中添加租户映射 [databases] saas_t_001 = host=postgres-primary port=5432 dbname=saas_platform saas_t_002 = host=postgres-primary port=5432 dbname=saas_platform -- 应用层查询前设置 search_path 隔离租户 SET search_path TO tenant_t_001, public; SELECT * FROM orders WHERE order_id = 'ord_123';

这段配置的关键在于：所有租户的 Schema 都在同一个 PostgreSQL 实例上，但通过search_path精确路由到各自 Schema。这样物理资源共享、逻辑完全隔离。参数说明：dbname=saas_platform是物理数据库名，saas_t_001是逻辑库名，PgBouncer 做翻译映射。查询前必须执行SET search_path，否则会默认访问publicSchema。实际生产中我建议在连接池初始化阶段用server_reset_query = DISCARD ALL来清空上一个租户的会话状态，避免会话串租户。

3.3 租户元数据服务：所有隔离方案的统一入口

无论用哪种数据面方案，都需要一个统一的租户元数据服务。这个服务维护一张核心表：租户 ID、租户名、套餐类型、数据面类型（pool/silo）、数据面终端节点、状态（active/suspended/deleted）。所有下游服务在处理请求前，先查这个表确认租户状态并获取数据面终端地址。

# 租户元数据服务：查询租户的数据面位置和状态 import boto3 import json dynamodb = boto3.resource('dynamodb') TABLE_NAME = 'saas_tenant_metadata' def get_tenant_context(tenant_id): table = dynamodb.Table(TABLE_NAME) # 强一致读取，保证状态是最新的 resp = table.get_item( Key={'tenant_id': tenant_id}, ConsistentRead=True ) item = resp.get('Item') if not item: raise TenantNotFoundException(tenant_id) # 租户挂起/欠费时直接阻断，避免数据面被无效请求打爆 if item['status'] != 'ACTIVE': raise TenantSuspendedException(tenant_id, item['status']) return { 'tenant_id': tenant_id, 'data_plane_type': item['data_plane_type'], 'endpoint': item['endpoint'], 'plan': item['plan'], # 拿到数据面连接配置 'config': json.loads(item['config_json']) }

这个服务在架构上是“配置中心”和“断路器”的结合体——租户被标记为SUSPENDED后，所有请求在到达业务逻辑之前就被拦截。生产环境里，这个表用 DynamoDB 加 DAX 加速读取，避免每次请求都打到 DynamoDB 本身。

4. 计费与成本归属：SaaS 架构里最容易做错的一层

4.1 从“按用量计费”倒推架构设计

很多 SaaS 团队把计费做成事后补丁，先上线功能再想办法统计用量，结果月底对账时发现：资源用了多少说不清、每个租户的成本摊不明白。正确做法是：在架构设计阶段就把计费数据的采集点埋好。

AWS 上的成本归属有两个维度。第一个是基础设施维度——EC2、RDS、S3 这些资源本身产生了多少费用。第二个是业务维度——某个租户发了多少请求、存储了多少数据、消耗了多少计算量。前者用 Cost Explorer 的标签分组就能解决，后者必须依赖应用层埋点。

基础设施维度我一般这样做：

1. 创建 AWS 成本分配标签tenant_id，所有按租户隔离的资源（独立 EC2、独立 RDS、独立 S3 桶）打上对应标签
2. 池化共享的资源（共享 ECS 集群、共享数据库）打上shared_platform标签
3. 在 Cost Explorer 里按标签分组，生成每日成本报表
4. 共享资源的成本按月摊到各租户——摊分公式不能乱拍脑袋，要基于应用层埋点的实际用量

# 应用层用量采集：在共享数据面服务里埋点 import boto3 import time import json cloudwatch = boto3.client('cloudwatch') def report_usage(tenant_id, resource_type, amount): # 将租户用量指标推送到 CloudWatch # 后续通过 GetMetricData 汇总并按量计费 cloudwatch.put_metric_data( Namespace='SaaS/Usage', MetricData=[{ 'MetricName': f'{resource_type}_usage', 'Dimensions': [ {'Name': 'TenantId', 'Value': tenant_id}, {'Name': 'ResourceType', 'Value': resource_type} ], 'Value': amount, 'Unit': 'Count' }] ) # 示例：文件上传服务在每次上传后记录用量 def upload_file(tenant_id, file_size_bytes): # ... 业务逻辑 ... report_usage(tenant_id, 'storage_bytes', file_size_bytes)

这段代码说明了一个关键点：用量指标要产线级埋点，不能靠事后查日志。CloudWatch Metrics 保留 15 个月，支持按维度聚合和告警。Namespace='SaaS/Usage'是自定义命名空间，避免污染 AWS 内置指标。put_metric_data每次调用可以批量上报多条，生产环境建议在内存里做聚合，每 30 秒批量同步一次，减少 API 调用成本。

4.2 按量计费的常见坑：高峰时段、最小计费单位、退款

按量计费最怕的是“用量尖峰导致费用暴涨”。用户可能在某天突然导入大量数据，或者某个 API 被脚本循环调用，账单直接失控。

我的做法是在用量统计层加两个机制：软限制和硬限制。软限制是设置用量阈值，接近阈值时发告警通知租户管理员；硬限制是直接阻断超额请求。这两个限制应该在 API Gateway 层实现，而不是在业务代码里做判断——因为业务代码可能被绕过，API Gateway 是唯一入口。

对于 API 调用量的限制，AWS 的 API Gateway 本身就支持按 API Key 做 Usage Plan：

# 创建 API Key 并关联 Usage Plan # 用 AWS CLI 完成租户配额管理 # 1. 创建 API Key（每个租户一个） aws apigateway create-api-key \ --name "tenant_t_001_key" \ --enabled \ --value "optional-custom-key-value" # 2. 创建 Usage Plan（定义限流和配额） aws apigateway create-usage-plan \ --name "tier_basic_plan" \ --description "Basic tier: 1000 req/day, 5 rps" \ --quota limit=1000,period=DAY \ --throttle burstLimit=10,rateLimit=5 # 3. 将 API Key 关联到 Usage Plan aws apigateway create-usage-plan-key \ --usage-plan-id "plan_id" \ --key-type "API_KEY" \ --key-id "api_key_id" # 4. 将 API 阶段关联到 Usage Plan aws apigateway update-usage-plan \ --usage-plan-id "plan_id" \ --patch-operations op=add,path=/apiStages,value="api_id:stage_name"

参数说明：--quota limit=1000,period=DAY表示每天最多 1000 次请求，超限后 API Gateway 直接返回429 Too Many Requests，不会真正打到后端。--throttle burstLimit=10,rateLimit=5表示每秒最多 5 个稳定请求，允许 10 个突发请求。这样即使某个租户的客户端有 bug 在疯狂重试，平台侧不至于被拖垮。

4.3 共享基础设施的成本摊分：定一个租户“单价”模型

共享资源（ECS 集群、RDS 实例、S3 桶）无法直接按标签归属到租户，必须做摊分。我见过最荒唐的摊分方式是按租户数量均摊——大客户和小客户付一样钱，小客户永远觉得亏。比较合理的做法是引入“租户加权用量”模型：

单租户成本 = 共享资源总成本 × (该租户加权用量 / 所有租户加权用量之和)

加权用量由应用层埋点数据算出，常用的权重因子包括：API 调用次数、存储量、数据传输量、Lambda 执行时长。每个因子分配一个权重系数，这个系数要根据实际成本结构定期调整。比如存储贵就调高存储权重，计算贵就调高执行时长权重，让摊分结果尽量贴近真实消耗。

5. 控制面扩展与高级技巧：多区域、离线迁移、灰度发布

5.1 控制面的多区域部署策略

SaaS 平台的“控制面”和“数据面”在部署上应该有完全不同的策略。控制面（租户注册、配置下发、计费采集）对延迟不敏感，但对一致性和可用性要求高，部署在单一主区域，通过 RDS 跨区域只读副本实现灾备就够了。数据面则按租户归属部署在离客户最近的区域，降低延迟。

多区域数据面的关键设计是“区域选址表”。在控制面的租户元数据表中，要增加region字段，每个租户绑定一个主区域和一个灾备区域。请求路由时，应用先查租户元数据拿到主区域，再调用该区域的数据面服务。这里对延迟敏感，路由表必须缓存，推荐用 ElastiCache Redis 加 TTL 5 分钟，缓存未命中才回源查 DynamoDB。

# 租户请求路由：先查缓存，再查元数据，失败时切换灾备区域 import boto3 import redis CACHE_PREFIX = "tenant_route:" redis_client = redis.Redis( host='saas-route-cache.redis.cache.amazonaws.com', port=6379, decode_responses=True ) def get_tenant_region(tenant_id): cache_key = f"{CACHE_PREFIX}{tenant_id}" # 先查缓存 region = redis_client.get(cache_key) if region: return region # 缓存未命中，查 DynamoDB 租户元数据 dynamodb = boto3.resource('dynamodb') table = dynamodb.Table('saas_tenant_metadata') resp = table.get_item(Key={'tenant_id': tenant_id}) metadata = resp.get('Item', {}) primary_region = metadata.get('primary_region', 'ap-northeast-1') standby_region = metadata.get('standby_region', 'ap-southeast-1') # 如果主区域被标记为不健康，自动切到灾备 if check_region_health(primary_region) is False: region = standby_region else: region = primary_region # 写缓存并设置过期时间 redis_client.setex(cache_key, 300, region) return region

check_region_health这个函数要监控主区域数据面的可用性，我一般用 Route 53 Health Check 加 CloudWatch Alarm 组合实现——每 30 秒发出一次健康检查请求，如果连续 3 次失败则视为区域不健康，触发自动切换。这里的缓存 5 分钟过期，意味着最坏情况下，从区域故障到路由全部切到灾备需要 5 分钟，业务侧要有重试机制兜底。

5.2 租户数据迁移：从池化到隔离的平滑演进

SaaS 平台最经典的演进路径是：前期全部池化省钱，后期大客户要求独立部署。你需要一套“租户数据迁移工具”，把指定租户的数据从共享库搬到独立库，过程中不停止业务。

DynamoDB 的迁移方案：用 AWS Glue 或 Data Pipeline 读取源表，按tenant_id过滤，写入目标表。但需要注意：Glue 默认的 ETL 任务是全量扫描，大表上跑全量扫描成本很高。更高效的做法是用 DynamoDB Streams 做持续复制——先做全量导出，再追平增量数据。

# DynamoDB 全量导出到 S3，然后用 Athena 过滤后导入目标表 # 这套流程可以做成 Step Functions 状态机，按租户粒度触发 # 1. 导出整个 DynamoDB 表到 S3（AWS 原生支持，无额外服务费） aws dynamodb export-table-to-point-in-time \ --table-arn arn:aws:dynamodb:ap-northeast-1:123456789012:table/saas_shared \ --s3-bucket saas-migration-bucket \ --s3-prefix exports/tenant_t_001/ \ --export-format DYNAMODB_JSON \ --s3-sse-algorithm AES256 # 2. 在 Athena 中查询并过滤目标租户数据 # 假设导出后的表结构为：Item 列包含整个租户的 JSON 数据 SELECT item FROM "saas_migration"."exports" WHERE item.tenant_id = 't_001' LIMIT 100;

说明：export-table-to-point-in-time是 DynamoDB 原生的导出功能，不消耗读取容量单位，对线上业务没有性能影响。导出格式DYNAMODB_JSON是专门的 JSON 结构，和标准 JSON 不兼容，Athena 建表时要用map<string, string>或直接查询原始文本。增量追平部分，需要开启 DynamoDB Streams 的NEW_AND_OLD_IMAGES，将增量数据写入 SQS 队列，由迁移消费者同步到目标表。迁移完成后，将租户元数据表中的数据面类型从pool改为silo，下一个请求就会路由到新的独立数据面。

5.3 灰度发布与租户级回滚

SaaS 应用的发布策略不能是“全局一次发布”，而应该按租户灰度。最实用的方案是：基于租户 ID 哈希的灰度规则。把租户 ID 的散列值映射到 0-99，灰度 10% 就是散列值 0-9 的租户先升级。

# 租户级灰度路由：按租户 ID 哈希值决定走哪个版本 import hashlib # 服务发现中维护两个版本的终端地址 VERSION_MAP = { 'v1': 'service-v1.internal:8080', 'v2': 'service-v2.internal:8080' } def route_by_tenant(tenant_id, gray_percent=10): """ 根据租户 ID 哈希值决定路由到哪个版本 gray_percent 控制灰度比例，0 到 100 """ # MD5 哈希后取整数值，分布比直接取模均匀 hash_val = int(hashlib.md5(tenant_id.encode()).hexdigest()[:8], 16) bucket = hash_val % 100 if bucket < gray_percent: return VERSION_MAP['v2'] # 灰度版本 return VERSION_MAP['v1'] # 稳定版本

灰度发布的关键参数是“灰度比例”和“回滚开关”。灰度比例可以放在 Systems Manager Parameter Store 里，发布过程中动态调整，不需要重新部署代码。回滚也简单——把灰度比例调回 0，新版本就停止接收流量。这里的VERSION_MAP我用的是 ECS Service Discovery 的命名空间地址，每次部署新版本会创建新的服务发现记录，无需改动路由代码。

最后说一个容易踩的坑：灰度期间的数据兼容性。v2 版本如果改了数据库 Schema（比如新增了字段），v1 版本的查询可能会失败。所以灰度发布之前，必须保证数据库变更向后兼容——只加字段不删字段，或者用双写方案。SaaS 平台一旦租户数量上来，不可能做到所有租户同时升级，数据层的向前兼容是硬约束，必须写进发布检查单。

除了灰度，另外一个容易被忽略但很重要的点是租户配置的“按版本生效”机制。灰度发布时，新版本代码可能读取到旧的租户配置导致运行异常。我一般会把租户配置连同版本号一起存入元数据表，请求进入后先取当前租户的配置版本号，与当前服务版本比对，不一致时走兼容逻辑或返回明确错误。这样即使灰度中途出现配置不匹配，也能快速定位是配置问题还是代码问题，不用整个回滚。

本文还有配套的精品资源，点击获取