一、立项原因
软件厂商和系统集成商把同一套业务系统卖给多个客户时，早期普遍是一个客户部署一套：几十套环境要分别升级、备份、排障，版本逐渐分叉，运维成本随客户数量线性上涨。改成多租户后，如果只在业务表加 tenant_id 而不做强制隔离，一条漏写 where 条件的 SQL 就会串数据，客户看到别家的订单和成员，属于最严重的一类事故。另外销售卖套餐、财务开票、客户经理续费各用各的 Excel，续费到期经常漏跟。
二、行业场景与业务背景
目标客户是 SaaS 厂商、软件外包与系统集成公司，以及有多门店、多组织的连锁品牌。典型业务是一套系统服务 N 个客户（租户）：每个租户有自己的组织架构、成员、角色与业务数据，平台方需要统一开通、统一配置套餐与配额、统一计费开票、统一看用量与续费。核心诉求只有三件事：数据绝不能串、开通和续费不能靠人肉、每个租户的用量和成本要算得清。
系统分为六个模块。
一、租户全生命周期。支持开通、试用转正、续费、停用、注销全流程；每个租户独立配置套餐、席位与资源配额、独立访问域名和品牌信息；停止服务时按策略冻结数据并保留 90 天。
二、多租户数据隔离。默认共享库加 tenant_id 行级隔离，叠加 PostgreSQL 行级安全策略（RLS）做兜底；对合规要求高的客户可切换为独立 schema 或独立数据库，业务代码无需改动。
三、成员与权限。多级组织架构与部门、成员邀请与批量导入、RBAC 角色与权限矩阵、数据范围（全部/指定部门/仅本人）、敏感字段脱敏、单点登录 SSO 与登录安全策略。
四、订阅与计费。按席位或用量计费，套餐升降级、账单生成、发票开具、续费提醒与试用转正跟进；账单与对账差异自动告警。
五、开放能力。OpenAPI 与 Webhook、API Key 管理、租户级配额与限流，超限自动降级并通知客户经理。
六、运营看板与审计。MRR、活跃租户、席位、用量 Top 榜、待处理事项；所有管理操作写入审计日志，可按租户、操作人、时间检索。
一、我的职责
主要开发者，负责平台从 0 到 1：多租户架构选型、库表设计、租户隔离与权限引擎、计费任务、运营看板、前端管理台、部署上线。
二、技术栈与架构
后端 Python 3.11 + FastAPI，SQLAlchemy 2.0 + Alembic 管理迁移，PostgreSQL 16 存租户数据，Redis 承担缓存、配额计数与 Celery 队列，认证使用 JWT + OAuth2。中间件从 JWT 与域名解析租户标识，注入上下文并绑定数据库会话，开事务时执行 SET LOCAL app.tenant_id，RLS 策略自动过滤其他租户数据；接口层用权限装饰器按 resource:action 校验，与前端菜单、路由共用同一份权限点定义。前端 Vue 3 + TypeScript + Element Plus，菜单按钮由权限点渲染。Docker Compose 编排全部服务，一条命令部署。
三、实现亮点
1. 双层隔离：业务层 tenant_id 条件加 RLS 兜底，漏写条件也查不到别家数据；平台侧用独立 BYPASSRLS 角色访问全量数据。
2. 租户上下文不串号：会话按请求创建、归还连接前重置，并发压测覆盖复用场景。
3. 配额与限流：Redis 滑动窗口按租户计数，超限自动降级并推送提醒。
4. 账单幂等：账期加租户做唯一键，配合状态机与重试，对账差异自动告警。
四、难点与解决
大租户分页慢，改为 (tenant_id, created_at) 复合索引加游标分页；多租户迁移用 Alembic 统一执行后灰度；平台与租户双视角用两套数据库角色和接口前缀区分。上线后支撑 128 个租户、1.8 万席位，租户开通从 2 天缩短到 10 分钟。
五、交付
迁移脚本、接口文档与部署手册，支持两种部署方式。
评论