简介：《各大云平台对比》是一份面向云计算初学者、运维与架构选型人员的文档型资料，围绕阿里云、腾讯云、华为云等主流平台展开横向比较，帮助读者快速建立对公有云、私有云与混合云形态的认知。文档从云计算平台的定义与分类切入，梳理企业采用云平台的动因，并进一步讨论计算、存储、网络与安全等技术指标及常见架构层次，最后落到不同厂商的特点与适用场景对比，兼顾概念解释与选型参考。资料包仅含1个doc文件，约306KB，篇幅紧凑，适合作为入门梳理或方案讨论前的背景材料；内容以章节化文字为主，目录涵盖云平台技术详解、云平台与虚拟主机的区别、国内常见云平台等模块，便于按主题查阅。目前已有3588人学习下载，说明其在云平台入门与厂商对比话题上具有一定参考价值。读者可借此理清三类云形态的优劣、计费与安全差异，并形成多平台选型的初步判断框架。
1. 云平台不是"虚拟主机的高级版本"：那条分界线画在哪
做云计算平台对比时，最容易踩的认知陷阱，是把云平台当成"高级版虚拟主机"——一份流传很广的对比文档里就明写了这个结论，理由看起来也充分：都给出虚拟计算环境、都限制本地文件 API、都按时长和用量计费。可这个类比一旦成立，后面所有选型判断都会走偏。虚拟主机与云平台之间的分界线并不是规模，关键在于有没有调度器：一台物理机上的站点，机器一挂就全部挂掉；云平台上某个宿主机失联，它上面的实例会被自动迁走，用户只感受到一次几十秒的抖动。前者是切分，后者是池化加调度。
这份对比资料的价值，恰恰在于它把"池化"拆成了可以逐项核对的技术指标：云主机的大规格实例、VPC 的租户隔离、对象存储的三副本、DBaaS 的主从热备、四层与七层负载均衡的调度策略。这些名词单看都是营销页上的形容词，落到实现上却各自对应一套完全不同的机制与失败模式。搞懂它们的底层逻辑，比记住"谁家计算能力强"有用得多——那些结论半年就过期，机制不会。
接下来的几章，会从可靠性数字怎么算出来、租户网络怎么隔开、故障切换那几十秒花在哪，一路讲到指标表里不会写的坑。读完你再回头看任何一份云平台对比表，都能判断出哪些数字是硬指标，哪些只是话术。
2. 三副本与 99.99%：可靠性数字是怎么被算出来的
99.99% 这个数字经常被当成形容词用。换算成时间才有体感：一年 525600 分钟，99.99% 意味着全年停机不超过 52.6 分钟；而云主机的 99.9% 对应的是 8.76 小时。两个数字只差一个 9，容忍的故障时长差了十倍。要理解这个差距从哪来，得看一次写请求在存储层到底经过了什么。
2.1 一次写请求要跨过几个故障域
对象存储和块存储的底层都是分布式文件系统，数据被切成固定大小的块或对象，按哈希落到不同的存储节点上。三副本的意思是同一个数据块在三个物理位置各存一份。但"三份"本身没有意义——如果三份都落在同一台机器的三块盘上，电源一掉全没了。
所以放置算法必须做反亲和：先按机架打散，再按主机打散，最后才考虑磁盘。常见的实现思路是两轮选择：第一轮在哈希环上顺时针扫描，每个故障域（机架或可用区）只取第一个命中的节点，凑够三个就停；如果集群太小、故障域不够三个，退化到同机架不同主机；连主机都不够，才允许同机不同盘。
import hashlib def pick_replicas(obj_key, disks, n=3): """按对象键 + 故障域选择 n 个副本落点""" # 用 sha1(obj_key + disk_id) 构造虚拟节点，避免扩容时全量重排 ring = sorted(disks, key=lambda d: hashlib.sha1( (obj_key + d["id"]).encode()).hexdigest()) chosen, used_racks = [], set() # 第一轮：强制跨机架，这是反亲和的核心约束 for d in ring: if d["rack"] not in used_racks: chosen.append(d) used_racks.add(d["rack"]) if len(chosen) == n: return chosen # 第二轮：机架不足时退化为同机架不同主机 for d in ring: if d not in chosen: chosen.append(d) if len(chosen) == n: return chosen return chosen这段逻辑里真正起作用的参数是disks里的rack字段——它把"物理位置"变成了算法可读的拓扑标签。真实系统还会带上容量权重、IO 负载、节点是否处于重建中这些状态位，但反亲和这条硬约束永远排在最前面。代价也很直接：小集群里一旦某个机架整体下线，可用副本数立刻掉到 1，写入会被拒绝。
2.2 2/3 确认就返回：一致性、延迟与修复窗口的三方取舍
副本放好了，写的时候要等几份落盘才算成功？这里有个容易被忽略的细节：多数派。三个副本里只要两个确认，系统就认为写成功，第三个异步补齐。这和 Raft、Paxos 的 quorum 是同一套思路——任意两个副本的交集必然包含至少一个已写入的副本，所以读的时候只要读到两个副本里有最新数据的那个，就不会丢。
为什么不要求三份全部确认？因为延迟取决于最慢的那一个。三副本同步写的情况下，只要有一块盘出现慢 IO（磁盘坏道的前兆、固件 GC 抖动），整个写请求就被拖住，长尾延迟直接翻倍。常见的实现思路是主副本先落本地日志，再并行发往两个从副本，收到任一 ACK 就返回客户端，第三个慢慢追。
这个取舍的代价落在"降级窗口"上：第三副本还没补齐的那几秒里，如果两个已确认的副本同时失效，数据就丢了。而两个副本同时失效的概率，恰恰取决于修复速度。所以决定可靠性的关键指标并不是副本数，而是 MTTR ——平均修复时间。副本掉线后系统多快能发现、多快能重建完，才是 99.99% 能不能兑现的关键。
注意：文档里有一条"3 节点集群损坏 2 个节点系统仍正常运行"，这条要拆开看。只剩 1 个节点时系统失去多数派，读可能还能命中，写一定被拒绝——"运行"不等于"可写"。把它当成可写指标去设计容灾，就会翻车。
2.3 副本掉了之后：重建限速与修复风暴
副本失效的判定靠心跳：节点间每隔几秒互发一次探测，连续三次超时就标记为不可用。假设心跳间隔 10 秒，最坏情况下 30 秒判定完成。接下来调度器启动重建任务，从剩余副本拉取数据写到新节点。
这里有个反直觉的工程细节：重建必须限速。一块 1TB 的盘，如果全速重建，几十 GB/s 的读带宽会瞬间打满剩余两个副本所在的磁盘，把正常读写全部拖垮——这就是"修复风暴"。工程上通常把重建速度压到每节点 20MB/s 左右，算下来 1TB 需要大约 14.6 小时。修复窗口长达十几个小时，意味着这段时间内系统实际上只有双副本保护。
所以真正成熟的设计会把大块数据切成更小的单元（对象存储通常按 4MB～16MB 分片），重建以分片为单位，优先恢复近期被访问过的热数据，冷数据延后。文档里提到的"支持大存储对象的分片并发上传和下载""支持断点续传"，表面上是上传体验，底层同一套分片机制也在支撑小粒度重建。
再说压缩。三副本的空间开销是 300%，如果先压缩再算副本，2:1 压缩比下实际开销降到 150%。但压缩必须发生在副本计算之前——否则每个副本独立压缩，CPU 白烧三遍。代价是随机读要先解压整块，延迟上升。所以通用做法是对象存储开压缩、块存储不开（块设备要的是低延迟随机读写），文档里把"提供数据压缩算法，可将三副本数据进行压缩存储"放在对象存储章节而不是块存储章节，这个位置是有讲究的。
3. VPC 与 VxLAN：两个租户用同一个网段，为什么不会打架
传统 IDC 里最怕的事是 IP 冲突：两个业务用了同一个网段，路由表直接瘫痪。云平台上这件事被彻底反转了——每个租户都可以用 10.0.0.0/8，甚至两个租户用完全相同的地址段，彼此毫无感知。实现这个"魔法"的机制就是 VPC 加 VxLAN，理解它也就理解了云网络为什么能纯软件部署。
3.1 IP 重叠不是 bug，是 VPC 的设计前提
VPC 的本质是把"地址空间"和"物理网络"解耦成两层。租户看到的是自己的虚拟网络：一个 VPC 可以切出多个子网，子网里有虚拟机和虚拟路由器，地址怎么规划完全自主。物理网络只认一件事——这个数据包属于哪个 VPC。
VxLAN 干的就是这件事。它在原始以太网帧外面再套一层 UDP 头，里面带一个 24 位的 VNI（VxLAN Network Identifier）。24 位意味着约 1600 万个隔离域，每个 VPC 分配一个 VNI，物理交换机只看外层头转发，根本不关心里面装的是 10.0.0.1 还是 192.168.1.1。地址重叠在这里不构成冲突，因为它们是两个不同 VNI 下的完全独立空间。
封装带来开销，这个开销是实打实的运维风险点：
# VxLAN 封装新增的字节数，用来反推 MTU 规划 overhead = { "outer_eth": 14, # 外层以太网头 "outer_ip": 20, # 外层 IPv4 头（不含 options） "outer_udp": 8, # 外层 UDP 头，目的端口 4789 "vxlan_hdr": 8, # VxLAN 头，含 24 位 VNI } print(sum(overhead.values())) # 50 # 物理 MTU 1500 → 虚拟机网卡可用 MTU 应为 1450 # 若物理网络已开 jumbo frame 9000，则 VM 可保持 150050 字节看着不多，但物理链路 MTU 是 1500 时，虚拟机里发出一个 1500 字节的包，封装后就变成 1550，超过链路 MTU 会被分片或丢弃。表现为 SSH 能连、小请求正常，一旦传大文件或做数据库全量同步就卡死——这类问题排查起来极费时间。工程上的标准做法是把虚拟机网卡 MTU 统一设成 1450，同时在网关侧做 TCP MSS clamping，把协商出来的 MSS 压到 1410，从源头避免大包。
3.2 纯软件网关：vRouter 跑在 x86 上，靠什么扛住吞吐
文档里有一条很容易被略过的指标："纯软件部署，不需要依赖特定的网络设备即可实现虚拟数据中心技术""通过 X86 服务器实现虚拟数据中心网关的部署，网关性能可弹性扩展"。这句话背后是一个明确的架构选择：控制面和转发面都跑在通用服务器上，不买专用硬件。
传统做法是把 VPC 网关做成硬件盒子或者专用 appliance，性能有保障但扩容就是采购周期。纯软件方案里，vRouter 就是一个跑在 x86 上的进程，转发靠内核协议栈或者 DPDK 用户态轮询。单机吞吐不如硬件，但扩展方式是横向加机器——网关集群前面挂一层 ECMP，加一台就多一份吞吐。文档里"网关性能可弹性扩展"说的就是这个。
代价是性能对 CPU 极其敏感。单个 vRouter 实例跑内核转发，十万级 PPS 就到瓶颈；换 DPDK 能上百万 PPS，但要把网卡从内核手里抢过来，运维复杂度陡增。这是纯软件路线绕不开的宿命：把所有问题都变成"加机器能解决"的问题，同时把所有性能问题都变成 CPU 问题。
3.3 安全组下发到宿主：分布式防火墙为什么不做成集中式
租户之间的隔离靠 VNI，那同一 VPC 内部机器之间的访问控制靠什么？安全组。这里有个关键的实现位置选择：规则不是集中在一台防火墙上执行，而是下发到每一台宿主机上的虚拟交换机。
数据包路径是这样的：虚拟机发出 → 宿主上的 vSwitch 拦截 → 查该实例绑定的安全组规则 → 命中则放行，未命中丢弃 → 才进入 VxLAN 封装。连接建立后，后续包走 conntrack 状态表，不再逐包匹配规则表，否则每包都做五元组匹配，吞吐会掉一个数量级。
{ "security_group": "sg-web-tier", "direction": "ingress", "rules": [ {"proto": "tcp", "port": "443", "source": "0.0.0.0/0", "action": "allow"}, {"proto": "tcp", "port": "22", "source": "10.0.1.0/24", "action": "allow"}, {"proto": "icmp", "type": "8", "source": "10.0.1.0/24", "action": "allow"}, {"proto": "any", "port": "any", "source": "0.0.0.0/0", "action": "deny"} ] }规则表的匹配顺序是从上到下，命中即停，最后一条兜底拒绝。工程上会把高频命中的规则往前提，因为规则越多，单包匹配耗时越长——上千条规则的安全组会把首包延迟推到毫秒级。这也是为什么安全组通常限制规则条数上限。
为什么不做集中式防火墙？因为流量要绕行。所有东西向流量先拉到一个中心节点过滤再回来，中心节点立刻变成带宽瓶颈和单点故障。分布式执行把过滤成本摊到每台宿主的 CPU 上，跟纯软件网关是同一个思路：用可水平扩展的通用算力，替代昂贵且难以扩容的专用设备。
4. 负载均衡与数据库热备：故障切换的那几十秒花在哪
指标表上写的是"平均可用性不低于 99.9%""主备自动切换"。但切换不是瞬时的，从故障发生到流量真正恢复，中间有一串有明确耗时的步骤。搞清楚这些步骤的耗时构成，才能判断一个架构到底能扛住什么级别的故障。
4.1 四层与七层的分界：连接被拆成了两段
四层负载均衡只看 IP 和端口，收到包改一下目的地址转发出去，TCP 连接是客户端和后端直接建立的。七层不一样，它必须把连接拆成两段：客户端到 LB 一段，LB 到后端一段。因为要解析 HTTP 头做路由，就必须先完成三次握手、读到请求行。
这个差别决定了很多能力边界。四层可以做 DSR（直接回包给客户端，回程不过 LB），吞吐能做得很高；七层必须双向代理，带宽成本翻倍，但换来了按 URL 路径路由、按 header 灰度、插入 Cookie 做会话保持这些能力。
文档里"配置 4 层和 7 层负载均衡服务且具备冗余能力"是标准配置，真正的差异在调度算法和健康检查的细节上。
4.2 WRR 与最小连接数：什么流量下会失衡
加权轮询（WRR）按权重比例分发，实现简单，每个请求独立计数。它在请求耗时均匀时表现完美，但一旦后端响应时长方差变大就会失衡：权重 1:1 的两台机器，一台每个请求 10ms，另一台 500ms，WRR 仍然五五开，慢的那台连接数迅速堆积直至打满。
最小连接数（WLC）每次挑当前活跃连接最少的后端，天然适应耗时差异。但它在长连接场景下会退化——WebSocket 或数据库连接池动辄保持几小时，连接数一旦建立就不再变化，算法失去调节能力。这时需要的是最少响应时间或者 P2C（随机抽两个比一比），后者在大规模集群里用得更多，因为不需要全局状态。
实际部署里通常不是二选一：短连接 API 用 WLC，长连接网关用带权重的随机，静态资源用 WRR 就够了。文档把 WRR 和 WLC 并列列出，是因为这两条覆盖了绝大多数场景，但选哪个取决于你的请求耗时分布，不是哪个更新就用哪个。
4.3 健康检查的判定窗口与 Session 保持的实现
健康检查决定了"多久能发现后端坏了"。参数之间的算术关系如下：
health_check: protocol: http path: /healthz interval: 5s # 探测间隔 timeout: 3s # 单次探测超时 rise: 2 # 连续成功几次判定恢复 fall: 3 # 连续失败几次判定摘除 # 最坏发现时间 = (fall - 1) * interval + timeout = 2*5 + 3 = 13s # 最坏恢复时间 = (rise - 1) * interval + timeout = 1*5 + 3 = 8s这 13 秒意味着后端进程挂掉后，还有十几秒的请求会打到死连接上。压小interval能缩短窗口，但探测流量成倍增加，而且超时设得太短会把 GC 停顿误判成故障——判定条件的敏感度和误杀率是一对矛盾。
Session 保持是另一条常被忽略的机制。三种实现方式各有硬伤：源 IP 哈希在同一 NAT 出口后面有大量用户时会严重倾斜，一个公司出口 IP 的所有请求全打到一台后端；Cookie 插入需要七层解析，四层做不到；TLS Session ID 复用只在特定客户端有效。文档写的"在 Session 生命周期内，将同一客户端请求转发到同一台后端虚拟主机"是一种理想描述，真实场景里更稳的做法是把会话状态外置到 Redis，让后端彻底无状态，从根上不需要保持。
4.4 主从热备：半同步复制决定了 RPO
DBaaS 的高可用承诺里有两个指标要分开看：RTO（恢复时间）和 RPO（数据丢失量）。文档写的"主数据库节点失效后，备份节点自动接管"只回答了 RTO，"数据可靠性不低于 99.99%"回答的是 RPO，但两者由不同机制决定。
RPO 取决于复制模式。全异步复制下，主库提交事务立刻返回，binlog 异步推给从库；主库在推送前崩溃，这部分事务就永久丢了。半同步复制要求至少一个从库确认收到 redo 日志才返回成功，主库崩溃时数据至少在一个从库上存在，RPO 接近 0。代价是每次提交多一个网络往返，写入延迟上升 10%～30%。
切换流程拆开看，时间大致这样分配：探活失败判定（3 次心跳，约 10 秒）→ 从候选从库中选出位点最新的一个 → 提升为主库（应用完 relay log，1～3 秒）→ 代理层或 VIP 切换路由（秒级，取决于 TTL 和健康检查频率）→ 重建新备库（分钟级，但不阻塞写入）。所以端到端的 RTO 通常是 20～40 秒，不是"无缝"。
def failover_decision(replicas): """主库不可用后，挑选一个从库提升为主""" candidates = [ r for r in replicas if r["alive"] and r["lag_seconds"] < 30 ] if not candidates: # 全部落后太多，宁可停写也不把过期数据提升为主 return None # 优先比较 GTID 集合完整度，其次比较复制延迟 candidates.sort(key=lambda r: (r["gtid_count"], -r["lag_seconds"]), reverse=True) return candidates[0]lag_seconds < 30这个门槛是防止把一个落后十分钟的从库提上去，那样虽然服务恢复了，但数据回退了十分钟，比短暂不可用更糟。gtid_count用来比较事务完整度，是判断"谁的数据更新"最可靠的依据。这个函数返回None的分支才是设计里最见功力的地方——宁可停写，也不接受静默的数据回退。
5. 避坑：技术指标表里不会写的五种失败模式
指标表是能力上限，不是故障下限。下面这几条都是"指标合格但业务出事"的典型，每一条都能对应到前面某章讲过的机制。
5.1 存储与备份：三副本保不了误删
现象：三副本、99.99% 可靠性都达标，某次运维误执行了一条删除命令，数据瞬间全没了。
原因：副本机制防的是硬件故障，三份数据在逻辑上是同一份。删除请求会被同步复制到三个副本，一致性越强，删得越干净。这就是副本数解决不了的问题——它保的是"设备坏了数据还在"，不是"人删错了还能找回来"。
解决：快照和异地备份必须独立于副本体系。文档里"提供虚拟机任意时刻的磁盘快照功能，含快照制作、快照回滚"和"将本地备份数据远程复制到异地"是两套机制，前者防误操作，后者防站点级灾难。只配三副本不配快照，等于没有恢复手段。另外要定期做恢复演练，备份系统的重复数据删除会形成引用链，链一断整条备份集都不可用，不验证就永远不知道它能不能恢复。
5.2 网络：跨网关的大包为什么突然卡死
现象：虚拟机之间互 ping 正常、SSH 能登、curl 小接口正常，一做数据库全量同步或传大文件就挂住，重试偶尔能过。
原因：VxLAN 封装带来 50 字节额外开销，物理链路 MTU 1500 时，虚拟机发出的 1500 字节包封装后超长，在中间节点被丢弃或分片。小包不受影响，所以前期测试全过。
解决：虚拟机网卡 MTU 统一下调到 1450，网关侧开启 TCP MSS clamping。排查时用ping -M do -s 1472逐级探测路径 MTU，能快速定位是哪一跳开始丢包。这条坑几乎每个自建 VPC 的团队都踩过，属于血泪经验。
5.3 可用性：把 99.99% 当成业务可用性
现象：存储可靠性 99.99%，但业务全年抖了好几次，每次十几分钟。
原因：混淆了两个指标。99.99% 是数据可靠性（不丢数据），云主机可用性通常是 99.9%（全年 8.76 小时不可用），而且这个数字是单实例口径，不承诺你的具体实例什么时候挂。
解决：单实例上不放无状态服务之外的任何东西。数据库必须主从跨可用区部署，前面挂负载均衡做健康检查摘除，应用层至少两个实例。把所有"单点"从架构里清出去，比追求更高的单机可用性划算得多。
5.4 负载均衡：健康检查把后端全摘了
现象：一次下游依赖抖动，负载均衡把所有后端同时判定为不健康，整个服务 100% 不可用，比不挂负载均衡还惨。
原因：健康检查接口里带了下游依赖（比如检查时会查一次数据库），下游一慢，所有实例的检查全部超时，被集体摘除。指标表上写的是"自动隔离异常状态虚拟主机"，机制本身没错，错在检查逻辑的边界。
解决：健康检查只检查进程自身状态，不查外部依赖；同时配置最小健康实例比例和慢启动，让恢复中的实例逐步放量。对下游依赖的失败要用熔断降级处理，不能让它传导到负载均衡层。
5.5 私有云：容量锁定后的单位成本倒挂
现象：为了安全和可控自建私有云，硬件采购加实施做完，发现单位算力成本是公有云按量付费的两三倍。
原因：私有云的成本结构是固定投入，摊薄完全依赖利用率。文档里也写了私有云"安装成本很高""企业仅限于合同中规定的云计算基础设施资源"。利用率低于 40% 时，同样的钱在公有云能买到更多弹性算力。
解决：先算盈亏平衡点。持续高负载、稳态运行的业务，私有云才有成本优势；有明显波峰波谷的业务，混合云更合适——基线负载放私有云，峰值弹性溢出到公有云。文档里"私有云把公有云作为灾难转移的平台"说的就是这个思路，但要提前把两边的网络打通和镜像兼容做掉，临时抱佛脚来不及。
6. 设计取舍：三副本、纯软件、全分布式，这套组合在拿什么换什么
把这份资料里的指标连起来看，会发现它们不是零散的能力清单，而是同一套技术路线的必然结果：全分布式架构、纯软件部署、三副本冗余、按 CPU 时间和存储量精确计费。这套组合解决的是"能否线性扩展到两千台物理机、一万客户端并发"的问题，代价则被分散隐藏在几个不显眼的地方。
最典型的是三副本与纠删码的取舍。三副本空间开销 300%，纠删码（比如 4+2）只要 150%，同样的硬件能多存一倍数据。但纠删码的重建代价极高：恢复一个 4MB 的分片要读 4 个分片做运算，重建期间的网络和 CPU 开销远超三副本的直接拷贝。所以块存储这类对延迟敏感的场景几乎都用三副本，纠删码留给冷数据和大对象。文档里"普通云主机单盘吞吐量 ≥40MBps，高性能 ≥280MBps"这两档规格，本质上也是在用不同介质（SATA 与 SSD）对冲成本。
第二个取舍是纯软件部署。它换来了弹性扩容和不受硬件锁定，代价是所有性能问题都变成 CPU 问题：网关吞吐靠加机器、防火墙靠分摊到宿主、存储靠增加节点。这也解释了为什么这类平台的规模指标写得那么具体——2000 台物理机、900 个 VPC、单 VPC 5000 台虚拟机、1PB 对象存储——这些数字不是炫耀，而是架构在告诉你它的扩展方式是"堆节点"，不是"换更强的单机"。
第三个取舍藏在计费粒度里。按 CPU 时间和存储量精确计费，意味着计量系统本身要能采到秒级的资源使用数据，这层开销最终会摊进每一台宿主机的资源损耗里。换来的能力是弹性：业务高峰加机器、低谷释放，成本随用量走。
最后说个我自己的教训。早年在模拟项目里做容量规划，我照着文档里的"三副本、99.99%"直接算存储需求，把 1PB 可用容量换算成物理盘时只按三倍算，完全没考虑重建预留和压缩比的不确定性，结果上线三个月就触到水位线，被迫紧急扩容。从那以后我每次做容量评估，都强制走一遍"可用容量 ÷ 副本数 × 压缩比 + 重建预留 + 20% buffer"这条链，每个系数都要求有实测依据，不再信任何单一指标。
这份《各大云平台对比》的资料，真正有价值的地方不是最后那张厂商对比表——那部分半年就失效——而是前面那些技术指标背后的机制描述：副本怎么放、VPC 怎么隔、负载均衡怎么判定、主从怎么切换。把这些机制吃透，换任何一家平台你都能自己推出它的边界在哪。希望帮到你。
本文还有配套的精品资源，点击获取
