架构的演变

概述

大型网站架构从单机逐步演变为分布式微服务架构，每一版均针对前一阶段的性能、负载、可用性等痛点优化，最终实现高性能、高可用、可伸缩等目标。架构演进的核心逻辑是 “按需迭代”：先解决核心瓶颈，再通过标准化、精细化优化提升架构韧性，避免 “过度设计”。

核心概念

分布式：业务拆分为多个子系统，部署在不同服务器（如商品、订单、支付），通过节点通信协同工作。

集群：同一业务部署在多台服务器，承担相同工作，通过负载均衡分流请求。比如 PHP 集群，MySQL 集群，Redis 集群。

微服务：分布式的主流实现方式，聚焦 “服务粒度” 拆分（独立部署、独立运维），强调服务闭环和低耦合，核心是 “标准化服务治理”+“细粒度拆分”。

各架构版本及解决的痛点

第 1 版：单机负载架构

架构组成：应用程序、数据库、文件均部署在单台服务器。

解决痛点：满足创业初期快速搭建系统的需求，以效率为核心完成基础功能落地。

第 2 版：应用与数据库进行服务器分离

架构组成：拆分出应用服务器、数据库服务器、文件服务器，各自独立部署。

解决痛点：单机负载过高，硬件性能触及瓶颈。

第 3 版：引入单机缓存优化性能

架构组成：在应用服务器增加本地缓存（如 Java 的 HashMap、Caffeine），新增单机 Redis 缓存服务器（独立部署，未做集群）。

解决痛点：热点数据访问频繁，数据库压力大；利用 “28 原则” 缓存热点数据（如商品详情、首页推荐），缩短访问路径，提升用户访问速度；单机 Redis 相比本地缓存，支持缓存数据共享（多应用实例可复用缓存），且缓存容量不受应用服务器内存限制。

第 4 版：应用与缓存集群化 + 基础网关能力

架构组成：

1、应用层新增多台应用服务器

2、部署Nginx 作为负载均衡 + 基础网关，集成核心能力：

  • 请求分发（轮询、加权、IP 哈希）；

  • 健康检查（剔除故障节点）；

  • 请求过滤（基于 Nginx + Lua 拦截非法请求、接口鉴权）；

  • SSL 卸载（解密 HTTPS 请求，避免应用服务器重复消耗资源）；

  • 静态资源本地缓存（补充后续 CDN 未覆盖的边缘场景）；

3、缓存层：

将单机 Redis 升级为Redis 集群（如主从复制 + 哨兵模式、Redis Cluster），提升缓存可用性与容量扩展能力。

核心说明：

Nginx 本身兼具 “负载均衡” 与 “反向代理” 的基础能力，无需单独拆分部署。本版将 “请求分流” 与 “基础流量优化” 合并，避免重复部署组件 ——SSL 卸载虽消耗资源有限，但集中在网关处理可减少应用服务器的重复配置与资源占用；请求过滤通过 Nginx + Lua 实现，无需额外组件，符合 “轻量迭代” 原则。

解决痛点：

  1. 单台应用服务器无法承载持续增长的访问量，负载均衡实现请求分流；

  2. 单机 Redis 存在单点故障风险，Redis 集群通过多节点冗余实现高可用与横向扩容；

  3. 非法请求直接穿透到应用服务器，增加业务处理压力，请求过滤实现第一层防护；

  4. 应用服务器需单独配置 HTTPS，维护成本高，SSL 卸载实现集中化配置。

第 5 版：数据库读写分离

架构组成：数据库拆分为主库（处理写操作）和从库（处理读操作），主从数据同步（如 MySQL 的 binlog 同步）。

解决痛点：数据库负载持续增大，读写请求冲突影响性能；分离读写操作，提升数据库并发处理能力，避免数据不一致问题。

第 6 版：引入 NoSQL 与搜索引擎

架构组成：新增两类核心组件，与原有关系型数据库、Redis 集群形成互补：

  1. 文档型 NoSQL 数据库（如 MongoDB）：用于存储非结构化 / 半结构化海量数据（如商品详情、用户行为日志、评论内容）；

  2. 搜索引擎（如 Elasticsearch）：独立部署搜索引擎集群，构建全文检索索引（如商品名称、描述、标签的关键词索引）；

  3. 补充说明：Redis 延续第 4 版的缓存集群功能，同时可作为 K-V 型 NoSQL 承载特定存储场景（如用户会话、临时配置、排行榜数据）。

解决痛点：

关系型数据库存在两大短板

① 对非结构化数据存储支持弱

② 模糊查询（如 “搜索超薄笔记本”）需全表扫描，效率极低，无法满足电商、内容平台的核心搜索需求；

通过 NoSQL 优化海量非结构化数据存储，搜索引擎通过倒排索引实现毫秒级全文检索，大幅提升查询精准度与速度；

Redis 作为 K-V 型 NoSQL 时，与缓存场景的核心区别是：存储数据生命周期更长（如用户会话有效期 7 天）、需保障数据可靠性（开启 RDB+AOF 持久化），而非临时缓存热点数据。

第 7 版：CDN 加速

架构组成：

CDN 服务器：部署在全国 / 全球运营商机房，缓存静态资源（图片、视频、JS/CSS 文件、静态页面）；

解决痛点：

跨地域访问延迟高：CDN 让用户从就近运营商机房获取静态资源，避免跨骨干网传输，提升静态资源加载速度；

第 8 版：垂直应用拆分（服务化雏形）

架构组成：

按业务线拆分为独立部署的应用（如商品应用、订单应用、用户应用），每个应用拥有独立的数据库（初步实现 “应用 - 数据库” 一一对应）；

通过 RPC 框架（如 Dubbo 基础版） 实现应用间同步调用，通过消息队列（如 RabbitMQ、Kafka）实现异步通信（如订单创建后异步通知库存扣减）。

核心定位：

这是 “服务化的雏形”—— 已实现 “独立部署、独立数据、跨应用调用”，但缺乏标准化的服务治理能力，仅能满足 “业务解耦” 和 “独立扩容” 的基础需求。

解决痛点：

  1. 单体应用臃肿，维护与迭代效率低；

  2. 不同业务线访问量差异大，无法单独扩容（如订单应用访问量激增，仅需扩容订单应用，不影响商品应用）；

  3. 业务耦合严重，一个模块故障影响整个系统，垂直拆分实现故障隔离。

第 9 版：服务化拆分（标准化治理）

架构组成：在第 8 版垂直应用的基础上，进行 “细粒度拆分” 与 “标准化治理”：

  1. 拆分优化：将垂直应用拆分为更细粒度的独立服务（如商品应用拆分为商品查询服务、商品库存服务、商品定价服务；用户应用拆分为用户认证服务、用户信息服务）；

  2. 服务治理：引入分布式服务框架（如 Dubbo、Spring Cloud）+ 配套组件：

  • 注册中心（Nacos/ZooKeeper）：服务注册与发现，替代硬编码服务地址；

  • 配置中心（Nacos/Apollo）：集中化配置管理，避免服务重启更新配置；

  • 熔断降级工具（Sentinel）：防止服务雪崩，保障部分故障不扩散；

  • 分布式事务框架（Seata）：解决跨服务数据一致性问题；

  1. 通信方式：保留 RPC 同步调用 + 消息队列异步通信，调用链路可监控、可追踪。

核心差异（与第 8 版对比）：

对比维度 第 8 版 垂直应用拆分（服务化雏形） 第 9 版 服务化拆分（标准化治理）
拆分粒度 粗粒度（业务线级，如商品应用、订单应用） 细粒度（功能级，如商品查询、库存扣减服务）
服务治理 无标准化组件，依赖硬编码、人工运维（如服务地址变更需修改配置） 全链路治理（注册发现、熔断降级、配置中心、事务一致性）
独立能力 应用级独立（部署、数据库），通用功能可能重复开发 服务级独立（专属开发 / 部署 / 运维），通用服务（如权限）可复用
故障影响范围 应用级故障（如商品应用故障，所有商品相关功能不可用） 服务级故障（如库存服务故障，仅影响库存操作，商品查询仍可用）
扩展性 业务线级扩容（如给订单应用新增 10 台服务器） 功能级精准扩容（如商品查询服务访问量激增，仅扩容该服务）

解决痛点：

  1. 垂直应用粒度粗，故障影响面广、扩容不精准；

  2. 跨应用调用无标准化框架，硬编码配置易出错、维护成本高；

  3. 通用功能重复开发（如每个应用都需实现权限校验），资源浪费；

  4. 跨应用事务难以保障，数据一致性风险高；

  5. 服务雪崩风险（一个应用故障可能连锁影响其他应用）。

第 10 版：数据库水平与垂直拆分

架构组成：：基于第 9 版 “细粒度服务拆分” 的结果，对数据层进行精细化优化（承接第 8 版的库级垂直拆分，聚焦未解决的细分问题）：

1、垂直拆分（含 “库级 + 表级” 两层）：

第 8 版已实现 “应用 - 数据库” 的库级垂直拆分，本版针对单服务内的超大表补充表级垂直拆分：​

拆分逻辑：对单服务下 “字段冗余、访问频率差异大” 的表，按字段重要性 / 访问频率拆分（如用户服务的用户表拆为 user_core（ID、姓名、手机号等高频字段）和 user_ext（头像、地址等低频字段））；​

核心价值：减少单表字段数量，提升查询效率（高频场景仅查核心表，避免冗余字段传输与存储开销）。

2、水平拆分（分表 + 分库）：

针对单服务下数据量超大的表（如订单服务的订单表、用户服务的行为日志表），解决 “单表数据量超限” 问题：​

分表规则：按时间范围（如 order_2024、order_2025）、用户 ID 哈希（如 user_1、user_2）、地域等维度拆分；​

分库扩展：若分表后子表数量过多（如 10 个年度子表总数据量仍超数据库承载上限），将子表分散部署到多台数据库服务器；

解决痛点：

  1. 单服务内超大表 “字段冗余、访问频率不均” 导致查询效率低（表级垂直拆分解决）；​

  2. 单表数据量过大（如千万 / 亿级），导致存储瓶颈、查询 / 写入延迟高（水平拆分解决）；​

  3. 服务化后单服务并发压力集中，数据层需适配 “细粒度服务” 的精准扩容需求（分库分表支持数据层与服务层同步扩容）。​

架构核心目标

  1. 高性能：通过多层优化（前端、应用、代码、存储）实现快速访问。

  2. 高可用：通过冗余备份、失效转移、熔断降级等策略，减少服务不可用时间。

  3. 可伸缩：通过增减硬件快速调整系统处理能力，适配访问量变化（支持业务线级 / 功能级精准扩容）。

  4. 可扩展：模块化、低耦合设计，支持快速新增 / 移除功能模块（服务化拆分后扩展更灵活）。

  5. 安全性：建立全链路安全机制（请求过滤、接口鉴权、数据加密），保障基础设施、应用与数据安全。

  6. 可观测性：分布式架构下，通过 Metrics（指标）、Logs（日志）、Traces（链路追踪）三大支柱，快速定位性能瓶颈和故障节点。

架构演进的 “业务 - 数据” 联动逻辑

阶段 业务层状态 数据层核心需求 数据层优化方案
第1-4版 单体应用/应用集群 缓解数据访问压力、避免单点故障 单机缓存→Redis集群、应用集群分流
第5版 单体应用（读写压力分化） 解决读写冲突、提升并发 读写分离（主从复制）
第8-9版 垂直应用→细粒度服务拆分 数据与业务边界对齐、独立扩容 库级垂直拆分（应用/服务-数据库一一对应）
第10版 服务化成熟（数据量激增） 解决单表存储/查询瓶颈 表级垂直拆分+水平分库分表