夜雨聆风回顾这几十年软件系统架构的发展，整体可以按照技术迭代和行业主流模式，清晰分成三个大阶段，分别是2015年之前的传统架构阶段、2015到2020年的微服务架构阶段，还有2020年之后至今的云原生架构阶段，每个阶段的架构模式、核心组件、配套软件以及协作逻辑都有明显的变化，也贴合不同时期的业务规模、终端设备与数据存储的实际需求。
先来说2015年之前的传统架构阶段，这也是早年行业内应用最普遍的模式，整体又沿着终端形态的迭代，分化为三种主流形态，层层递进、逐步过渡，全程都属于单体架构的技术范畴，所有业务逻辑都集中部署在单一应用进程内。
最早成型并大规模商用的是传统客户端服务器模式，也就是纯C/S架构。当时的系统结构简洁直接，PC终端上需要安装专门的桌面客户端程序，服务端后台会部署一台独立的业务应用服务器，服务器后端直接对接数据库完成数据持久化。日常运行时，桌面客户端主要负责图形界面渲染、本地简单交互逻辑处理，用户的操作请求会通过网络直接发送至后端应用服务器；应用服务器承担全部核心业务运算、权限校验与数据存取逻辑，完成业务处理后再直接读写数据库返回结果，整套标准链路就是PC客户端→应用服务器→数据库。在这一时期，商用领域主流的应用服务器以老牌闭源产品为主，比如IBM WebSphere、Oracle WebLogic，开源领域则以Tomcat、Jetty为代表；数据库几乎清一色采用关系型数据库，行业内以Oracle、DB2、SQL Server为大型企业核心选型，中小企业普遍使用开源的MySQL，这类数据库擅长处理结构化表格数据，能够保证数据的强一致性，适配当时的业务场景。
随着互联网普及，用户不再愿意安装厚重的桌面客户端，架构自然过渡到了B/S浏览器服务器模式。这种模式下，客户端被彻底简化为通用的Web浏览器，无需任何专用安装包，服务端则新增了一层职责明确的Web服务器，形成了更精细的分层结构。Web服务器的核心定位是静态资源分发与请求转发，不参与任何业务逻辑运算，行业内主流选型是Nginx与Apache，专门负责分发HTML、CSS、JavaScript这类静态网页资源，同时将用户提交的动态业务请求精准转发至后方的应用服务器；应用服务器依旧是整个系统的业务核心，沿用之前Tomcat、WebLogic这类产品，负责接收请求、执行业务代码、完成数据运算，最终对接数据库实现数据读写，整套标准链路为Web浏览器→Web服务器→应用服务器→数据库。这个阶段的数据库依旧以关系型数据库为主，没有发生本质改变，系统核心诉求仍是处理交易、用户、订单这类规整的结构化数据。
智能手机全面普及后，移动端APP架构随之兴起，本质上是C/S架构在移动终端上的延伸，手机APP就相当于移动版的专用客户端，只是交互形式发生了根本变化。为了适配移动端轻量化、高频次的接口调用需求，服务端新增了专门的API服务器，APP不再请求网页内容，而是通过网络调用标准化接口，和API服务器交换数据，传输格式基本统一为轻量的JSON文本；API服务器再将接口请求转发给后方的应用服务器，沿用成熟的业务逻辑处理体系，最终依旧对接关系型数据库完成数据落地，整套链路为手机APP→API服务器→应用服务器→数据库。值得一提的是，这一阶段互联网业务开始出现大量非结构化数据，比如用户头像、短视频片段、聊天图文，传统关系型数据库难以高效存储这类数据，非关系型数据库开始进入行业视野，代表性产品是MongoDB与Redis，前者用于存储文档型非结构化数据，后者兼具缓存与简单KV数据存储能力，和传统MySQL形成互补，开始形成“关系库+非关系库”的混合存储雏形。整体来看，2015年之前的整个时期，无论终端是PC、浏览器还是手机，系统核心都还是单体应用架构，结构简单、开发便捷，但面对海量并发、复杂业务时，耦合严重、扩容困难、维护成本高的短板会被持续放大。
接下来是2015-2020年的微服务架构阶段，这是行业为解决单体架构性能瓶颈、业务耦合问题，完成的一次根本性架构升级，也是中大型互联网企业与大型商用软件的主流选型。
架构变革的核心动作，是将原本庞大臃肿、高度耦合的单体应用服务器，按照业务边界彻底拆分成数十个独立运行的微型服务单元，例如用户服务、订单服务、支付服务、商品服务、库存服务，每个微服务仅聚焦单一业务领域，独立部署、独立迭代、独立扩容，互不干扰。服务端的组件体系也随之全面重构，最外层原本零散的Web服务器、API服务器被统一替换为API网关，成为所有客户端请求的唯一入口，行业主流产品为Spring Cloud Gateway、Kong，它集中承担请求路由、统一鉴权、流量限流、日志监控等公共能力，将不同业务请求精准分发至对应的微服务实例。
业务层由拆分后的微服务集群构成，每个微服务本质上都是轻量化的独立应用，通常基于Spring Boot这类开源框架开发，运行在轻量级容器或独立进程中；由于微服务之间需要频繁跨服务调用协作，比如下单流程需要同步调用库存扣减、支付扣款、物流创建服务，行业随之引入了大量配套的服务治理组件与中间件。其中，注册中心与配置中心是核心治理组件，主流产品为Nacos、Eureka、Apollo，注册中心负责记录所有微服务的网络地址与运行状态，保障服务之间能够互相发现、完成调用；配置中心实现全集群配置的集中化管理，无需修改代码即可动态调整数据库地址、超时阈值等参数。同时，分布式中间件体系快速成熟，Redis作为分布式缓存被大规模普及，专门缓存热点商品数据、用户会话信息，大幅降低数据库的查询压力；RocketMQ、Kafka等消息队列用于实现业务异步解耦，例如下单成功后通过消息队列异步触发物流发货、短信通知，避免同步调用导致的系统阻塞；Seata等分布式事务组件则专门解决跨服务数据一致性问题，确保下单、扣库存、扣款这类跨服务操作能够同时成功或同时回滚。
数据存储层面也发生了结构性升级，一方面关系型数据库不再是全局唯一实例，每个核心微服务都会配套独立的MySQL数据库，避免业务之间互相影响，海量订单、流水数据还会通过ShardingSphere、MyCat等分库分表组件进行水平拆分；另一方面非关系型数据库的应用场景全面扩大，MongoDB用于存储海量用户行为日志、图文内容，Redis同时承担缓存与高速KV存储能力，形成了“多实例关系库+多样化非关系库”的混合数据存储体系，能够同时适配结构化交易数据与非结构化海量数据的存储需求。
最后就是2020年至今的云原生架构阶段，这是在微服务架构成熟的基础上，结合云计算基础设施发展完成的深度优化，核心解决微服务时代服务数量激增带来的部署繁琐、运维复杂、扩容滞后等问题，目前是头部互联网大厂、超大型商用系统的主流架构方向。
架构变革的核心思路，是将所有微服务、中间件、数据库组件全部标准化打包为Docker容器，容器能够屏蔽底层服务器环境差异，保证应用在任何服务器上都能稳定运行，彻底解决了传统部署中“环境不一致”的经典难题。在此基础上，行业引入了Kubernetes（简称K8s）作为核心管控组件，专门负责全集群所有容器的生命周期管理，能够实现容器的自动化部署、弹性扩容、故障自愈，例如电商大促并发量暴涨时，K8s可自动新增数十个订单服务容器分担压力；当某个容器异常宕机时，也能自动重启新的容器实例，极大降低了人工运维成本。
在整体组件分工上，接入层依旧沿用成熟的API网关，保持统一的外部请求入口；业务层则转变为大规模容器化微服务集群，所有微服务、Redis、消息队列等中间件都以容器形式运行，由K8s统一调度；服务治理层面的注册中心、配置中心继续沿用Nacos等成熟产品，保障服务发现与配置管理；中间件体系保持稳定，Kafka、Redis、Seata等组件持续承担异步通信、缓存加速、分布式事务等核心能力。数据存储层面则全面升级为云原生分布式数据库，代表性产品有OceanBase、TiDB，这类数据库融合了关系型数据库的强一致性与分布式数据库的横向扩容能力，无需人工分库分表，即可实现海量结构化数据的高效存储与查询，同时搭配对象存储、分布式文件系统等组件，进一步强化非结构化数据的存储能力。
整体梳理下来，软件架构数十年的演变，本质上是沿着业务复杂度提升、数据规模扩大、并发流量增长的需求持续迭代。从2015年前单体架构的简单分层、组件单一，到微服务时代的业务拆分、中间件丰富、数据存储多元化，再到云原生时代的容器化管控、自动化运维、分布式数据能力升级，每一次架构变革与配套软件的普及，都精准解决了上一代架构的核心痛点，不断提升大型软件系统的稳定性、扩展性与运维效率。
