软件架构演变：从单体架构到LLM链式调用|工作流|应用程序|服务器|虚拟机|软件架构|链式调用

点击下方“JavaEdge”，选择“设为星标”

第一时间关注技术干货！

免责声明~ 任何文章不要过度深思！万事万物都经不起审视，因为世上没有同样的成长环境，也没有同样的认知水平，更「没有适用于所有人的解决方案」；别急着评判文章列出的观点，只需代入其中，适度审视一番自己即可，能「跳脱出来从外人的角度看看现在的自己处在什么样的阶段」才不为俗人。怎么想、怎么做，全在乎自己「不断实践中寻找适合自己的大道」

0 前言

软件架构——我们数字世界的蓝图——自20世纪中叶计算机时代诞生以来，已经发生了巨大演变。20世纪60年代和70年代早期，以大型主机和单体软件为主导。而今天，数字领域已完全不同，运行在由云计算、API连接、AI算法、微服务和编排平台组成的分布式网络上。

软件架构是如何随着岁月演变的？回顾几十年来的技术进步，我们可以看到商业需求、市场趋势和工程实践的变化如何影响了软件架构。

1 大型主机和单体架构：约1940年代

最早的计算机是大型主机计算机——占据一个房间的大型强力硬件设备。大型主机最初是独立的机器，能够执行复杂的计算任务。在20世纪70年代之前，向大型主机发送指令通常使用打孔卡或磁带，输出则通过打印机接收。

1950年代的数据中心注释图示，包含中央处理器、磁带单元、磁带控制器、输入/输出控制器、控制台、打孔卡、卡片读取器、磁盘存储和高速打印机：

20世纪70年代之前，数据中心中安装了可以接收打孔卡或磁带指令的大型主机。图片来源：未知。

第一台大型主机计算机是哈佛马克一号（Harvard Mark I）和ENIAC，分别在20世纪30年代和40年代为军事和研究目的而开发。1948年，首台商用大型主机UNIVAC问世。接下来的几十年，大型主机凭借其在批处理事务数据方面的卓越能力，迅速被银行、金融和航空公司广泛采用。至今，许多此类系统仍在使用中。

大型主机应用通常使用COBOL（通用商业导向语言）编写，至今仍在大型主机环境中流行。这些应用的软件架构是单体式的，即整个代码库是一个整体，包含数据架构、应用方法、数据库连接、展示逻辑等，未做模块化设计。要更新这些组件的任何一个，开发人员都需要访问整个代码库，并将其以一个整体包重新部署。

单体架构图示，用户界面、应用逻辑和数据库存储在单一代码库中，一起部署：

网络连接计算机并促进它们之间的通信——从大型主机到终端、大型主机到大型主机，后来扩展到客户端到服务器。从1958年开始，网络技术的发展使得大型主机可以通过电子方式连接，将其转变为可以连接多个终端的多用户计算机。取代了打孔卡和打印机，人们可以使用显示器、键盘和命令行界面（CLI）来发送和接收数据。

技术限制制约了最初的几台互联计算机系统。例如，多路复用大型主机只能在本地使用，因为电缆长度的限制要求终端与大型主机的位置非常接近。这些早期的数据中心不仅包含计算机，还有大量的人力向大型主机发送任务。

ARPANET是首个公共的广域计算机网络，1969年正式上线。它使用分组交换来传输数据，这成为了我们今天所知的现代互联网的基础。

网络技术在1980年代推动了客户端-服务器结构的普及，其中应用分为服务器软件和通过计算机网络通信的客户端软件。这种结构在今天很常见：客户端，通常是台式计算机，远程向服务器发出请求，服务器返回响应。通过分配计算资源，服务器负责数据处理和检索，而客户端负责展示数据。

客户端-服务器架构图示，客户端侧包含用户界面，向服务器侧发出请求，应用逻辑和数据库存储在服务器上：

首批客户端-服务器应用是邮件服务、Web服务器以及其他具有在线功能的桌面应用程序。如今，客户端-服务器已成为大多数应用程序的标准范式，更广义上涵盖了服务请求方和服务提供方的通用模型。

尽管存在两层分离，许多此类应用程序仍然是单体构建的。所有应用功能都在单一代码库中，紧密耦合，并共享一个数据库的访问权限。

3 万维网、网站和Web应用：约1980年代

1983年标志着互联网时代的到来。互联网是使用TCP/IP协议在设备和应用之间传输通信的全球计算机网络系统。这是FTP程序、SSH系统以及当然还有万维网（WWW）的基础。

尽管互联网和万维网如今经常被混用，但万维网实际上是几乎十年后在1990年才发明的。万维网是一个信息系统——一个由HTML内容和链接组成的网络——通过互联网使用HTTP协议共享和组织信息。这种信息存储方式在全球范围内可访问，为网站和网络编程时代铺平了道路。

早期的网站是静态页面，从Web服务器上显示数据。1993年“通用网关接口”（CGI）的引入，使Web的交互性开始崭露头角，开启了Web应用的前景。

随着1995年JavaScript的发明，Web交互性迅速发展，JavaScript将脚本逻辑引入客户端。它很快成为Web编程的新标准，Web服务器可以更轻松地提供动态、交互式内容。早期的论坛、公告栏和Web表单正是这一时期的产物。

Web的发明及其潜在可能性很快引发了下一波应用开发浪潮。与其为应用程序构建一个专用客户端，不如简单地构建一个可以托管在Web上的网站。

4 面向服务的架构和Web服务：约1990年代

随着应用开发的发展，单一代码库变得越来越难以管理，而且很明显一个系统中包含的功能或数据可以在另一个系统中复用。

为了解决这些问题，模块化成为讨论的主题。在20世纪90年代，服务器端进一步分为两层：应用服务器和数据库服务器。应用服务器存储所有的应用和业务逻辑，而数据库服务器则存储数据记录，这种分离降低了高处理量下的延迟。

大约在同一时间，面向服务的架构（SOA）作为一种架构模式出现，其中软件功能被设计成独立的服务，只要系统遵循其使用规范，这些服务可以与任何系统一起使用。SOA鼓励开发企业应用时将其分解为松散耦合的服务，这些服务通过网络上的通信协议交互，这种模式至今仍占主导地位。

在SOA模式下，一个购物应用可能包含多个服务：一个用于库存跟踪，另一个用于订单处理，还有一个用于用户认证。与基于微服务的应用不同，SOA模式中的服务仍然通过应用层共享同一个数据库。

面向服务的架构图示（SOA），应用逻辑被分成独立的服务，尽管这些服务共享一个数据库：

随SOA发展，出现了制定一套标准和协议以定义这些服务与各种客户端之间的交互需求。DCOM和CORBA是一些非基于Web的标准，但很快被SOAP和REST API等基于Web的标准所取代。SOA提供了一种方式，让不同提供商的服务可以整合到一个应用中，或者让同一个服务在不同的客户端上使用，比如Web门户或专用桌面接口。

5 虚拟机和云计算：约2000年代

SOA为从传统的桌面应用向一种新型软件应用模式——SaaS（软件即服务）过渡铺平了道路，但虚拟机和云计算的出现进一步推动了未来几十年SaaS产品的快速增长。

虚拟机（Virtual Machine）是存在于软件层而非物理机上的计算机系统，由管理程序（hypervisor）支持实现。利用虚拟机，可以更轻松地创建、更新和销毁多个运行不同操作系统的机器，从而在应用开发过程中最大化资源分配和利用。

虚拟机图示，虚拟机通过管理程序运行在同一物理机上：

虽然机器虚拟化自20世纪60年代就已存在，但直到2000年代随着Linux、Microsoft和VMware的快速发布，才进入主流使用阶段。这段时间，亚马逊等公司发现了虚拟化带来的商业机会：管理型云计算服务。物理裸机昂贵且难以管理，对于需要扩展的公司来说是一个限制因素。有了Amazon EC2这样的云计算服务，公司可以租用虚拟机获得处理能力并根据需求进行扩展。

像Facebook和Netflix这样的新兴公司，得以专注于构建其软件功能，而无需维护底层硬件和数据中心。启动的技术门槛显著降低，加速了未来数十年初创公司和数字化原生业务的崛起。随之而来的是分布式计算和软件架构的下一步发展：微服务。

6 API、容器与微服务的崛起：约2010年代

2010年代是多个向分布式计算趋势汇集的时代。由于需要让第三方访问其服务，2000年Salesforce和eBay推出了首批商业API，允许其合作伙伴或客户在自己的网站或应用中集成功能。从Twitter和Google Maps到Stripe、Twilio以及如今的OpenAI，API经济迅速膨胀，推动了网络上的功能集成。

同样，微服务架构在像Amazon和Netflix这样的扩展型公司中开始流行起来，这些公司需要加快和简化开发周期，而这一进程常被单体代码库拖慢。通过将应用分解为独立的微服务，每个微服务都有自己的数据库，各团队可以独立更新和部署，带来了更快速的发布和改进。

基于微服务的架构图示，独立的服务与独立数据库连接，可以独立部署：

虽然有多种方式来打包和部署微服务——可以运行在物理机或虚拟机上——微服务架构的增长也得益于容器的出现。与虚拟机类似，容器也是一个抽象层，概念上自20世纪70年代提出，但直到2013年Docker开源后才进入企业领域。

与虚拟机相比，容器提供了更高水平的隔离，因此多个相同应用的实例和版本可以在同一操作系统上运行。运行应用程序所需的所有组件——代码、运行时、库、依赖项和系统工具——都存储在容器内，这为部署应用或微服务提供了更高的可移植性和可扩展性。

容器图示，容器是一种抽象层，能实现应用或微服务的隔离：

现代应用开发需要一种健全的方式来架构和整合本地或第三方服务、数据库等各种组件。这就引出了今天的软件架构：编排和事件系统。

7 编排、事件系统与分布式依赖问题的解决：当代

随着计算模式向分布式模式发展——微服务、API以及某种程度上的SOA——软件架构面临一个突出的挑战：这些独立的服务、数据库和组件如何进行通信和交互，以形成一个协调一致的流程？

解决分布式服务间依赖问题的主要方法有两种：事件驱动架构和编排。

7.1 事件驱动架构

在事件驱动架构中，服务会将数据推送到一个服务总线或事件管道中，任何连接的服务都可以读取并在必要时执行相关操作。整体系统响应事件或状态变化，而不跟踪单个事件对其他事件的影响，从而降低服务之间依赖性。

尽管服务总线的概念自SOA出现以来就已存在，但随着微服务的普及，它得到了进一步推广，代表性技术包括Kafka和Amazon SQS。事件驱动系统使得系统可以实时更新并提高响应能力，同时在并行处理中提升吞吐量。这一架构支持快速更新的系统，如网约车或机票交易系统。

事件驱动架构图示，服务（生产者）将数据（称为事件）推入事件流中，其他服务（消费者）可以订阅并接收事件：

编排为解决微服务依赖性问题以及事件驱动架构中遇到的问题提供了另一种可行方案。在编排模式中，中心协调器按照预定义的流程调度每项任务或微服务，仅在前一任务成功完成后才继续下一个任务。不同于事件流，编排器会跟踪整个流程的进度，使开发人员能够更轻松地追踪和调试错误，实施故障补偿机制。

编排图示，各服务、数据库、事件流等连接至中央编排器，协调各组件进入有向的工作流：

利用先进的工作流编排平台如xxx Conductor，可在分布式计算领域释放开发者的生产力。广泛应用于微服务编排、事件处理和LLM链式调用，xxx Conductor帮助团队轻松构建具备高弹性和可扩展性的系统：

可视化工作流编辑器— 使用数十种集成、定制任务和内置的系统任务及操作器，涵盖API、Webhook、数据库及LLM，通过可视化方式构建和编辑工作流
弹性能力—在Conductor的稳健基础设施上以最小延迟运行数百万个并发工作流，设计为耐久、快速和具备冗余
故障处理—提供速率限制、重试策略、超时等原生支持
版本管理—无中断地对工作流进行版本控制，确保生产运行稳定
内省与指标—检查工作流性能和日志，以便于测试和调试，并获取吞吐量等聚合分析
企业级安全性—通过SSO、RBAC和密钥变量实现安全访问

关注我，紧跟本系列专栏文章，咱们下篇再续！

★ 作者简介：魔都架构师，多家大厂后端一线研发经验，在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。负责：中央/分销预订系统性能优化活动&券等营销中台建设交易平台及数据中台等架构和开发设计车联网核心平台-物联网连接平台、大数据平台架构设计及优化 LLM Agent应用开发区块链应用开发大数据开发挖掘经验推荐系统项目目前主攻市级软件项目设计、构建服务全社会的应用系统。 ”

参考：