01-电商项目整体架构详解-

图灵第一课

课程介绍

课程安排

项目架构

• 用户请求链路：客户 / 消费者 → 网站 / APP → SpringCloud Gateway 网关（鉴权 + 路由） → 业务中台（会员 / 商品 / 交易等） → 对应微服务（订单 / 支付 / 库存等） → 数据库 / 中间件。
• 服务治理链路：微服务启动 → 注册到 Nacos → 网关 / 其他服务从 Nacos 发现并调用 → Sentinel 限流保护 + Prometheus 采集监控数据 → Grafana 可视化展示，异常时触发报警。
• 部署运维链路：开发人员提交代码到 Git → Jenkins 打包构建 → Docker 容器化部署 → K8S 弹性伸缩，运维人员通过运维后台操作。
• 监控保障链路：认证中心统一鉴权，ELK 收集日志，Pinpoint 追踪调用链，覆盖从入口到底层的全链路监控。

架构图最核心的逻辑是 **“分层解耦”**，你这张图从下到上清晰分成了 6 层：

• 基础设施层（IaaS）：MySQL/Redis/ES/RocketMQ 等中间件集群，是系统的 “地基”，提供存储、消息、检索能力。
• 公共技术层：通用技术中台（消息总线、分布式事务 Seata 等），解决通用技术问题，避免重复造轮子。
• 平台服务层（PaaS）：微服务治理、监控体系（Sentinel/Prometheus/Grafana/ELK/Pinpoint），保障系统稳定运行。
• 业务层：业务中台（会员 / 商品 / 交易 / 营销 / 数据中台）+ 原子微服务，是系统的 “业务核心”。
• 网关层：SpringCloud Gateway 网关 + 认证授权中心，负责流量入口、鉴权、路由分发。
• 展示层（SaaS）：多端入口（网站 / APP / 运维 / 商家后台），是用户直接交互的界面。看分层的关键是：搞清楚每一层的职责是什么，层与层之间的依赖关系是怎样的（比如上层依赖下层提供能力，下层不直接调用上层）。

电商业务转变

常见术语

高并发的任务

代码

电商发展趋势

用户请求 → Apache（Web服务器） → MOD_PHP4（PHP运行时） → Pear_DB（数据库操作封装） → MySQL 4.0 主从集群

• 主从复制读写分离：1 个写主库，2 个读从库，通过 MySQL 主从复制同步数据，实现读写分离，缓解单库压力。
• 单体部署：所有业务逻辑（下单、登录、Session、HTTP 请求处理）都在同一台服务器上完成，没有服务拆分。

1.当用户量上来后，单 MySQL 库的读写性能、存储容量都会成为瓶颈

2.跨部门 / 业务拆分：解决单体耦合问题

业务扩张后，会员、商品、交易等不同业务耦合在同一个单体里，开发、测试、发布都会互相影响：

• 拆分方式：按业务垂直拆分（会员部门、商品部门、交易部门），独立开发、测试、预演、上线，互不影响。
• 核心痛点：拆分后变成了 N 个独立服务，服务之间的调用依赖变多了，带来了「服务通信」和「分布式事务」的新问题。

3. 分布式服务通信与一致性：解决服务拆分后的问题

服务拆分后，服务之间需要通信，同时跨服务 / 跨数据库的事务一致性也成了难题：

• RPC 调用选型：Dubbo、Feign、HTTP，解决服务之间的同步调用问题。
• 异步调用与分布式事务：
  • 用 RocketMQ + ShardingSphere 实现异步下单，核心作用是削峰、解耦，比如用户下单后，不用同步等待库存扣减、订单创建全流程完成，直接返回 “下单成功”，后续流程通过 MQ 异步处理。
  • 同时也引出了异步调用的经典问题：消息重复、消息丢失、消息积压、幂等性问题，需要额外的方案解决（比如消息幂等表、死信队列、重试机制）。

1.1 版本的核心目标就是解决数据库性能瓶颈，同时拆分核心业务，缓解单体压力。

• 从 1.0 的单台应用服务器，升级为双 Apache+PHP 节点集群。
• 新增独立的搜索引擎（Search）模块，专门处理商品搜索这类高频读请求。

4.0时代

1、用户模块 （网关、授权）
2、商品新增 (数据库设计)
3、商品访问（多级缓存)
4、购物车（ 在线购物车、离线购物车）
5、下单（秒杀、防刷、分布式事务、取消订单）
6、订单 （分库分表、异步）
7、营销系统（秒杀业务设计）