一、先纠正一个常见画面

提到混合云，脑子里出现的画面常常是"两个机房，用一根线连着"。

这个画面不算错，但它跳过了最难的一步：东西该怎么分。因为线怎么拉是技术问题（有标准做法，照着做就行），而什么东西放哪边是判断问题——判断错了，线拉得再好也是白搭。

换个更准确的说法：混合云的本质是一份分类表。你把所有的系统和数据列出来，逐个贴上标签，那些标签决定了位置。

二、八个例子，看分类怎么发生的

这张表最值得留意的是它的"不整齐"：同样是核心系统，客户主数据留在私有云，而对外网站去了公有云。理由完全不同——前者是合规逼的，后者是负载逼的。这说明分类不是按重要程度排的，是按约束条件排的。

三、两条判据

把上面八条理由归一下类，会发现它们其实只有两个来源：

判据一：这份数据允许出网吗？

不能出网，就不用再想别的了——留在本地或私有云。注意这条判据的措辞是【允许】，它问的是规定和合同允不允许，而不是技术上做不做得到。技术上把数据传到哪儿都做得到，难的是事后说得清。

判据二：这个系统的负载波动大吗？

波动越大，公有云的价值越高。因为第二章前面讲的那条账——自建要为峰值付钱——在有波动的地方才成立；一个负载平稳得像条直线的系统，自建的账反而可能更好看。

两条判据的组合结果：

右下角那一格是最难受的位置：既不能出门、波动又大。这种情况下通常的做法是把波动的部分拆出去——比如把不涉及敏感数据的计算或缓存层放到公有云，核心数据仍留在本地。这也是"拆"这个动作在混合云里的另一种用法。

四、把两边连起来：VPN 与专线

位置定了之后，就该连线了。常规做法有两种：

• VPN：走公网，用加密隧道把两边连起来。便宜、开通快，但延迟和抖动受公网影响。
• 专线：向运营商租一条物理或逻辑上的专用通道。稳定、延迟低，但贵、开通慢（要等运营商施工）。

选择逻辑很朴素：这条线是用来"偶尔传点东西"还是"时时刻刻离不开"？ 前者 VPN 够用，后者必须专线——因为一旦业务依赖它，公网那点抖动就是事故。

五、动手 Demo：把分类和连线都算一遍

下面这个 Demo 先把八类东西按两条判据过一遍，再对比两种连接方式的指标。

# 判据一：数据允许出网吗   判据二：负载波动大吗
def place(can_leave, bursty):
    if not can_leave:
        return "私有云 / 本地"      # 合规先定生死
    return "公有云" if bursty else "两边都行"

实跑输出：

==================================================================================================
D3 云服务的运用形态：混合云，按敏感度分开摆
==================================================================================================
  【一】八类东西，各自该放哪里

  系统 / 数据                   放哪里          理由
  --------------------------------------------------------------------------------------------
  对外网站（高并发）            公有云          访问量峰值差 10 倍以上，自建养不起
  客户主数据                    私有云          合规要求数据不出境，只能放在自己手上
  内部 ERP                      私有云          改造代价大，先不动它
  邮件与协作                    SaaS            标准功能，没有自建的理由
  开发测试环境                  公有云          用完即删、按需开，自建纯浪费
  灾备副本                      公有云          异地冗余，比自建第二个机房便宜
  数据分析与 AI 训练            公有云          偶尔要 GPU，自建一年闲 11 个月
  生产线的工控系统              本地            不能停、不能出网，改动风险高

  【二】把两边连起来：VPN 与专线，差的不是钱，是稳定性

  方式        带宽              延迟            月成本          适用
  ----------------------------------------------------------------------------------------------
  VPN         100 Mbps~1 Gbps   20~60 ms        数千元          试水、非实时同步
  专线        100 Mbps~10 Gbps  2~10 ms         数万元          生产系统、实时同步

  ④ 混合云不是【两个机房连起来】，而是【按数据的敏感度分类，
     各自放到最合适的地方】。判据只有两条：这份数据允许出网吗？
     这个系统的负载波动大吗？两条答完，位置基本就定了。

读这个输出：第二张表的两个数字最值得记——延迟从 20~60 ms 降到 2~10 ms。这个差别在"每天同步一次"的场景里毫无意义，但在"两边的数据库要实时保持一致"的场景里是生死线。所以连线方式不是按预算挑的，是按业务对延迟的依赖程度挑的——先确定要不要实时，再决定花多少钱。

六、⚠️ 2026 现状

• "混合云"正在变成默认状态，而不是一种特殊选择。有调查显示，采用多云混合架构的企业已超过六成，只用单一公有云的比例反而降到三成以下。所以今天讨论的重点已经不是"要不要混合"，而是"怎么分得清楚"。
• 分类的依据正在从"能不能"转向"该不该"。早期主要是合规硬约束（数据能不能出境），现在多了软约束：某些行业要求关键数据可审计、某些客户要求数据具有可携带性。这些要求的共同点是：它们都不阻止你上云，只是要求你说得清数据在哪。
• 连线之外多了"逻辑隔离"这条路。今天不少公有云提供专供单一客户的合规区域或专属环境，使得一部分原本必须放私有云的负载，可以在一份可审计的合同下放进公有云。这让上面那张表的右下方格变小了——但代价是价格和灵活性，不是白拿的。

30 秒实验

拿一张纸，写下你现在接触的三个系统（或者三个数据集合），各自回答两个问题：

1. 有规定或合同说它不能出网吗？ 有 → 记 A；没有 → 记 B。
2. 它的负载是一条平线，还是经常有大起大落？ 平线 → 记 1；波动大 → 记 2。

组合起来：【B2】是最该上公有云的，【A1】是最踏实放本地的。剩下两种（A2、B1）都需要再算一次账——而工作里的争议，几乎全部发生在剩下这两种上。

常见误区

1. 错误：混合云就是过渡方案，早晚要全部上公有云。——纠正：它越来越像长期形态，而不是中间站。原因是分类的约束条件不会消失：合规要求、老旧系统的改造成本、产线设备的物理约束，这些都是长期存在的。所以正确的态度是"把分类做好并保持"，而不是"忍一忍等全面上云"。

2. 错误：只要数据敏感，就一定要放私有云。——纠正：先问清楚"敏感"的具体含义。是法律不允许出境，还是公司内部要求谨慎？前者是硬约束，只能照办；后者则可以通过技术手段（加密、脱敏、专属环境）处理。把软约束当成硬约束，会让很大一部分本来能上云的负载无谓地留在本地——这也是很多"混合云"最后变成"全都自己扛"的原因。

3. 错误：既然分开放，那两边各管各的就行。——纠正：分开放的代价是"必须把两边看成一个整体"。因为数据一旦跨两边流动，就出现了新的问题：一致怎么保证、故障怎么隔离、权限怎么统一、备份怎么对得上。分类表只是第一步，后面还得有一份"跨边界的规则"。 少了这份规则，混合云会变成两套割裂的运维。

4. 错误：VPN 便宜，先用着，不够再换专线。——纠正：这条线一旦成了生产依赖，换的成本远高于一开始就选对的成本。因为在用 VPN 的这段时间里，围绕它建立起来的流程、监控、应急预案都是按它的特性调的；改成专线时这些都要重做。判断标准很简单：这条线断了，业务是"等一下"还是"立刻出事"？ 如果是后者，一开始就该用专线。

• ☐ 下一节（2-4 一切尽在云中：XaaS、DBaaS）

相关笔记

• 云原生的真正含义 —— 上一篇：系统该怎么写才配得上云
• 云服务的两个潮流 —— 公有云与私有云在第一章的首次出场
• 数据中心与云服务 —— 四种形态的区别：机器是谁的、谁管机器
• 云服务的特点 —— "为峰值付钱"这条账，是判据二的来源
• 一切尽在云中 —— 下一篇：云上到底能买到哪些层次
• ☁️ 云计算 · 索引 —— 全课路线图