2.1 云参考架构与服务模型

2.1 云参考架构与服务模型

本节摘要：参考架构是描述云系统的通用语法——分层看职责、按服务模型切责任。本节从一份架构评审邀请函的真实场景切入，给出一套四层参考架构的读图方法，再演示面对合规与成本约束时，IaaS、PaaS、SaaS 三种服务模型的选型推演怎么做。

从一份架构评审邀请函说起

周一早上，你收到一封评审邀请：公司要给海外业务搭一套订单系统，附件里是架构草图——一个负载均衡器、一组应用服务器、一个托管数据库、一个对象存储，外加一句"尽量省成本、下季度上线"。邀请函的问题是：这样搭安全吗？

这个问题没法直接回答，因为草图缺了语法。它只画了"有什么"，没说"每层谁负责、信任怎么流动、数据住在哪"。参考架构的作用就是把语法补上：任何云系统都能按层拆开，每层有明确的职责与责任归属，评审时逐层过一遍，问题自然浮出来。这也是 CCSP 架构域的训练目标——不是背架构模板，而是拿到任何一张草图都能快速建立结构化的判断。

四层参考架构的读图方法

云上系统可以拆成四层来看，自上而下是：访问层（用户与外部系统从哪里进来）、应用层（业务逻辑跑在哪里）、数据层（数据住在哪里、怎么流动）、资源层（计算存储网络等底层资源）。每层问三个问题：这一层的职责边界在哪、责任由谁承担、它与相邻层的信任关系是什么。

读图时特别要盯住的是跨层的数据流，而不是单层组件。订单系统草图里藏着一条典型的流：用户请求从访问层进来，经应用层写入数据层的数据库，发票文件落进对象存储。评审问题随之产生——数据流经过的每一跳，传输是否加密；数据落地的每个位置，静态是否加密；数据在两个存储位置之间的同步，是否经过了不可信的中间节点。安全评审的大部分发现，都来自对数据流的追问而非对组件的清点。

图 2-1：四层参考架构与一条订单数据的旅程

服务模型选型推演

语法有了，第二个决策是服务模型。这不是技术偏好题，而是责任与约束的交换题。拿邀请函里的订单系统做一次完整推演，约束是三条：涉及海外用户个人数据、团队只有四名后端工程师、成本有上限。

推演 IaaS：自己管操作系统、补丁、加固，灵活度最高，四个人团队要养一套系统运维流程，合规审计时每层都要自证，人力成本先爆。结论：除非有特殊的合规隔离或性能要求，四人团队选它是给自己挖坑。

推演 PaaS 或容器托管：操作系统与运行时交给厂商，团队专注代码与数据，补丁与大部分加固自动完成。代价是可定制性下降、厂商锁定加深。对这套订单系统，托管数据库加容器平台基本吃掉全部运维负担，四个人刚好够业务开发加安全运营。

推演 SaaS：直接采购现成订单系统，责任最轻，但订单流程是业务核心竞争力，全盘 SaaS 意味着流程被产品方绑架，且数据驻留与出口条款要逐条谈判。

结论倾向 PaaS 路线，但注意选型推演的价值不在结论而在过程：每一步都在交换"责任、控制力、成本、锁定"四个变量。考试场景题给的往往正是这类约束组合，答题时先列约束、再算交换、后下结论，正确选项通常是让"客户保留的责任"与"团队能力"匹配的那个。

把读图方法变成习惯

本节留下两件可复用的东西。一是评审追问清单：入口、传输、落地、流动、权限、留痕六问，适用于任何架构草图，建议贴在工位上。二是选型推演的三步法：列约束、算交换、下结论——克制住直接报答案的冲动，约束变一个字母，结论就可能翻转。

区域与冗余：被草图吞掉的另一半决策

邀请函的草图还有一块没画：这套系统部署在哪里、坏一个机房会怎样。云的区域与可用区结构给了冗余的积木，但冗余从来不是免费的，安全审查要问三件事。

第一问，冗余边界与故障域：单可用区部署是成本默认，跨可用区部署抗机房级故障，跨区域部署抗区域级故障。冗余每升一级，数据同步的复杂度与延迟同步上升——跨区数据库同步还要过 7.1 的跨境合规审查。评审时先问业务能接受多长的中断，再反推冗余级别，而不是无脑顶配。

第二问，故障切换的安全一致性：主区切换到备区时，访问控制、日志采集、密钥服务在备区是否等价可用？大量事故发生在切换演练时——备区能跑业务，但安全控制是半套。所以冗余设计的验收标准应当包含"安全控制在备区全量生效"，这也要写进演练清单（第六章）。

第三问，数据驻留的合规含义：区域选择不只是延迟问题。监管对数据存放地与运维可及地都有约束（7.1 详述），草图阶段选错区域，上线后搬家要付出十倍代价。这是"合规要求塑造技术架构"的第一个实例，本册后面还会反复遇到。

把区域决策接回选型推演：给订单系统补上这块决策——海外用户、合规要求用户数据不出指定区域、团队四个人，结论是单区域内跨可用区部署起步，跨区冗余等业务量与合规评估成熟后再议。你看，约束清单一旦列全，答案自己就站出来了。

常见误判与快速自查

三个高频误判值得点名。误判一："托管就是安全"——托管服务只是把组件运维转移给厂商，配置与数据治理仍在客户手里，托管数据库的公网可达开关照样能被一键打开。误判二："画进架构图的控制就是存在的控制"——图上有 WAF 不代表规则配过，评审要坚持"要证据不要承诺"，每条声明的控制问一句"怎么验证"。误判三："成本与安全是零和"——很多安全整改同时是成本优化（收回过宽的公网入口降低了防护面与流量费），评审时把双赢项先挑出来，能快速建立信任。

自查口诀收束本节：画了什么不重要，数据怎么流、坏了会怎样、责任归谁管——三问过完，草图才算读完了。

评审纪要怎么写：让发现可执行

评审的产出不是会议，是纪要。一条合格的发现包含四栏：位置（哪一层哪个组件）、事实（看到了什么配置或证据，不是"我觉得"）、风险（不修会怎样，用业务语言）、建议（改到什么状态，可验证）。四栏缺一，发现就退化成意见——位置缺失无法整改，事实缺失无法复核，风险缺失排不进优先级，建议缺失无从验收。

拿订单系统演示一条完整发现：位置写"数据层对象存储（发票归档桶）"；事实写"静态加密未启用，公开读权限开启，变更记录显示 92 天前由开发账号直接开启"；风险写"发票含购买方抬头与税号，公开读状态下可被批量拉取，属个人信息泄露事件，触发 7.1 的通报义务"；建议写"关闭公开读、启用账户级封禁与静态加密，开启访问日志并外送，一周后复查配置截图"。这条发现交给任何人都能执行、能复核——这就是"可验证"的含义。

纪要还有个常被忽略的收尾动作：把本轮发现按"已进模板基线 / 需人工流程兜底"分类归档（接 2.4）。分类的价值在于让评审逐次变轻——同类问题第二次出现时，机器卡点已经替你拦住了，评审资源留给判断型问题。

本节要点回顾

• 参考架构是评审的语法：四层职责加跨层数据流，安全发现大多来自沿数据流的追问，而非组件清点。
• 服务模型选型是责任与约束的交换：列约束、算交换、下结论三步走，结论随约束变化而翻转。
• 区域与冗余是安全决策：故障域、切换时的安全控制等价性、数据驻留合规，三问缺一不可。
• 评审产出物是四栏纪要：位置、事实、风险、建议，四栏齐全的发现才可执行、可复核。
• 托管不等于安全，画进图不等于存在：证据永远优先于承诺。

下一节把"好坏怎么判"补齐：六条设计原则是架构评审的判据库，六问清单配六条原则，评审就有了完整的打分表。