一、四个阶段：从一台机器到一堆服务

系统架构的演进，可以按"一个整体被切成多细"来分：

这四个阶段不是"越新越好"，而是"切得越细，弹性越好、复杂度也越高"：

• 单体搬起来最容易（整台换掉就行），但它的弹性最差——整台一起扩，浪费大。
• 微服务的弹性最好（每个服务独立扩缩），但对运维能力的要求也最高。

所以上云不必然要向微服务演进。很多业务停在"分层架构"就已经拿到了主要的收益——该走到哪一步，取决于你的业务需不需要按服务独立扩容。

二、真正的工作：服务的调查与评估

教材这一节的副标题是"服务的调查与评估"，这才是核心动作。它的做法非常朴素：

1. 把系统拆成一个个服务（官网、数据库、打印、批处理……）；
2. 逐个问一句话：它离得开现在待的那台机器吗？
3. 按答案分三类处理。

那"离不开"具体指什么？主要是三样：

• 绑了硬件：加密狗、专用打印机、直连的仪器。
• 绑了专线或特殊链路：生产线控制、语音话务。
• 绑了自己的运行状态：数据库这类有状态的服务，因为数据要保持一致。

反过来，最容易上云的一类是"无状态"服务：它不保存任何属于自己的数据，每次请求都从头算，换一台机器照样跑——这正是上一篇"虚拟机可以被搬来搬去"在应用层的前提。

三、动手 Demo：九个服务逐个过一遍

# 评估核心：离得开现在待的那台机器吗
def assess(stateful, local_hw):
    if local_hw:
        return "不宜上云"          # 绑了物理硬件，搬不动
    if stateful:
        return "需改造后上云"      # 有状态，要先解决数据一致性
    return "可直接上云"            # 无状态，换台机器就能跑

实跑输出：

==================================================================================================
D13 云计算对系统架构的改变：从一台机器到一堆服务
==================================================================================================
  阶段            典型样子                      上云时的动作
  ----------------------------------------------------------------------------------------------
  单体应用        一台服务器装整套系统          整台搬到云主机即可
  分层架构        Web / 应用 / 数据库分开       每层单独上云、各自扩容
  微服务          一堆小服务各管一段            按服务容器化、按需伸缩
  云原生          一开始就按云写                天生就在云上，无所谓迁移

  【服务的调查与评估：九个服务逐个过一遍】
  服务                    有无状态      依赖本地硬件    评估结果              原因
  ------------------------------------------------------------------------------------------------
  对外官网                无状态        不依赖          可直接上云            换台机器就能跑
  商品图片存储            有数据        不依赖          可直接上云            对象存储天生适合
  订单数据库              有状态        不依赖          需改造后上云          要解决复制与一致性
  老打印服务              有状态        依赖专用打印机  不宜上云              物理设备搬不走
  生产线控制程序          有状态        依赖专线设备    不宜上云              延迟与安全都不允许
  内部 OA                 有状态        不依赖          可直接上云            标准 SaaS 就能满足
  数据分析批处理          无状态        不依赖          可直接上云            用完即关，最能省
  自研加密狗授权系统      有状态        依赖加密狗      不宜上云              硬件授权绑定
  呼叫中心话务系统        有状态        依赖专线        需改造后上云          语音链路要重新规划

  ④ 评估的核心只有一问：这个服务【离得开它现在待的那台机器吗】。
     无状态的最容易，改一改就能走；绑了硬件、绑了专线、绑了授权的，
     就得先改造甚至留在原地。教材把这一节叫【服务的调查与评估】——
     上云不是把系统整体搬走，是先拆成一个个服务，再逐个决定它的去向。

读这个输出：九行里最值得注意的是"不宜上云"那三行——它们都不是技术落后，而是"上云解决不了它的问题"。加密狗绑的是授权、打印机绑的是物理位置、生产线绑的是延迟与安全。把它们留在原地不是妥协，而是判断的结果。这也解释了为什么真实的迁移方案永远是混合的：一部分搬、一部分改、一部分留。

四、⚠️ 2026 现状

• "云原生"从目标变成了默认。今天的新应用大多一开始就按云的方式写（容器、无状态、按需伸缩），所以"迁移"这个动作本身在新系统上正在减少——难的是老系统的存量。
• 有状态服务的上云门槛明显降低了。托管数据库、分布式存储这些服务成熟之后，"有状态"不再等于"搬不动"，而是"要选对托管方式"——评估结论从"不宜"变成了"要用哪一类产品"。
• 拆得越细，成本治理越难。微服务化之后，资源被打散成几十上百份，"谁在用多少"变得难以看清。所以今天的评估多了一项：这个服务的成本能不能单独归集——拆得过细而无人治理，账单会失控。

30 秒实验

打开你电脑上的一个常用业务系统（或回想一个你熟悉的系统），试着拆三句：

1. 它哪一部分是"谁都能算"的？（比如页面展示、报表生成——这些通常可以直接上云）
2. 它哪一部分握着一份"只有它有"的数据？（这一部分要先解决数据怎么搬、怎么保持一致）
3. 它有没有绑着什么硬件或专线？（加密狗、打印机、专线——这部分多半要留在原地）

拆完你会发现："上云"这件事从来不是一个是非题，而是一张清单，每个格子的答案不一样。

常见误区

1. 错误：上云就是把整个系统搬到云上。——纠正：正确的动作是先拆、再逐个决定。整体搬迁会把"能搬的"和"搬不动的"绑在一起，结果是最难的那一小块拖住了全部。所以教材叫"服务的调查与评估"而不是"系统迁移"——评估在前，动作在后。

2. 错误：微服务架构比单体更先进，所以上云就该改成微服务。——纠正：拆得越细，弹性越好，但复杂度也越高。微服务带来独立扩缩的同时，也带来了分布式事务、跨服务排查、成本归集这些新问题。很多业务停在分层架构就够了——先看你的需求是不是"某个部分要单独扩容"，不是，就不必付出那份复杂度。

3. 错误：有状态的服务一定不能上云。——纠正："有状态"意味着要额外解决数据一致性，不是不能搬。Demo 里订单数据库的结论是"需改造后上云"，呼叫中心是"需改造"，只有绑了物理设备的才判"不宜"。差别在于：状态能不能被搬到别处、硬件能不能被替代。

4. 错误：不能上云的部分说明技术太老、需要淘汰。——纠正："不宜上云"往往是合理的判断，不是落后的证明。加密狗绑授权是为了防复制、生产线留在本地是为了延迟与安全——这些理由今天依然成立。把"留在本地"当成技术债去清，反而可能破坏原本正确的设计。

• ☐ 下一节（1-14 从基础设施看云计算的优越性：IT设备、相关设施）

相关笔记

• 云计算的历史与普及的原因 —— 上一篇：集中化为什么划算
• 从基础设施看云计算的优越性 —— 下一篇：从设施这一侧算云到底省在哪
• 云计算的服务器是虚拟服务器 —— 应用能搬来搬去，前提是资源本身能被搬运
• 云服务的两个潮流 —— "一部分搬、一部分留"，就是混合云
• ☁️ 云计算 · 索引 —— 全课路线图