20世纪60年代和70年代早期#xff0c;以大型主机和单体软件为主导。

而今天#xff0c;数字领域已完全不同#xff0c;运行在由云计算、API连接、AI算法、微服务…0

软件架构——我们数字世界的蓝图——自20世纪中叶计算机时代诞生以来已经发生了巨大演变。

20世纪60年代和70年代早期以大型主机和单体软件为主导。

而今天数字领域已完全不同运行在由云计算、API连接、AI算法、微服务和编排平台组成的分布式网络上。

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

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

最早的计算机是大型主机计算机——占据一个房间的大型强力硬件设备。

大型主机最初是独立的机器能够执行复杂的计算任务。

在20世纪70年代之前向大型主机发送指令通常使用打孔卡或磁带输出则通过打印机接收。

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

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

图片来源未知。

Mark

I和ENIAC分别在20世纪30年代和40年代为军事和研究目的而开发。

1948年首台商用大型主机UNIVAC问世。

接下来的几十年大型主机凭借其在批处理事务数据方面的卓越能力迅速被银行、金融和航空公司广泛采用。

至今许多此类系统仍在使用中。

大型主机应用通常使用COBOL通用商业导向语言编写至今仍在大型主机环境中流行。

这些应用的软件架构是单体式的即整个代码库是一个整体包含数据架构、应用方法、数据库连接、展示逻辑等未做模块化设计。

要更新这些组件的任何一个开发人员都需要访问整个代码库并将其以一个整体包重新部署。

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

网络和客户端-服务器约1950年代

网络连接计算机并促进它们之间的通信——从大型主机到终端、大型主机到大型主机后来扩展到客户端到服务器。

从1958年开始网络技术的发展使得大型主机可以通过电子方式连接将其转变为可以连接多个终端的多用户计算机。

取代了打孔卡和打印机人们可以使用显示器、键盘和命令行界面CLI来发送和接收数据。

技术限制制约了最初的几台互联计算机系统。

例如多路复用大型主机只能在本地使用因为电缆长度的限制要求终端与大型主机的位置非常接近。

这些早期的数据中心不仅包含计算机还有大量的人力向大型主机发送任务。

ARPANET是首个公共的广域计算机网络1969年正式上线。

它使用分组交换来传输数据这成为了我们今天所知的现代互联网的基础。

网络技术在1980年代推动了客户端-服务器结构的普及其中应用分为服务器软件和通过计算机网络通信的客户端软件。

这种结构在今天很常见客户端通常是台式计算机远程向服务器发出请求服务器返回响应。

通过分配计算资源服务器负责数据处理和检索而客户端负责展示数据。

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

首批客户端-服务器应用是邮件服务、Web服务器以及其他具有在线功能的桌面应用程序。

如今客户端-服务器已成为大多数应用程序的标准范式更广义上涵盖了服务请求方和服务提供方的通用模型。

尽管存在两层分离许多此类应用程序仍然是单体构建的。

所有应用功能都在单一代码库中紧密耦合并共享一个数据库的访问权限。

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

互联网是使用TCP/IP协议在设备和应用之间传输通信的全球计算机网络系统。

这是FTP程序、SSH系统以及当然还有万维网WWW的基础。

尽管互联网和万维网如今经常被混用但万维网实际上是几乎十年后在1990年才发明的。

万维网是一个信息系统——一个由HTML内容和链接组成的网络——通过互联网使用HTTP协议共享和组织信息。

这种信息存储方式在全球范围内可访问为网站和网络编程时代铺平了道路。

早期的网站是静态页面从Web服务器上显示数据。

1993年“通用网关接口”CGI的引入使Web的交互性开始崭露头角开启了Web应用的前景。

随着1995年JavaScript的发明Web交互性迅速发展JavaScript将脚本逻辑引入客户端。

它很快成为Web编程的新标准Web服务器可以更轻松地提供动态、交互式内容。

早期的论坛、公告栏和Web表单正是这一时期的产物。

Web的发明及其潜在可能性很快引发了下一波应用开**潮。

与其为应用程序构建一个专用客户端不如简单地构建一个可以托管在Web上的网站。

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

为了解决这些问题模块化成为讨论的主题。

在20世纪90年代服务器端进一步分为两层应用服务器和数据库服务器。

应用服务器存储所有的应用和业务逻辑而数据库服务器则存储数据记录这种分离降低了高处理量下的延迟。

大约在同一时间面向服务的架构SOA作为一种架构模式出现其中软件功能被设计成独立的服务只要系统遵循其使用规范这些服务可以与任何系统一起使用。

SOA鼓励开发企业应用时将其分解为松散耦合的服务这些服务通过网络上的通信协议交互这种模式至今仍占主导地位。

在SOA模式下一个购物应用可能包含多个服务一个用于库存跟踪另一个用于订单处理还有一个用于用户认证。

与基于微服务的应用不同SOA模式中的服务仍然通过应用层共享同一个数据库。

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

随SOA发展出现了制定一套标准和协议以定义这些服务与各种客户端之间的交互需求。

DCOM和CORBA是一些非基于Web的标准但很快被SOAP和REST

API等基于Web的标准所取代。

SOA提供了一种方式让不同提供商的服务可以整合到一个应用中或者让同一个服务在不同的客户端上使用比如Web门户或专用桌面接口。

虚拟机和云计算约2000年代

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

虚拟机Virtual

Machine是存在于软件层而非物理机上的计算机系统由管理程序hypervisor支持实现。

利用虚拟机可以更轻松地创建、更新和销毁多个运行不同操作系统的机器从而在应用开发过程中最大化资源分配和利用。

虽然机器虚拟化自20世纪60年代就已存在但直到2000年代随着Linux、Microsoft和VMware的快速发布才进入主流使用阶段。

这段时间亚马逊等公司发现了虚拟化带来的商业机会管理型云计算服务。

物理裸机昂贵且难以管理对于需要扩展的公司来说是一个限制因素。

有了Amazon

EC2这样的云计算服务公司可以租用虚拟机获得处理能力并根据需求进行扩展。

像Facebook和Netflix这样的新兴公司得以专注于构建其软件功能而无需维护底层硬件和数据中心。

启动的技术门槛显著降低加速了未来数十年初创公司和数字化原生业务的崛起。

随之而来的是分布式计算和软件架构的下一步发展微服务。

2010年代是多个向分布式计算趋势汇集的时代。

由于需要让第三方访问其服务2000年Salesforce和eBay推出了首批商业API允许其合作伙伴或客户在自己的网站或应用中集成功能。

从Twitter和Google

Maps到Stripe、Twilio以及如今的OpenAIAPI经济迅速膨胀推动了网络上的功能集成。

同样微服务架构在像Amazon和Netflix这样的扩展型公司中开始流行起来这些公司需要加快和简化开发周期而这一进程常被单体代码库拖慢。

通过将应用分解为独立的微服务每个微服务都有自己的数据库各团队可以独立更新和部署带来了更快速的发布和改进。

虽然有多种方式来打包和部署微服务——可以运行在物理机或虚拟机上——微服务架构的增长也得益于容器的出现。

与虚拟机类似容器也是一个抽象层概念上自20世纪70年代提出但直到2013年Docker开源后才进入企业领域。

与虚拟机相比容器提供了更高水平的隔离因此多个相同应用的实例和版本可以在同一操作系统上运行。

运行应用程序所需的所有组件——代码、运行时、库、依赖项和系统工具——都存储在容器内这为部署应用或微服务提供了更高的可移植性和可扩展性。

现代应用开发需要一种健全的方式来架构和整合本地或第三方服务、数据库等各种组件。

这就引出了今天的软件架构编排和事件系统。

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

7.1

在事件驱动架构中服务会将数据推送到一个服务总线或事件管道中任何连接的服务都可以读取并在必要时执行相关操作。

整体系统响应事件或状态变化而不跟踪单个事件对其他事件的影响从而降低服务之间依赖性。

尽管服务总线的概念自SOA出现以来就已存在但随着微服务的普及它得到了进一步推广代表性技术包括Kafka和Amazon

SQS。

事件驱动系统使得系统可以实时更新并提高响应能力同时在并行处理中提升吞吐量。

这一架构支持快速更新的系统如网约车或机票交易系统。

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

7.2

编排为解决微服务依赖性问题以及事件驱动架构中遇到的问题提供了另一种可行方案。

在编排模式中中心协调器按照预定义的流程调度每项任务或微服务仅在前一任务成功完成后才继续下一个任务。

不同于事件流编排器会跟踪整个流程的进度使开发人员能够更轻松地追踪和调试错误实施故障补偿机制。

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

使用xxx

Conductor可在分布式计算领域释放开发者的生产力。

广泛应用于[微服务编排]、[事件处理]和[LLM链式调用]xxx

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

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

作者简介魔都架构师多家大厂后端一线研发经验在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。

各大技术社区头部专家博主。

具有丰富的引领团队经验深厚业务架构和解决方案的积累。

中央/分销预订系统性能优化