最初我只想知道域名、域名系统（DNS）和一台虚拟专用服务器（VPS）怎样连起来。实际部署后，网络边界、身份、数据恢复和可观测性也进入了长期维护范围。

本文整理供应商中立的架构逻辑。价格、可用区、套餐配额、免费额度和具体产品会变化，采购或部署当天应回到供应商官方页面复核。本次事实复核日期为 2026-08-08。

先画出一次请求的完整路径

对普通 Web 服务，一次请求可以经过下列全部或部分环节：

Browser
  -> domain name and DNS
  -> CDN / edge reverse proxy
  -> load balancer
  -> cloud firewall / security group / routing / NAT
  -> cloud VM or container platform
  -> reverse proxy / application process
  -> database / object storage / external service

小型站点往往会合并若干层：一台云主机同时运行反向代理和应用，或者托管平台直接承担 TLS、路由和计算。合并并不改变逻辑边界；出错时仍然要逐层判断。

域名与 DNS：名字不是服务器

域名是稳定的公开名称，DNS 是分布式命名系统。注册商负责域名注册关系，权威 DNS 服务负责发布资源记录，递归解析器则为客户端查询并缓存结果。RFC 1034 定义了这套分层、分布式和缓存模型。

建站常用的记录是：

  • A 和 AAAA：名称分别指向 IPv4 和 IPv6 地址。
  • CNAME：将一个名称别名指向另一个规范名称，不是端口转发。
  • MX：指定邮件交换器及优先级。
  • TXT：传递特定协议需要的文本数据，常见于域名所有权和邮件策略验证。
  • SRV：按 RFC 2782 发布服务、协议、目标主机、端口、优先级和权重；客户端必须明确支持它才会使用。

TTL 是缓存上限，不是“修改必定在某时间全球生效”的保证。计划迁移时可提前降低 TTL，迁移完成后再调回正常值；同时要保留旧端点，直到旧缓存大致退出。

CDN、反向代理与负载均衡的职责

  • 内容分发网络（CDN） 在靠近访问者的边缘节点缓存可复用响应，减少回源和跨区传输。动态请求、已登录响应和错误缓存规则需要单独处理。
  • 反向代理 代表后端接收客户端请求，可以终止 TLS、按主机名或路径路由、限流，再把请求转给应用。
  • 负载均衡器 在多个可用后端之间分配请求，通常依赖健康检查排除异常节点。只有一个后端时，它不会凭空产生高可用。

Cloudflare 的 CDN 参考架构 是一个供应商实现例：边缘节点以反向代理形式处在源站前，可命中缓存或回源。不同服务商的缓存键、回源、健康检查和计费语义不同，部署当天必须查相应官方文档。

应用、数据库与对象存储：分开生命周期

应用进程应尽量是可替换的：代码、依赖和启动方式由版本化配置重建，不把唯一副本数据留在某台主机或某个容器的本地文件系统中。

  • 数据库 提供查询、索引、并发控制与特定一致性语义，适合应用状态和关系数据。
  • 对象存储 以“键 + 对象 + 元数据”组织文件，适合用户上传、静态资产、归档与备份；不应默认把它当成可挂载的普通磁盘。
  • 块存储／云盘 呈现为主机磁盘，适合文件系统或数据库卷；快照是一种恢复材料，仍需通过隔离副本和恢复演练满足备份要求。

对象版本等机制可以降低误删和覆盖的恢复成本；例如 Amazon S3 版本控制文档 明确说明保留多版本的行为。该机制只覆盖版本保留，采购时还要核对一致性、锁定、生命周期、跨区复制和恢复费用。

选择计算产品：控制权与托管程度的交换

NIST SP 800-145 将云服务区分为 IaaS、PaaS 和 SaaS。实际计算产品还会用“容器”、“函数”、“Serverless”等交叉标签。选择产品时直接问：谁管操作系统？谁打补丁？能否选内核、网络和运行时？扩缩容的最小粒度是什么？

形态 你获得什么 你要管什么 更适合 主要代价
VPS / 云虚拟机 一台可管理的虚拟机和可配置网络 操作系统、补丁、运行时、容量和大部分故障 需要 root / 管理员权限、自定义软件或学习完整系统 运维责任大；宿主租户模式会影响隔离和性能波动
裸金属 不经过客户可见虚拟机管理层，直接使用物理服务器 更多系统、硬件选型和容量规划 需要硬件级隔离、特殊授权、稳定硬件性能或特定加速器 起步成本和扩缩容粒度较大
容器 应用与用户空间依赖的可重复镜像 镜像、运行时配置、密钥、状态和编排边界 需要一致打包、快速发布或多实例运行 容器只提供进程隔离与打包边界；自管编排会增加复杂度
托管 PaaS 代码或镜像到可运行服务的托管流程 应用、数据、配置和产品约束 Web/API、小团队、不想管主机的常驻服务 运行时、网络、调试和可迁移性受平台约束
函数 / Serverless 由事件触发、平台调度的执行单元 函数代码、权限、事件和外部状态 间歇任务、事件处理、流量可弹性伸缩的接口 执行时间、冷启动、并发、调试和单位费用必须按当前产品复核

执行抽象和硬件租户是两个独立维度。虚拟机可以运行在多租户硬件、专用实例或专用／单租户宿主机上；专用宿主机仍然承载虚拟机，并不等同于裸金属产品。采购时应分别比较这两个维度；Google Cloud 的虚拟机租户指南和 Amazon EC2 专用宿主机文档展示了两种供应商实现。

“容器”与“Serverless”不在同一分类轴上：容器是打包和运行形式，可以跑在自管虚拟机、托管集群或 Serverless 容器平台。Kubernetes 容器文档 强调镜像包含代码和运行依赖；Azure 计算服务选型指南 则展示了虚拟机、PaaS、容器与 FaaS 之间“控制权对管理便利”的实际交换。这些链接只用来说明机制，不构成产品推荐。

一个实用的选择顺序

  1. 先写工作负载：是持续 Web 服务、定时任务、队列消费、数据库，还是需要 GPU 的计算？
  2. 再写不可让步的边界：操作系统、特权端口、本地磁盘、特定网络、驱动、端到端延迟、数据驻留和合规。
  3. 在满足边界的候选中选托管程度最高的最简单方案；只有证明平台约束无法接受时，才承担更多底层运维。
  4. 用小型原型验证：原型必须覆盖发布、回滚、扩容、日志、备份、恢复和最坏月费用。

网络与 TLS：每一层只放行必要流量

公网、私网、子网、路由与 NAT

IPv4 私网地址范围由 RFC 1918 保留，不会在公共 Internet 上被全局路由。在 AWS 及采用相同约定的平台中，“公有子网”指路由表能够到达 Internet 网关的子网。工作负载还要具备可在 Internet 路由的地址，并通过入站过滤，才能接收公网发起的新连接。AWS 的 Internet 网关文档给出了这一定义。其它云可能使用不同标签：Azure 把公共 IP 建模为独立资源，Google Cloud 则分别描述虚拟私有云（VPC）路由与防火墙规则。跨云判断应检查外部地址或边缘入口、有效路由和入站过滤。

  • 子网 从虚拟网络的地址段中划分工作负载。
  • 路由表 选择某个目标网段应交给哪个下一跳或网关。
  • Internet 或边缘网关 会以不同供应商名称连接虚拟网络与公网，但路由存在不等于防火墙已放行。
  • 网络地址转换（NAT） 通常让私网 IPv4 资源主动访问外部，并用转换后的地址和端口接收返回流量。它默认不接受 Internet 发起的新连接。AWS 的 NAT 机制文档 可作为此行为的供应商实现例。

小型 Web 系统的常见边界是：只让负载均衡或反向代理位于公网入口；应用实例和数据库使用私网；数据库仅在指定端口接受应用身份或应用子网的连接，0.0.0.0/0 不进入允许范围。

安全组、网络 ACL 和主机防火墙的边界

名称因云平台而异，但可以按作用对象区分：

  • 云防火墙 / 安全组 通常附着于网卡或资源，按来源、目标、协议和端口过滤。
  • 网络访问控制列表（ACL） 常作用于子网边界，可用作粗粒度护栏；它可能是无状态的，因此返回流量也需匹配规则。
  • 主机防火墙 在操作系统内过滤，即使云侧规则误放宽，仍可保留最后一层约束。
  • 应用鉴权 决定连接建立后谁能执行哪些操作。网络规则只决定连接能否到达应用。

AWS 安全组文档 展示了一种有状态、资源级的实现。设计规则时先列出真实流量矩阵：“谁→谁→什么协议/端口→为什么”，再逐项实现。不要因为排障方便就长期开放所有端口。

端口只表示监听点，TLS 也可能分两段

TCP 443 可达至少需要：地址可路由、有效路由存在、各层防火墙放行，且某个进程确实在预期地址上监听。要让某个域名正确提供 HTTPS，还需要 DNS（或显式诊断覆盖）、预期的 Host／SNI、有效证书链和匹配的应用路由。端口本身不会创建服务，安全组放行也不会让未监听的进程开始工作。

TLS 1.3 的标准定义见 RFC 8446。当 CDN 或边缘代理位于访问者和源站之间时，通常存在两段独立 TLS：

  1. 访问者 ↔ 边缘：边缘向浏览器提供匹配访问主机名的公开信任证书。
  2. 边缘 ↔ 源站：源站提供另一张由边缘验证的证书，并应使用严格验证模式。

Cloudflare SSL/TLS 概览 明确区分边缘证书和源站证书。Cloudflare Origin CA 文档 也提醒：其源站 CA 证书是为被代理的边缘↔源站链路准备的；如果暂停代理、让浏览器直连该源站，浏览器可能不信任它。因此“CDN 已有 HTTPS”不能推出回源链路已加密或已验证。

安全与可靠性：把恢复能力一起部署

身份、密钥与最小权限

  • 人员账号启用多因素认证，日常不使用根账号或所有者账号。
  • 人和工作负载使用不同身份；优先使用短期凭据、工作负载身份或实例角色，不把长期访问密钥写进代码、镜像或仓库。
  • 从零权限开始，按实际调用补充“动作 + 资源 + 条件”，定期删除未使用权限。
  • 密钥由专用密钥服务或部署平台注入，支持轮换、撤销和审计；日志不记录密钥、会话令牌或完整个人数据。

AWS IAM 安全实践 是一个可核验的供应商实现：它建议临时凭据、MFA、最小权限及定期清理未使用凭据。换用其它平台时，应按这些能力寻找等价的身份和密钥机制。

补丁、供应链与可重现部署

自管云主机要维护操作系统、运行时、反向代理、应用和依赖。NIST SP 800-40 Rev. 4 将补丁管理定义为持续识别、排序、获取、安装和验证更新的预防性维护。

安全自动化要求部署输入可审查、版本固定、完整性经过校验、执行权限最小化，并先在预发或可回退环境验证。更新后还要检查服务状态和关键请求；单个命令的退出码只覆盖执行过程的一部分。

备份必须通过恢复演练证明

先定义两个目标：恢复点目标（Recovery Point Objective，RPO）表示故障发生前可接受的数据丢失时间窗口；恢复时间目标（Recovery Time Objective，RTO）表示服务中断后恢复到目标服务水平的目标时长。随后再决定备份频率、保留期、复制位置和恢复流程。

  • 备份覆盖数据库、对象、必要配置和密钥恢复手段；可从代码和镜像重建的临时文件无需进入主要数据备份。
  • 至少一份恢复副本与生产故障域隔离：不同凭据、账户、项目、区域或离线介质的选择取决于威胁模型。
  • 监控备份任务和保留策略；数据可用性需要通过恢复演练另行验证。
  • 定期在隔离环境从空白状态恢复，校验数据完整性、应用启动、权限和实际耗时。

NIST SP 800-34 Rev. 1 将备份和恢复放在完整应急计划中，并强调测试、演练和持续维护。云盘快照、数据库自动备份或对象版本可以是方案组件，但都要进入真实恢复演练。

日志、指标、链路追踪与告警

  • 日志 记录离散事件：何时、哪个组件、哪个请求发生了什么。
  • 指标 用时间序列表达请求率、错误率、延迟、饱和度和业务结果。
  • 链路追踪 把一次请求穿过代理、应用和下游依赖的路径串起来。
  • 告警 按可行动条件汇聚各类信号，并把异常通知给对应负责人。

OpenTelemetry 信号概览 给出了日志、指标和链路追踪的跨工具概念。最小可运行监控应至少包括：外部健康检查、HTTP 错误和延迟、主机／容器资源、数据库容量与连接、备份结果、证书过期时间，以及一条经过演练的告警送达通道。

成本与供应商：比较完整负载

完整成本需要把同一份负载表填入候选供应商的官方计价器，并统一日期、币种和税费口径：

类别 必须记录的输入
计算 架构、vCPU、内存、GPU、常驻时长、峰值并发、扩缩容下限与预留/承诺期
存储 容量、每秒输入／输出操作数（IOPS）、吞吐、快照、对象请求数、版本和生命周期
网络 入站、出站、跨区/跨可用区传输、CDN 回源、公网 IP、负载均衡和 NAT
平台 数据库实例、备份保留、日志摄入/保留、密钥请求、镜像仓库、DNS 查询和支持计划
风险 超额上限、配额、服务级别协议（SLA）前提、故障域、数据驻留、导出方式和销毁流程
人力 补丁、值班、数据库运维、安全审查、迁移和故障恢复时间

使用费用上限或预算告警控制意外，并确认每项控制触发后发送通知还是强制停服。核验预算阈值下的计费行为。保存每次比较的日期、区域、费率页版本或截图、输入和假设；需要采购时重新计算，历史数字只提供背景。

价格之外，还要实测目标用户到候选区域的延迟、丢包和路由稳定性，核对支持响应、产品退役政策、数据导出能力和退出成本。网络质量需要按“用户地点 + 时间 + 运营商 + 区域 + 协议”测量，单个区域标签提供的信息不足。

一条可回滚、可恢复的部署流程

  1. 定义服务边界：记录数据分类、用户地点、容量、服务级别目标（SLO）、RPO、RTO、合规和预算上限。
  2. 画架构和流量矩阵：标出每个组件的公/私网边界、端口、身份、数据存储位置和故障域。
  3. 建立账户护栏：保护所有者账号，为日常管理建立独立身份、MFA、最小权限、审计日志、预算和配额告警。
  4. 在一份可审查变更中定义基础设施和护栏：优先使用版本化的基础设施即代码（IaC）或可重复官方工具；在挂接任何公网入口前声明限制性路由、安全组／防火墙和管理路径，让应用与数据资源从创建起保持私有；锁定依赖，评审变更，不执行未审查远程脚本。
  5. 创建资源时不留下暴露窗口：先验证有效流量矩阵，再创建或挂接唯一预期公网入口；管理面经 VPN、身份感知代理或限定来源访问；应用、数据库和存储用最小规则连接。
  6. 创建可替换运行环境：使用受支持的系统/运行时、非特权应用用户、锁定且经过验证的包或镜像；不在机器内手工堆积唯一配置。
  7. 配置密钥和 TLS：通过密钥服务注入，建立证书签发/续期自动化，分别验证客户端↔边缘和边缘↔源站。
  8. 部署前完成恢复准备：创建备份、写明回滚与从空白恢复步骤，并实际演练。
  9. 切流前验证数据：在接收生产写入前检查 schema 兼容、数量或校验值、应用兼容性和回退路径。若新系统会接收写入，应预先决定是否需要双写、反向复制或向前修复；盲目回滚可能丢失新数据。AWS 的数据库切换指南是一个“先验证、再让应用指向新库”的供应商实例。
  10. 在放量前建立可观测性：验证结构化日志、关键指标、外部探测、备份状态、告警送达、仪表盘和明确负责人。运行准备同时需要健康检查和经过测试的通知路径。
  11. 小流量发布：运行关键业务冒烟测试，并在切流后持续检查数据一致性；按明确的停止、回滚或向前修复条件逐步扩大流量。
  12. 交付运行手册：保存负责人、仪表盘、告警、常见故障、扩容、补丁、证书、备份恢复和服务下线流程。

对很小的个人项目，一页 Markdown 和一份配置仓库便可承载这些信息。验收标准是能够据此从空白环境完成重建、回滚和恢复。

故障定位：沿请求链由外到内

先记录一个可复现样本：时间（含时区）、客户端网络、URL、请求 ID、期望结果和实际结果。然后按层次检查：

顺序 要回答的问题 常用观测
1. 客户端 URL、协议、时间、代理和本地网络是否正确？ 另一网络/客户端对照
2. DNS 权威答案、递归缓存、A/AAAA/CNAME 和 TTL 是否符合预期？ dig, nslookup
3. 连接与 TLS TCP 能否建立，证书主机名、链、有效期和 SNI 是否正确？ curl -v https://host/, openssl s_client -servername host
4. CDN / 边缘 DNS 是否真在代理，缓存、WAF、重定向和回源规则是否改写了结果？ 响应头、边缘日志、保留 Host/SNI 的源站测试
5. 负载均衡 监听器、路由、健康检查和后端端口是否一致？ 后端健康、访问日志
6. 云网络 地址、路由、NAT、安全组和 ACL 是否同时允许这条路径？ 流日志、路由表、规则命中计数
7. 主机/容器 主机防火墙是否放行，进程是否在正确地址与端口监听？ ss -lntup, 服务管理器、容器状态
8. 应用与依赖 配置、密钥、数据库、对象存储和外部 API 是否正常？ 结构化日志、指标、跟踪、依赖健康

需要在不修改公共 DNS 的情况下对照源站时，curl --resolve 可以把域名定向到指定 IP，同时为 HTTP 和 TLS 保留 URL 中的主机名；curl 手册记录了这一行为。应从获准的诊断位置测试，不要为了排障而公开源站或关闭边缘保护；Cloudflare 的源站保护指南展示了一种供应商做法。还要注意，curl -I 发送的是 HEAD；有些服务会拒绝 HEAD，却能正常处理普通 GET。

一次只改一个变量，为临时诊断放宽的端口、规则或日志级别设置明确回收时间。按因果证据选择表格中的检查起点：明确的应用层 4xx／5xx 或应用跟踪可以让你直接检查第 8 层；若请求根本没有到达入口，重启应用则通常没有信息价值。

如何保持这篇文不再过时

文中的基本边界来自标准和长期维护的官方架构文档。但下列信息仍必须在每次实际决策时重查：

  • 产品是否存在、区域可用性、配额和 SLA 前提；
  • 价格、免费额度、公网 IPv4、NAT、负载均衡、日志和出站费用；
  • 支持的操作系统、运行时、API 版本和产品退役计划；
  • 证书有效期、签发/续期规则、TLS 策略和浏览器信任链；
  • 目标用户的实测网络质量、数据驻留和法规要求。

本文引用的主要一手来源包括：IETF 的 DNS、SRV、私网 IPv4 和 TLS 标准；NIST 的云计算、补丁与应急恢复指南；Cloudflare 的 CDN 与双段 TLS 机制文档；Kubernetes 的容器文档；Azure 的计算选型指南；AWS 的对象版本、VPC 与 IAM 实现文档；OpenTelemetry 的可观测性信号定义。供应商文档在这里只用于解释可核验机制，不代表对其产品的无条件推荐。