大型网站架构演化历史 - 软件架构设计师

📑 演化阶段导航

1 单体架构时代（2000年前后） 2 垂直架构分离（2005年前后） 3 引入缓存时代（2008年前后） 4 服务集群与负载均衡（2010年前后） 5 数据库拆分（2012年前后） 6 分布式存储与CDN（2014年前后） 7 微服务架构兴起（2016年前后） 8 容器化与云原生（2020年前后） 9 现代架构范式（2023年至今） 10 未来趋势展望（2025年+）

🗺️ 架构演化全景图

单体架构

→

垂直架构

→

引入缓存

→

服务集群

→

数据库拆分

分布式存储

→

微服务

→

容器化/云原生

→

Serverless

→

AI原生架构

🏢 第一阶段：单体架构时代（2000年前后）

1️⃣

单体架构（Monolithic Architecture）

互联网早期，一切从简开始

单体架构：应用程序、数据库、文件系统全部部署在同一台服务器上，所有功能模块打包在一个进程内运行。

用户界面（HTML/JSP/PHP）

↕

业务逻辑层（All-in-One）

↕

数据访问层

↕

数据库 + 文件系统（同一台服务器）

技术栈

LAMP

Linux + Apache + MySQL + PHP，早期最流行的Web开发栈

JSP + Tomcat

Java Web应用，Servlet/JSP + Apache Tomcat

ASP + IIS

微软体系，Windows Server + IIS + SQL Server

                                ⚠️ 遇到的瓶颈：
                                单服务器性能有限，无法支撑高并发
应用与数据库强耦合，扩展困难
任何模块故障都可能导致整个系统宕机
代码规模增大后，开发效率急剧下降

                            

🔀 第二阶段：垂直架构分离（2005年前后）

2️⃣

垂直架构（Vertical Architecture）

第一次演化：应用、数据库、文件分离

垂直架构：将应用程序、数据库、文件系统分别部署到不同的服务器上，实现物理层面的分离，各司其职。

❌ 问题

单体架构中，应用、数据库、文件争夺同一台服务器的CPU、内存、IO资源

→

✅ 解决方案

将应用服务器、数据库服务器、文件服务器分离，独立扩展

应用服务器
Tomcat/WebLogic/WebSphere

数据库服务器
MySQL/Oracle/SQL Server

文件服务器
NFS/FTP/共享存储

关键技术

组件	技术选型	作用
Web服务器	Apache、Nginx	处理HTTP请求，静态资源服务
应用服务器	Tomcat、WebLogic、WebSphere、JBOSS	运行业务逻辑，处理动态请求
数据库	MySQL、Oracle、SQL Server	数据持久化存储
文件存储	NFS、FTP服务器	存储图片、文档等静态文件

                                💡 演化意义：
                                首次实现了资源的物理分离，各组件可独立扩展
数据库服务器可配置更高性能的存储（如RAID）
应用服务器可水平扩展（增加数量）
为后续的缓存、集群打下基础

                            

⚡ 第三阶段：引入缓存时代（2008年前后）

3️⃣

使用缓存改善性能

第二次演化：用空间换时间

缓存（Cache）：将热点数据存储在高速存储介质（如内存）中，减少对数据库的访问，用空间换时间。

缓存技术演进

🟦 Memcached

年代：2003年发布

特点：高性能分布式内存缓存，简单KV存储

局限：仅支持String，无持久化

🟥 Redis

年代：2009年发布

特点：支持多种数据结构，可持久化

优势：String/Hash/List/Set/ZSet

🟩 Squid

年代：1996年发布

特点：高性能代理缓存服务器

场景：Web代理、CDN边缘节点

三种缓存使用模式

Cache-Aside（旁路缓存）

读：先查缓存，miss则查DB并回填缓存

写：先更新DB，再删除缓存

最常用模式

Read/Write Through（读写穿透）

读：先查缓存，miss则由缓存层加载DB

写：先写缓存，由缓存层同步到DB

缓存作为统一入口

Write Behind（异步写入）

写：只写缓存，异步批量刷新到DB

优点：写性能极高

适合写多读少场景

Redis vs Memcached 对比

对比项	Redis	Memcached
数据结构	String/Hash/List/Set/ZSet	仅String
持久化	支持RDB/AOF	不支持
集群模式	原生支持	客户端分片
线程模型	单线程（6.0+多线程IO）	多线程
内存效率	较高（有额外结构开销）	更高（简单KV）
适用场景	复杂业务、需要持久化	纯缓存、简单KV

🎯 缓存常见问题

缓存雪崩：大量缓存同时失效，请求全部打到DB

解决：随机过期时间、多级缓存、熔断降级

缓存穿透：查询不存在的数据，缓存永远miss

解决：布隆过滤器、缓存空值

缓存击穿：热点key过期，大量请求打到DB

解决：互斥锁、永不过期+异步更新

缓存预热：系统启动时缓存为空

解决：启动时加载热点数据

⚖️ 第四阶段：服务集群与负载均衡（2010年前后）

4️⃣

服务集群与负载均衡

第三次演化：用数量换性能

负载均衡（Load Balancing）：将用户请求分发到多个服务器上，避免单点压力过大，提高系统整体处理能力。

❌ 问题

单台应用服务器性能有限，无法支撑日益增长的用户访问量

→

✅ 解决方案

部署多台应用服务器，通过负载均衡器分发请求

负载均衡分类

四层负载均衡（传输层）

原理：基于IP和端口转发

特点：不解析应用数据，性能极高

代表：LVS、F5、HAProxy（四层模式）

七层负载均衡（应用层）

原理：基于HTTP内容转发（URL、Cookie）

特点：可做精细流量控制

代表：Nginx、HAProxy（七层模式）

负载均衡算法

算法	原理	优点	缺点
轮询（Round Robin）	按顺序轮流分配	简单、公平	不考虑服务器性能差异
加权轮询	按权重比例分配	可按服务器能力分配	权重需手动配置
最少连接	分配给当前连接数最少的服务器	动态均衡	需维护连接状态
源地址哈希	同一IP的请求发往同一服务器	可保持会话	可能不均衡
一致性哈希	哈希环，节点增减影响小	适合分布式缓存	实现复杂

Session共享问题

                                问题：用户登录状态（Session）存储在单台服务器上，负载均衡后可能路由到其他服务器导致Session丢失。
                            

Session Sticky

同一用户的请求始终发往同一服务器。简单但不灵活。

Session Replication

Session在所有服务器间同步。可靠但开销大。

Session集中存储

Session存储在Redis等集中式存储中。推荐方案。

🗄️ 第五阶段：数据库拆分（2012年前后）

5️⃣

数据库读写分离与分库分表

第四次演化：突破数据库瓶颈

5.1 读写分离

读写分离：主数据库处理写操作，从数据库处理读操作，通过主从复制实现数据同步。

写请求
INSERT/UPDATE/DELETE

→

主库（Master）
负责写入

⇅

从库（Slave）×N
负责读取

←

读请求
SELECT

5.2 分库分表

垂直拆分

分库：按业务模块拆分数据库（用户库、订单库、商品库）

分表：将大表按列拆分为多个小表

解决：不同业务间的耦合

水平拆分

分库：同一业务数据按规则分散到多个库

分表：同一张表按行拆分（如按用户ID取模）

解决：单表数据量过大

分库分表中间件

中间件	类型	特点
ShardingSphere	Apache顶级项目	支持分库分表、读写分离、分布式事务
MyCat	数据库中间件	基于Cobar，支持MySQL协议
TDDL	阿里内部	淘宝分布式数据层

🎯 分库分表带来的问题

分布式事务：跨库事务难以保证ACID，常用TCC、Saga、最终一致性
跨库Join：无法直接Join，需要应用层组装或使用宽表
全局ID：需要分布式ID生成方案（雪花算法、UUID、号段模式）
扩容困难：增加分片需要数据迁移

🌐 第六阶段：分布式存储与CDN（2014年前后）

6️⃣

分布式存储与CDN

第五次演化：海量数据与就近访问

6.1 CDN内容分发网络

CDN（Content Delivery Network）：将内容缓存到离用户最近的边缘节点，用户访问时就近获取，减少网络延迟。

                                形象比喻：CDN就像连锁便利店，把商品（内容）分散存放在各个小区门口（边缘节点），用户不用跑到市中心的总仓库（源站）取货。
                            

CDN存储内容

静态资源（JS/CSS/图片）
视频流媒体
软件安装包
API响应（可缓存部分）

CDN工作流程

用户请求资源
DNS解析到最近的CDN节点
CDN节点有缓存则直接返回
无缓存则回源站获取并缓存

6.2 分布式存储

技术	类型	特点	适用场景
Hadoop HDFS	分布式文件系统	高吞吐、批处理	大数据分析、日志存储
FastDFS	分布式文件系统	轻量级、高性能	图片、文档存储
MinIO	对象存储	S3兼容、云原生	云存储、数据湖
Ceph	统一存储	块/文件/对象统一	云平台底层存储

6.3 NoSQL数据库兴起

NoSQL：非关系型数据库，解决关系型数据库在高并发、海量数据、灵活Schema方面的不足。

键值存储（KV Store）

代表：Redis、Memcached、DynamoDB

场景：缓存、会话、配置

文档数据库

代表：MongoDB、CouchDB

场景：内容管理、用户画像

列族数据库

代表：HBase、Cassandra

场景：时序数据、物联网

图数据库

代表：Neo4j、JanusGraph

场景：社交网络、推荐系统

6.4 JWT认证

JWT（JSON Web Token）：无状态的认证方案，Token中包含用户信息，服务端无需存储Session。

组成：Header（算法）+ Payload（数据）+ Signature（签名）

优势：无状态、跨服务、适合微服务架构

🔧 第七阶段：微服务架构兴起（2016年前后）

7️⃣

微服务架构（Microservices）

第六次演化：按业务拆分，独立部署

微服务架构：将单一应用程序拆分为一组小型服务，每个服务运行在独立进程中，围绕业务能力构建，通过轻量级机制通信。

微服务特征

服务组件化，围绕业务能力组织
去中心化治理，技术栈自由选择
独立部署，不影响其他服务
容错设计，服务降级与熔断

核心技术栈

Spring Cloud：Netflix全家桶
Dubbo：阿里高性能RPC框架
gRPC：Google高性能RPC
Istio：服务网格

微服务关键组件

功能	Spring Cloud	Dubbo	说明
服务注册发现	Eureka、Nacos	Zookeeper、Nacos	服务自动注册与发现
负载均衡	Ribbon	内置	客户端负载均衡
服务熔断	Hystrix、Sentinel	Sentinel	防止雪崩
API网关	Zuul、Gateway	—	统一入口、路由、鉴权
配置中心	Config、Nacos	Nacos	集中配置管理
链路追踪	Sleuth + Zipkin	SkyWalking	分布式调用链追踪

事件驱动架构

消息队列：服务间异步通信的核心组件
                                
                                        Kafka

                                        高吞吐、日志收集、流处理
                                    
                                        RabbitMQ

                                        功能丰富、中小规模
                                    
                                        RocketMQ

                                        阿里开源、事务消息

☁️ 第八阶段：容器化与云原生（2020年前后）

8️⃣

容器化与云原生架构

第七次演化：标准化交付与自动化运维

云原生（Cloud Native）：一种构建和运行应用程序的方法，充分利用云计算的优势，以容器化、微服务、DevOps为核心。

云原生四要素

🐳 容器化

技术：Docker、Containerd

价值：环境一致性、快速部署、资源隔离

☸️ 容器编排

技术：Kubernetes（K8s）

价值：自动扩缩容、服务发现、滚动更新

🔄 DevOps

技术：CI/CD、GitOps

价值：持续交付、自动化部署

📡 可观测性

技术：Prometheus、Grafana、Jaeger

价值：监控、日志、链路追踪

Serverless架构

Serverless（无服务器）：开发者无需管理服务器，只需编写业务代码，平台自动处理扩缩容、运维。
                                
                                        FaaS

                                        函数即服务
AWS Lambda
阿里云函数计算
                                    

                                        BaaS

                                        后端即服务
Firebase
Supabase
                                    

                                        特点

                                        按需付费
自动扩缩
事件驱动
                                    

服务网格（Service Mesh）

Service Mesh

原理：将服务通信逻辑下沉到Sidecar代理（如Envoy），应用无需感知网络细节。

代表技术：Istio、Linkerd

价值：流量管理、安全策略、可观测性统一治理

🚀 第九阶段：现代架构范式（2023年至今）

9️⃣

现代架构范式

数据融合、边缘计算、平台工程

9.1 数据与计算融合

                                湖仓一体：数据湖（S3/OSS）+ 数据仓库（Redshift/MaxCompute）融合，一份数据同时做BI + ML
                            

Lambda → Kappa架构

从批流分离到统一流处理，Kafka/Flink替代批量ETL

Data Mesh

数据产品思维，分域治理、联邦查询，去中心化数据管理

9.2 边缘计算

边缘计算（Edge Computing）：将计算任务从云端下沉到靠近数据源的边缘节点，减少延迟、节省带宽。

核心优势

超低延迟：数据就近处理，毫秒级响应
带宽节省：减少数据上传云端
隐私保护：敏感数据不出本地
高可靠性：断网也能独立运行

应用场景

CDN内容分发
物联网（IoT）数据处理
实时视频分析
AI边缘推理
自动驾驶

边缘计算三层架构

云中心层
全局调度、模型训练、大数据分析

↕

边缘层
区域计算、数据预处理、AI推理

↕

终端设备层
传感器、摄像头、手机、工控设备

9.3 响应式Web设计

                                响应式设计：一套代码适配多种设备（PC、平板、手机），通过媒体查询、弹性布局、流式图片实现。
                            

🔮 第十阶段：未来趋势展望（2025年+）

🔟

未来架构趋势

AI原生、Serverless 2.0、绿色计算

趋势1：AI原生架构

AI能力内嵌到架构各层：

AI辅助编码（Copilot）
AI驱动的自动扩缩容
智能运维（AIOps）
RAG + Agent应用架构

趋势2：Serverless 2.0

从FaaS扩展到全栈无服务器：

边缘函数（Cloudflare Workers）
数据库Serverless化（Aurora Serverless）
毫秒级冷启动
WebAssembly运行时

趋势3：平台工程

构建内部开发者平台（IDP）：

自助式基础设施
标准化交付流程
黄金路径模板
开发者体验优化

趋势4：绿色计算

碳中和驱动的架构优化：

ARM芯片（功耗低30-60%）
数据中心选址清洁能源区
碳感知调度
FinOps成本优化

国内外云厂商技术对比

厂商	计算	数据库	AI/ML	特色
AWS	EC2、Lambda、ECS	Aurora、DynamoDB	SageMaker、Bedrock	产品最全、生态最成熟
Azure	VM、Functions、AKS	Cosmos DB	OpenAI Service	企业集成、OpenAI独占
Google Cloud	GCE、GKE、Cloud Run	Spanner、Bigtable	Vertex AI、Gemini	K8s发源地、AI最强
阿里云	ECS、函数计算	PolarDB、OceanBase	PAI、通义千问	国内最大、电商经验丰富
腾讯云	CVM、SCF	TDSQL	混元大模型	游戏、社交场景优化
华为云	ECS、FunctionGraph	GaussDB	盘古大模型	政企市场、鲲鹏生态

⚖️ 核心理论：CAP定理与分布式权衡

CAP定理：分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）三者不可兼得，最多只能满足其中两个。

C - 一致性

所有节点看到的数据是一致的

例：银行转账后余额一致

A - 可用性

每个请求都能得到响应

例：电商下单不超时

P - 分区容错

网络分区时系统仍能运行

例：机房断网不影响服务

                    实际选择：
                    CP系统：放弃可用性，保证一致性。如：ZooKeeper、Etcd、HBase
AP系统：放弃强一致性，保证可用性。如：Cassandra、DynamoDB、Eureka
CA系统：理论存在，实际不存在（网络分区不可避免）。如：传统单机数据库

                

🎯 BASE理论（CAP的补充）

Basically Available（基本可用）：系统保证基本可用，允许部分功能降级

Soft State（软状态）：允许数据存在中间状态，不要求实时一致

Eventually Consistent（最终一致性）：经过一段时间后，数据最终达到一致

📊 技术维度总览

维度	涉及技术	解决的问题
架构模式	MVC → MVP → MVVM → 微服务 → Serverless	代码组织、解耦、可维护性
并发分流	集群、负载均衡、CDN	高并发、低延迟
缓存	Memcached、Redis、Squid	数据库压力、响应速度
数据库	主从复制、分库分表、NoSQL	数据量、读写性能
消息队列	Kafka、RabbitMQ、RocketMQ	异步解耦、削峰填谷
分布式存储	HDFS、FastDFS、MinIO、Ceph	海量数据存储
Web服务器	Apache、Nginx、Tomcat、IIS	HTTP服务、反向代理
容器化	Docker、Kubernetes	环境一致性、自动运维
可观测性	Prometheus、Grafana、Jaeger	监控、追踪、告警
安全	JWT、OAuth2、HTTPS、WAF	认证、授权、数据安全

🎯 考试重点与易错点

📝 高频考点

架构演化顺序：单体 → 垂直 → 缓存 → 集群 → 读写分离 → 分库分表 → 微服务 → 云原生
负载均衡算法：轮询、加权轮询、最少连接、一致性哈希
CAP定理：三选二，P必须选
缓存问题：雪崩、穿透、击穿的区别与解决方案

微服务组件：注册发现、负载均衡、熔断、网关、配置中心
数据库拆分：垂直拆分vs水平拆分
NoSQL分类：KV、文档、列族、图数据库
云原生四要素：容器化、编排、微服务、DevOps

易错点提醒

CAP三选二是误导：分区容错P必须保证，实际是CP或AP二选一
缓存穿透vs击穿：穿透是查询不存在的数据，击穿是热点key过期
四层vs七层负载均衡：四层基于IP:Port，七层基于HTTP内容
微服务vs SOA：微服务更细粒度、去中心化、独立部署
Serverless≠没有服务器：只是开发者不管理服务器，服务器仍然存在