带你看清架构发展：图解五大电商系统架构模式

软件架构模式的发展就像一场波澜壮阔的技术革命，每一次进化都推动了互联网和应用服务的前行。在这个过程中，电商系统作为一个极具代表性和典型性的场景，经历了从简单的单体架构到复杂的微服务架构的历程。我们从最基础的阶段讲起，结合吴军《浪潮之巅》的风格，用一种浅显易懂又直观的方式来描述每个阶段的架构演进。

单体架构 (Monolithic Architecture)

前端与服务端交互逻辑

在单体架构中，所有的代码被打包在一个应用程序里，包括前端的页面逻辑、后端的业务逻辑、数据库的访问等。通常，用户通过浏览器访问网站，前端通过 HTTP 请求直接与后端的应用服务器交互，应用服务器内部处理所有业务逻辑并与数据库交互。

技术栈

• 前端：HTML、CSS、JavaScript

• 网关：Nginx 或 Apache（可选，作为负载均衡器）

• 应用服务器：Java（JSP/Servlet）

• 数据库：MySQL、PostgreSQL

架构模式

单体架构模式下，所有功能模块被集成在一个应用程序里，便于开发初期快速搭建系统，但随着系统的复杂度增加，部署和维护变得困难。

具体框架

• Java：Spring Framework, Struts, JSP + Servlet添加图片注释，不超过 140 字（可选）

核心功能

• 简单的 MVC 模式支持，能够快速响应业务需求的变化。• 开发和部署简单，适用于小型电商系统的快速上线。

端到端的交互序列

在单体架构中，用户通过浏览器访问前端，前端请求被直接发送到应用服务器，应用服务器负责处理所有的业务逻辑，并与数据库交互。最终，应用服务器返回处理结果给前端。

核心角色与系统交互

• 用户：通过浏览器发送 HTTP 请求。

• 应用服务器：接收并处理请求，包含业务逻辑和数据库交互。

• 数据库服务器：存储电商系统中的商品、用户、订单等数据。描述

1. 用户通过浏览器发出商品页面的请求。

2. 浏览器将请求发送到应用服务器。

3. 应用服务器根据请求从数据库查询商品信息。

4. 数据库返回查询结果给应用服务器。

5. 应用服务器将结果组装为页面并返回给浏览器。

6. 浏览器最终向用户展示商品页面。

分层架构

随着电商系统的规模扩大，单体架构无法满足需求，系统逐步向分层架构过渡。通过将应用划分为表示层、业务逻辑层和数据访问层，分层架构不仅提升了代码的可维护性，还提高了系统的可扩展性。

前端与服务端交互逻辑

在分层架构中，用户通过浏览器访问前端页面，前端请求被传递到网关服务器，再由网关将请求转发至 Web 服务器，Web 服务器负责处理静态资源，而动态请求交由应用服务器处理，应用服务器再与数据库服务器交互完成操作。

技术栈

• 前端：HTML、CSS、JavaScript + AJAX

• 网关：Nginx

• Web服务器：Tomcat• 应用服务器：Spring Framework + Spring MVC

• 数据库：MySQL

架构模式

分层架构主要分为以下几层：

• 表现层（UI 层）：处理用户交互，通常是 HTML、CSS、JavaScript。

• 业务逻辑层：包含核心的业务规则和逻辑。

• 数据访问层：负责数据库的 CRUD 操作。

具体框架

• Java：Spring MVC, Hibernate

核心功能

• Spring Framework 提供了依赖注入、AOP 等功能，方便开发者进行模块化开发。

• Hibernate 提供了 ORM 功能，简化了与数据库的交互。

端到端的交互序列

分层架构通过将系统划分为不同的层次，每层负责处理特定的任务。用户的请求先经过网关服务器，再进入 Web 服务器，Web 服务器将请求转发给应用服务器。应用服务器处理业务逻辑并访问数据库。

核心角色与系统交互

• 用户：通过浏览器发起 HTTP 请求。

• 网关服务器：负责接收请求并转发到 Web 服务器。

• Web 服务器：处理静态资源并转发动态请求到应用服务器。

• 应用服务器：处理业务逻辑，访问数据库。

• 数据库服务器：提供数据存储服务。添加图片注释，不超过 140 字（可选）

描述

1. 用户通过浏览器发起商品页面请求，发送到网关服务器。

2. 网关服务器转发请求到 Web 服务器。

3. Web 服务器识别请求为动态内容后，将其发送给应用服务器。

4. 应用服务器处理业务逻辑，并从数据库查询商品数据。

5. 数据库返回商品数据给应用服务器。

6. 应用服务器将数据发送给 Web 服务器，Web 服务器将结果传回网关服务器。

7. 网关服务器最终将响应返回给用户。

面向服务架构 (SOA - Service-Oriented Architecture)

当系统规模进一步扩大，单纯的分层架构开始表现出局限性，服务的复用性和模块之间的耦合性问题日益突出。SOA 通过将系统分割成多个服务，每个服务独立部署和运行，解决了这个问题。

前端与服务端交互逻辑

在 SOA 架构中，用户的请求首先经过网关，网关会根据请求的类型将其转发到不同的服务。每个服务独立运行，并可以通过服务总线（ESB）进行通信。最终，服务与数据库交互。

技术栈

• 前端：HTML、CSS、JavaScript + AJAX

• 网关：Nginx

• 应用服务器：Spring Boot

• 服务总线：Apache Camel、WSO2

• 数据库：MySQL、PostgreSQL

架构模式

SOA 将系统的功能分解为独立的服务，通过 ESB（企业服务总线）进行通信和协调。

具体框架

• Java：Spring Boot, Apache Camel, WSO2

核心功能

• Spring Boot 提供了快速构建独立应用服务的能力。• Apache Camel 和 WSO2 作为服务总线的实现，提供了服务之间的协调和通信。

核心角色与系统交互

SOA 架构将系统分割为多个服务，每个服务独立部署和执行。用户的请求通过网关进入服务总线，服务总线协调各个服务的调用，完成业务逻辑的处理。

• 用户：通过浏览器发起请求。

• 网关服务器：负责请求路由。

• 服务总线 (ESB)：管理各个服务之间的通信和协调。

• 各个独立服务：如用户管理服务、商品服务、订单服务。

• 数据库服务器：存储服务的数据。

序列图

描述

1. 用户通过浏览器请求商品页面，发送到网关服务器。

2. 网关服务器将请求转发至服务总线。

3. 服务总线调用商品服务来处理业务逻辑。

4. 商品服务从数据库查询商品数据。

5. 数据库返回商品数据给商品服务。

6. 商品服务通过服务总线返回数据给网关服务器。

7. 网关服务器最终将响应返回给用户。

4. 微服务架构 (Microservices Architecture)

SOA 在一定程度上解耦了服务，但仍然存在服务之间的紧密耦合问题，微服务架构进一步细化了服务。微服务架构强调 去中心化管理，每个微服务只专注于某一个功能，独立部署和扩展。API 网关作为外部请求的入口，负责路由请求给不同的微服务，微服务之间通过轻量级的通信协议（如 HTTP/REST 或 gRPC）进行交互。在复杂场景下，可以引入消息队列进行异步通信。前端与服务端交互逻辑在微服务架构中，用户请求通过 API 网关进入，API 网关负责调用多个微服务，每个微服务只处理其独立的业务逻辑，微服务之间通过消息队列或 HTTP/REST 进行通信，最终与数据库交互。

技术栈

• 前端：React, Vue.js• 网关：Nginx, Spring Cloud Gateway• 应用服务器：Spring Boot, Spring Cloud• 服务通信：Kafka, RabbitMQ• 数据库：MySQL、MongoDB

技术栈

微服务架构依赖于不同的技术栈来支持独立的服务化模块和通信。其主要技术栈如下：

• 前端：React、Vue.js

• API 网关：Nginx、Spring Cloud Gateway

• 微服务：Spring Boot + Spring Cloud

• 服务通信：Kafka、RabbitMQ、gRPC、HTTP/REST

• 数据库：MySQL、MongoDB、PostgreSQL

具体框架

在 Java 领域，Spring Boot 和 Spring Cloud 成为微服务架构的主力框架。Spring Boot 提供了快速构建独立微服务的能力，而 Spring Cloud 提供了服务发现、配置管理、负载均衡等分布式系统的核心组件。

核心功能

• Spring Boot：提供了简化开发、独立部署、自动化配置的能力，使开发者能够轻松创建轻量级的微服务应用。

• Spring Cloud：为分布式系统提供完整的微服务解决方案，包括服务发现（Eureka）、配置管理（Spring Cloud Config）、熔断机制（Hystrix）、负载均衡（Ribbon）等。

• 消息队列（Kafka/RabbitMQ）：在服务之间进行异步通信，适用于高并发、解耦合的场景。• API 网关：作为所有微服务的统一入口，进行请求路由、负载均衡、认证授权等操作。

端到端的交互序列

微服务架构通过将应用拆分为多个微服务，每个服务独立部署。用户请求通过 API 网关进入，API 网关调用多个微服务处理不同业务，微服务之间可以通过消息队列或 HTTP 进行通信。

核心角色与系统交互

• 用户：通过浏览器发起请求。

• API 网关：负责请求路由和负载均衡。

• 多个微服务：如用户管理服务、商品服务、订单服务等。

• 消息队列：用于微服务之间的异步通信。

• 数据库服务器：存储各个微服务的数据。

序列图

5. 无服务器架构 (Serverless Architecture)

进入云时代，微服务架构虽然在灵活性和扩展性上表现优异，但仍然需要开发者管理基础设施。随着云计算的发展，无服务器架构（Serverless）逐渐成为一种新的选择，在这个架构中，开发者只需关注业务逻辑，基础设施的管理、扩展和维护交由云提供商来处理。

前端与服务端交互逻辑

在 Serverless 架构中，用户通过前端发起请求，通常会先经过一个 API 网关。API 网关将请求转发至无服务器函数（如 AWS Lambda 或 Azure Functions），这些函数在云中按需运行，无需持续的服务器实例。无服务器函数可以与数据库或其他云服务交互，处理完成后返回结果。

技术栈

Serverless 架构的技术栈主要由云服务提供商的各种托管服务组成，开发者可以根据需求自由组合这些服务：

• 前端：React、Vue.js• API 网关：AWS API Gateway、Azure API Management

• 无服务器计算：AWS Lambda、Azure Functions

• 数据库：DynamoDB、Firebase Firestore

• 存储：S3、Azure Blob Storage

架构模式

无服务器架构模式通过将业务逻辑封装为单独的函数，并利用云计算平台的按需分配资源模式，极大简化了基础设施的管理。开发者不再需要关心服务器的运行状态，而是专注于具体的业务逻辑。

具体框架

在 Java 开发领域，AWS 提供了 Java SDK 支持 Lambda 函数的开发。通过 AWS SAM（Serverless Application Model），开发者可以方便地定义和部署无服务器应用。

核心功能

• 无服务器计算（AWS Lambda/Azure Functions）：按需执行函数，根据请求自动伸缩，只有在执行期间产生费用，极大地降低了资源浪费。• API 网关：处理所有外部请求，路由到不同的无服务器函数，并进行请求验证、速率限制等功能。• 数据库与存储：与无服务器函数进行集成，提供持久化数据存储和文件存储。

端到端的交互序列

在无服务器架构中，用户请求通过 API 网关进入，API 网关将请求转发至无服务器函数（如 AWS Lambda），无服务器函数处理业务逻辑并访问数据库或其他云服务，返回结果给用户。

核心角色与系统交互

• 用户：通过浏览器发起请求。

• API 网关：处理请求并路由到无服务器函数。

• 无服务器函数：按需执行业务逻辑。

• 数据库和云服务：无服务器函数所需的数据存储和服务。

描述

1. 用户通过浏览器发起商品页面请求，发送到 API 网关。

2. API 网关将请求转发给无服务器函数。

3. 无服务器函数处理业务逻辑，并查询数据库中的商品数据。

4. 数据库返回数据给无服务器函数。

5. 无服务器函数将结果返回 API 网关。

6. API 网关将最终响应返回给用户。

总结

软件架构模式的发展，从最初的单体架构到如今的无服务器架构，都是围绕提升可扩展性、简化维护、优化性能为核心目的。每种架构模式都有其适用的场景，在电商系统中，随着业务规模的扩展，从单体架构逐渐演变为分层架构、SOA、微服务，再到如今的 Serverless，体现了技术在应对复杂度和灵活性要求上的不断进化。通过合理选择技术栈和架构模式，电商系统得以应对不断增长的用户需求、流量压力以及快速变化的市场环境。