一、Web 系统能成立，靠三个前提

一个业务要能搬进浏览器，得同时满足三件事：

界面能被浏览器画出来：业务要拆得开——客户端发请求、服务器算、结果回传。这是第 2 章讲的整套骨架。

地址能连上：浏览器和服务器之间要有一条网络路径。第 3 章讲的那一整套（TCP/IP、DNS、TLS、代理）都是在满足这一条。

随时能重启：HTTP 是无状态的（2-6 讲过），一个请求结束，进程可以随时被换掉。整个 Web 的弹性扩展能力都建立在这条假设上。

搬不动的系统，就是踩了其中一条或者几条。

二、四类搬不动的系统

绑死硬件的：加密狗、专用板卡、工业控制总线。这些设备只在物理机器上存在，虚拟机和浏览器里都没有那个接口。

拆不开的：逻辑全塞在一个程序里，动一处全崩。重写成 Web 版本的成本，可能比重建一个新系统还高。

不许出门的：法规要求数据不能出机房。这一类不是【做不到】，是【不允许】——医保、金融、政务里很多。

不能等的：毫秒级响应。请求要走网络一个来回，物理距离本身就是延迟——光在光纤里跑 1000 公里单程就要约 5 毫秒，往返就是 10 毫秒。

这四类里，只有第一类是纯粹的技术障碍。剩下三类都是【不划算】或者【不允许】——它们不会因为技术进步而消失。

三、本地部署还占着多少

2026 年企业工作负载的分布大致是这样：

本地自建机房 35%，亚马逊云 AWS 32%，微软云 Azure 23%，谷歌云 GCP 10%。

三个云加起来 65%，剩下三分之一强还在机房里。 教材 5-1 的第二个关键词【内部部署】说的就是这 35%。

值得注意的是：这 35% 不是【还没来得及搬】，而是前面那批好搬的早就搬完了。十年前上云的第一波是邮件、协作、CRM、开发测试环境——这些负载本来就是云原生形状的。剩下的 ERP、核心银行、制造后端，才是真正的硬骨头。

四、硬搬的代价

2026 年 200 多个迁移项目的复盘结果是：65% 按时且按预算完成，38% 超预算（平均超 23%），31% 超期（头号原因是老系统太复杂），18% 至少回滚一部分工作负载。

一个 200 万美元的迁移项目，如果落在【超预算】那一档，就是多花 200 × 23% = 46 万美元；按概率摊开，期望溢价约 0.38 × 46 万 ≈ 17.5 万美元。这还没算那 18% 的回滚——回滚期新旧两套要并行跑，基础设施开支直接翻倍。

所以这一节的判据只需要一句话：这套系统放到浏览器里，业务还成立吗？ 不成立的那部分，就该老老实实待在机房里——这不是守旧，是不花冤枉钱。

五、动手 Demo：四类系统与硬搬的账

把这一节的几个数字拉到一起算一遍，看看【硬搬】到底要付多少钱。

local_vs_cloud = [("本地自建机房", 35), ("亚马逊云 AWS", 32),
                 ("微软云 Azure", 23), ("谷歌云 GCP", 10)]
for name, pct in local_vs_cloud:
    print("  %-14s %2d%%" % (name, pct))
print("  本地合计 35%%，三个云合计 %d%%" % sum(p for n, p in local_vs_cloud if "云" in n))

budget = 200          # 万美元
over_ratio = 0.23     # 平均超支比例
over_p = 0.38         # 超预算的项目占比
print("  200 万美元的项目若超预算：多花 %.0f 万美元" % (budget * over_ratio))
print("  按概率摊开：%.1f 万美元的期望溢价" % (budget * over_ratio * over_p))
print("  另外还有 18%% 的项目要回滚，回滚期新旧两套并行，开支翻倍")

实跑输出：

--------------------------------------------------------------------
D1 哪些系统搬不上 Web
--------------------------------------------------------------------
  教材 5-1 说，有些系统压根没法变成 Web 系统。按【为什么搬不动】分成四类：

  类别            为什么搬不动                                典型例子
  ------------------------------------------------------------------------------------
  绑死硬件        加密狗、专用板卡、工业总线只能在真机上跑    工控机、医疗影像设备
  拆不开          逻辑全塞在一个程序里，动一处全崩            自研二十年的老系统
  不许出门        法规要求数据不能出机房                      金融、政务、病历
  不能等          毫秒级响应，网络一去一回就超时              交易撮合、生产控制

  判据只有一句：**把这套系统放到浏览器里，业务还成立吗？**

  先看这些搬不动的系统现在站在哪儿。2026 年企业工作负载的分布：

  放在哪                    占比
  ----------------------------------------
  本地自建机房              35%
  亚马逊云 AWS              32%
  微软云 Azure              23%
  谷歌云 GCP                10%

  三个云加起来 65%，本地还留着三分之一强——搬不动的那些就在这 35% 里。

  再看真去搬的人，成绩单什么水平（2026 年 200 多个迁移项目的复盘）：

  结果                  比例        补充
  ------------------------------------------------------------------------------
  按时且按预算完成      65%         比 2022 年的 54% 好了一截
  超出预算              38%         平均超 23%
  超出工期              31%         头号原因是老系统太复杂
  至少回滚一部分        18%         性能、成本或兼容性问题

  最后算一笔硬搬的账。假设一个预算 200 万美元的迁移项目：

  ----------------------------------------------------------------------------------------
    落在【超预算】那 38% 里 → 200 × 23% = 多花 46 万美元
    按概率摊开：0.38 × 46 万 ≈ 17.5 万美元的期望溢价
    还有 18% 要回滚，回滚期新旧两套并行跑，基础设施开支直接翻倍
  ----------------------------------------------------------------------------------------

  结论：**搬不动的系统硬搬，等于先付 17.5 万美元的期望溢价，再赌一个 18% 的回滚。**

先看前几行：本地那 35% 不是零头，它是三个云里任何一个的两倍还多。教材把【内部部署】和【无法迁移】写在同一节标题里，就是因为这两件事本来就是一面。 再看最后两行：46 万和 17.5 万，是两个不同的数。46 万是【一旦超支就多花这么多】，17.5 万是【把 38% 的概率摊开之后的平均代价】。看预算风险的时候要看后者，看最坏情况的时候要看前者。

30 秒实验

1. 打开公司的一个内部系统，按 F12 切到网络面板，看它是不是标准的 HTTP 请求。
2. 找一个你还在用的老软件（门禁、开票、生产设备配套），看它是网页还是要装客户端。
3. 想想它能不能只靠浏览器用——如果不能，卡在上面三条前提里的哪一条。

常见误区

1. 错误：搬不上 Web 是因为技术不行。——纠正：多数情况是不允许或者不划算。法规限制、硬件依赖、重写成本高，都不是【技术做不到】。只有【绑死硬件】这一类是硬障碍。
2. 错误：云就是 Web。——纠正：两码事。云说的是【机器放在谁家】，Web 说的是【客户端用什么界面】。一家公司可以把 Web 系统跑在自己的机房里（这就是内部部署），也可以把老式的客户端软件跑在云主机上。
3. 错误：上云一定省钱。——纠正：取决于负载的形状。2026 年有 25% 到 53% 的企业至少把一部分负载搬回了本地，头号理由是成本。

• ☐ 下一节（5-2 不能停止运行的系统1：关键任务系统、响应时间）

相关笔记

• Web系统的多样化 —— 上一章讲【形态变多】，这一节讲【变不过去的那部分】
• 运行和管理服务器 —— 内部部署与云服务的分界就在这里
• 将希望装在云上的系统明确化 —— 决定【哪些系统上云】的第一步
• 在企业中活用Web系统 —— 企业里那些只对内部开放的 Web 系统
• 🕸️ Web技术原理 · 索引