拓冰网站定制 
简介《云计算PaaS平台总体设计说明书》是一份面向云计算架构师、平台开发者和运维人员的系统性设计文档聚焦互联网环境下PaaS平台的功能架构、开发运行环境与部署策略帮助读者理解从平台管理层、服务管理层到应用、数据、网络管理层的分层设计逻辑。资源包内仅含1个PDF文件压缩包大小2.87MB内容按目录化章节编排既解释了PaaS/IaaS/SaaS术语也覆盖了总体结构、子系统逻辑图、生产/开发测试平台物理部署架构及灾备部署方案。文档同时详述了开发环境中的CI/CD工具链、运行环境中的监控日志安全防护以及平台运行时、控制台、租户管理等关键子系统的交互关系可为方案设计、技术选型和高可用架构规划提供直接参考。目前已有229人学习下载适合云平台建设团队研读或作为相关课程的项目参考。1. 云计算 PaaS 平台总体设计说明书.pdf它不是文档是架构的契约一份《云计算 PaaS 平台总体设计说明书.pdf》被提上日程时很多团队把它当成「评审完就归档」的文档。我的看法相反这份 PDF 是全项目里唯一能约束后面几个月不跑偏的文件。它要回答的从来不是「用什么开源组件」而是「平台和租户的边界在哪、控制面和数据面怎么切、容量按什么假设算、故障影响范围多大」。读完这篇你能照着把这份说明书拆出目录、填上选型和参数并在评审前用一张问题清单自查。适合正在写或者要评审这份文档的架构师和技术负责人新手也能按章节顺序一步步补齐内容。2. 从目录到章节职责一份 PaaS 总设说明书到底该管到哪一层2.1 先定边界再谈组件PaaS 与 IaaS、业务应用的分界线我评审过不少 PaaS 设计文档头三页都在讲组件选型第四页开始画架构图唯独不写边界。边界不清楚后面每个模块都能找理由往自己这边捞职责最后平台变成「什么都做、什么都慢」的黑匣子。所以在总设说明书里第一时间要画的不是架构图而是三根边界线。第一根是 PaaS 和 IaaS 的线虚拟机、网络、存储、可用区属于底座直接调用云厂商能力即可容器编排、服务目录、中间件交付、应用生命周期管理属于 PaaS。第二根是平台和租户的线平台负责运行时和治理租户负责自己的业务应用和配置这根线直接决定权限模型和故障责任。第三根是控制面和数据面的线控制面管调度、认证、观测数据面管实际跑业务负载的节点和中间件集群。这三根线全部要落到一张职责矩阵里接入层、平台层、数据层、基础设施层分别有什么组件谁负责维护、谁负责审批、谁负责观测。这块写清楚之后后续的组件选型、配额限值、SLO 拆分才有依据否则整份说明书就是一堆名词堆叠。2.2 目录骨架一张表九个章节对应九个要回答的问题总设说明书的目录不是越全越好而是每一章都要能回答一个具体问题。我一般按九个章节组织中小规模平台压缩到五页以内没问题集群规模大就写到二三十页但骨架不变。章节要回答的问题常见错误背景与目标为什么建 PaaS服务谁目标是什么写成口号没有量化目标现状与约束现有资源、团队技能、离线或合规约束不提约束导致选型脱离环境总体架构与分层边界怎么划组件之间什么关系只有大图没有职责线关键技术选型与决策K8s、中间件、观测体系怎么选只写结论不写备选和被否理由数据与接口设计服务目录、API 契约、租户接入流程接口写到一半状态码和错误码缺失部署架构与资源规划Region/可用区、节点池、容量推算只写当前规模不写增长模型安全与多租户设计身份、隔离、密钥、审计怎么落地用 Namespace 一笔带过可观测性与 SLO监控指标、日志、告警、可用性目标堆指标列表没有对应 SLI版本演进与升级策略发版节奏、灰度、回滚方案完全没有升级方案这个目录里最容易漏掉的是「版本演进与升级策略」。PaaS 平台一旦跑起来就不能随便停租户业务在上面升级 K8s 版本或者中间件版本必须写清楚灰度方式和回滚触发条件。没有这一章运维阶段每一次升级都是一场赌博。2.3 三层写多深才算合格基础设施一页说清编排层写透应用层给契约写总设说明书最怕两种极端像 PPT 一样只有图或者像详细设计一样塞一堆部署命令。我给团队定的深度标准是总体设计管到「接口、参数、阈值、策略」为止内部实现一律交给详细设计文档。这个切分能让总设说明书保持可评审不被实现细节淹没。基础设施层一到两页就够了引用云厂商的服务清单写明用了哪些可用区、网络模型选 VPC 还是扁平网络、账号体系怎么对接不要重复设计 IaaS。容器编排层是整份说明书的核心要写透。写透不等于代码量大而是把 K8s 版本基线、网络插件、Ingress 方案、HPA 参数、PodDisruptionBudget、Namespace 规划、资源预留百分比全部明确写出来。这些参数缺一个实施阶段就会有人拍脑袋定一个评审时又吵一轮。应用服务层给的是「服务目录」和接口契约。比如数据库 PaaS 化交付租户申请时能拿到什么规格、SLA 是多少、备份策略是什么、扩容怎么操作。每一项服务必须有负责人和 SLA否则运维阶段找不到人为故障买单。各层深度在说明书里用一段话写清楚「本章节只定义接口与策略详细设计另立文档」评审人就不会拿实现细节来纠缠你。3. 控制面与数据面分离PaaS 技术选型的四个硬约束3.1 四维选型过滤先淘汰会拖垮交付的组件PaaS 平台选型最常犯的错误是「按 GitHub star 数排序选型」。star 高说明有人用但不代表适合你的交付场景。我一般用四个维度做过滤任何一个维度不通过就直接淘汰不再往下比功能。第一个维度是社区活跃度与治理发版频率、issue 响应速度、是否有基金会或大厂背书。第二个维度是许可证Apache 2.0 和 MIT 风险低SSPL 这类对商业场景有限制的许可证要法务确认才能引入。第三个维度是运维复杂度和团队技能树每引一个组件就意味着值班团队多一份排障负担说明书里要算「每个组件对应的运维成本」。第四个维度是生态兼容性在当前 K8s 版本下能不能跑、能不能离线部署、能不能和企业现有监控系统打通。私有化交付的项目第四条往往一票否决。维度要问的问题一票否决条件社区活跃度发版频率、issue 响应、治理结构超过一年不发布issue 无人回复许可证是否允许商业闭源使用SSPL 等限制性许可证未获法务确认运维复杂度安装、升级、排障成本需要 3 人以上专职维护且团队不具备生态兼容是否兼容当前 K8s 版本、可离线部署不支持离线安装或与现有版本冲突过滤之后的每个组件要在说明书里给一段「决策依据」背景、候选方案、最终结论、不选理由。这段文字写得越短说明当初想得越清楚。我见过有人把候选方案写了两页结论就一句话评审时被追问「为什么不选另一个」当场答不上来这就是决策依据没想透。3.2 控制面组件分工API Server、调度、认证与观测如何落位控制面的职责是「接入、鉴权、调度、观测」。常见基线是 K8s 作为控制面底座认证接 OIDC 对齐企业现有账号体系租户之间通过 RBAC 隔离观测栈用 Prometheus 加 Grafana。这套组合不需要重新发明轮子重点是说明书里要把分工写清楚。API Server 是唯一入口所有对平台的访问都走它不能绕过。调度器决定 Pod 放到哪个节点策略参数如调度失败重试次数、节点亲和性要写明。认证鉴权按租户建角色和绑定关系集群管理员权限只留给平台运维组。观测方面除了 Prometheus 指标审计日志必须开启并保留 180 天给后面的云计算运维工程师留排查入口各组件的 metrics 端点、日志路径在说明书附录里列全。控制面要特别注意「不要塞太多插件」。每加一个插件就是排障时的一个额外变量。说明书里单列一张「控制面组件清单」组件、版本基线、存活要求、故障影响范围。例如 etcd 挂了影响整个集群必须单独强调存储性能和备份策略而某个监控 exporter 挂了只影响观测不影响业务两者故障级别完全不同。3.3 数据面组件决策中间件服务化与有状态服务的两条路线数据面是 PaaS 平台和纯容器平台最大的分水岭。纯容器平台只跑无状态应用PaaS 平台要交付数据库、缓存、消息队列给租户。中间件服务化有两条路线对接云厂商现成的中间件服务或者引入中间件 Operator 自建交付平台。绝大多数团队选前者最优只有在私有化交付、不能依赖云厂商服务的场景下才需要走 Operator 路线。说明书写中间件服务化时要明确一个原则交付给租户的是「服务」而不是「Pod」。租户只看到连接串、控制台和 SLA不应该看到 K8s 底层的 Deployment 和 StatefulSet。运维团队要对每个中间件掌握备份、扩容、故障切换方案这些方案统统写进说明书不能等故障了再现场查。中间件类型容器化部署风险说明书至少写明的参数数据库数据丢失、性能抖动、备份复杂备份频率、RPO、RTO、存储类型缓存持久化策略不清重启丢数据持久化开关、内存上限、淘汰策略消息队列堆积后磁盘打满消费滞后堆积告警阈值、单分区吞吐上限对象存储容量规划不足访问密钥泄露桶策略、生命周期规则、容量冗余数据面组件在说明书里要给出明确的 SLA 和故障切换流程。数据库服务化交付时RPO 和 RTO 是租户最关心的两个数写不清楚租户不敢把核心业务放上来。缓存和消息队列虽然可以容忍少量数据丢失但「丢多少、什么时候丢」必须提前写明白。4. 把「支撑多少应用」换算成 CPU、内存和存储容量规划的三张表4.1 从 QPS 反推副本数与节点池规模一个可复现的估算流程容量规划是总设说明书里最容易被「估个数」糊弄过去的章节。我见过某项目写「按未来三年业务增长预留 30%」没有任何计算过程也没有业务假设到了压测阶段才发现节点数完全不够。容量章节的核心不是把数算对而是把假设写清楚让任何人在业务量变化时能重算。估算流程分四步。第一步定业务假设未来支撑多少个应用、峰值 QPS、单请求平均耗时、目标资源利用率。第二步算单副本容量单副本每秒处理的请求数等于 1000 除以平均耗时毫秒再乘以 0.4。这个 0.4 是给 CPU 争抢、垃圾回收、网络抖动预留的系数直接按理论值算必翻车。第三步算副本数峰值 QPS 除以单副本容量乘以 1.3 的冗余系数。第四步算节点数副本数乘以单 Pod 的 CPU 请求除以单节点可用 CPU可用 CPU 按物理核数的 80% 计。举例某业务 P99 延迟 50 毫秒峰值 2000 QPS单副本容量约 8 QPS副本数约 325 个Pod CPU 请求 0.5 核64 核节点可用约 52 核约需要 4 到 5 个节点再加 20% 节点冗余。这个例子里数字本身不重要重要的是计算链路完整可复核。租户对预留资源的覆盖度计算也要做成表格每个租户配额、实际用量、预留量覆盖度长期低于 60% 说明配额给得太松需要回收。4.2 租户配额与 Pod 规格基线新租户开通时抄这三组参数多租户 PaaS 平台如果没有统一配额基线新租户开通时就是运维现场拍脑袋。说明书里直接给出一组推荐参数新租户开通照着填就行。配置项推荐值说明ResourceQuota CPU32 核新租户默认上限压测后按需放开ResourceQuota 内存128 GiB与 CPU 配额比例约 1:4ResourceQuota PVC 数20 个防止租户创建过多存储卷ResourceQuota Service 数50 个防止服务发现条目膨胀LimitRange 默认 request0.1 核 / 256 MiB没写资源申请的 Pod 兜底值LimitRange 默认 limit1 核 / 2 GiB防止单个 Pod 无限占用LimitRange 最大 limit8 核 / 16 GiB超大规格必须走审批流程HPA CPU 目标65%低于 60% 容易抖动扩容HPA 缩容冷却时间300 秒避免流量回落时副本数反复横跳配额默认值故意设得偏低是合理的。新租户先按小规格开通压测验证后再逐步放开避免一个租户把平台资源吃满。Pod 规格不开放给租户直接选机型而是通过服务目录里的几档规格等级选择这样成本归属和资源覆盖度都清晰可控。提示配额和 LimitRange 的数值写进说明书正文但具体调整记录放附录表。评审通过后改参数只动附录不动正文避免每次调参都要重新走全量评审。4.3 存储与网络性能预算别只算容量要算 IOPS 和吞吐容量规划最容易漏的是性能维度。存储只算 GB 不算 IOPS上线就会被数据库和 etcd 打脸。说明书里要有一张存储矩阵按用途把存储类型、性能基线、扩容方式定死。存储用途推荐类型性能基线扩容方式etcd本地盘或高 IOPS 云盘800 IOPS 以上跟随控制面节点扩容容器镜像仓库对象存储高吞吐容量弹性按镜像数量自动扩数据库/缓存SSD 云盘单盘 IOPS 随规格调整扩容需评估停机窗口应用日志低频对象存储不追求低延迟按月归档清理网络预算同样要写清楚Ingress 带宽、单节点带宽上限、租户 QoS 标记。常见做法是给每个租户的网络流量打标签超过配额后限速而不是直接拒绝避免单租户流量打满整条链路。说明书里要写明「超限策略」不然线上故障时运维不知道是该限速还是该关停租户实例现场决策永远是最后悔的决策。5. 多租户、安全与高可用总设说明书最容易翻车的五个地方下面五个坑都是我评审或接手 PaaS 项目时实际见过的按现象、原因、解决三段写。不想让评审会变成事故复盘会就提前在说明书里把这些问题补上。5.1 坑一租户隔离只写了 Namespace越权访问一测就翻车现象评审演示时租户 A 的 Pod 直接通过 Service 名访问租户 B 的应用接口安全负责人当场叫停整场评审。原因K8s 的 Namespace 只做资源分组不提供网络隔离和权限隔离。说明书里写「按租户建 Namespace」等于根本没设计隔离只是给资源画了个圈。解决隔离模型必须写三层。账号层用 OIDC 接入企业身份体系RBAC 按租户建角色网络层用 NetworkPolicy 默认拒绝再按白名单放通跨命名空间访问资源层用 ResourceQuota 和 LimitRange 控制用量。说明书最后加一条验收要求跨命名空间访问必须被拒绝并把这条写进租户开通流程的验收项。5.2 坑二SLO 只写平台整体 99.9%数据面一抖动就违约现象上线后存储节点抖动租户数据库响应变慢平台可用性直接低于对外承诺的 99.9%客户拿着合同来找。原因99.9% 是控制面高可用的结果但租户感知的是数据面。数据面涉及存储、中间件、网络任何一个环节出故障都会被租户感知整体一个数根本兜不住。解决把 SLO 拆成三层控制面 99.95%、数据面中间件 99.9%、租户应用不承诺。对照可用性预算99.9% 每年约 8.76 小时不可用99.95% 每年约 26 分钟不可用。拆分后每一层单独告警、单独复盘拆分表直接放说明书「可用性设计」章节。租户合同里签哪个数以拆分后的对应层为准别拿总体一个数签。5.3 坑三HPA 参数没写压测时副本疯涨、收不住现象压测时 Pod 数几分钟内翻了三倍流量回落后两个小时不缩容平台资源被占满其他租户开始受影响。原因CPU 阈值设太低、缩容冷却时间没配HPA 对短时抖动过度敏感。说明书里写「启用 HPA」五个字不写参数等于没写实施的人只能按默认值或自己猜。解决基线参数写进说明书CPU 目标 65% 到 70%内存 70%缩容冷却时间 300 秒到 600 秒单次缩容比例限制在 25%。压测前用这几个参数验证一轮评审时直接把压测报告附在说明书后面当证据比任何文字都管用。5.4 坑四存储只算了大小没算性能IOPS 上线后被打满现象数据库 PaaS 化交付后延迟抖动监控面板 IOPS 长时间满格业务 SQL 全部变慢租户投诉不断。原因容量规划只写了「数据库分配 500GB」没写 IOPS 和吞吐要求。通用云盘和 SSD 混用性能模型完全没区分性能这块全靠玄学。解决存储矩阵按用途区分性能等级etcd 用本地盘或高 IOPS 云盘数据库用 SSD 云盘日志用对象存储。IOPS 估算公式写成预估峰值 QPS 乘以平均每请求 IO 次数再乘 1.5 冗余把结论数值直接写进说明书。采购和选盘时按这个数来别等上线了再补。5.5 坑五镜像安全只做入口扫描运行时的漏洞没人处理现象入口扫描全绿上线三个月后集群扫描报出十几个高危镜像漏洞研发说不是自己的事运维说没有更新流程漏洞挂了两周没人动。原因说明书里写了「CI 接入镜像扫描」但没写运行时扫描和漏洞修复闭环。入口挡住了一部分运行时的漏洞没有归属方。解决镜像安全写成三段策略CI 阶段阻断高危镜像入库仓库扫描每 24 小时一轮运行时扫描每天一轮。修复窗口按严重级别定义高危 48 小时内处理中危 7 天内处理。基础镜像更新由平台团队统一跟进租户业务镜像的漏洞由租户负责这条责任边界写清楚推诿情况会少很多。6. 用一轮挑刺式评审验证总设说明书8 个问题问倒设计团队总设说明书写完不叫完要能扛住一轮挑刺式评审。我习惯把评审做成问题清单设计团队先自评一遍再上评审会避免评审会变成「大家看了一遍都说挺好」。评审问题对应说明书章节合格标准租户 A 能不能访问租户 B 的数据多租户隔离设计默认拒绝有验证记录数据面某个中间件挂掉影响多少租户故障域与爆炸半径受影响范围有明确数字容量按什么业务峰值算的资源规划QPS 来源和冗余系数可复核哪些组件自研哪些直接采用技术选型每个自研项有决策依据SLO 拆分后能被监控验证吗可观测性设计每个 SLI 有指标和告警平台升级会打断租户业务吗版本演进与升级策略有灰度与回滚方案新租户从申请到开通要几步服务目录不超过 5 步集群要迁移哪些组件可以保留解耦设计有标准接口或适配层评审流程我一般这样组织提前三天把问题清单发给各章节负责人要求对应章节的编写人自己先答一遍。评审会上不看 PPT直接对着清单过答案。结论分三个等级通过、有条件通过、不通过。有条件通过必须列出遗留项、负责人和截止日期不能只写一句「后续完善」。我自己评审时有个习惯专门挑一个最冷门的场景比如「某个可用区整体不可用时租户数据库怎么恢复」随机点一个组件负责人回答。答不上来说明这份说明书把愿望清单当设计了需要回去补。这个习惯帮我在不少项目里躲过了上线后的大故障希望帮到你。本文还有配套的精品资源点击获取 云计算PaaS平台总体设计说明书：架构师必看的编写与评审指南
简介《云计算PaaS平台总体设计说明书》是一份面向云计算架构师、平台开发者和运维人员的系统性设计文档聚焦互联网环境下PaaS平台的功能架构、开发运行环境与部署策略帮助读者理解从平台管理层、服务管理层到应用、数据、网络管理层的分层设计逻辑。资源包内仅含1个PDF文件压缩包大小2.87MB内容按目录化章节编排既解释了PaaS/IaaS/SaaS术语也覆盖了总体结构、子系统逻辑图、生产/开发测试平台物理部署架构及灾备部署方案。文档同时详述了开发环境中的CI/CD工具链、运行环境中的监控日志安全防护以及平台运行时、控制台、租户管理等关键子系统的交互关系可为方案设计、技术选型和高可用架构规划提供直接参考。目前已有229人学习下载适合云平台建设团队研读或作为相关课程的项目参考。1. 云计算 PaaS 平台总体设计说明书.pdf它不是文档是架构的契约一份《云计算 PaaS 平台总体设计说明书.pdf》被提上日程时很多团队把它当成「评审完就归档」的文档。我的看法相反这份 PDF 是全项目里唯一能约束后面几个月不跑偏的文件。它要回答的从来不是「用什么开源组件」而是「平台和租户的边界在哪、控制面和数据面怎么切、容量按什么假设算、故障影响范围多大」。读完这篇你能照着把这份说明书拆出目录、填上选型和参数并在评审前用一张问题清单自查。适合正在写或者要评审这份文档的架构师和技术负责人新手也能按章节顺序一步步补齐内容。2. 从目录到章节职责一份 PaaS 总设说明书到底该管到哪一层2.1 先定边界再谈组件PaaS 与 IaaS、业务应用的分界线我评审过不少 PaaS 设计文档头三页都在讲组件选型第四页开始画架构图唯独不写边界。边界不清楚后面每个模块都能找理由往自己这边捞职责最后平台变成「什么都做、什么都慢」的黑匣子。所以在总设说明书里第一时间要画的不是架构图而是三根边界线。第一根是 PaaS 和 IaaS 的线虚拟机、网络、存储、可用区属于底座直接调用云厂商能力即可容器编排、服务目录、中间件交付、应用生命周期管理属于 PaaS。第二根是平台和租户的线平台负责运行时和治理租户负责自己的业务应用和配置这根线直接决定权限模型和故障责任。第三根是控制面和数据面的线控制面管调度、认证、观测数据面管实际跑业务负载的节点和中间件集群。这三根线全部要落到一张职责矩阵里接入层、平台层、数据层、基础设施层分别有什么组件谁负责维护、谁负责审批、谁负责观测。这块写清楚之后后续的组件选型、配额限值、SLO 拆分才有依据否则整份说明书就是一堆名词堆叠。2.2 目录骨架一张表九个章节对应九个要回答的问题总设说明书的目录不是越全越好而是每一章都要能回答一个具体问题。我一般按九个章节组织中小规模平台压缩到五页以内没问题集群规模大就写到二三十页但骨架不变。章节要回答的问题常见错误背景与目标为什么建 PaaS服务谁目标是什么写成口号没有量化目标现状与约束现有资源、团队技能、离线或合规约束不提约束导致选型脱离环境总体架构与分层边界怎么划组件之间什么关系只有大图没有职责线关键技术选型与决策K8s、中间件、观测体系怎么选只写结论不写备选和被否理由数据与接口设计服务目录、API 契约、租户接入流程接口写到一半状态码和错误码缺失部署架构与资源规划Region/可用区、节点池、容量推算只写当前规模不写增长模型安全与多租户设计身份、隔离、密钥、审计怎么落地用 Namespace 一笔带过可观测性与 SLO监控指标、日志、告警、可用性目标堆指标列表没有对应 SLI版本演进与升级策略发版节奏、灰度、回滚方案完全没有升级方案这个目录里最容易漏掉的是「版本演进与升级策略」。PaaS 平台一旦跑起来就不能随便停租户业务在上面升级 K8s 版本或者中间件版本必须写清楚灰度方式和回滚触发条件。没有这一章运维阶段每一次升级都是一场赌博。2.3 三层写多深才算合格基础设施一页说清编排层写透应用层给契约写总设说明书最怕两种极端像 PPT 一样只有图或者像详细设计一样塞一堆部署命令。我给团队定的深度标准是总体设计管到「接口、参数、阈值、策略」为止内部实现一律交给详细设计文档。这个切分能让总设说明书保持可评审不被实现细节淹没。基础设施层一到两页就够了引用云厂商的服务清单写明用了哪些可用区、网络模型选 VPC 还是扁平网络、账号体系怎么对接不要重复设计 IaaS。容器编排层是整份说明书的核心要写透。写透不等于代码量大而是把 K8s 版本基线、网络插件、Ingress 方案、HPA 参数、PodDisruptionBudget、Namespace 规划、资源预留百分比全部明确写出来。这些参数缺一个实施阶段就会有人拍脑袋定一个评审时又吵一轮。应用服务层给的是「服务目录」和接口契约。比如数据库 PaaS 化交付租户申请时能拿到什么规格、SLA 是多少、备份策略是什么、扩容怎么操作。每一项服务必须有负责人和 SLA否则运维阶段找不到人为故障买单。各层深度在说明书里用一段话写清楚「本章节只定义接口与策略详细设计另立文档」评审人就不会拿实现细节来纠缠你。3. 控制面与数据面分离PaaS 技术选型的四个硬约束3.1 四维选型过滤先淘汰会拖垮交付的组件PaaS 平台选型最常犯的错误是「按 GitHub star 数排序选型」。star 高说明有人用但不代表适合你的交付场景。我一般用四个维度做过滤任何一个维度不通过就直接淘汰不再往下比功能。第一个维度是社区活跃度与治理发版频率、issue 响应速度、是否有基金会或大厂背书。第二个维度是许可证Apache 2.0 和 MIT 风险低SSPL 这类对商业场景有限制的许可证要法务确认才能引入。第三个维度是运维复杂度和团队技能树每引一个组件就意味着值班团队多一份排障负担说明书里要算「每个组件对应的运维成本」。第四个维度是生态兼容性在当前 K8s 版本下能不能跑、能不能离线部署、能不能和企业现有监控系统打通。私有化交付的项目第四条往往一票否决。维度要问的问题一票否决条件社区活跃度发版频率、issue 响应、治理结构超过一年不发布issue 无人回复许可证是否允许商业闭源使用SSPL 等限制性许可证未获法务确认运维复杂度安装、升级、排障成本需要 3 人以上专职维护且团队不具备生态兼容是否兼容当前 K8s 版本、可离线部署不支持离线安装或与现有版本冲突过滤之后的每个组件要在说明书里给一段「决策依据」背景、候选方案、最终结论、不选理由。这段文字写得越短说明当初想得越清楚。我见过有人把候选方案写了两页结论就一句话评审时被追问「为什么不选另一个」当场答不上来这就是决策依据没想透。3.2 控制面组件分工API Server、调度、认证与观测如何落位控制面的职责是「接入、鉴权、调度、观测」。常见基线是 K8s 作为控制面底座认证接 OIDC 对齐企业现有账号体系租户之间通过 RBAC 隔离观测栈用 Prometheus 加 Grafana。这套组合不需要重新发明轮子重点是说明书里要把分工写清楚。API Server 是唯一入口所有对平台的访问都走它不能绕过。调度器决定 Pod 放到哪个节点策略参数如调度失败重试次数、节点亲和性要写明。认证鉴权按租户建角色和绑定关系集群管理员权限只留给平台运维组。观测方面除了 Prometheus 指标审计日志必须开启并保留 180 天给后面的云计算运维工程师留排查入口各组件的 metrics 端点、日志路径在说明书附录里列全。控制面要特别注意「不要塞太多插件」。每加一个插件就是排障时的一个额外变量。说明书里单列一张「控制面组件清单」组件、版本基线、存活要求、故障影响范围。例如 etcd 挂了影响整个集群必须单独强调存储性能和备份策略而某个监控 exporter 挂了只影响观测不影响业务两者故障级别完全不同。3.3 数据面组件决策中间件服务化与有状态服务的两条路线数据面是 PaaS 平台和纯容器平台最大的分水岭。纯容器平台只跑无状态应用PaaS 平台要交付数据库、缓存、消息队列给租户。中间件服务化有两条路线对接云厂商现成的中间件服务或者引入中间件 Operator 自建交付平台。绝大多数团队选前者最优只有在私有化交付、不能依赖云厂商服务的场景下才需要走 Operator 路线。说明书写中间件服务化时要明确一个原则交付给租户的是「服务」而不是「Pod」。租户只看到连接串、控制台和 SLA不应该看到 K8s 底层的 Deployment 和 StatefulSet。运维团队要对每个中间件掌握备份、扩容、故障切换方案这些方案统统写进说明书不能等故障了再现场查。中间件类型容器化部署风险说明书至少写明的参数数据库数据丢失、性能抖动、备份复杂备份频率、RPO、RTO、存储类型缓存持久化策略不清重启丢数据持久化开关、内存上限、淘汰策略消息队列堆积后磁盘打满消费滞后堆积告警阈值、单分区吞吐上限对象存储容量规划不足访问密钥泄露桶策略、生命周期规则、容量冗余数据面组件在说明书里要给出明确的 SLA 和故障切换流程。数据库服务化交付时RPO 和 RTO 是租户最关心的两个数写不清楚租户不敢把核心业务放上来。缓存和消息队列虽然可以容忍少量数据丢失但「丢多少、什么时候丢」必须提前写明白。4. 把「支撑多少应用」换算成 CPU、内存和存储容量规划的三张表4.1 从 QPS 反推副本数与节点池规模一个可复现的估算流程容量规划是总设说明书里最容易被「估个数」糊弄过去的章节。我见过某项目写「按未来三年业务增长预留 30%」没有任何计算过程也没有业务假设到了压测阶段才发现节点数完全不够。容量章节的核心不是把数算对而是把假设写清楚让任何人在业务量变化时能重算。估算流程分四步。第一步定业务假设未来支撑多少个应用、峰值 QPS、单请求平均耗时、目标资源利用率。第二步算单副本容量单副本每秒处理的请求数等于 1000 除以平均耗时毫秒再乘以 0.4。这个 0.4 是给 CPU 争抢、垃圾回收、网络抖动预留的系数直接按理论值算必翻车。第三步算副本数峰值 QPS 除以单副本容量乘以 1.3 的冗余系数。第四步算节点数副本数乘以单 Pod 的 CPU 请求除以单节点可用 CPU可用 CPU 按物理核数的 80% 计。举例某业务 P99 延迟 50 毫秒峰值 2000 QPS单副本容量约 8 QPS副本数约 325 个Pod CPU 请求 0.5 核64 核节点可用约 52 核约需要 4 到 5 个节点再加 20% 节点冗余。这个例子里数字本身不重要重要的是计算链路完整可复核。租户对预留资源的覆盖度计算也要做成表格每个租户配额、实际用量、预留量覆盖度长期低于 60% 说明配额给得太松需要回收。4.2 租户配额与 Pod 规格基线新租户开通时抄这三组参数多租户 PaaS 平台如果没有统一配额基线新租户开通时就是运维现场拍脑袋。说明书里直接给出一组推荐参数新租户开通照着填就行。配置项推荐值说明ResourceQuota CPU32 核新租户默认上限压测后按需放开ResourceQuota 内存128 GiB与 CPU 配额比例约 1:4ResourceQuota PVC 数20 个防止租户创建过多存储卷ResourceQuota Service 数50 个防止服务发现条目膨胀LimitRange 默认 request0.1 核 / 256 MiB没写资源申请的 Pod 兜底值LimitRange 默认 limit1 核 / 2 GiB防止单个 Pod 无限占用LimitRange 最大 limit8 核 / 16 GiB超大规格必须走审批流程HPA CPU 目标65%低于 60% 容易抖动扩容HPA 缩容冷却时间300 秒避免流量回落时副本数反复横跳配额默认值故意设得偏低是合理的。新租户先按小规格开通压测验证后再逐步放开避免一个租户把平台资源吃满。Pod 规格不开放给租户直接选机型而是通过服务目录里的几档规格等级选择这样成本归属和资源覆盖度都清晰可控。提示配额和 LimitRange 的数值写进说明书正文但具体调整记录放附录表。评审通过后改参数只动附录不动正文避免每次调参都要重新走全量评审。4.3 存储与网络性能预算别只算容量要算 IOPS 和吞吐容量规划最容易漏的是性能维度。存储只算 GB 不算 IOPS上线就会被数据库和 etcd 打脸。说明书里要有一张存储矩阵按用途把存储类型、性能基线、扩容方式定死。存储用途推荐类型性能基线扩容方式etcd本地盘或高 IOPS 云盘800 IOPS 以上跟随控制面节点扩容容器镜像仓库对象存储高吞吐容量弹性按镜像数量自动扩数据库/缓存SSD 云盘单盘 IOPS 随规格调整扩容需评估停机窗口应用日志低频对象存储不追求低延迟按月归档清理网络预算同样要写清楚Ingress 带宽、单节点带宽上限、租户 QoS 标记。常见做法是给每个租户的网络流量打标签超过配额后限速而不是直接拒绝避免单租户流量打满整条链路。说明书里要写明「超限策略」不然线上故障时运维不知道是该限速还是该关停租户实例现场决策永远是最后悔的决策。5. 多租户、安全与高可用总设说明书最容易翻车的五个地方下面五个坑都是我评审或接手 PaaS 项目时实际见过的按现象、原因、解决三段写。不想让评审会变成事故复盘会就提前在说明书里把这些问题补上。5.1 坑一租户隔离只写了 Namespace越权访问一测就翻车现象评审演示时租户 A 的 Pod 直接通过 Service 名访问租户 B 的应用接口安全负责人当场叫停整场评审。原因K8s 的 Namespace 只做资源分组不提供网络隔离和权限隔离。说明书里写「按租户建 Namespace」等于根本没设计隔离只是给资源画了个圈。解决隔离模型必须写三层。账号层用 OIDC 接入企业身份体系RBAC 按租户建角色网络层用 NetworkPolicy 默认拒绝再按白名单放通跨命名空间访问资源层用 ResourceQuota 和 LimitRange 控制用量。说明书最后加一条验收要求跨命名空间访问必须被拒绝并把这条写进租户开通流程的验收项。5.2 坑二SLO 只写平台整体 99.9%数据面一抖动就违约现象上线后存储节点抖动租户数据库响应变慢平台可用性直接低于对外承诺的 99.9%客户拿着合同来找。原因99.9% 是控制面高可用的结果但租户感知的是数据面。数据面涉及存储、中间件、网络任何一个环节出故障都会被租户感知整体一个数根本兜不住。解决把 SLO 拆成三层控制面 99.95%、数据面中间件 99.9%、租户应用不承诺。对照可用性预算99.9% 每年约 8.76 小时不可用99.95% 每年约 26 分钟不可用。拆分后每一层单独告警、单独复盘拆分表直接放说明书「可用性设计」章节。租户合同里签哪个数以拆分后的对应层为准别拿总体一个数签。5.3 坑三HPA 参数没写压测时副本疯涨、收不住现象压测时 Pod 数几分钟内翻了三倍流量回落后两个小时不缩容平台资源被占满其他租户开始受影响。原因CPU 阈值设太低、缩容冷却时间没配HPA 对短时抖动过度敏感。说明书里写「启用 HPA」五个字不写参数等于没写实施的人只能按默认值或自己猜。解决基线参数写进说明书CPU 目标 65% 到 70%内存 70%缩容冷却时间 300 秒到 600 秒单次缩容比例限制在 25%。压测前用这几个参数验证一轮评审时直接把压测报告附在说明书后面当证据比任何文字都管用。5.4 坑四存储只算了大小没算性能IOPS 上线后被打满现象数据库 PaaS 化交付后延迟抖动监控面板 IOPS 长时间满格业务 SQL 全部变慢租户投诉不断。原因容量规划只写了「数据库分配 500GB」没写 IOPS 和吞吐要求。通用云盘和 SSD 混用性能模型完全没区分性能这块全靠玄学。解决存储矩阵按用途区分性能等级etcd 用本地盘或高 IOPS 云盘数据库用 SSD 云盘日志用对象存储。IOPS 估算公式写成预估峰值 QPS 乘以平均每请求 IO 次数再乘 1.5 冗余把结论数值直接写进说明书。采购和选盘时按这个数来别等上线了再补。5.5 坑五镜像安全只做入口扫描运行时的漏洞没人处理现象入口扫描全绿上线三个月后集群扫描报出十几个高危镜像漏洞研发说不是自己的事运维说没有更新流程漏洞挂了两周没人动。原因说明书里写了「CI 接入镜像扫描」但没写运行时扫描和漏洞修复闭环。入口挡住了一部分运行时的漏洞没有归属方。解决镜像安全写成三段策略CI 阶段阻断高危镜像入库仓库扫描每 24 小时一轮运行时扫描每天一轮。修复窗口按严重级别定义高危 48 小时内处理中危 7 天内处理。基础镜像更新由平台团队统一跟进租户业务镜像的漏洞由租户负责这条责任边界写清楚推诿情况会少很多。6. 用一轮挑刺式评审验证总设说明书8 个问题问倒设计团队总设说明书写完不叫完要能扛住一轮挑刺式评审。我习惯把评审做成问题清单设计团队先自评一遍再上评审会避免评审会变成「大家看了一遍都说挺好」。评审问题对应说明书章节合格标准租户 A 能不能访问租户 B 的数据多租户隔离设计默认拒绝有验证记录数据面某个中间件挂掉影响多少租户故障域与爆炸半径受影响范围有明确数字容量按什么业务峰值算的资源规划QPS 来源和冗余系数可复核哪些组件自研哪些直接采用技术选型每个自研项有决策依据SLO 拆分后能被监控验证吗可观测性设计每个 SLI 有指标和告警平台升级会打断租户业务吗版本演进与升级策略有灰度与回滚方案新租户从申请到开通要几步服务目录不超过 5 步集群要迁移哪些组件可以保留解耦设计有标准接口或适配层评审流程我一般这样组织提前三天把问题清单发给各章节负责人要求对应章节的编写人自己先答一遍。评审会上不看 PPT直接对着清单过答案。结论分三个等级通过、有条件通过、不通过。有条件通过必须列出遗留项、负责人和截止日期不能只写一句「后续完善」。我自己评审时有个习惯专门挑一个最冷门的场景比如「某个可用区整体不可用时租户数据库怎么恢复」随机点一个组件负责人回答。答不上来说明这份说明书把愿望清单当设计了需要回去补。这个习惯帮我在不少项目里躲过了上线后的大故障希望帮到你。本文还有配套的精品资源点击获取