软件架构演化简史：从单体到AI原生
千丽大大_6210
2026-05-29
518人浏览
原创
{"type":"doc","content":[{"type":"paragraph","attrs":{"id":"cc9a58b9-119f-4467-a01c-1a6e84d3b9b3","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"这篇文章原本想写成“硬核”技术科普，来回顾和展望软件系统架构演化——也确实总结得差不多了，本质、驱动力、底层逻辑、基本原理、核心问题、价值体现、各发展阶段的定义和主流方案、所包含组件及历史里程碑统统都有。鉴于ai才是当红炸子鸡，大模型、智能体、驾驭工程才能博得一些关注，不如轻松点儿，用自己的视角来讲故事。讲述架构发展史的文章有很多，不少关于架构的书里也有相关章节，不差我一个，所以写点不一样的。"}]},{"type":"image","attrs":{"id":"37717d61-7fb3-4055-9ee6-7e4a68ce7c31","src":"https://developer.qcloudimg.com/http-save/audit-5829009/955ca933f55ba3f384daa84212db4339.png","extension":"png","align":"center","alt":"","showalt":false,"href":"","boxshadow":"","width":1100,"aspectratio":"2.357143","status":"success","showtext":true,"ispercentage":false,"percentage":0,"ishoverdraghandle":false}},{"type":"paragraph","attrs":{"id":"94123d5e-f3a4-4008-90ef-7d96ddec2fed","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false}},{"type":"paragraph","attrs":{"id":"c1b807cd-066c-4c39-9384-6d84c12fa5aa","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}},{"type":"bold"}],"text":"架构演化阶段论"}]},{"type":"paragraph","attrs":{"id":"0fe08725-38d1-47fb-8e96-3209fe5b1270","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"首先要说，所有的\"架构演化阶段论\"，都是事后诸葛亮，包括本文。那些整整齐齐的\"单体→分布式→soa→微服务→云原生→ai原生\"或者\"单体-c/s分层→soa→微服务→云→云原生/serverless\"的分段框架，都是后人总结实践经验形成的叙事框架，只是为了便于人脑记忆和理解，即便是成为“标准”，也很难“标准化实现”。真实的历史是混乱的，当下是正在发生的历史，未来是将要发生的历史，都是如此。从我个人角度，简单好理解就够了，比如\"单体→原始分布式→soa→微服务→云原生\"这样。"}]},{"type":"paragraph","attrs":{"id":"ce766578-ad21-474c-b72c-a03a4978d5e3","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"工程师不知道自己处于\"微服务时代\"还是\"云原生时代\"。他们只是面对一个个具体的问题——系统扛不住了、故障太多了、部署太慢了——然后在各种限制下，做一个当时能做的最优决策。这个限制可能是团队规模、可能是技术基础、可能是预算、可能是时间压力，也可能只是老板一句\"这个需求明天就要上线\"。所以，与其说架构在\"演化\"或者“演进”，不如说在\"权衡\"、在“取舍”、在“折中”、在“急中生智”。演进是结果，“解决当下问题”才是过程。"}]},{"type":"paragraph","attrs":{"id":"7b66b1d6-02e9-43ea-8f15-ba233a0114fd","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"绝大多数的软件系统架构都不是标准化的，也不需要严格遵循所谓当下阶段定义。单体够用就用单体，用了esb但可能没有服务目录，用着spring cloud框架不代表真的做好了微服务拆解，云原生也可能是只是把应用装进docker部署到云上，ai原生可以是把“loading”改成“thinking”。"}]},{"type":"paragraph","attrs":{"id":"001c5a14-63b4-4efd-999e-287e7f4692d7","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"我工作后参与开发的第一个系统，覆盖8省1市相当于三分之一个中国的业务，是c/s架构——用powerbuilder写客户端，连后台oracle数据库，算分布式还是单体，做的时候没听同事提过，系统能跑、需求能满足，就是好架构——甚至那时候可能都没人提“架构”。"}]},{"type":"paragraph","attrs":{"id":"f7197943-839a-4cb6-a332-3f0684924888","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"之后还用过c++builder和delphi，连过sybase数据库，中间还会加一层tuxedo或者cics，变成三层架构，中间这层就叫“中间件”。技术上其实已经是分布式了，只是这些系统运行在小型机和大型机上，是封闭的商业生态，不是后来的所谓互联网分布式架构。"}]},{"type":"paragraph","attrs":{"id":"24816711-b26f-44f9-b154-466522d8234a","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"后来的工作中又经历了soa、微服务、云原生，每个阶段都亲身见证过。带着这个视角，来看架构到底是怎么演进的，其中到底有没有什么规律。"}]},{"type":"image","attrs":{"id":"f9df6801-49dd-48c7-a5c9-40db856f3467","src":"https://developer.qcloudimg.com/http-save/audit-5829009/c298da1dbfa25aad52389d6b56a5ea99.webp","extension":"","align":"center","alt":"","showalt":false,"href":"","boxshadow":"","width":"","aspectratio":0,"status":"success","showtext":true,"ispercentage":false,"percentage":0,"ishoverdraghandle":false}},{"type":"paragraph","attrs":{"id":"9ec62d2e-0730-4ed2-a4c6-f81c3cb8bee8","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}},{"type":"bold"}],"text":"原始分布式：一个美丽的设想（1980s-2000s）"}]},{"type":"paragraph","attrs":{"id":"00c36fce-acad-4de3-9f57-3e53ab151ba3","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"分布式架构的故事从一个优雅的理想开始。那个年代，处理大型计算任务需要多台机器协同。工程师们提出了一个设想——让分布式变得\"透明\"。位置透明、访问透明、失败透明。程序员写代码就像写单机一样，背后有多少台机器、在哪里、出了什么故障，统统感知不到。"}]},{"type":"paragraph","attrs":{"id":"4b79e56d-73bf-4093-9e24-a0e38e230401","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"corba、dce/rpc就是这个理想的产物。ibm、oracle、sun，那个年代最聪明的工程师团队，设计出了精密的架构体系——idl生成跨语言代理，iiop协议栈，理论上可以让任何系统互联互通。概念上听起来完美。然后现实给了一记响亮的耳光。网络延迟不是零，消息可能重复，节点随时可能宕机。这些分布式系统的本质特性，不会因为在上面加了一层\"透明抽象\"就消失。sun工程师peter deutsch早在1994年就总结出了\"分布式计算的八个谬误\"——网络是可靠的、延迟是零、带宽是无限的……这些工程师想当然的假设，一旦遇上真实网络全部失效。"}]},{"type":"paragraph","attrs":{"id":"bd44ca5a-767a-4328-ae85-44042019ab97","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"原始分布式架构没有解决这些问题，只是把它们藏了起来。把复杂性藏起来，不等于解决了复杂性，只是让它以更隐蔽的方式爆发。"}]},{"type":"image","attrs":{"id":"127f6ddd-ff43-461b-b150-7603eb85ce7b","src":"https://developer.qcloudimg.com/http-save/audit-5829009/34cad59262d718ea666514dc3b411ca0.webp","extension":"","align":"center","alt":"","showalt":false,"href":"","boxshadow":"","width":"","aspectratio":0,"status":"success","showtext":true,"ispercentage":false,"percentage":0,"ishoverdraghandle":false}},{"type":"paragraph","attrs":{"id":"011e2f66-b33f-412f-ae76-6ff5f7c5aeb9","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}},{"type":"bold"}],"text":"soa：中心化管理（2000s-2010s）"}]},{"type":"paragraph","attrs":{"id":"c591b0d9-3e56-424a-bb26-b23a925c98ed","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"既然分布式无法透明，那就集中管理。esb（企业服务总线）是soa时代最流行的企业级架构组件。思路清晰：所有服务通过一个总线通信，总线负责协议转换、路由寻址、消息管理。ibm的websphere message broker、oracle service bus、tibco enterprise message service、f5硬件负载均衡、oracle 、db2、sqlserver数据库集群，配套hp、ibm、sun小型机，是soa时代的标准方案。"}]},{"type":"paragraph","attrs":{"id":"06ad9863-9700-4580-997d-22032c8b95e2","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"2005年，gartner将soa列为值得关注的企业级技术趋势。衍生出的基于soap的web services，追求标准化和严谨，代价是又重又慢。这套方案有它的适用场景——对规模中等、系统相对稳定、有强异构集成需求的大企业，效果不错。各种遗留系统通过esb打通，集成成本确实降低了。但对于用户量爆炸式增长的互联网公司——esb的吞吐量很快撑不住。总线是单点。一旦成为瓶颈，整个系统雪崩。"}]},{"type":"paragraph","attrs":{"id":"6c81b472-5ac7-4eae-975e-070304c5e38e","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"我在亚信用过tibco——非常优秀的esb产品，开发工具和运行容器都很专业，但好用不等于能用好。esb架构对服务治理和组织协作的要求极高，没有匹配的治理能力，有总线也是摆设，服务最终还是各自为政。工具没有问题，问题在于soa的理想，大多数团队做不到，最后esb只是成了系统集成工具。"}]},{"type":"paragraph","attrs":{"id":"1a454106-c5bd-4523-9863-3cd0a697ad15","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"soa架构的中心化治理解决了异构系统集成，却制造了单点瓶颈和性能天花板。"}]},{"type":"image","attrs":{"id":"8fffb0d0-6115-473a-9531-24b4a49be5c0","src":"https://developer.qcloudimg.com/http-save/audit-5829009/95f3b6f44e214b2f025bdc609796d22c.webp","extension":"","align":"center","alt":"","showalt":false,"href":"","boxshadow":"","width":"","aspectratio":0,"status":"success","showtext":true,"ispercentage":false,"percentage":0,"ishoverdraghandle":false}},{"type":"paragraph","attrs":{"id":"d8cb4c50-6538-4571-8524-01b0b8a75f2c","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}},{"type":"bold"}],"text":"微服务：去中心化的代价（2010s-2020s）"}]},{"type":"paragraph","attrs":{"id":"7d89b79a-d953-4848-9643-ca9af5538607","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"小型机和soa扛不住互联网公司业务的高速发展，自然要找新的方案，开始去ioe，拥抱开源，搞lamp，用x86的服务器，搭虚拟机，搞出了云计算和微服务。"}]},{"type":"paragraph","attrs":{"id":"6fdf6388-0f86-4ef9-b63e-54dca475438a","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"比如在当当那几年，我们从.net转向电商主流的开源java技术栈和mysql，架构部基于dubbo做了一些扩展，开源了dubbox——因为当时dubbo版本不支持http调用，而我们需要对接原有的异构系统，后来还做了sharding-jdbc（现在的shardingsphere），来解决分库分表问题。"}]},{"type":"paragraph","attrs":{"id":"c965a730-9f9d-47f3-813c-5fc9f4154f56","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"2014年，thoughtworks的martin fowler与james lewis联署发表了那篇定义性文章，把这套去中心化服务自治的做法正式命名为\"微服务\"——netflix、amazon等早已在实践这套思路。核心思想是把中心化的esb扔掉，改成服务自治：每个服务独立开发、独立部署，服务之间用rest或消息队列通信，用软件实现负载均衡，用开源组件替代商业软件。"}]},{"type":"paragraph","attrs":{"id":"bddb9bbe-9388-449b-81d9-24dd24fcc13b","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"dubbo、spring cloud、eureka、hystrix……降本提效效果显著。迭代速度从\"月级\"变成了\"周级\"甚至“日级”。这样的架构是互联网公司爆发式增长的技术底座。那些年，整个行业都在做“微服务化”——把大应用切成几十个、上百个小服务，随之而来的则是技术团队的快速膨胀。"}]},{"type":"paragraph","attrs":{"id":"6123a705-3556-42d5-a921-faf786556c8f","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"这里有个需要戳破的幻觉：用着微服务框架，不代表真的做好了服务拆解，实现高内聚低耦合。有的系统，分布式的复杂性全有了，单体的问题一个没解决——服务之间调用链路一层套一层，但边界划分不清，数据模型依然耦合，甚至共用数据库。服务拆分之后，运维复杂度指数级上升。一个线上bug，可能要翻遍五六个服务的日志才能定位。分布式链路追踪、分布式事务、跨服务调试——每一个都是独立的技术难题。去中心化解决了扩展性问题，把运维复杂度摊给了开发和运维团队，devops成为必备素养！"}]},{"type":"paragraph","attrs":{"id":"a27e76ef-a221-425e-a8a2-247d4bb63c1d","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"微服务的复杂度，在\"异地多活\"这个方向上被推向极限。我们在饿了么做过异地多活架构升级——多个地域的数据中心同时提供服务，单一机房故障，流量切换，用户无感知。听起来是个运维方案，实际上是分布式系统最顶级的工程挑战之一：数据怎么分片？跨机房的一致性怎么保证？写操作怎么路由？故障切换的时延窗口有多宽？数据冲突怎么解决？cap定理、最终一致性——在异地多活里全部变成了必须解决的工程问题。"}]},{"type":"paragraph","attrs":{"id":"23caedad-533e-45e3-9c29-c1a21b21f17d","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"微服务架构和技术团队扩张支撑了业务快速发展，但也给适应业务萎缩和转型设置了障碍，拆服务简单，想再合起来谈何容易？毕竟系统不是技术团队，不能说砍就砍。"}]},{"type":"image","attrs":{"id":"a7b00549-4b23-42c4-8454-3614ffe89dc3","src":"https://developer.qcloudimg.com/http-save/audit-5829009/62af202ad599de736cc626c37d01675b.webp","extension":"","align":"center","alt":"","showalt":false,"href":"","boxshadow":"","width":"","aspectratio":0,"status":"success","showtext":true,"ispercentage":false,"percentage":0,"ishoverdraghandle":false}},{"type":"paragraph","attrs":{"id":"9782d817-547c-40b7-b792-8da1a37d55e9","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}},{"type":"bold"}],"text":"云原生：研发标准化，运维自动化（2020s-至今）"}]},{"type":"paragraph","attrs":{"id":"f6ad75cc-0782-4581-a308-0d1c22879d5d","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"云原生不是云计算，是基于容器的新架构，cncf把pivotal提出的概念重新定义来讲新故事。至于容器，早在2013-14年，我们在当当就做过docker的调研，看到了容器化的方向，只是没想到docker、mesos最后都败给了k8s。"}]},{"type":"paragraph","attrs":{"id":"d1f7ed9b-1489-40a3-a9a5-8d68709b903a","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"有人总结软件架构的差别是“以谁为中心”，从“服务器”到“资源”到“应用”，云原生时代“系统”彻底解耦掉了，“serverless”了，只剩下“应用”，不知道接下来要说的是以“agent”为中心，还是以“token”为中心，总不至于以“结果”为中心吧？"}]},{"type":"paragraph","attrs":{"id":"dcab3806-f47f-4d9a-bdcb-8569dc531a5a","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"换个角度看，前几个阶段有个共同特点——人来管。架构师设计架构，运维配置服务，开发者排查故障。云原生的核心思路是：让研发、运维从一开始就按照云（容器）的标准方式，从而实现应用运维的自动化。kubernetes负责容器调度，自动扩缩容，节点故障自动迁移；istio/linkerd的service mesh接管服务间通信，熔断限流、链路追踪——这些以前需要人工配置的事情，变成了声明式配置，由基础设施自动执行。但云原生并没有消灭前几代的架构，只是在下面又加了一层。"}]},{"type":"paragraph","attrs":{"id":"2f364288-6a44-4849-9e27-9abf91effe75","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"这几年做了基于k8s的云原生架构升级，搭建新的devops流水线，加上基于otel的可观测能力，推动原有系统改造迁移。金融行业的云原生架构落地，跟互联网公司有明显不同——可谓如履薄冰，做好了随时出故障的心理准备，也知道出了故障系统会更健壮，但还是得祈祷“永不宕机”。"}]},{"type":"paragraph","attrs":{"id":"e0d2ec11-7c25-467c-ac1d-3694264fdf79","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"据我观察，金融行业系统的真实状态是：物理机、虚拟机、容器并存，有微服务也有单体系统，甚至可能还有esb遗留，各种架构相安无事，能跑就行。这不是技术债——这是现实。"}]},{"type":"paragraph","attrs":{"id":"cffdf571-be18-47df-a5e7-12d16ee7a023","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"云原生定义了新的研发运维模式，也抬高了技术门槛，能玩得转本身就是实力的体现，实力有限就别给自己挖坑。"}]},{"type":"paragraph","attrs":{"id":"4f66ae6a-82a7-41b0-aefa-83cb994c6976","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}},{"type":"bold"}],"text":"两条规律"}]},{"type":"paragraph","attrs":{"id":"5e2e8bd2-c7d3-40fe-9c2e-0c4cfbb8e777","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"回顾完这几个阶段，有两条规律值得单独说。"}]},{"type":"paragraph","attrs":{"id":"4cf04a3b-9476-495d-9203-1207906fbebd","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"一、解耦粒度细化和故障域隔离强化，是两条主线。"}]},{"type":"paragraph","attrs":{"id":"449d48c9-4ca6-4d0a-a186-b0b14e38a328","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"每一次架构演进，都是在这两个维度上同时推进，整体趋势是粒度越细，协调成本越高，这个权衡没有完美答案。"}]},{"type":"paragraph","attrs":{"id":"42c6ae35-ab8d-4c34-9868-fa95bad9cf93","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"解耦粒度：单体 → rpc → soa服务解耦 → 微服务业务边界解耦 → 云原生基础设施解耦。"}]},{"type":"paragraph","attrs":{"id":"b772ff12-f7f2-4e6f-a0ef-aec5b13d768c","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"故障域隔离：无隔离 → 熔断限流（微服务）→ service mesh + k8s自愈（云原生）。"}]},{"type":"paragraph","attrs":{"id":"dc3402b1-edf5-40b9-8b67-03dd908ace85","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"值得注意的是，soa阶段在这条线上是个例外——esb制造了新的单点，反而是故障隔离的倒退。这也解释了为什么互联网公司不用esb：它在解耦维度有价值，却在隔离维度挖了坑。"}]},{"type":"paragraph","attrs":{"id":"7120d0d4-5342-4465-987f-e118548a521d","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"二、从\"追求零故障\"到\"设计容错性\"，是一次理念转变。"}]},{"type":"paragraph","attrs":{"id":"5bf9cf1d-032c-4a77-95ca-99610265bbac","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"以前架构师的目标，是建一个永远不会出错的系统。现在架构师的目标，是建一个出了错也能快速恢复的系统。"}]},{"type":"paragraph","attrs":{"id":"f03f5bb1-b4c2-4a5a-a8e3-d8f84ec8b28c","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"netflix的chaos monkey——在生产环境随机终止服务实例的工具，混沌工程的早期实践——是这种转变的极致体现。主动引入故障，是为了验证系统的容错能力够不够强。阿里的“双十一”是融合了事前模拟、精准预测、流量调控、资源调度、降级熔断的一套大工程，一次次提升线上线下的系统能力极限。"}]},{"type":"paragraph","attrs":{"id":"e1fe618b-510a-496e-b94f-df1e81bbe9f8","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"拥抱不确定性，才是软件架构的第一性原理。ai大模型的到来，把不确定性往前推了更大的一步。"}]},{"type":"paragraph","attrs":{"id":"11f4893b-fd5c-43a8-807f-3bd294c6f58f","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}},{"type":"bold"}],"text":"ai时代的新挑战"}]},{"type":"paragraph","attrs":{"id":"be3ab6f6-0791-4fb9-b3cd-6dc7894180d6","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"现在谈ai原生架构，需要保持谦逊。大模型已经来了，ai agent、工作流编排、skills仓库、ai网关、模型路由层……各种新概念和新组件在快速涌现。已经有人开始喊\"ai native架构\"，也有人在聊\"ai云原生架构\"。但这个领域现在没有共识，大家都在探索，都在试错。新范式的共识，总是在大量实践之后才形成。"}]},{"type":"paragraph","attrs":{"id":"aed1e52c-c5d5-4cd0-a99e-92f04e4dc162","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"可以确定的是，ai时代带来了几个前所未有的新挑战，架构的旧答案在这里还不够用。"}]},{"type":"paragraph","attrs":{"id":"fad1cb65-ba74-44a9-8ba7-4bd5bf7cfb5c","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"挑战一：不确定性的质变"}]},{"type":"paragraph","attrs":{"id":"6db47f83-6ee1-4ef4-a1c6-853b30b29b46","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"之前不管哪个阶段系统的故障是确定的——节点宕机有心跳检测，网络超时有熔断器，消息丢失有重试机制，实在搞不清楚的就当做“黑天鹅事件”处理。这些故障有固定的失败模式，可以被监控、被告警、被自动恢复。ai模型的\"幻觉\"不一样。一个看起来完全正常的输出，可能是错误的——而且你不知道它是错的。传统的健康检查发现不了这种故障，得上升到业务监控的层面，才能识别\"输出看起来成功、但语义上是错的\"的问题。"}]},{"type":"paragraph","attrs":{"id":"9ab870c2-7f66-45f7-91e8-99a888368be2","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"挑战二：状态管理的张力"}]},{"type":"paragraph","attrs":{"id":"69fda477-dbfc-40e8-8dc6-99be6d5efaa3","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"云原生有一个核心理念——无状态化。服务本身不保存状态，状态全部外置到数据库或缓存，这样才能任意横向扩展。k8s的pod可以随时被杀掉重建，正是基于这个前提。"}]},{"type":"paragraph","attrs":{"id":"74058e21-f4ef-419c-b148-da0ac2ed5972","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"ai agent打破了这个前提。agent需要维护对话历史、任务进度、工具调用记忆——这是一种内生的\"有状态\"需求。而且这个状态跟传统数据库里的结构化数据不同，它是语义状态，是上下文窗口。怎么持久化？怎么分片？agent横向扩展时怎么保证上下文一致性？一想就头疼。"}]},{"type":"paragraph","attrs":{"id":"2775f052-7ce8-4bcd-8853-e437a2916dc7","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"挑战三：编排逻辑的不确定性"}]},{"type":"paragraph","attrs":{"id":"dcb55b0e-1d85-41a7-91f4-aa59f187d711","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"传统的服务编排是确定的——服务a调用服务b，返回结果，流程在代码里写死，行为可预期。ai agent的编排是动态的——agent会根据推理结果决定下一步调用哪个工具，调用几次，要不要回溯，什么时候停止。这个决策过程不在代码里，在模型里。这给服务治理带来了新问题：你无法静态分析一个ai工作流的调用链路，无法预估它的资源消耗，也无法像传统限流那样精确控制它的行为边界。"}]},{"type":"paragraph","attrs":{"id":"4599fcdc-00a2-4c48-b977-784a42da004b","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"挑战四：可观测性的新维度"}]},{"type":"paragraph","attrs":{"id":"8d4d4be9-7481-4dc7-9224-ad0e7cbfd237","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"传统可观测性三大支柱——metrics、logs、traces——在ai系统里都还在，但不够用了。"}]},{"type":"paragraph","attrs":{"id":"7469274a-5119-4645-98b6-42e00fca6e28","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"我们需要新的观测维度：模型输出的质量评估、推理链路的语义追踪、token消耗的成本监控、幻觉率的统计……opentelemetry的现有标准还没有覆盖这些。"}]},{"type":"paragraph","attrs":{"id":"ed6d9cc3-4254-488a-b710-686da479f912","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"更难的是：怎么定义\"ai系统健康\"？cpu占用率正常、响应时间达标，但输出质量悄悄下降——这种退化，传统监控发现不了。"}]},{"type":"paragraph","attrs":{"id":"83ad7fd3-0bf1-4742-8e36-dcbb8478ec43","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"这四个挑战，指向同一个根本矛盾——软件架构演进积累的方法论，建立在\"故障是可观测的、行为是可预期的\"这个前提上，但ai打破了这个前提。好在架构演进的历史里留下的另一个遗产，在ai时代可能比以往更有价值——\"不追求零故障，而是设计容错性\"这个理念。ai系统不可能消除幻觉，正如分布式系统不可能消除网络分区。重要的是：怎么设计系统，让它在模型出错时依然可控、可恢复、损失可界定，也许“驾驭工程”就是答案。"}]},{"type":"paragraph","attrs":{"id":"8850a555-dcd6-48a2-8761-1b969e330cbb","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"无论怎样，系统好用才是王道。这话在以前是对的，在ai时代也是对的。至于ai原生的定义，等到新一代架构涌现之后自有人来评说。马克·吐温有句话——\"历史不会重复，但总是押韵。\"从单体到分布式，从soa到微服务，从云原生到ai原生，每个历史阶段的问题不同，但架构理念相同：解耦、隔离、容错、拥抱不确定性，权衡、取舍、折中、解决当下的问题。"}]},{"type":"paragraph","attrs":{"id":"01f84907-0772-478d-9758-8866a774ee3f","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false},"content":[{"type":"text","marks":[{"type":"textstyle","attrs":{"color":"","background":""}}],"text":"正如生命，从单细胞到多细胞，从无性到有性，从本能到智能——没有门纲目科属的定义，只有每一次对环境变化的适应。"}]},{"type":"image","attrs":{"id":"cf59c4fb-c535-4c4e-8ed7-5ccebfd80628","src":"https://developer.qcloudimg.com/http-save/audit-5829009/6219fe67bd9365ea7ef95edeb82cf3bd.png","extension":"png","align":"center","alt":"","showalt":false,"href":"","boxshadow":"","width":1100,"aspectratio":"1.791667","status":"success","showtext":true,"ispercentage":false,"percentage":0,"ishoverdraghandle":false}},{"type":"paragraph","attrs":{"id":"c71818a8-ca71-4de6-a955-260efbf6532c","textalign":"inherit","indent":0,"color":null,"background":null,"ishoverdraghandle":false}}]}
