大型电商网站商品详情页系统的架构设计

发表于 阅读次数： 评论数： 本文字数： 3.7k 阅读时长 ≈ 3 分钟

页面静态化方案

电商网站通常拥有上千万级商品，每个商品都有独立的详情页。为了提升页面响应速度，常采用页面静态化（生成静态 HTML 文件）技术。

小型电商网站的页面静态化

页面静态化处理

  • 核心思路：

    • 开发一个页面静态化系统，将网站所有页面（如首页、商品详情页等）预先生成为静态 HTML 文件。
    • 用户访问时，直接由 Nginx 返回对应的静态 HTML 文件的内容，无需查询数据库或执行后端代码。

  • 优点：

    • 高性能：无需每次请求都进行数据库交互或逻辑处理，响应速度快。
    • 简单高效：适合页面数量有限的场景（几十到几万个页面）。

  • 缺点：

    • 不适合大规模网站，若页面数量达到亿级别，任何模板改动（如样式、文字等）都需要重新全量生成所有页面，耗时耗资源，不可行。

静态 HTML 文件更新

思考

页面静态化系统预先生成所有静态 HTML 文件后，如果有多个 Nginx 对外提供服务，那如何动态更新多个 Nginx 服务器上的静态 HTML 文件呢？

结合版本控制与配置管理工具实现静态 HTML 文件的更新，这是最常用、最规范的方法，利用自动化工具完成分发和生效。

  • 流程：
    • 生成：页面静态化系统将网站所有页面预先生成为静态 HTML 文件。
    • 存储：将新的静态 HTML 文件存放在一个版本控制系统（如 Git）中，这便于管理版本、回顾历史、协同工作。
    • 触发：开发人员将修改后的静态 HTML 文件推送（git push）到 Git 仓库（如 GitLab/GitHub）。
    • 自动分发：通过 CI/CD 工具（如 Jenkins， GitLab CI）监听 Git 仓库的变更。一旦有新的推送，CI/CD 工具自动触发部署脚本。
    • 执行部署脚本：脚本通过配置管理工具（如 Ansible、SaltStack、Puppet）或简单的 rsync 命令，将新的静态 HTML 文件同步到所有 Nginx 服务器的指定目录下。
  • 优点：
    • 自动化、可追溯、规范性强，非常适合大规模集群。
  • 缺点：
    • 需要同时维护和理解一整套工具链（GitLab/GitHub、CI/CD、Ansible/SaltStack 等），对运维和开发团队的技术能力要求较高。
  • 适用场景：
    • 几十台到上万台服务器规模的管理，自动化优势能得到极大体现。

大型电商网站的页面静态化

页面静态化处理

通过 “本地模板 + 多级缓存（本地缓存 + Redis 缓存） + 消息队列” 的方式，在不牺牲太多性能的前提下，完美解决了大型电商网站海量商品详情页数据动态更新和模板全局更新的难题，是一种兼具高性能、高时效性和高可扩展性的优秀方案。

  • 核心思路

    • 不再预生成所有静态 HTML 页面，而是采用 “本地模板 + 动态数据” 的方式，在收到请求时实时渲染页面。

  • 架构组成

    • (1) 本地模板与缓存：

      • Nginx 服务器本地存有 HTML 模板文件。
      • 渲染所需的数据也在 Nginx 本地有一份缓存（如存储在内存中），有效期较短（例如 10 分钟）。

    • (2) 请求处理流程：

      • 用户请求到达 Nginx。
      • Nginx 首先使用本地的 HTML 模板文件和本地的缓存数据快速渲染出一个页面返回。
      • 因为所有操作都在本地完成，所以速度非常快，性能损耗仅在于渲染 HTML 本身。

    • (3) 数据更新与同步机制（关键）：

      • 触发更新：当商品信息、店铺信息、广告信息等发生变更时，相关服务会向消息队列（如 RabbitMQ） 发送一个消息。
      • 数据处理：有一个缓存构建服务会消费这个消息，调用各个服务接口（比如商品信息接口等）获取最新的数据，并整合成前端页面渲染所需的数据格式。
      • 更新缓存：将整合好的最新数据更新到 Redis 分布式缓存中。
      • 过期与拉取：Nginx 渲染页面时，若本地的缓存数据过期了，会主动去 Redis 分布式缓存中获取最新的数据来更新本地缓存。

  • 架构优点

    • 解决了全量静态化的弊端：HTML 模板文件变更时，无需重新生成亿级页面，只需更新模板文件，下次请求所有用户都会自动使用新模板渲染。
    • 保证了高性能：大部分请求直接使用本地缓存的数据和模板进行渲染，速度极快。
    • 保证了数据时效性：通过 “消息队列 + Redis” 的机制，能在秒级或分钟级内将变更的数据同步到整个服务器集群，实现了数据更新与页面渲染的解耦。
    • 具备高可扩展性：适合海量页面（如亿级）的场景。

模板文件动态更新

思考

如果有多个 Nginx 对外提供服务，那如何动态更新多个 Nginx 服务器上的 HTML 模版文件呢？

方案一：结合版本控制与配置管理工具（推荐）

这是最常用、最规范的方法，利用自动化工具完成分发和生效。

  • 流程：
    • 存储：将 HTML 模板文件存放在一个版本控制系统（如 Git）中，这便于管理版本、回顾历史、协同工作。
    • 触发：开发人员将修改后的模板推送（git push）到 Git 仓库（如 GitLab/GitHub）。
    • 自动分发：通过 CI/CD 工具（如 Jenkins， GitLab CI）监听 Git 仓库的变更。一旦有新的推送，CI/CD 工具自动触发部署脚本。
    • 执行部署脚本：脚本通过配置管理工具（如 Ansible、SaltStack、Puppet）或简单的 rsync 命令，将新的模板文件同步到所有 Nginx 服务器的指定目录下。
  • 优点：
    • 自动化、可追溯、规范性强，非常适合大规模集群。
  • 缺点：
    • 需要同时维护和理解一整套工具链（GitLab/GitHub、CI/CD、Ansible/SaltStack 等），对运维和开发团队的技术能力要求较高。
  • 适用场景：
    • 几十台到上万台服务器规模的管理，自动化优势能得到极大体现。

方案二：利用分布式文件系统

让所有 Nginx 服务器不从本地磁盘，而是从同一个网络位置读取模板文件。

  • 流程：
    • 搭建一个分布式文件系统（如 NFS、GlusterFS）或使用对象存储（如 AWS S3， 阿里云 OSS，但通常需要配合缓存使用）。
    • 将所有 Nginx 服务器的模板目录挂载到这个共享的网络存储上。
    • 需要更新模板时，只需更新共享存储上的一份文件即可，所有 Nginx 服务器立即就能看到最新的文件。
  • 优点：
    • 管理简单，只需修改一个点。
  • 缺点：
    • 单点故障和性能瓶颈：如果网络存储出现故障或网络延迟高，所有网站都会受影响。
    • 性能：每次请求都可能产生网络 I/O，延迟比本地读取高。
    • 通常需要配合本地缓存使用，这又引入了缓存一致性问题。
  • 适用场景：
    • 中小规模集群或对实时性要求不极端的场景。

方案三：使用反向代理层切换

在更复杂的架构中，Nginx 本身可能也分为多级。可以在最前层的反向代理（或负载均衡器）上做文章。

  • 流程：
    • 假设有两组后端 Nginx 服务器：Group A（当前在线）和 Group B（待更新）。
    • 先更新 Group B 的模板文件，并重启其服务。
    • 通过前层的负载均衡器（如 LVS、F5，或另一个 Nginx）将流量从 Group A 平滑切换到 Group B。
    • 确认 Group B 工作正常后，再更新 Group A 的模板，并将其作为新的备用组。
  • 优点：
    • 完全无缝更新，对用户无感知，是最高级的更新方式。
  • 缺点：
    • 架构复杂，需要额外的机器资源（至少多一整套备用服务器）。
  • 适用场景：
    • 超大规模、对可用性要求极高的网站（如淘宝、京东级别）。

方案四：容器化部署（云原生方案）

这是现代应用部署的趋势，与方案一紧密结合。

  • 流程：
    • 将 HTML 模板文件存放在一个版本控制系统（如 Git）中，这便于管理版本、回顾历史、协同工作。
    • 通过 CI/CD 工具（如 Jenkins）监听 Git 仓库的变更。一旦模板文件更新，自动拉取代码，将 Nginx 和最新的模板文件一起构建成一个 Docker 镜像，并推送至镜像仓库。
    • CI/CD 工具（如 Jenkins）调用 Kubernetes API，触发 Deployment 的滚动更新（Rolling Update），使用新镜像逐步替换旧 Pod（容器）。
    • Kubernetes 的滚动更新（Rolling Update）策略会自动完成流量切换与新老实例更替，实现无缝、零宕机的全集群模板更新。
  • 优点：
    • 环境一致，部署流程标准化，是云原生时代的最佳实践。
  • 缺点：
    • 技术栈复杂，需要引入容器和编排平台。
  • 技术栈：
    • 版本控制系统（VCS）：如 Git，用于存储和管理模板文件、Dockerfile、部署脚本等。
    • CI/CD 工具：如 Jenkins、GitLab CI、GitHub Actions，用于自动化构建和部署流程。
    • 容器镜像仓库：如 Docker Hub、Harbor、AWS ECR，用于存储构建好的 Docker 镜像。
    • 容器编排平台：如 Kubernetes（K8s），用于最终的应用部署和滚动更新。
    • 配置管理（融入了镜像）：Dockerfile 和 K8s 的 YAML 文件会替代 Ansible 等工具的角色（功能）。
方案优点缺点适用场景
CI/CD + 配置管理自动化、规范、可靠、无单点瓶颈需要搭建和维护一套工具链绝大多数场景，最通用推荐
分布式文件系统管理简单，更新即时存在单点故障和性能风险中小集群，开发测试环境
反向代理切换无缝更新，用户体验最佳架构复杂，资源成本高超大型网站，金融级应用
容器化部署环境一致，现代化，易于扩展技术复杂度最高云原生技术栈团队

总结

方案一（CI/CD + Ansible 等工具）是最平衡、最常用的选择。它既能快速响应模板变更，又能可靠地管理成百上千台服务器，完美契合了 "模板变更了，不需要将所有页面全部重新静态化" 的设计初衷。