这篇文章原本想写成“硬核”技术科普，来回顾和展望软件系统架构演化——也确实总结得差不多了，本质、驱动力、底层逻辑、基本原理、核心问题、价值体现、各发展阶段的定义和主流方案、所包含组件及历史里程碑统统都有。鉴于AI才是当红炸子鸡，大模型、智能体、驾驭工程才能博得一些关注，不如轻松点儿，用自己的视角来讲故事。讲述架构发展史的文章有很多，不少关于架构的书里也有相关章节，不差我一个，所以写点不一样的。
架构演化阶段论
首先要说，所有的"架构演化阶段论"，都是事后诸葛亮，包括本文。那些整整齐齐的"单体→分布式→SOA→微服务→云原生→AI原生"或者"单体-C/S分层→SOA→微服务→云→云原生/Serverless"的分段框架，都是后人总结实践经验形成的叙事框架，只是为了便于人脑记忆和理解，即便是成为“标准”，也很难“标准化实现”。真实的历史是混乱的，当下是正在发生的历史，未来是将要发生的历史，都是如此。从我个人角度，简单好理解就够了，比如"单体→原始分布式→SOA→微服务→云原生"这样。
工程师不知道自己处于"微服务时代"还是"云原生时代"。他们只是面对一个个具体的问题——系统扛不住了、故障太多了、部署太慢了——然后在各种限制下，做一个当时能做的最优决策。这个限制可能是团队规模、可能是技术基础、可能是预算、可能是时间压力，也可能只是老板一句"这个需求明天就要上线"。所以，与其说架构在"演化"或者“演进”，不如说在"权衡"、在“取舍”、在“折中”、在“急中生智”。演进是结果，“解决当下问题”才是过程。
绝大多数的软件系统架构都不是标准化的，也不需要严格遵循所谓当下阶段定义。单体够用就用单体，用了ESB但可能没有服务目录，用着Spring Cloud框架不代表真的做好了微服务拆解，云原生也可能是只是把应用装进Docker部署到云上，AI原生可以是把“Loading”改成“Thinking”。
我工作后参与开发的第一个系统，覆盖8省1市相当于三分之一个中国的业务，是C/S架构——用PowerBuilder写客户端，连后台Oracle数据库，算分布式还是单体，做的时候没听同事提过，系统能跑、需求能满足，就是好架构——甚至那时候可能都没人提“架构”。
之后还用过C++Builder和Delphi，连过Sybase数据库，中间还会加一层Tuxedo或者CICS，变成三层架构，中间这层就叫“中间件”。技术上其实已经是分布式了，只是这些系统运行在小型机和大型机上，是封闭的商业生态，不是后来的所谓互联网分布式架构。
后来的工作中又经历了SOA、微服务、云原生，每个阶段都亲身见证过。带着这个视角，来看架构到底是怎么演进的，其中到底有没有什么规律。
原始分布式：一个美丽的设想（1980s-2000s）
分布式架构的故事从一个优雅的理想开始。那个年代，处理大型计算任务需要多台机器协同。工程师们提出了一个设想——让分布式变得"透明"。位置透明、访问透明、失败透明。程序员写代码就像写单机一样，背后有多少台机器、在哪里、出了什么故障，统统感知不到。
CORBA、DCE/RPC就是这个理想的产物。IBM、Oracle、Sun，那个年代最聪明的工程师团队，设计出了精密的架构体系——IDL生成跨语言代理，IIOP协议栈，理论上可以让任何系统互联互通。概念上听起来完美。然后现实给了一记响亮的耳光。网络延迟不是零，消息可能重复，节点随时可能宕机。这些分布式系统的本质特性，不会因为在上面加了一层"透明抽象"就消失。Sun工程师Peter Deutsch早在1994年就总结出了"分布式计算的八个谬误"——网络是可靠的、延迟是零、带宽是无限的……这些工程师想当然的假设，一旦遇上真实网络全部失效。
原始分布式架构没有解决这些问题，只是把它们藏了起来。把复杂性藏起来，不等于解决了复杂性，只是让它以更隐蔽的方式爆发。
SOA：中心化管理（2000s-2010s）
既然分布式无法透明，那就集中管理。ESB（企业服务总线）是SOA时代最流行的企业级架构组件。思路清晰：所有服务通过一个总线通信，总线负责协议转换、路由寻址、消息管理。IBM的WebSphere Message Broker、Oracle Service Bus、TIBCO Enterprise Message Service、F5硬件负载均衡、Oracle 、DB2、SQLServer数据库集群，配套HP、IBM、Sun小型机，是SOA时代的标准方案。
2005年，Gartner将SOA列为值得关注的企业级技术趋势。衍生出的基于SOAP的Web Services，追求标准化和严谨，代价是又重又慢。这套方案有它的适用场景——对规模中等、系统相对稳定、有强异构集成需求的大企业，效果不错。各种遗留系统通过ESB打通，集成成本确实降低了。但对于用户量爆炸式增长的互联网公司——ESB的吞吐量很快撑不住。总线是单点。一旦成为瓶颈，整个系统雪崩。
我在亚信用过TIBCO——非常优秀的ESB产品，开发工具和运行容器都很专业，但好用不等于能用好。ESB架构对服务治理和组织协作的要求极高，没有匹配的治理能力，有总线也是摆设，服务最终还是各自为政。工具没有问题，问题在于SOA的理想，大多数团队做不到，最后ESB只是成了系统集成工具。
SOA架构的中心化治理解决了异构系统集成，却制造了单点瓶颈和性能天花板。
微服务：去中心化的代价（2010s-2020s）
小型机和SOA扛不住互联网公司业务的高速发展，自然要找新的方案，开始去IOE，拥抱开源，搞LAMP，用X86的服务器，搭虚拟机，搞出了云计算和微服务。
比如在当当那几年，我们从.net转向电商主流的开源Java技术栈和MySQL，架构部基于Dubbo做了一些扩展，开源了DubboX——因为当时Dubbo版本不支持HTTP调用，而我们需要对接原有的异构系统，后来还做了Sharding-JDBC（现在的ShardingSphere），来解决分库分表问题。
2014年，ThoughtWorks的Martin Fowler与James Lewis联署发表了那篇定义性文章，把这套去中心化服务自治的做法正式命名为"微服务"——Netflix、Amazon等早已在实践这套思路。核心思想是把中心化的ESB扔掉，改成服务自治：每个服务独立开发、独立部署，服务之间用REST或消息队列通信，用软件实现负载均衡，用开源组件替代商业软件。
Dubbo、Spring Cloud、Eureka、Hystrix……降本提效效果显著。迭代速度从"月级"变成了"周级"甚至“日级”。这样的架构是互联网公司爆发式增长的技术底座。那些年，整个行业都在做“微服务化”——把大应用切成几十个、上百个小服务，随之而来的则是技术团队的快速膨胀。
这里有个需要戳破的幻觉：用着微服务框架，不代表真的做好了服务拆解，实现高内聚低耦合。有的系统，分布式的复杂性全有了，单体的问题一个没解决——服务之间调用链路一层套一层，但边界划分不清，数据模型依然耦合，甚至共用数据库。服务拆分之后，运维复杂度指数级上升。一个线上Bug，可能要翻遍五六个服务的日志才能定位。分布式链路追踪、分布式事务、跨服务调试——每一个都是独立的技术难题。去中心化解决了扩展性问题，把运维复杂度摊给了开发和运维团队，Devops成为必备素养！
微服务的复杂度，在"异地多活"这个方向上被推向极限。我们在饿了么做过异地多活架构升级——多个地域的数据中心同时提供服务，单一机房故障，流量切换，用户无感知。听起来是个运维方案，实际上是分布式系统最顶级的工程挑战之一：数据怎么分片？跨机房的一致性怎么保证？写操作怎么路由？故障切换的时延窗口有多宽？数据冲突怎么解决？CAP定理、最终一致性——在异地多活里全部变成了必须解决的工程问题。
微服务架构和技术团队扩张支撑了业务快速发展，但也给适应业务萎缩和转型设置了障碍，拆服务简单，想再合起来谈何容易？毕竟系统不是技术团队，不能说砍就砍。
云原生：研发标准化，运维自动化（2020s-至今）
云原生不是云计算，是基于容器的新架构，CNCF把Pivotal提出的概念重新定义来讲新故事。至于容器，早在2013-14年，我们在当当就做过Docker的调研，看到了容器化的方向，只是没想到Docker、Mesos最后都败给了K8S。
有人总结软件架构的差别是“以谁为中心”，从“服务器”到“资源”到“应用”，云原生时代“系统”彻底解耦掉了，“Serverless”了，只剩下“应用”，不知道接下来要说的是以“Agent”为中心，还是以“Token”为中心，总不至于以“结果”为中心吧？
换个角度看，前几个阶段有个共同特点——人来管。架构师设计架构，运维配置服务，开发者排查故障。云原生的核心思路是：让研发、运维从一开始就按照云（容器）的标准方式，从而实现应用运维的自动化。Kubernetes负责容器调度，自动扩缩容，节点故障自动迁移；Istio/Linkerd的Service Mesh接管服务间通信，熔断限流、链路追踪——这些以前需要人工配置的事情，变成了声明式配置，由基础设施自动执行。但云原生并没有消灭前几代的架构，只是在下面又加了一层。
这几年做了基于K8s的云原生架构升级，搭建新的DevOps流水线，加上基于OTEL的可观测能力，推动原有系统改造迁移。金融行业的云原生架构落地，跟互联网公司有明显不同——可谓如履薄冰，做好了随时出故障的心理准备，也知道出了故障系统会更健壮，但还是得祈祷“永不宕机”。
据我观察，金融行业系统的真实状态是：物理机、虚拟机、容器并存，有微服务也有单体系统，甚至可能还有ESB遗留，各种架构相安无事，能跑就行。这不是技术债——这是现实。
云原生定义了新的研发运维模式，也抬高了技术门槛，能玩得转本身就是实力的体现，实力有限就别给自己挖坑。
两条规律
回顾完这几个阶段，有两条规律值得单独说。
一、解耦粒度细化和故障域隔离强化，是两条主线。
每一次架构演进，都是在这两个维度上同时推进，整体趋势是粒度越细，协调成本越高，这个权衡没有完美答案。
解耦粒度：单体 → RPC → SOA服务解耦 → 微服务业务边界解耦 → 云原生基础设施解耦。
故障域隔离：无隔离 → 熔断限流（微服务）→ Service Mesh + K8s自愈（云原生）。
值得注意的是，SOA阶段在这条线上是个例外——ESB制造了新的单点，反而是故障隔离的倒退。这也解释了为什么互联网公司不用ESB：它在解耦维度有价值，却在隔离维度挖了坑。
二、从"追求零故障"到"设计容错性"，是一次理念转变。
以前架构师的目标，是建一个永远不会出错的系统。现在架构师的目标，是建一个出了错也能快速恢复的系统。
Netflix的Chaos Monkey——在生产环境随机终止服务实例的工具，混沌工程的早期实践——是这种转变的极致体现。主动引入故障，是为了验证系统的容错能力够不够强。阿里的“双十一”是融合了事前模拟、精准预测、流量调控、资源调度、降级熔断的一套大工程，一次次提升线上线下的系统能力极限。
拥抱不确定性，才是软件架构的第一性原理。AI大模型的到来，把不确定性往前推了更大的一步。
AI时代的新挑战
现在谈AI原生架构，需要保持谦逊。大模型已经来了，AI Agent、工作流编排、Skills仓库、AI网关、模型路由层……各种新概念和新组件在快速涌现。已经有人开始喊"AI Native架构"，也有人在聊"AI云原生架构"。但这个领域现在没有共识，大家都在探索，都在试错。新范式的共识，总是在大量实践之后才形成。
可以确定的是，AI时代带来了几个前所未有的新挑战，架构的旧答案在这里还不够用。
挑战一：不确定性的质变
之前不管哪个阶段系统的故障是确定的——节点宕机有心跳检测，网络超时有熔断器，消息丢失有重试机制，实在搞不清楚的就当做“黑天鹅事件”处理。这些故障有固定的失败模式，可以被监控、被告警、被自动恢复。AI模型的"幻觉"不一样。一个看起来完全正常的输出，可能是错误的——而且你不知道它是错的。传统的健康检查发现不了这种故障，得上升到业务监控的层面，才能识别"输出看起来成功、但语义上是错的"的问题。
挑战二：状态管理的张力
云原生有一个核心理念——无状态化。服务本身不保存状态，状态全部外置到数据库或缓存，这样才能任意横向扩展。K8S的Pod可以随时被杀掉重建，正是基于这个前提。
AI Agent打破了这个前提。Agent需要维护对话历史、任务进度、工具调用记忆——这是一种内生的"有状态"需求。而且这个状态跟传统数据库里的结构化数据不同，它是语义状态，是上下文窗口。怎么持久化？怎么分片？Agent横向扩展时怎么保证上下文一致性？一想就头疼。
挑战三：编排逻辑的不确定性
传统的服务编排是确定的——服务A调用服务B，返回结果，流程在代码里写死，行为可预期。AI Agent的编排是动态的——Agent会根据推理结果决定下一步调用哪个工具，调用几次，要不要回溯，什么时候停止。这个决策过程不在代码里，在模型里。这给服务治理带来了新问题：你无法静态分析一个AI工作流的调用链路，无法预估它的资源消耗，也无法像传统限流那样精确控制它的行为边界。
挑战四：可观测性的新维度
传统可观测性三大支柱——Metrics、Logs、Traces——在AI系统里都还在，但不够用了。
我们需要新的观测维度：模型输出的质量评估、推理链路的语义追踪、Token消耗的成本监控、幻觉率的统计……OpenTelemetry的现有标准还没有覆盖这些。
更难的是：怎么定义"AI系统健康"？CPU占用率正常、响应时间达标，但输出质量悄悄下降——这种退化，传统监控发现不了。
这四个挑战，指向同一个根本矛盾——软件架构演进积累的方法论，建立在"故障是可观测的、行为是可预期的"这个前提上，但AI打破了这个前提。好在架构演进的历史里留下的另一个遗产，在AI时代可能比以往更有价值——"不追求零故障，而是设计容错性"这个理念。AI系统不可能消除幻觉，正如分布式系统不可能消除网络分区。重要的是：怎么设计系统，让它在模型出错时依然可控、可恢复、损失可界定，也许“驾驭工程”就是答案。
无论怎样，系统好用才是王道。这话在以前是对的，在AI时代也是对的。至于AI原生的定义，等到新一代架构涌现之后自有人来评说。马克·吐温有句话——"历史不会重复，但总是押韵。"从单体到分布式，从SOA到微服务，从云原生到AI原生，每个历史阶段的问题不同，但架构理念相同：解耦、隔离、容错、拥抱不确定性，权衡、取舍、折中、解决当下的问题。
正如生命，从单细胞到多细胞，从无性到有性，从本能到智能——没有门纲目科属的定义，只有每一次对环境变化的适应。
