1 云架构设计方法要回答什么
云架构设计要回答的核心问题是：为了让某项服务在约定条件下持续工作，应该怎样组织资源、责任和变化？资源包括计算、网络、身份、数据与观测设施；责任包括谁能访问、谁来运维、谁在故障时作决定；变化则包括发布新版本、业务增长、依赖失败和预算调整。架构图只是这些答案的表达形式，不能代替答案本身。
本课用一家小型零售业务的订单 API 作为例子。用户提交商品与数量，服务检查请求、生成订单并返回订单号，运营人员随后查询订单。服务运行在云上的应用实例中，经由网络入口接收请求，把订单写入数据库，并把日志与指标送到观测系统。这里先不讨论复杂的库存协调和支付事务，只约定：返回成功的订单应当能够再次查到，重复提交应有明确处理规则。
这段业务描述已经引出了设计问题。应用实例是否可以替换？数据库是否成为共同依赖？谁有权读取订单？一次发布失败会影响多少用户？入口无法访问时，能否区分网络阻断与应用无响应？这些问题跨越产品名称和部署脚本，因此适合在选择具体云服务之前讨论。设计者先描述所需能力，再比较服务是否提供这种能力以及使用它的条件。
可以把架构方法看成持续收集证据的过程：从业务目标出发，把质量要求写成可检验的场景，识别约束，提出候选方案，再通过计算、试验和评审选择方案。实施后还要检查实际行为是否符合假设。一次压力测试可能改变实例数量，一次故障演练可能暴露共同依赖，一项数据规定也可能改变部署区域。设计结果应能随着这些证据修订。
阅读这张图时，注意“运行证据”会返回需求与决策，而不只是流向运维报表。假如预估的请求峰值是每秒 120 次，实测却在每秒 70 次时出现大量超时，首先要核对请求分布、数据量和测试环境，再决定修改需求假设还是修改实现。架构工作需要明确哪些数字来自业务承诺，哪些来自试验，哪些还只是估计。
初学者不必追求覆盖所有细节的总图。能够说明请求如何到达、身份如何获得、数据何时持久化、故障如何暴露，并能把这些路径与需求对应起来，就形成了可评审的起点。暂时没有答案的问题也应留下记录，包括待确认事项、确认人和期限。明确的不确定性比未经验证的肯定句更便于协作。
2 需求、约束与质量属性
功能需求说明服务做什么，例如创建订单、查询订单。质量属性说明服务在什么条件下做到什么程度，例如高峰期的响应时间、发生故障后的恢复能力、敏感数据的访问范围以及维护成本。非功能需求常缩写为 NFR，它并不表示“不重要的需求”，其中很多要求直接决定业务能否接受这个系统。
“系统要快、稳定、安全”无法直接指导设计。可以把质量要求写成“条件—刺激—响应—度量”的场景。例如：在指定商品数量与数据库规模下，持续 15 分钟收到每秒 120 次创建订单请求，正常运行期间成功请求的第 95 百分位响应时间不超过 500 毫秒，同时统计失败率与超时率。百分位表示观察值中相应比例不超过该值，平均响应时间不能代替它。
这个场景还需要注明请求从哪里发出、计时到哪里结束、是否包含网络传输、失败如何分类。否则应用内部处理耗时达标，用户仍可能因入口排队而等待很久。性能数据也需要测试条件：订单大小、读写比例、缓存状态和后台任务都会影响结果。入门阶段先把主要条件写清，复杂的负载建模可以逐步补充。
可用性与恢复要求也应分开表述。正常时每月允许多少不可用时间，是长期服务目标；某个故障发生后多久恢复，是具体故障场景。恢复时间目标称为 RTO，表示业务希望在多长时间内恢复到约定状态；恢复点目标称为 RPO，表示恢复时可接受的数据回退范围。它们是目标，不是勾选备份功能后自然获得的保证。
例如业务提出：某个可用区不可用时，订单接口应在 5 分钟内恢复受限服务，已确认订单不能因为应用实例丢失而消失；数据库严重损坏时，允许恢复到最多 15 分钟前的数据，并在 60 分钟内完成恢复。这是不同故障下的不同承诺。若业务要求所有情形都绝不丢失已确认订单，就必须重新审视后者的恢复方案和预算，不能同时默默接受相互冲突的要求。
约束则限定可选范围。例如数据只能保存在批准的区域、月度资源预算为 1000 个成本单位、团队只有 2 名维护人员、首版必须在 4 周内上线。质量目标通常可以协商，法规和组织强制规则则未必允许调整。把两者区分开，讨论时才能知道哪些条件需要优化、哪些需要负责人正式批准变更。
还要给要求排序。订单业务可以把“成功订单可查询”设为必须满足，把“单个应用实例故障后继续服务”设为上线门槛，把“整区故障后立即保持全部性能”列为后续目标。排序应由业务和技术共同确认，并说明不实现某个目标的影响。所有要求都标成最高优先级，会让取舍隐藏在实现过程里，最后由偶然选择决定。
3 视图、接口与演进边界
架构视图是围绕某类问题选择信息的表达方式。业务负责人需要看到用户、订单流程和外部依赖；实现人员需要看到模块接口与数据归属；运维人员需要看到资源位置、权限、监控与恢复入口。把所有细节堆到同一张图上，往往既难阅读，也无法回答任何具体问题。多张视图之间应使用一致名称，并保持关键事实相互对应。
订单服务可以先准备 3 类视图。上下文视图说明用户、运营人员和外部系统如何使用服务；运行视图说明入口、应用实例、数据库和观测设施如何交互；部署视图说明这些组件落在哪个区域、可用区和网络范围内。图上每条连线都应有含义，例如 HTTPS 请求、数据库连接或日志上报，不能只用无说明的箭头表示“有关联”。
接口是边界上的承诺。创建订单接口需要说明请求字段、身份校验、成功响应、错误类型、超时和重试行为。假如客户端等待超时，服务可能已经完成写入，客户端此时不能仅凭“没收到成功”推断订单未创建。可以为请求提供幂等键，让相同业务操作的重复提交得到一致结果；键的作用范围、保留时间和参数冲突处理也属于接口契约。
身份边界同样重要。用户身份用于判断谁能下单，应用的工作负载身份用于访问数据库或密钥服务，运营身份用于维护资源。它们应分别授予所需权限，并保留可追踪的操作记录。把管理员凭证放进应用配置，会让应用漏洞直接跨越运维边界。入门设计至少要写清凭证从哪里来、允许访问什么，以及撤销后会影响哪些操作。
数据边界决定谁对数据含义与修改规则负责。订单表可以由订单服务负责写入，其他使用方通过约定接口读取所需信息。当前即使只有 1 个应用，也值得说明这种归属，以免后续报表脚本直接修改业务记录。共享数据库并不天然错误，但共享之后的字段变更、权限和恢复操作都需要协调，不能假设每个使用方都能独立变化。
演进边界关注变化传播到哪里。新增可选字段可能只需要兼容接口与存储；更换订单号规则可能影响客户端、日志查询和外部对账。设计时可以列出预期变化，并检查它是否越过过多边界。对当前没有需求的变化，不必提前建设整套扩展平台；先保留清晰接口、版本兼容规则和迁移路径，通常更容易维护。
图还应标注抽象层次与省略内容。例如运行图中的“数据库”只是逻辑组件，不能据此判断它部署在几个可用区；部署图中的“私有网络”也不能证明每条访问都已授权。遇到跨视图的问题，应回到相应说明核对。清楚标注“位置待确认”“恢复能力待演练”，有助于避免读者从简化图形推导出不存在的保证。
4 动手：把 NFR 映射到架构决策
现在为订单 API 做一次纸面设计练习。准备需求表、候选决策表和验证记录即可，不需要立即开通云资源。先约定教学场景：峰值每秒 120 次请求；无状态应用可随时重建；测试表明每个实例在指定负载下可稳定处理每秒 80 次请求；正常时数据库的已验证处理能力为每秒 240 次。这里的数字只用于练习，实际项目必须重新测量。
先写场景，再写决策。对于正常峰值，2 个实例的应用处理能力合计为每秒 160 次，超过当前峰值。但这只给出粗略容量判断，不能证明延迟与错误率目标已经达成。连接池、排队、热点数据和入口限制都可能改变结果。候选决策可以是“部署至少 2 个应用实例并进行负载分配”，验证动作则是按约定负载测试整条请求路径。
再加入故障要求：最大承载可用区不可用后，剩余实例仍要接住每秒 120 次请求。可用区是云区域内用于隔离部分基础设施故障的位置；隔离程度和服务支持范围需要查明。若 2 个实例分放在 2 个可用区，损失其中任意 1 个后只剩每秒 80 次能力，因此“正常够用”与“故障后够用”得到不同结论。
接着比较 3 个与 4 个实例。按尽量均衡方式分布在 2 个可用区，3 个实例形成 2 与 1 的分布，损失承载 2 个实例的可用区后仅剩每秒 80 次；4 个实例形成 2 与 2 的分布，同样故障后剩余能力为每秒 160 次。如果只按“总数减去 1”计算，就把可用区故障错误地当成了实例故障。
交互按顺序展开需求、边界、候选方案和证据。观察每个阶段增加了什么信息：需求确定评价标准，失败域决定损失范围，容量计算筛选候选方案，验证检查计算是否可信。最后写出的决策不是“采用高可用架构”，而是“为满足指定可用区故障场景，将 4 个应用实例均衡部署，并验证剩余路径能够接收业务流量”。
随后补齐数据、身份与网络条件。应用跨可用区仍可运行，不代表数据库也能继续写入；还要确认数据库的部署方式、切换条件和连接恢复行为。入口需要能把流量导向剩余实例，应用身份需要在故障时仍可使用，剩余网络路径也要允许访问数据。这些都是候选方案成立的前提，应分别指定验证任务。
对于数据恢复要求，可以形成另一条映射：“允许最多 15 分钟数据回退”对应备份频率与恢复点覆盖，“60 分钟内恢复”对应恢复步骤、数据规模和演练时长。备份成功日志只证明任务曾报告完成，还应实际恢复副本并检查订单能否读取。原环境仍在运行时的恢复试验，也要说明是否代表生产故障下的操作条件。
完成练习时，把每条 NFR 连到至少 1 项决策、1 个成立前提和 1 项验收证据。暂时不能验证的条目标成待验证，并写明它会影响哪个上线判断。这样可以区分“方案中已经安排”“配置已经完成”和“目标已经被证据支持”。这 3 种状态经常被混用，也是架构评审中最值得澄清的地方。
5 理想架构与落地约束取舍
理想方案常希望同时拥有更强隔离、更高容量、更短恢复时间和更低费用，但资源与维护能力有限。取舍应比较具体候选方案及其后果。例如增加实例能提高应用容量，却会增加常驻费用；跨可用区可能缩小部分故障影响，却引入网络路径与部署管理要求；选择托管数据库可以减少部分维护工作，但团队仍需要负责权限、数据模型和恢复验证。
为了看清约束，继续使用简化模型：固定数据与入口成本为每月 300 个单位，每个应用实例为 180 个单位，每个实际使用的可用区增加 60 个单位的网络及运维摊销。实例按尽量均衡方式放入最多 2 个可用区，正常处理能力取应用合计与数据库能力的较小值。这里忽略许多真实费用，模型用于暴露关系，不用于生成采购报价。
拖动实例数量，分别查看正常容量、最大承载可用区失效后的应用容量和月成本。2 个实例的月成本为 780 个单位，正常容量足够，故障后不足。3 个实例花费 960 个单位，仍不能满足指定故障目标。4 个实例达到故障后容量要求，月成本却升至 1140 个单位，超过 1000 个单位预算。这个模型下，当前条件没有全部达标的候选项。
没有可行解时，应公开冲突并组织选择。可以争取预算，协商故障期间只接收每秒 80 次请求，或者通过实测证明单实例能力能够提高。每个选择都需要负责人确认与后续证据。不能一边保留每秒 120 次的故障承诺，一边把容量缺口放进未说明的“弹性伸缩会处理”之中，因为扩容本身需要时间与可用资源。
还应把维护复杂度写入比较。团队可能承受得起更多实例的费用，却没有能力长期维护多个区域的数据同步与演练。初始方案可以接受某些低优先级场景下的人工恢复，同时明确预期中断、操作步骤与值班责任。合理的简化需要被看见，尤其要说明什么时候重新评估，例如业务峰值持续上升或恢复演练超时。
比较方案时，优先用已批准目标检查硬性门槛，再比较其他收益与代价。把安全、性能和成本随意换算成总分，可能让必要条件被平均分掩盖。例如未满足数据驻留要求的方案，即使成本和性能表现很好，也不能靠加权得分通过。评分可以帮助讨论偏好，不能代替对约束和风险的判断。
6 常见坑：先画图后补需求
先选一组熟悉的组件画成漂亮架构图，再给图补上需求，是常见的顺序倒置。图中出现多个实例，就写“高可用”；出现缓存，就写“高性能”；出现备份，就写“数据安全”。这些标签省略了成立条件。修正办法是反向追问每个组件：它解决哪个已排序的场景？依赖什么假设？没有它时会出现什么可观察的差异？
另一个坑是把服务自身提供的能力直接当成端到端结果。数据库提供自动切换，不代表应用能在切换后自动建立新连接；实例具有健康检查，不代表检查能发现依赖数据库失败的情况；入口配置了重试，也不代表重复的创建订单请求会得到正确处理。架构需要贯穿用户操作的完整路径，并说明超时、重试与数据结果的关系。
网络连通与授权也常被混淆。应用位于私有网络，只说明它所处的网络范围及访问路径，不说明它拥有最小权限。访问数据库通常同时涉及路由、网络访问规则、服务身份和数据库权限。排查时应逐层取证，设计时则要写明每层允许的主体和目标，避免用“放在内网就安全”替代权限设计。
观测方面的常见误区是只写“接入监控”，却没有说明监控回答什么问题。订单 API 至少需要关注入口成功率、响应时间、应用饱和度、数据访问失败和成功订单可查询性。日志应能用请求标识关联主要步骤，同时避免记录凭证与不必要的个人信息。单看 CPU 利用率，可能看不到连接耗尽造成的失败。
还要防止需求在不同文档中逐渐分裂。方案写恢复时间为 5 分钟，运维手册却要求人工审批 20 分钟，测试报告又只验证实例重启，那么“已满足恢复目标”的结论就缺乏支撑。可以用简短追踪表维护场景、决策、实施状态和证据链接，并在关键变更时更新。表的价值在于减少矛盾，不在于增加文档数量。
最后是忽略发布与回退。资源部署在多个位置，并不能防止错误版本同时覆盖所有实例。设计应说明发布分批方式、暂停条件和回退判断；如果新版本改变数据结构，还要确认旧版本能否继续读取。这里先理解“变化也可能成为故障来源”，复杂的数据库迁移策略留给后续专题，不能仅凭保留旧镜像就承诺随时回退。
7 案例：未写清失败域导致误判
某团队评审订单服务时展示了“2 个应用实例加托管数据库”的图，并声称能够承受故障。测试人员停止了其中 1 个应用进程，入口把请求转发到另 1 个实例，服务仍可访问。评审于是把可用性要求标记为通过。几周后，承载这 2 个实例的可用区发生异常，订单创建大面积失败，团队才发现此前没有约定故障范围。
这里的失败域指某种故障可能同时影响的资源集合。应用进程、实例、可用区、区域可能对应不同范围，公共配置或发布操作也可能造成跨位置故障。停止进程的试验验证了特定进程失败下的行为，不能推出实例、可用区和区域故障都可承受。问题既在部署选择，也在证据被扩大解释。
复盘时应先还原事实。通过资源清单确认 2 个应用实例位于同一可用区；检查入口记录，发现请求无法获得健康后端；再检查数据库与网络状态，确认哪些依赖同时受影响。若某项证据缺失，就把它标为未知，不要仅凭服务名称或架构图猜测。故障期间的时间线还应区分发现、定位、采取措施和恢复业务的时刻。
团队提出把实例分放到 2 个可用区。但前面的容量模型提醒我们：这只使故障后仍存在应用实例，每秒 80 次的剩余能力仍低于每秒 120 次峰值。数据库如果仍依赖受影响位置，订单写入也可能不可用。修复方案因此需要同时检查位置分布、剩余容量、数据服务行为、入口转发和身份访问路径。
交互从“进程停止试验通过”开始，逐步揭示共享可用区、故障传播和修复后的容量缺口。它强调每次试验只能支持明确范围内的结论。图中变灰的资源表示在教学场景里不可用，并不表示真实的可用区故障一定以完全相同方式表现；真实故障还可能出现部分网络异常，因此后续验证要覆盖业务实际关心的情形。
重新写验收条件后，团队按阶段收集证据：确认位置和依赖清单；在批准的隔离测试环境中演练目标可用区不可用；持续发送约定负载；记录失败请求、恢复耗时和订单核对结果。若使用停止资源或阻断网络来模拟，需要说明模拟能覆盖什么、无法覆盖什么。测试应有恢复步骤和停止条件，并由有权限的人员执行。
最终结论也应限定范围，例如“在指定负载和测试配置下，目标可用区隔离后，服务在约定时间内恢复到受限能力；区域级故障未验证”。这样的结论便于决定是否上线，以及是否接受残余风险。它也让后续改进有明确起点：下次增加的是哪项能力，准备弥补的是哪块证据，而不是重复追求没有定义的“更高可用”。
8 把架构决策记录写进方案
架构决策记录常称为 ADR，用于保存重要选择的背景、理由和后果。它可以很短，但应让后来接手的人知道为什么这样做，以及条件变化时是否需要重议。记录对象可以是跨可用区部署、使用某类数据存储、身份权限边界或恢复方式；无需把每项无关紧要的参数都写成独立决策。
订单案例可以建立“ADR-004：应用部署与可用区故障目标”。背景写明业务峰值、实例能力的测试来源、预算与团队限制；目标写明需要承受的失败域和故障期间允许的业务降级；候选项比较 2、3、4 个实例及其容量和费用。决定采用哪项配置之前，还要标注预算或目标调整是否已批准，不能把待讨论内容写成最终事实。
一条完整记录应包含状态、日期、负责人、关联需求、选择、替代方案、后果和复审触发条件。状态可以是提议、接受、被替代。后果既包括收益，也包括运维负担、费用和未覆盖的故障。若某次测试推翻了单实例能力假设，应追加新证据，并说明决策是否需要替代；保留历史有助于理解当时条件下的合理性。
记录需要和实际配置连接起来。决定“均衡分布”之后，应能找到部署声明或资源清单；决定“最小权限”之后，应能找到身份与权限配置；决定“备份可恢复”之后，应能找到恢复演练记录。文档中的未来状态与现有状态最好明确分栏，防止设计图已经升级，运行环境却仍停留在旧版本。
验证证据也要注明有效条件。某次容量测试使用了什么版本、数据规模和实例规格，某次恢复用了哪个备份、耗费多少时间，都会影响证据是否还能支持当前决定。当数据增长或依赖改变时，不必机械重做所有试验，但应判断哪些结论失效，并安排必要的重新验证。证据有适用范围，不能永久贴上“已通过”的标签。
评审会议可以围绕 3 类内容展开：目标是否清楚，决策是否有依据，未覆盖风险是否有人接受。遇到分歧，先定位属于事实差异、目标冲突还是偏好不同。事实差异可安排测量，目标冲突需要负责人取舍，偏好则可比较维护成本与可逆性。把争论落到可操作事项上，比反复讨论哪张图“更先进”更有效。
9 从云架构设计方法走向大规模架构模式（C46）
到这里，订单服务已经形成从需求到运行证据的闭环：功能说明业务操作，质量场景定义表现，视图表达边界，决策记录保存取舍，测试与观测检验假设。这套方法同样适用于文件处理、内部查询或内容服务。更换业务时应重新确定关键场景，不能把订单例子的峰值、恢复目标和数据要求当成通用标准。
规模扩大后，变化可能出现在多个方向：请求数量增加、用户分布更广、数据持续增长、团队开始并行发布，或者故障影响的业务范围扩大。每种变化都会改变原来的约束。例如数据库能力达到瓶颈时，单纯增加应用实例可能只让更多请求同时等待；多个团队共享表结构时，即使流量不高，发布协调也可能成为主要障碍。
大规模架构模式为反复出现的问题提供组织方式，例如把耗时任务放入异步处理路径、把不同访问需求分开、按数据或业务边界分散负载。这些名称先作为下一课的路标。本课不展开消息投递语义、分布式一致性或跨区域数据协议；选择相关模式之前，仍然要回答它解决哪个场景，以及引入哪些新的失败和维护条件。
尤其要识别模式可能改变的业务承诺。同步返回创建结果，改为先接受任务再查询结果，会改变接口状态与用户等待方式；引入缓存会增加数据更新与失效规则；拆分服务会增加远程调用和授权边界。规模模式并不只改变部署图，它们也改变业务流程、可观测性与故障定位，因此需要重新核对接口和质量场景。
在进入 C46 前，可以用自己的方案回答几个问题：最重要的质量要求能否被测试？任何“冗余”声明是否写清失败域？最大的共同依赖是什么？预算与故障容量是否同时满足？关键决策是否保存了适用条件？如果这些问题还没有答案，先补齐证据和边界，下一课的模式比较才有稳定依据。
放进方案里
把云架构设计方法写进方案时，开头先说明业务范围与成功结果。例如本方案覆盖订单创建和查询，成功响应表示订单已按约定持久化，支付与库存协调暂由外部流程处理。随后列出高峰请求、数据规模和主要使用方，标注数字来源与待确认事项，让读者知道设计依据是什么。
将质量要求写成可验收场景，至少覆盖正常运行、关键故障、数据恢复与访问控制。每个场景注明条件、度量口径、目标、优先级和负责人。把数据驻留、交付期限、预算和维护人数单独列为约束。发生冲突时，写清需要调整哪项条件以及谁负责批准，不用“后续优化”代替取舍。
附上上下文、运行和部署视图，并在图旁说明接口、身份、数据归属与失败域。用简短追踪表把需求连接到架构决策、实施配置和验证证据。对关键选择保留决策记录，包括候选项、成立前提、成本与维护后果；对未覆盖场景说明业务影响、临时处理办法和风险接受人。
验收部分写清如何获得证据：压力测试采用什么请求与数据，故障演练隔离哪个范围，恢复演练如何核对订单，观测如何关联用户失败与组件异常。所有结果注明版本、环境和日期，尚未完成的项目保留待办状态。最后列出复审触发条件，例如峰值超过容量余量、数据量明显增长、预算变化或恢复演练超时，使方案能随运行事实持续修订。
补充故障容量验收表：逐项列出各可用区实例数、最大损失范围、剩余处理能力和数据库写入前提。订单案例须在隔离目标可用区后，按批准的故障负载核验恢复时间、错误率与成功订单可查询性；同时保留流量转移记录和订单核对结果。若只做进程停止试验，结论只能覆盖该进程故障，不能据此勾选可用区故障验收通过。
10 小结：下一步大规模架构模式（C46）
云架构设计从可检验的需求开始，经由边界、候选方案和取舍，落到部署配置与运行证据。实例数量、跨区分布和托管能力都需要放进完整请求路径中判断；关于故障承受能力的结论，必须写清负载、失败域与验证范围。
自测时，可以重新比较 2、3、4 个实例：为什么正常容量达标仍可能无法承受可用区故障？为什么增加实例不能消除数据库瓶颈？为什么备份成功还需要恢复演练？能把答案连回需求、决策和证据，就具备了继续讨论模式的基础。C46 将沿着规模增长带来的新问题，学习如何选择大规模架构模式，以及怎样评估它们带来的新代价。