可扩展的基本思想是"拆"，及三种拆分思路的范围关系

软件系统和硬件、建筑最根本的差异在于软件天生是可扩展的——一颗CPU生产出来就不会再回工厂加功能，一座金字塔矗立千年结构从未改变，但一个软件系统如果开发出来后再也没有更新迭代，反而说明它没有生命力，真正有生命力的系统（如Windows从3.0一路演化到10）都在持续发展。这种天生的可扩展性既是软件的魅力所在，也是难点所在：魅力在于可以不断通过修改扩展让系统跟上新需求；难点在于如何以最小代价完成扩展，因为很多时候牵一发动全身，扩展时到处都要改、到处都要推倒重来，改动范围越大，投入越大、出错概率也越大。可扩展性架构设计万变不离其宗，背后的核心思想可以归结为一个字：”拆”——把原本大一统的系统拆成多个小规模部分，扩展时只需要动其中一部分，不用整个系统到处改，从而缩小改动范围、降低改动风险。但软件系统的”拆”和日常生活里用推土机拆房子、用剪刀拆快递这种破坏性的拆完全不同，软件的拆是建设性的——目标不是摧毁系统，而是让系统变得更优美、更具备可扩展性，因此难度要高得多。按不同思路拆分软件系统，会得到不同架构，常见的拆分思路有三种，理解它们的关键是弄清”流程”“服务”“功能”三者的范围关系：从大到小依次是流程>服务>功能。以TCP/IP协议栈为例：流程对应”应用层→传输层→网络层→物理和数据链路层”这个不管应用层具体是什么、都固定不变的通信流程；服务对应应用层里的HTTP、FTP、SMTP这类具体服务（HTTP提供Web服务、FTP提供文件服务、SMTP提供邮件服务）；功能对应每个服务内部更细粒度的能力（HTTP的GET/POST、FTP的上传下载、SMTP的邮件收发）。据此，面向流程拆分是把整个业务流程切成若干阶段、每个阶段作为一部分；面向服务拆分是把系统提供的各类服务分别独立出来；面向功能拆分是把每个服务内部提供的具体功能进一步拆细。

结构图：

flowchart TB
  A["可扩展架构的基本思想：拆"]
  A --> B["三种拆分思路，范围从大到小"]
  B --> C["面向流程拆分<br/>如TCP/IP：应用层→传输层→网络层→物理数据链路层"]
  B --> D["面向服务拆分<br/>如应用层内：HTTP/FTP/SMTP各自独立服务"]
  B --> E["面向功能拆分<br/>如HTTP服务内：GET/POST等细粒度功能"]
  C --> F["流程 > 服务 > 功能"]
  D --> F
  E --> F