架构演进史,技术选型的秘密全文约 1.6 万字,成稿于 2026 年 8 月。以行业架构演进史为主轴,穿插真实系统案例。不吹新架构,不贬老架构,只回答一个问题:每一代架构师,到底是在什么约束下做选型的,为什么选,事后对错如何。文中虚构团队故事均已标注,行业案例(Prime Video、Segment、Shopify、Netflix、Amazon 等)均来自公开出处。观点谱系:本文的核心观点(先单体后拆分、成熟技术总账更便宜、架构是组织的一面镜子等)承自 Martin Fowler、Dan McKinley、DHH 等人的公开论述,本文的贡献在于把它们放进六十年演进史中检验、本地化,并沉淀为可执行的检查清单。论证依赖行业公开复盘与从业者共识,属经验归纳而非严格学术证据,适用边界见文末附则。目录开篇:每个时代的架构师,都觉得自己选错了第1章 主机时代(1960s–1980s):硬件贵到极致,集中式就是唯一答案第2章 客户机/服务器时代(1980s–1990s):计算下放,然后被两层架构反噬第3章 Web 与单体黄金期(1990s–2005):第一场"框架选型"大战第4章 SOA 与 ESB 时代(2005–2012):企业集成的野心,和中央瓶颈的溃败第5章 互联网规模时代(2008–2015):以 MySQL 为中心的外围工程化第6章 微服务时代(2014–2020):独立的收益,和刚性成本第7章 云原生与平台工程(2018–2023):从选组件,到选平台第8章 AI 原生时代(2023–今):大模型没有消灭约束,只是换了约束第9章 选型的底层逻辑:约束、可逆性、总账与组织第10章 反模式与决策检查清单结语:架构没有终局附:写作时间、观点谱系与适用边界开篇:每个时代的架构师,都觉得自己选错了2019 年,一个做跨境电商的团队干了一件事(虚构,但可对应到多起真实事件):把核心交易系统从单体拆成微服务。拆了一年,上线三个月,然后他们花了一个季度把几个最痛的服务合并了回去。技术负责人在复盘会上说了句大实话:“2015 年我劝老板别拆,被打成保守派;2019 年我牵头拆,被打成激进派;现在我合回去,不知道会被打成什么派。”这句话几乎可以放进任何一年:2005 年不上 SOA 被说落后,2016 年不拆微服务被面试官嫌弃,2023 年还吹微服务被同行嘲笑。每个时代都有自己的"政治正确"。如果你把时间轴拉长,会发现一个耐人寻味的事实:每一代架构师都觉得自己的选型是错的,而每一代的技术选型在当时都有充分理由。大型机的集中式,在当时是最便宜的方案;两层的 C/S,在当时是最快的方案;微服务,在组织到了那个规模后是唯一能走的路。事后看全是教训,当时看全是理性。所以这篇文章不想做"事后诸葛亮",只想做一件事:把架构演进史重讲一遍,但每一次决策,都放回它当时的约束里去。当你把"约束"这根主线拉出来,技术选型的秘密会自己浮现出来:架构没有进步与退步,只有约束的变化。技术选型不是选"最好的技术",而是在当下的约束下,选代价最小、后悔空间最大的方案。再补一句更扎心的:架构演进史其实不是技术的进化史,而是复杂度如何被引入、又如何被治理的历史。每一次新架构的诞生,都是上一代架构的某个约束被打破;每一次选型灾难,都是有人把"前代的成功条件"当成了"永恒真理"。这句话请记住,后面每一章都会反复验证它。先看一张八十年演进总览,本文的所有章节都挂在它的节点上:主机1960s-80s约束:硬件贵C/S1980s-90s约束:变更成本Web单体1990s-05约束:交付速度SOA/ESB2005-12约束:系统集成互联网分布式2008-15约束:流量与成本微服务2014-20约束:组织规模云原生2018-23约束:运维成本AI原生2023-今约束:智能成本与合规每个时代的架构,都是被上一代的约束逼出来的;每个时代的悲剧,都是把上一代的约束当成了永恒。下面,我们从 1960 年代开始。那个时代没有微服务、没有云、甚至没有"架构师"这个头衔,但那个时代的技术决策,决定了此后六十年所有选型的底层逻辑。第1章 主机时代(1960s–1980s):硬件贵到极致,集中式就是唯一答案1.1 当时的约束:一台机器 200 万美元,程序员比机器便宜今天你很难体会 1965 年的工程师面对的世界:一台 IBM System/360 中型系统的价格在百万美元级别,大型配置上千万美元,而一台内存以 KB 计的小机器,就能占满一个机房。与之对比,一个程序员的年薪在当时不过一两万美元。硬件是稀缺资源,人是便宜资源。这就是主机时代唯一的约束,它决定了此后二十年的所有架构决策:集中式部署:计算、存储、应用全部放在一台主机上,通过终端(哑终端,只有键盘和屏幕,没有计算能力)访问。批处理为主:业务逻辑按批次跑,晚上跑完白天出报表。银行、保险、铁路、政府的核心业务全部如此。专有软件栈:IBM 的 OS/360、COBOL、CICS(事务处理中间件),后来还有 IMS 数据库。每一层都是厂商锁定的,换一家厂商等于重写。你可能会觉得"集中式好落后",但站在当时算总账:买一台大机器,比买十台小机器加十个运维团队便宜,而且可靠性更高。硬件贵,所以一切软件设计都要"省着用":省内存、省磁盘、省 CPU。COBOL 里为什么有那么多对记录格式的精确描述?因为那时候磁盘 1 字节都要精打细算。当时的架构长这样——一切计算都在主机里,终端只是"眼睛和手":哑终端 1只有键盘和屏幕主机应用 + 数据 + 事务处理哑终端 2哑终端 N报表 / 批处理输出1.2 主机时代的"选型秘密",藏在三个遗产里主机时代没有我们今天意义的"技术选型"——因为根本没得选,IBM 就是全部。但这段历史留下了三个遗产,今天依然在影响我们:遗产一:事务处理(Transaction)成为"可靠性"的代名词。CICS 和 IMS 定义了"要么全做,要么全不做"的 ACID 语义。此后六十年,分布式系统的所有痛苦——两阶段提交、分布式事务、最终一致性——本质上都是在回答同一个问题:当系统不在一台机器上时,怎么保住主机时代理所当然的 ACID?我们今天为分布式事务掉的所有头发,都是主机时代欠下的。遗产二:核心系统的"不迁移"惯性。全球主要银行的账户核心系统,至今仍有大量跑在 COBOL 上。不是没人想换,而是:一台跑了三十年的主机,承载着几千个业务规则,没人能证明"换掉它不会出错"。可靠性越高的系统,越不敢动;越不敢动,技术债务越高;债务越高,越没人敢动。这个死循环不是技术问题,是风险偏好问题——它在后面每一章都会以不同形式重演。遗产三:集中式思维的惯性。直到今天,还有很多企业架构师的默认假设是"数据应该集中、控制应该集中、一切应该集中"。这个思维不是从教科书来的,是从"硬件很贵"的时代遗传下来的。当云计算把硬件价格打下来之后,这种惯性就变成了包袱。1.3 一个今天仍在上演的主机故事(虚构,但每天都在发生)2020 年,我认识的一位银行架构师接到任务:把核心系统从大型机往分布式架构迁移。项目立项时,业务方给的期限是三年。三年后,迁移范围缩水到"只迁外围系统",核心账务模块依然留在主机上。他说了句很诚实的话:“我们算过,迁移能省 40% 的运维成本,但迁移失败的风险,业务部门不愿意承担。架构选型最后选什么,不取决于技术,取决于谁为失败买单。”这句话请划重点。"谁为失败买单"是贯穿全部技术选型的隐藏变量。后面 SOA 为什么失败、微服务为什么被过度采用、AI 为什么人人都在试,都能用它解释。1.4 这一章的选型秘密当你面对的是一个"没得选"的市场时,选型的重心不是挑技术,而是识别哪些约束会变、哪些资产会被锁死。主机时代锁死的是数据与核心逻辑(COBOL),今天锁死你的可能是云厂商账单、模型供应商或某个中间件。谁为失败买单,往往比技术评测结果更决定选型的真实走向。第2章 客户机/服务器时代(1980s–1990s):计算下放,然后被两层架构反噬2.1 约束变了:硬件降价,局域网普及,人变贵了1980 年代,个人电脑开始普及,以太网让办公室的机器能连起来。硬件的价格曲线第一次让"给每个人一台电脑"成为可能,而程序员和 IT 人员的薪资在涨。约束翻转了:机器变便宜,人变贵。于是架构师做了一个顺理成章的决定:把计算能力从昂贵的主机,下放到便宜的 PC 上。这就是客户机/服务器(Client/Server)架构——数据库和业务逻辑留在服务器,界面和一部分逻辑跑到客户端。这个决定在当时是教科书级的正确:PC 便宜、部署快、界面体验好(图形界面 vs 哑终端)。两层的 C/S 架构(PowerBuilder、Delphi、Visual Basic + SQL Server/Oracle)统治了 1990 年代上半期的企业应用。2.2 两层架构的溃败:逻辑塞进客户端,升级是噩梦但 C/S 迅速暴露出一个要命的缺陷:逻辑放哪?客户端便宜,于是业务逻辑被塞进了客户端程序——校验、计算、甚至部分数据处理都在 PC 上。后果今天看一目了然:升级是灾难:每个用户的 PC 上都要装客户端 架构演进史,技术选型的秘密
架构演进史,技术选型的秘密全文约 1.6 万字,成稿于 2026 年 8 月。以行业架构演进史为主轴,穿插真实系统案例。不吹新架构,不贬老架构,只回答一个问题:每一代架构师,到底是在什么约束下做选型的,为什么选,事后对错如何。文中虚构团队故事均已标注,行业案例(Prime Video、Segment、Shopify、Netflix、Amazon 等)均来自公开出处。观点谱系:本文的核心观点(先单体后拆分、成熟技术总账更便宜、架构是组织的一面镜子等)承自 Martin Fowler、Dan McKinley、DHH 等人的公开论述,本文的贡献在于把它们放进六十年演进史中检验、本地化,并沉淀为可执行的检查清单。论证依赖行业公开复盘与从业者共识,属经验归纳而非严格学术证据,适用边界见文末附则。目录开篇:每个时代的架构师,都觉得自己选错了第1章 主机时代(1960s–1980s):硬件贵到极致,集中式就是唯一答案第2章 客户机/服务器时代(1980s–1990s):计算下放,然后被两层架构反噬第3章 Web 与单体黄金期(1990s–2005):第一场"框架选型"大战第4章 SOA 与 ESB 时代(2005–2012):企业集成的野心,和中央瓶颈的溃败第5章 互联网规模时代(2008–2015):以 MySQL 为中心的外围工程化第6章 微服务时代(2014–2020):独立的收益,和刚性成本第7章 云原生与平台工程(2018–2023):从选组件,到选平台第8章 AI 原生时代(2023–今):大模型没有消灭约束,只是换了约束第9章 选型的底层逻辑:约束、可逆性、总账与组织第10章 反模式与决策检查清单结语:架构没有终局附:写作时间、观点谱系与适用边界开篇:每个时代的架构师,都觉得自己选错了2019 年,一个做跨境电商的团队干了一件事(虚构,但可对应到多起真实事件):把核心交易系统从单体拆成微服务。拆了一年,上线三个月,然后他们花了一个季度把几个最痛的服务合并了回去。技术负责人在复盘会上说了句大实话:“2015 年我劝老板别拆,被打成保守派;2019 年我牵头拆,被打成激进派;现在我合回去,不知道会被打成什么派。”这句话几乎可以放进任何一年:2005 年不上 SOA 被说落后,2016 年不拆微服务被面试官嫌弃,2023 年还吹微服务被同行嘲笑。每个时代都有自己的"政治正确"。如果你把时间轴拉长,会发现一个耐人寻味的事实:每一代架构师都觉得自己的选型是错的,而每一代的技术选型在当时都有充分理由。大型机的集中式,在当时是最便宜的方案;两层的 C/S,在当时是最快的方案;微服务,在组织到了那个规模后是唯一能走的路。事后看全是教训,当时看全是理性。所以这篇文章不想做"事后诸葛亮",只想做一件事:把架构演进史重讲一遍,但每一次决策,都放回它当时的约束里去。当你把"约束"这根主线拉出来,技术选型的秘密会自己浮现出来:架构没有进步与退步,只有约束的变化。技术选型不是选"最好的技术",而是在当下的约束下,选代价最小、后悔空间最大的方案。再补一句更扎心的:架构演进史其实不是技术的进化史,而是复杂度如何被引入、又如何被治理的历史。每一次新架构的诞生,都是上一代架构的某个约束被打破;每一次选型灾难,都是有人把"前代的成功条件"当成了"永恒真理"。这句话请记住,后面每一章都会反复验证它。先看一张八十年演进总览,本文的所有章节都挂在它的节点上:主机1960s-80s约束:硬件贵C/S1980s-90s约束:变更成本Web单体1990s-05约束:交付速度SOA/ESB2005-12约束:系统集成互联网分布式2008-15约束:流量与成本微服务2014-20约束:组织规模云原生2018-23约束:运维成本AI原生2023-今约束:智能成本与合规每个时代的架构,都是被上一代的约束逼出来的;每个时代的悲剧,都是把上一代的约束当成了永恒。下面,我们从 1960 年代开始。那个时代没有微服务、没有云、甚至没有"架构师"这个头衔,但那个时代的技术决策,决定了此后六十年所有选型的底层逻辑。第1章 主机时代(1960s–1980s):硬件贵到极致,集中式就是唯一答案1.1 当时的约束:一台机器 200 万美元,程序员比机器便宜今天你很难体会 1965 年的工程师面对的世界:一台 IBM System/360 中型系统的价格在百万美元级别,大型配置上千万美元,而一台内存以 KB 计的小机器,就能占满一个机房。与之对比,一个程序员的年薪在当时不过一两万美元。硬件是稀缺资源,人是便宜资源。这就是主机时代唯一的约束,它决定了此后二十年的所有架构决策:集中式部署:计算、存储、应用全部放在一台主机上,通过终端(哑终端,只有键盘和屏幕,没有计算能力)访问。批处理为主:业务逻辑按批次跑,晚上跑完白天出报表。银行、保险、铁路、政府的核心业务全部如此。专有软件栈:IBM 的 OS/360、COBOL、CICS(事务处理中间件),后来还有 IMS 数据库。每一层都是厂商锁定的,换一家厂商等于重写。你可能会觉得"集中式好落后",但站在当时算总账:买一台大机器,比买十台小机器加十个运维团队便宜,而且可靠性更高。硬件贵,所以一切软件设计都要"省着用":省内存、省磁盘、省 CPU。COBOL 里为什么有那么多对记录格式的精确描述?因为那时候磁盘 1 字节都要精打细算。当时的架构长这样——一切计算都在主机里,终端只是"眼睛和手":哑终端 1只有键盘和屏幕主机应用 + 数据 + 事务处理哑终端 2哑终端 N报表 / 批处理输出1.2 主机时代的"选型秘密",藏在三个遗产里主机时代没有我们今天意义的"技术选型"——因为根本没得选,IBM 就是全部。但这段历史留下了三个遗产,今天依然在影响我们:遗产一:事务处理(Transaction)成为"可靠性"的代名词。CICS 和 IMS 定义了"要么全做,要么全不做"的 ACID 语义。此后六十年,分布式系统的所有痛苦——两阶段提交、分布式事务、最终一致性——本质上都是在回答同一个问题:当系统不在一台机器上时,怎么保住主机时代理所当然的 ACID?我们今天为分布式事务掉的所有头发,都是主机时代欠下的。遗产二:核心系统的"不迁移"惯性。全球主要银行的账户核心系统,至今仍有大量跑在 COBOL 上。不是没人想换,而是:一台跑了三十年的主机,承载着几千个业务规则,没人能证明"换掉它不会出错"。可靠性越高的系统,越不敢动;越不敢动,技术债务越高;债务越高,越没人敢动。这个死循环不是技术问题,是风险偏好问题——它在后面每一章都会以不同形式重演。遗产三:集中式思维的惯性。直到今天,还有很多企业架构师的默认假设是"数据应该集中、控制应该集中、一切应该集中"。这个思维不是从教科书来的,是从"硬件很贵"的时代遗传下来的。当云计算把硬件价格打下来之后,这种惯性就变成了包袱。1.3 一个今天仍在上演的主机故事(虚构,但每天都在发生)2020 年,我认识的一位银行架构师接到任务:把核心系统从大型机往分布式架构迁移。项目立项时,业务方给的期限是三年。三年后,迁移范围缩水到"只迁外围系统",核心账务模块依然留在主机上。他说了句很诚实的话:“我们算过,迁移能省 40% 的运维成本,但迁移失败的风险,业务部门不愿意承担。架构选型最后选什么,不取决于技术,取决于谁为失败买单。”这句话请划重点。"谁为失败买单"是贯穿全部技术选型的隐藏变量。后面 SOA 为什么失败、微服务为什么被过度采用、AI 为什么人人都在试,都能用它解释。1.4 这一章的选型秘密当你面对的是一个"没得选"的市场时,选型的重心不是挑技术,而是识别哪些约束会变、哪些资产会被锁死。主机时代锁死的是数据与核心逻辑(COBOL),今天锁死你的可能是云厂商账单、模型供应商或某个中间件。谁为失败买单,往往比技术评测结果更决定选型的真实走向。第2章 客户机/服务器时代(1980s–1990s):计算下放,然后被两层架构反噬2.1 约束变了:硬件降价,局域网普及,人变贵了1980 年代,个人电脑开始普及,以太网让办公室的机器能连起来。硬件的价格曲线第一次让"给每个人一台电脑"成为可能,而程序员和 IT 人员的薪资在涨。约束翻转了:机器变便宜,人变贵。于是架构师做了一个顺理成章的决定:把计算能力从昂贵的主机,下放到便宜的 PC 上。这就是客户机/服务器(Client/Server)架构——数据库和业务逻辑留在服务器,界面和一部分逻辑跑到客户端。这个决定在当时是教科书级的正确:PC 便宜、部署快、界面体验好(图形界面 vs 哑终端)。两层的 C/S 架构(PowerBuilder、Delphi、Visual Basic + SQL Server/Oracle)统治了 1990 年代上半期的企业应用。2.2 两层架构的溃败:逻辑塞进客户端,升级是噩梦但 C/S 迅速暴露出一个要命的缺陷:逻辑放哪?客户端便宜,于是业务逻辑被塞进了客户端程序——校验、计算、甚至部分数据处理都在 PC 上。后果今天看一目了然:升级是灾难:每个用户的 PC 上都要装客户端