2. 核心需求分析：多租户隔离、资源弹性伸缩、高可用与容灾、安全合规
好，咱们进入正题。做PaaS平台的数据库服务化，说白了就是要把数据库当成水电煤一样供给业务方。但这事儿没那么简单。我这些年踩过的坑，总结下来就四个核心需求：多租户隔离、资源弹性伸缩、高可用与容灾、安全合规。这四个点，少一个，平台就立不住。
2.1 多租户隔离：别让一个“坏邻居”拖垮所有人
多租户隔离，是我在项目中遇到最多问题的环节。你想想看，一个PaaS平台上跑着几十上百个业务线，每个业务线都觉得自己是VIP。如果隔离没做好，一个租户的慢查询就能把整个数据库节点的CPU打满，其他租户全跟着遭殃。
核心原则：“一个租户的故障，不应该影响其他租户的正常使用。”
我个人习惯把隔离分为三个层次：
- 资源隔离：CPU、内存、磁盘IO、网络带宽。每个租户的资源配额要硬性限制。
- 数据隔离：租户之间的数据绝对不能串。常见方案有独立数据库、独立Schema、共享表加租户ID。
- 性能隔离：通过连接池、限流、熔断等手段，防止某个租户的突发流量影响全局。
举个例子，我在做某金融云PaaS时，遇到过一个大租户半夜跑数据清洗任务，直接把IO打满了。其他小租户的TPS从2000掉到了200。后来我们引入了cgroup + IO限流，每个租户的IOPS上限写死。嗯，从那以后，再也没出现过“坏邻居”事件。
避坑指南：我曾经以为共享表加租户ID就够了，结果某个租户的慢查询导致全表锁，所有租户都超时。后来我强制要求：所有租户表必须带租户ID索引，且查询必须强制走该索引。
2.2 资源弹性伸缩：扛得住双11，也省得了日常
弹性伸缩，说白了就是“用多少给多少，不用就回收”。但数据库的弹性伸缩比应用难得多。应用可以随便加Pod，数据库不行——数据是有状态的。
我建议从两个维度来设计：
- 垂直伸缩：升级CPU、内存、磁盘。适合中小规模场景，操作简单，但需要重启。
- 水平伸缩：增加只读节点、分库分表。适合大规模场景，但架构复杂。
这里我分享一个实战经验。我们当时做的是基于Kubernetes的数据库Operator，通过自定义资源（CRD）来管理数据库实例。当监控指标（比如CPU使用率超过80%）触发时，自动触发扩容流程：
# 伪代码：弹性伸缩策略
if cpu_usage > 80% for 5 minutes:
if current_replicas < max_replicas:
scale_up(current_replicas + 1)
notify_owner("实例已自动扩容")
elif cpu_usage < 30% for 30 minutes:
if current_replicas > min_replicas:
scale_down(current_replicas - 1)
notify_owner("实例已自动缩容")为什么会这样设计？因为数据库的扩容不能太激进。你想想看，扩容后数据同步需要时间，如果频繁扩缩，反而会引发抖动。所以我设了一个冷却期：每次扩缩后，至少等待15分钟才能再次触发。
注意：自动缩容一定要谨慎。我曾经因为缩容太快，导致一个只读节点上的慢查询还没跑完就被干掉了，业务方数据对不上。后来我加了连接数检查：如果当前活跃连接数大于0，禁止缩容。
2.3 高可用与容灾：别让单点故障毁了你的周末
高可用，是PaaS平台的底线。我见过太多因为数据库挂了导致整个业务线瘫痪的案例。高可用不是“挂了能恢复”，而是“挂了用户无感知”。
我一般把高可用分为三个层级：
| 层级 | 方案 | RTO | RPO | 适用场景 |
|---|---|---|---|---|
| L1 | 主从切换（半同步复制） | < 30秒 | < 1秒 | 同机房，一般业务 |
| L2 | 跨机房主从 + 自动切换 | < 60秒 | < 5秒 | 同城双活，核心业务 |
| L3 | 异地多活 + 数据同步 | < 120秒 | < 30秒 | 异地容灾，金融级 |
我个人习惯用半同步复制作为默认方案。为什么？因为异步复制丢数据，全同步复制太慢。半同步保证至少有一个从库收到了binlog，主库才提交。这样既保证了性能，又保证了数据安全。
我记得有一次，某机房光纤被挖断了。我们的L2方案自动触发，30秒内完成了主从切换。业务方甚至没察觉到异常。嗯，那一刻我觉得之前的加班都值了。
避坑指南：我曾经以为有了自动切换就万事大吉，结果忽略了切换后的数据一致性校验。有一次切换后，主库和从库的某张表差了3条记录。后来我强制要求：每次切换后，自动运行一次pt-table-checksum，并发送报告给DBA。
2.4 安全合规：别让数据泄露毁了你的职业生涯
安全合规，是PaaS平台的底线中的底线。数据泄露不是小事，轻则罚款，重则坐牢。我见过太多公司因为安全没做好，被监管部门罚得倾家荡产。
我建议从以下四个方面入手：
- 网络安全：VPC隔离、安全组、白名单。数据库绝对不能暴露在公网。
- 访问控制：基于角色的权限管理（RBAC）。每个租户只能看到自己的数据库。
- 数据加密：传输层用TLS，存储层用透明数据加密（TDE）。
- 审计日志：记录所有SQL操作，谁在什么时间做了什么，一目了然。
这里我重点说一下审计日志。很多公司觉得审计日志没用，占磁盘又慢。但真出了事，审计日志就是你唯一的救命稻草。我曾经帮一个客户排查数据泄露事件，就是靠审计日志找到了那个半夜偷偷导出数据的内部员工。
核心原则：“安全不是功能，而是基础设施。它不应该成为业务的瓶颈，但必须成为业务的底线。”
另外，合规性也很重要。比如金融行业要求数据必须存储在境内，医疗行业要求数据脱敏。PaaS平台需要提供数据脱敏和数据销毁的能力。我建议在创建数据库实例时，就让用户选择合规等级，平台自动应用对应的安全策略。
注意：数据销毁不是简单的DELETE。我曾经见过一个案例，某公司删除了数据库，但磁盘没有覆写，结果被恢复工具把数据全读出来了。正确的做法是：先删除数据，再对磁盘进行全量覆写（比如写0或随机数），最后销毁磁盘。
好了，核心需求分析就讲到这里。这四个点，多租户隔离是基础，弹性伸缩是能力，高可用是保障，安全合规是底线。下一章，我会讲如何把这些需求落地到架构设计中。咱们到时候见。