下载掌阅APP，畅读海量书库
立即打开
过去20年企业软件架构最大的变化是“系统体积的不断膨胀，以及数量的不断增多”，主导架构由单体系统架构进化为SOA架构，再到微服务架构和云原生架构。在第二个时期，企业软件日益庞大，“面向服务”成为系统建设的主题词。软件架构的技术关注点，已经由实现模块的设计模式（核心是对象间关系）层面，上升为颗粒度更大的架构风格（核心是系统间、服务间关系）层面。本节从几方面来透析（以互联网为代表的）企业软件架构的演变道路以及路上的几大主角。
单体架构多使用水平分层的架构风格。例如几乎每个人都能倒背如流的表现层、业务逻辑层、数据层。分层风格的单体系统，优点是结构清晰，容易开发、部署和测试，缺点是耦合性高，技术选型单一，众多功能堆积在一个系统
之中，迭代效率比较低。
单体架构并非一无是处。现在很多平台也开始发声，倡导单体架构。这是挺有意思的事情，大抵是因为不堪微服务系统（过多节点）复杂性的重负吧。这好像印证了那句俗话——此一时彼一时。软件只是手段，能否交付业务才是最终评价，如果依靠功能堆积的开发框架和开发方式，可以满足业务需求，那么单体系统也无妨。
银行的账户有一个，但是有柜台、自助机、网银等多个渠道，这就是一个系统群（或平台）。在15～20年前，如何建立这样的系统群架构呢？限于软硬件资源和技术能力，那时候架构工作更多是面向通信领域，以“系统间通信处理”
为核心命题。在技术实现层面，高级语言广泛使用Socket（套接字），对于Java来说选择则更多，例如使用RMI。HTTP协议此时也正快速发展，但是在H5之前，HTTP还谈不上是公认首选的通信协议。
XML出现之前，联机系统之间的交易还是字符串文本格式，对于银行来说，广泛使用的是“8583标准
”的报文，字符串之间常以“|”作为分隔符。
那么多个渠道怎么接入呢？各类业务线的系统群架构中，广泛存在前置系统（或者接入系统）的概念，前置系统在系统群中地位重要，却并不实现业务功能，从这点来说，我们已经可以看到：软件是个业务功能和质量属性的二元世界。
对于前置系统来说，系统间关系中的通信关系是最重要、最基础的关系。并发、日志、鉴权、统计、监控等非业务功能类职能，都是在通信基础上逐步发展和建设的。这时的前置系统角色已经体现了边界和网关的理念。
随着业务发展，机构间系统的对接量得以快速增长。以支付领域为例，商户、三方支付机构、银联、发卡行……多机构方系统串行连接，联合实现业务场景，成为业务发展的主要形态。
前置系统已算是机构API网关的雏形，但明显跟不上互联网发展
的脚步。对于跨机构形成的系统群，架构师关注的架构量子的体积明显更大，边界更为明显，网关系统迅速发展起来，名正言顺地成为架构中的主要角色。
网关的技术形态和实现方式很多，代表性的形态包括：①供C端用户业务操作的页面网关，例如互联网支付时点击支付按钮，跳转到了微信平台提供的支付网关页面；②提供接口聚合、请求路由、协议转换的API网关，这是面向合作机构的网关的最常见形态；③其他特定目的（如减少跨网间系统网状调用等）的技术型网关，这类并非严格意义上的网关，主要是实现优良的系统部署架构，与企业应用架构的关联性相对较小。
网关的核心理念是通过反向代理等技术对外屏蔽细节。中大型平台架构中，网关作为边界隔离成为企业架构中的战略级要塞，与应用系统形成一对多关系。网关的地位，自出现后有增无减。
笔者从2004年开始在银行工作，那时的架构中枢是前置系统。20年后的今日，其替代者是网关。两者都是汇聚服务、聚焦边界架构思想的产物，他们背后的思想脉络和角色定位实际上是相通的。
企业内部系统数量的激增，导致另外一些质量属性成为重要话题，包括可扩展性、高可用性、灵活性。换句更容易理解的话说，系统数量过多，就需要从架构方面进行管控与治理，在银行工作的后期（2008—2012年），SOA架构风风火火，迅速走红。整个厂商或者行业铺天盖地地宣扬以Service API和中心化的服务总线（ESB）作为系统群的统一管理机制。SOA到底是哪路神仙？与其说是架构风格，倒不如称为一种理念。SOA架构风格已经体现了业务服务化的理念，但是技术本质上并没有真正摆脱单体架构的束缚，每个系统都对ESB存在硬性依赖。
以ESB为轴心建立的系统间契约式关系体系，跟不上时代的发展，随着应用系统的数量越来越多，ESB耀武扬威的时间并不长。其核心问题在于，系统的形态与业务模型之间并不协调。SOA基于严格定义的服务分类方法来组织服务，业务服务的目标是以“抽象的方式捕捉公司所做的事情”。在促进服务复用的同时，“服务本身的分类方法、服务抽象的合理性”通常会形成致命障碍。例如，要实现客户的统一账单，需通过ESB调用众多的业务服务，每个业务服务的背后可能是对多个应用系统的查询请求，而这些部分由不同的团队负责。即客户账单这一业务领域概念被打散到整个技术架构中，ESB驱动的SOA架构对于迭代式变更十分不利。
工作多年以后，我对SOA架构的通用服务一词给出四字评语，那就是“过于理想”。实际工作中发现，服务越通用，就越干瘪，越需要开发人员定制使其发挥作用，不仅引入更高的复杂度，而且很容易受到服务变更的冲击。如此发展下去，通用服务最终会成为“美丽的僵尸”。
在弹性、耦合性方面，ESB不能满足越来越多的应用系统之后，去中心化思想应运而生，更高级的服务治理模式出现了，这就是微服务架构
的最重要价值体现。由微服务框架提供服务注册、服务发现、服务流控、服务熔断、轻量级通信等完整的服务管控与治理体系，例如，大名鼎鼎的框架——Spring Cloud，就是集成了这些能力的典型代表。
面向服务的架构风格在架构世界占据主要地位，但是它们只能称霸于同步通信的领域（或阵地）。以事件驱动为核心思想的异步通信架构，在这个时期同样呈现爆炸式增长的态势。虽然异步通信架构在实现服务协调和事务行为方面颇具挑战，但是它们能提供极好的并发规模。以代理、中介为主的架构风格，在大型企业平台被广泛应用，尤其是对于需要削峰、解耦等业务场景，成为不二之选。
最后，对本节做一下总结，对于应用架构的发展和成熟，第二个时期的重要程度不言而喻。网关隔离边界、内部服务治理，这两者是当代架构思想的标志，是近20年应用架构发展历程的重要线索，是很多企业（尤其是互联网业务类型企业）中后台架构的命脉。
如果系统间关系是企业系统群架构中的纵向关系，那么这一节我们从纵向切换到横向，描述在第二个时期中，横向关系方面的架构变化。
先来看边车模式，边车模式的英文名称是Sidecar，生活中的原型是在二轮摩托车旁边增加一个座位变成三轮摩托车，增加的部分称为边车。也就是说，我们可以通过给一个摩托车加上一个边车的方式来扩展现有的服务和功能，对应到软件系统，即是体现“控制”和“逻辑”的分离。
从实现方式来看，边车可以是控制应用服务的Agent（代理）服务，在分布式开发工作中体现为：开发者不需要在应用程序中实现（如监视、日志记录、限流、熔断、服务注册、协议适配转换等）控制面上的能力，而只需要专注地做好和业务逻辑相关的代码，然后，由Agent服务来实现与业务逻辑无关的控制功能。
对于系统节点数量超过千级的中大型平台，控制的重要性提升到技术战略地位，“控制”和“逻辑”的分离，也就成为重要话题。上千个使用单车模式的应用节点，部署后就是一个由上千个控制应用服务的Agent形成的巨大网格，即服务网格（Service Mesh）。
服务网格更适合作为一种架构思想来体会，实战中，服务网格的技术体现正是锐不可当的Kubernets（简称K8S）。K8S是云原生体系中最具代表性的技术能力，近年来，如Istio、Envoy和Linkerd这样的主流开源服务网格项目，不约而同地选择以K8S为技术基础进行构建和发展。能够掌控K8S，几乎等同于拿到了服务网格的“毕业证”。
K8S提供一整套的虚拟基础设施和容器
编排能力，除此之外，在服务治理领域的出色表现，令其横跨软件世界的两大领域：一是作为基础设施平台层面的服务提供者，K8S技术所向披靡；二是作为实现应用系统服务管控的技术框架，K8S在应用开发侧也产生了深远影响。
回顾云计算发展历程，不难发现发展方向始终是让应用开发者的关注点由底层一点点向上层移动：先是用操作系统来管理物理机，然后是将软件运行在托管虚拟机上，进一步发展更加小型化、轻量化的容器。我们常说的SaaS模式，即这样的发展理念体现到最终具体形态上的例子，其特征是，作为云服务的消费者，用户完全不用管理任何应用和基础设施。这样的发展趋势非但没有减缓迹象
，而且还在加速涌现新生架构，作为其代表，Serverless（无服务器）架构是新一代云计算技术的佼佼者。
在以前，我们常需要花费很多时间来弄清楚为什么在一个环境通过测试的系统，在另外一个环境会失效。使用虚拟化环境的好处是能够实现环境一致性。在高度虚拟化的软件运行环境中，持续集成服务让一切应用可以无数次重新构建，镜像技术让一切系统可以被无成本、无差别重新部署。“增量修改”不如“全量重建”，这是基础设施无关性的典型特征。软件的规格虽然从未被标准化
，但是软件的制造，已经开始享受流水线式生产的待遇了。
多层虚拟化成为常态，并催生了云资源和自助服务，这种趋势的目的是什么？降低管理基础设施的成本，降低开发门槛，让技术人员将更多的精力应用于业务中。如果用架构思想来进行概括，可以是“关注点分离”五个字。架构师可以将运行资源视为商品，并可以将其作为独立领域外包出去。
那么，虚拟化是否有反模式呢？当然有，最明显的是性能开销。面对这样的矛盾，只能做折中平衡。从质量属性角度看，性能虽然依然重要，但其敏感度确实在降低，适当牺牲性能，使用云平台支撑分布式集群、大型系统群的建设，已经成为必然。运行于JVM上的Java成为第一大语言，这场好戏还在继续，只不过舞台的主角（从语言的虚拟化）换成了整个系统环境的虚拟化。抱怨无用，很多反对虚拟化技术的技术极客们必须要醒一醒。
这就是云原生架构的由来，以云平台、云计算为依托搭建企业软件，成为主流的系统建设模式。云原生架构的典型特征包括在业务层面强调基于云化的中台战略，在开发运维层面强调依托云服务提供（包括服务网格、Serverless应用、容器化、API服务化、自助资源管理、持续开发与持续集成，以及DevOps开发运维一体化等）若干能力。
云原生一词，是对相当多技术的宏观概括，是一个庞大的技术集团。相比于技术架构，将其理解为软件业的时代现象，更恰到好处。
在第二个时期，以API网关、服务注册与发现的应用架构治理思想，以及以K8S与Serverless为代表的云原生架构逐渐发展起来，进入第三个时期之后，立刻成为架构领域的主宰者。展望未来不难预测，他们依然会是主角，难觅取代者。
经历了单体、SOA、微服务、云原生四个架构时代后，面向未来，我们迎来的是智能原生架构时代。每个时代的涌现，都能在上一个时代找到伏笔，智能原生四个字，描绘出基于人工智能的软件世界，而人工智能则始于大数据处理技术和机器学习的不断发展。在分布式技术框架的加持之下，传统软件架构已经步入成熟稳定期，云原生、智能原生，已经是从另外一个轨道上开辟软件行业的新空间，它们并非取代（或是抛弃）传统架构的任何成果，而是在其基础之上，引入新的关注点，结出更多的果实。
希望智能原生一词能恰如其分地表达新的架构时代。对于思想而言，没有人喜欢背诵长篇大论，使用关键词来画龙点睛，或许是表达技术哲学的最佳境界。
分离，前端架构的革命
企业架构发展的主脉络，一直掌握在后端技术手中。如果要说得更具体一些，应该是“架构是由‘后端架构风格和模式’所主导的世界”。这是为何？答案在于后端承载着企业业务逻辑，并进行企业数据资产的操作行为，这样的职责使命督促着后端架构的率先发展。前端领域，起初只是页面这薄薄的一层，局限于以HTML以及Script脚本语言为主的开发技术。在第二个时期的开始，ASP、JSP是前端的主要实现方式，前后端耦合性较高，行业中还没有独立的前端工程师岗位。
1998年Ajax
技术的出现，允许客户端脚本发送HTTP请求（XMLHTTP），并且局部刷新页面，这种突破性的创新推动了Web的发展。随着HTML5、CSS3、ES6的出现，专职的Web工程师从无到有，被赋予了更重要的使命。
整个事情的转变从前后端分离思想开始。在这个时期中，前端从一个薄层向立体化、架构化迅速发展，这样的发展势头一直延续至今，从未放缓脚步，主要标志特征如下。
（1）SPA单页的应用：随着Ajax技术的出现和发展，特别是使用CDN作为静态资源存储之后，SPA迅速占领前端市场。前后端分工明确，接口契约的重要性增强，Ajax接口成为关键协作点。
（2）大前端：前端开发的重要性提升，出现了多种前端架构模式，如（以同步通信为主的）MVC、（以异步通信为主的）MVP和MVVM，使得前后端的职责更加清晰，且分工更为合理高效。
（3）前端全栈：Node.js的出现使得前端开发者可以在服务器端进行编程，从而实现了前端的全栈开发，进一步提升了开发效率和灵活性。
（4）整体架构：垂直方向使用Mock Server进行前后端并行开发，使用BFF作为前端、后端之间的中间层；水平方向使用微前端架构将单体前端工程拆分为多个小型前端应用，可以独立开发、独立部署。
上面这些远非前端发展故事的全部内容，前端私服（如Nexus）、脚手架（如Lerna）、组件库、混合开发平台（如Uni-app）、工程构建（如Webpack）、开发框架（如Vue）……各种新技术层出不穷，令人眼花缭乱。等到本书上市时，很多技术的面貌（指版本情况、市场使用情况等）可能早已焕然一新。
只要系统越来越庞大、复杂，那么任何重要领域都不会是世外桃源。摩尔定律让移动设备的性能与日俱增，互联网快速步入千家万户。客户端多样化发展，浏览器、App、各类小程序争相抢夺用户，越来越多的内容（例如短视频）进入移动端。前端生态的新陈代谢也在持续进行，鸿蒙生态已经由冉冉升起之星，成为前端生态的新巨头。软件架构思想仍旧以后端为代表，在于后端所承载的业务属性和数据属性，如果抛开这些，仅就技术属性而言，前端与后端可谓是旗鼓相当、不分伯仲。
第二个时期的初期，是大型商业数据库的天下，Oracle以跨平台优势逐渐占据比SQL Server更大的份额，金融行业还广泛使用IBM DB2，期间超大型企业使用Teradata等产品建立自己的数据仓库。在这个商业数据库主导市场的年代，数据库软件及专用硬件价格高、技术封闭相互不兼容。
大概2007年、2008年之后，MySQL等开源数据库的突出特点，让很多企业降低了数据软件投入的成本，虽然单体性能不及大型商业数据库，但是开源属性催生了集群化部署，以及分库分表、读写分离技术的广泛应用，实现了投入成本与性能之间的真正平衡，使得开源数据库成为中小企业、新生企业的首选，传统大资产行业也在逐渐剥离对昂贵商业数据库的依赖。此时，“数据存在的形态和主要的应用模式”这些最核心的要素并没有变，仍是SQL标准和范式下二维表的结构化存储和输出形态。
大概2013年、2014年之后，以大数据产业驱动和分布式计算发展带来的Hadoop生态圈，其中的数据库技术栈是革命性的，包括NoSQL、HDFS存储、非结构化数据库（如HBase列式数据库）以及数据仓库（Hive）等，并极大地推进了数据智能、数据服务、数据搜索、数据推荐等多种多样的数据类应用。
SQL的统治地位发生动摇发生在第二个时期末期。面向超大规模应用，NoSQL和多种持久化日益成为主流，该趋势发展迅猛，在第三个时期成为数据领域的主要市场。放眼未来，这样的格局变化应该会继续深化。架构师的武器库里面，不仅可以有键值型数据库、文档型数据库、宽列型数据库，还可以考虑向量数据库（数据结构是向量，它采用向量化存储和查询技术，将数据以向量形式存储和处理）、图数据库（数据结构是图，使用节点和边的关系来表示和存储数据）这样更先进的技术品类。
这么多的技术品类，对于传统架构师简直是有些超纲了，很多从业者因担心跟不上技术发展节奏而搓手顿脚。但是，必须要承认的是，数据经济的到来，数据库产品线的繁荣，这些终归是好事情。
那么应该以何种心态面对技术产品发展速度如此之快的局面呢？当今时代，已经不存在“通吃天下”的全能型技术人才。即使有某个奇才，对前端、后端、数据三个领域都无比精通，但可能对量子计算的世界一窍不通。因此笔者认为，大可不必每见到一门新技术就如同惊弓之鸟一般惶恐不安，相比于盲目地学各种技术，还是镇定自若些更好。
讲架构思维，不得不提“治理”的理念，于应用侧而言是服务治理，对数据则当然是数据治理。当前，大范围的数据治理已经成为各大平台的标配，数据标准、数据字典、数据质量、数据分级分类等各项工作目标皆为让数据更加坚固、可靠。
总体而言，数据库技术与数据架构发展的脉络十分清晰，但数据侧的发展总体滞后于应用侧，这是不争的事实。数据库语言远未达到程序语言那样“百花齐放、百家争鸣”的场面。相比于应用系统的设计开发，数据库开发工具应该说少得可怜，这是为何？答案在于，数据领域的可设计空间，并不像应用领域那么大，可从三方面体现。
一是固化的设计模式方面。本质上，数据模型是对实体、关系和属性的定义，以及所使用的范式。不同的范式，在数据冗余与数据完整性上给出不同的原则和约束。列式非结构化库本质是存储技术上改变了数据存储方式，近年来，各行业数据类服务应用的拓展可谓是锋行天下，然而从数据模型的设计角度看，几十年来并没有产生什么革命性的设计模式和新方法，数据在各方面的可伸缩性、容错性，远远弱于应用程序。
二是数据的“笨重”性方面。影响到数据的问题往往解决起来更加麻烦，要改变代码和行为不是大问题，修改发布即可，将数据结构从老版本迁移到新版本，则需要付出更加巨大的努力。有经验的发布人员都知道，发布失败的回退，对于进行了大量数据结构和内容变更的上线投产工作，往往是无路可退的。
三是数据的不可变性方面。用户界面和应用逻辑会变化，业务会发展，人员会变动，但是数据会永远保留下来，不论是二维结构化还是非结构化数据，都改变不了数据的不可变特性。
有句行话叫作“数据为王”。如果说“程序是碗”，那么“数据才是碗里的肉”。数据承载着企业的核心资产，这无形中约束了数据产品的开放性、灵活性。专业厂商的商业化数据库产品，仍然是数据领域的领头羊。同样是软件从业者，程序员和DBA的职场生存策略截然不同。DBA找工作，很大程度依赖于持有某厂商的中高级认证。生活在世界各地的DBA，好像是数据库厂商所拥有的隐形部队，他们是厂商的拥趸者，对数据库厂商的效忠程度，甚至大于其雇主。DBA会忽略那些来自第三方的数据库工具和开发组件，其结果便是数据侧工程实践的创新水平有些停滞不前。在Hadoop生态圈以及众多NoSQL数据库出现后，这样的问题已经得到明显缓解，但是承载联机交易的数据库、中大型企业的核心业务系统数据库，至少占据着数据库市场的半壁江山，这些数据库显然无法快速转型。对此，只能寄希望于信创工程的发展，以及全行业的国产化替代要求的推行。
我对这个黄金年代
充满了无限赞誉，从软件技术、软件市场、软件就业等各个维度上看，这是一个无比美好的高光时代。如果要找几项美中不足，或者是选点精华中的糟粕，也并非难事。这样做，既不是想泼冷水，也不是图一时口舌之快，真正的目的是揭示问题，避免走弯路。这是一种批判精神。
在信息过剩的年代，技术能力唾手可得，软件从业大军中更为可贵的是具有批判性精神的人才。工作实战中，在批判性思维上投入少量的精力，即会有“从根本上避免大量失败”之效。
企业里的IT管理，最大问题并非出在技术身上。中大型企业的技术决策，所面临最大的困境在于：掌握信息的不掌握决策，掌握决策的不掌握信息。中小企业的软件开发工作则更不乐观，大量的情况是，技术团队与业务出身的老板之间，在面临压力时出现分崩离析的局面，信任感瞬间消失的背后原因在于：双方的思维理念和所使用的对话语言根本不在一个频道上。
管理层经常会听到一些“完全正确”的技术观点，并为此引入看似完全符合正确观点的技术产品，著名的反模式——死亡征途，或许最适合形容这样的项目。
在这个时期，看似正确技术观点中的著名反例，就是很多企业大张旗鼓地引入“由某个软件商打造的，封装了表单、任务流、报表等各类功能组件的”统一开发平台，支持这个技术决策的理由包括：部门所有员工能够使用一致的技术栈；使用这样的平台开发出来的软件易于统一管理与维护；这样的平台能够让程序员少犯错误；这样的平台能够自然提供底座，加快各个业务系统的实施进度；这样的平台可以降低开发门槛，让程序员们不需要考虑底层框架，专注于业务逻辑代码开发；使用这样的平台进行应用系统开发，易变和风险性更小，即使遇到问题，统一开发平台厂商会统一进行解决。
可惜，决策者们的世界存在盲区。因为若干有利原因而引入统一开发平台，这是决策陷阱的典型例子。
很多企业花钱引入了这样的开发平台，然后开发工作就走上了一条不归路。那么结果呢？决策者们当然不会承认决策失败，而是把责任归于统一平台厂商不给力，或者其他的背锅侠。最终，统一开发平台会令人忍无可忍，被逐渐地摒弃，具体方式，可以是某项目写明不适用统一开发平台的原因，因此不再采用它。有第一个这样的项目，就自然会有第二个、第三个……接踵而至。以笔者切身经历来说，企业此时其实早已经付出了极大的代价。
为何拥有完美技术观点的统一开发平台会成为“罪大恶极”者呢？这是一个很好的技术决策思辨话题。
上面列举了若干个支持统一开发平台的观点，这些无疑都是正确的，但是只要有一项致命短板，就足以令其不堪一击。这个短板就是统一开发平台的领域能力问题。在软件行业早已市场化的时代，每个领域都有众多专业化产品，细分领域的竞争态势焦灼。任何统一开发平台，不可能在如此多的领域内都达到业界领先性，那么结果就是，报表多样性不够、任务流的功能还有差距、表单功能不好用等问题。
领域能力的重要性极高，足可以拥有一票否决权。这与木桶原理是一致的，最短的那块板决定木桶能装多少水。
除此之外，统一开发平台是应用系统的一部分，与上层应用程序形成强关联，因此，过度依赖统一开发平台厂商也是致命问题。引入软件要考虑“耦合度”问题，采购统一开发平台，导致企业在应用开发方面，全面地、直接地被捆绑，这如同打开自己围场的栅栏，让外人一脚踩了进来。相比而言，采购云平台、大模型是情有可原的，做应用系统的企业难以有自行构建的能力。这样的采购令各方之间保持良好的距离，并不会打破各自的赛道。
现在，把批判性思维的话题延伸到云计算领域。云计算扛起了近十几年IT生态发展的一面大旗，但即使这样，我们仍旧不能对它的反模式视而不见。
最近进行的一项研究结果显示，在美国接受调查的企业中，有42%的企业考虑或已经着手将基于云的工作负载迁回内部基础设施，可以将这种现象称为云遣返。这项调查收集了350名IT领导者目前其公司正在采用的云计算战略方式。调查显示，94%的受访者在过去三年中参与过云计算遣返项目。相比IDC公司于2019年公布的有80%的客户报告云遣返活动的数据值，如今有越来越多的公司加入这一浪潮。
关于云遣返的原因，首要因素是安全问题（占全部调查中的41%）和对项目有较高的期望值（占全部调查中的29%），另一个重要驱动因素包括客户端／服务器、企业应用集成、面向服务的架构以及现在的云技术未能满足内部期望，占全部调查的24%。与此同时，不少受访者还提到了云会导致一些意外的成本、性能问题、兼容性问题和服务停机。
企业云资源分为公有云、私有云、混合云几种形态，上述研究结果主要指的是公有云。倘若是对于私有云用户，调查结果会如何呢？我认为赞成云遣返
的比例也不低。原因在于，除了安全问题相对可控之外，前面列举的其他问题，对于私有云而言或多或少同样存在。
云仍然是构建和部署新系统（如生成式人工智能）最方便的平台，它还拥有几乎所有的最新、最先进的技术。云平台非常适合利用无服务器、容器或集群等服务的现代应用程序。然而，这并不适合大多数企业应用。
以我的观点，这份调查并不会威胁到云供应商。云供应商可能会失去原本就不应该出现在公有云上的工作负载和数据集。但是考虑到AI的快速普及趋势，他们仍将享受爆炸式增长，毕竟云是构建和托管生成式人工智能应用和数据最方便的地方。建立和运行基于AI的系统所需的大量基础设施，将迅速取代因不少企业选择云遣返而造成的任何损失。因此，云计算还是很健康。
反模式是必然存在的，反模式意味着局部不健康，但并不代表整体不健康，只是必要的新陈代谢。这是一条重要的架构思维。
鲜活的思维，可以令我们随心所欲地想象、不被束缚，并且在这个过程中享受创造的乐趣。本节的最后，把云遣返的话题再做延伸，思考一下，能否在云遣返行为与软件架构之间发现一些有启发价值的关联？
笔者这里给出的参考答案是，软件架构有无数的质量属性，有一个不得不提的是“可牺牲”，很多从业者可能听过“可牺牲架构”这句行话。可牺牲架构是指在概念性验证
之后即可被抛弃的架构。
eBay最初使用Perl开发，然后迁移到C++，最后又用Java重新改写。这样的折腾行为，按理说是不可取的，但是并未妨碍eBay的成功。是否指重做系统并非成功与否的答案，关键在于有没有本事如此操作（指在可牺牲方面的战略和战术素养）。
eBay的例子好像在暗示，即使是“最佳实践”这个词，也是靠不住的，对于如何建设系统，没有什么一定是客观绝对的。我们生活中的事实也是如此：张三、李四都取得了成功，但两者的实践方式大相径庭。软件与生活，两者间多数道理是相通的，具有一致性。
云上环境使得可牺牲架构更具吸引力，对于实施云遣返工作的企业，正是通过公有云获得了这种能力，如果开发人员需要验证或搭建某个项目，可在云上构建初始版本，并能够在未来需要时进行彻底变化。这就是复杂性的深层来源——任何问题的无穷缠绕性。云遣返本来是作为一个反模式登场的，但摇身一变，反转成为“可牺牲架构”的代表者。
精华和糟粕，两者之间交替着相伴而生，形成合力，在整体上最终呈现螺旋式上升。所有的行业皆如此，软件当然也不例外。