📚 课程目录第2章 PostgreSQL云化架构选型

2. PostgreSQL云化架构选型

PostgreSQL 上云并不是“把数据库装到云主机上”这么简单。同一套 PostgreSQL 内核，在不同云化模式下，运维边界、弹性能力、故障恢复责任和成本结构差异极大。选型时真正要回答的问题是：哪些能力由云平台提供，哪些能力仍由 DBA 团队自己承担。本节围绕 IaaS、PaaS、DBaaS、Kubernetes Operator 四种主流模式展开对比，并给出可落地的判断依据。

四种模式的本质差异

IaaS 自建模式：在云主机（如 8 vCPU / 32 GB / ESSD 云盘）上自行安装 PostgreSQL。云厂商只保证虚拟机、网络、块存储的可用性，数据库的安装、参数调优、备份、主从复制、版本升级全部由自己负责。它的优势是控制力最强，可以使用任意扩展、任意内核参数、任意文件布局；代价是运维成本高，高可用需要自己用 Patroni、repmgr 或流复制加 VIP 搭建。

PaaS 托管实例模式：云厂商提供“数据库实例”这一抽象，用户拿到连接串即可使用，底层主备、备份、监控由平台完成。用户仍可调整部分参数、创建扩展、管理账号与库。它适合希望减少运维投入、但仍需要一定数据库控制权的团队。

DBaaS 全托管模式：进一步屏蔽底层，用户只面对数据库、账号、连接和少量白名单配置，备份、扩缩容、故障切换、小版本升级全部自动化。控制粒度最粗，但运维负担最低，适合业务团队直接消费数据库能力。

Kubernetes Operator 模式：在 K8s 集群中以 CRD（自定义资源）声明式管理 PostgreSQL，例如 CloudNativePG、Zalando Operator、Crunchy Operator。Operator 通过控制器循环持续把“期望状态”收敛为“实际状态”，自动完成主备编排、故障切换、备份调度和副本扩缩。它兼具声明式交付与较强控制力，但要求团队具备 K8s 与存储、网络的基础能力。

关键选型维度与判断依据

把四种模式放在同一张表里比较，能更清楚地看到取舍。下表以“中等规模在线业务（约 500 GB 数据、峰值 3000 TPS、要求 RPO≈0、RTO≤60 秒）”为示例场景，参数为合理假设，用于说明判断逻辑而非实测结论。

维度	IaaS 自建	PaaS 托管实例	DBaaS 全托管	K8s Operator
高可用实现	Patroni/流复制自建	平台内置主备	平台自动切换	Operator 自动编排
备份与 PITR	pgBackRest 自管	平台备份+可配保留	自动备份，保留可调	CR 声明备份策略
弹性扩缩	换虚机规格，需停机或迁移	规格内在线升配	一键扩缩，分钟级	改 CR 副本数/资源
参数与扩展	完全自由	部分参数可调	受限	较自由，受镜像约束
版本升级	自行规划	平台窗口升级	自动小版本升级	改镜像版本滚动升级
运维人力	高	中	低	中（需 K8s 能力）
典型适用	特殊定制、合规隔离	常规业务系统	快速交付、中小业务	云原生、多集群统一交付

Operator 模式的实际工作方式

Operator 的核心是“声明期望状态，控制器持续收敛”。以 CloudNativePG 为例，用户提交一个 Cluster 资源，声明实例数、存储、备份目标，Operator 就会创建主库与副本、配置流复制、注册备份任务。下面是一个示例片段，参数为教学示例：

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: pg-prod
spec:
  instances: 3
  storage:
    size: 500Gi
    storageClass: fast-ssd
  postgresql:
    parameters:
      max_connections: "500"
      shared_buffers: "8GB"
  backup:
    barmanObjectStore:
      destinationPath: s3://pg-backup/prod
      retentionPolicy: "30d"

提交后可用 kubectl get cluster pg-prod 观察状态，正常时 STATUS 为 Cluster in healthy state，INSTANCES 显示 3。若某个副本 Pod 被驱逐，Operator 会重新调度并重建副本，使实例数回到 3。判断是否收敛成功，关键看三处：实例数是否等于声明值、主库标识是否唯一、备份任务是否按 retentionPolicy 生成。若长时间停留在 Setting up primary，通常要检查存储类是否可动态供给、网络策略是否放通 5432 与 8008 端口。

选型时先明确“谁负责 RTO/RPO”。如果团队没有 7×24 DBA 值班，却要求 RTO≤60 秒，IaaS 自建往往不现实；反之，如果业务依赖自定义 C 扩展或特殊内核参数，DBaaS 可能直接不支持，此时 PaaS 或 Operator 更合适。

按场景给出选型建议

强合规、需深度定制、已有 DBA 团队：选 IaaS 自建，用 Patroni + pgBackRest + 监控体系自建高可用，接受较高运维投入。
常规在线业务、希望减少运维但保留调参空间：选 PaaS 托管实例，把主备与备份交给平台，自己专注库表设计与 SQL 优化。
中小业务、快速上线、无专职 DBA：选 DBaaS 全托管，用连接串直接消费数据库能力，接受参数与扩展的限制。
已全面容器化、多集群统一交付、需要声明式管理：选 Kubernetes Operator，用 CRD 管理 PostgreSQL 生命周期，但必须先具备 K8s、存储类和网络策略的运维能力。

混合部署中常见误区：把 Operator 当成“零运维”。Operator 自动化的是编排动作，不替代容量规划、慢查询治理和备份恢复演练。无论选哪种模式，恢复演练都必须真实执行一次，确认 RTO 与 RPO 达标，而不是只看控制台显示“备份成功”。

选型的落点可以归纳为一句话：控制力越强，责任越重；托管越深，约束越多。先确定业务对 RTO/RPO、扩展能力、参数自由度和交付速度的硬性要求，再对照上表的责任归属，就能在 IaaS、PaaS、DBaaS 与 Operator 之间做出可解释、可复盘的决策。