01-谷粒商城介绍
本文根据课程 PDF 的「一、项目简介」和「二、分布式基础概念」整理，对应 PDF 第 2～8 页。概念说明补充了商城示例；课程原图与本项目当前约定分别标注。
本项目已有云服务器。本文不包含虚拟机安装、服务器环境配置和中间件部署步骤。
目录
分布式与微服务
从单体到微服务
单体应用将商品、会员、订单、库存等业务放在同一个应用中，通常作为一个整体部署。它结构直观，开发和调试相对简单，适合业务规模较小的阶段。
随着业务增长，某个模块的修改可能需要重新发布整个应用，不同模块也难以分别扩容。例如，商品浏览量很大，但后台管理访问量很小，整体扩容会同时增加所有模块的资源。
微服务架构按照业务能力拆分应用。每个服务运行在独立进程中，通过网络通信，并能够独立部署。
flowchart LR
subgraph 单体应用
A[商品模块]
B[订单模块]
C[库存模块]
end
subgraph 微服务应用
D[商品服务]
E[订单服务]
F[库存服务]
E -->|网络调用| D
E -->|网络调用| F
end
微服务的关键是业务边界和独立运行能力。拆成多个 Maven 模块，并不自动形成微服务；不同服务也不要求必须使用不同语言或不同数据库产品。
拆分之后，系统需要处理网络超时、服务发现、跨服务数据一致性和故障传播等问题。微服务提高了独立部署和扩容的灵活性，也增加了开发、测试与运维成本。
分布式、集群与节点
分布式系统由多个通过网络通信的独立节点协作完成工作，对外提供一个整体的系统能力。商城中，商品服务提供商品信息，订单服务创建订单，库存服务管理库存，它们共同完成交易流程。
集群是一组共同提供服务的节点。课程通过“同一个业务部署多份”说明集群，例如启动 3 个商品服务实例，共同承接商品查询请求。集群也可以包含不同角色的节点，例如数据库的主节点和副本节点。
节点是系统中参与工作的一个成员。具体含义取决于上下文，可以指服务器、虚拟机或某个服务实例。
| 概念 | 关注点 | 商城示例 |
|---|---|---|
| 分布式 | 多个节点协作 | 订单调用库存服务 |
| 集群 | 一组节点共同提供能力 | 商品服务运行多个实例 |
| 节点 | 参与工作的成员 | 一个商品服务实例 |
分布式和集群可以同时存在：商城按业务拆分多个服务，每个服务又可以部署多个实例。
💡 多个服务可以先运行在同一台云服务器上，用于学习服务拆分与网络调用。但它们仍然共享这台服务器的故障风险，不具备多机容灾能力。
远程调用
在同一个 Java 应用中，订单模块可以直接调用库存模块的方法。拆成独立服务后，订单服务需要通过网络请求库存服务，这就是远程调用。
课程主要采用 HTTP + JSON 完成服务间通信，并在架构图中使用 Feign 描述声明式远程调用。
sequenceDiagram
participant O as 订单服务
participant W as 库存服务
O->>W: HTTP 请求：查询商品库存
W-->>O: JSON 响应：库存结果
远程调用可能发生超时、连接失败或响应丢失。超时并不代表对方一定没有执行成功，因此创建订单、扣减库存等写操作不能简单地无限重试，需要考虑幂等性。
微服务基础组件
负载均衡
当商品服务部署多个实例时，需要将请求分配给这些实例。负载均衡用于分摊访问压力，提高资源利用率和服务可用性。
课程介绍了以下常见策略，具体支持情况取决于所用组件：
| 策略 | 分配方式 | 特点 |
|---|---|---|
| 轮询 | 按顺序依次分配 | 实现直观 |
| 最小连接 | 优先选择连接较少的实例 | 适合连接持续时间较长的场景 |
| IP 散列 | 根据来源 IP 选择实例 | 可使同一来源倾向固定实例 |
连接数只能反映部分负载，不能完全代表 CPU、内存或业务处理压力。IP 散列也不能保证在实例变化时始终命中原实例。
负载均衡可以发生在流量入口，也可以发生在服务调用端。课程架构图分别展示了 Nginx 集群和服务调用侧的 Ribbon。
注册中心
服务实例的地址和数量可能变化。订单服务需要知道商品服务有哪些实例、哪些实例可以调用，注册中心用于提供这些信息。
基本过程如下：
- 商品服务启动后，向注册中心登记服务名和实例地址。
- 注册中心维护实例信息，并通过心跳或健康检查感知状态。
- 订单服务发现商品服务的可用实例。
- 调用端结合负载均衡策略选择一个实例，发起请求。
课程使用 Nacos 作为注册中心。注册中心负责提供实例信息，业务请求通常仍然由调用方直接发送给目标实例。
📌 故障检测和实例列表更新存在延迟。即使使用注册中心，调用端仍然需要设置超时并处理调用失败。
配置中心
多个服务、多个实例通常需要不同环境的配置，例如连接地址、业务开关和超时参数。配置中心用于集中管理这些配置。
课程使用 Nacos 作为配置中心。注册中心和配置中心是两种职责，即使使用同一个产品，也应分别理解。
- 注册中心回答“服务在哪里”。
- 配置中心回答“服务使用什么配置”。
配置更新是否可以动态生效，取决于配置项和应用接入方式。有些配置仍然需要重启应用。
熔断与降级
订单服务依赖库存服务。如果库存服务持续变慢，订单请求可能长时间等待并占用线程，进而影响更多功能。这种故障沿依赖链扩散的现象称为服务雪崩。
服务熔断是在失败率或慢调用等指标达到条件时，暂时停止访问异常依赖，快速返回失败或进入兜底流程。经过一定时间后，再尝试恢复调用。
服务降级是在故障或资源紧张时，简化或关闭部分功能，优先保障核心流程。例如，暂时关闭商品推荐，保留商品浏览和下单能力。
熔断可以触发降级，但降级也可以主动执行，两者不必同时发生。课程架构图使用 Sentinel 表示熔断、降级等服务保护能力。
📌 兜底结果必须符合业务语义。库存服务异常时，应提示暂时无法确认库存，不能编造“库存充足”的结果。
API 网关与限流
微服务数量增加后，前端逐个维护服务地址会比较繁琐。API 网关可以作为统一入口，根据请求路径将请求转发给目标服务。
flowchart LR
A[管理后台或商城前端] --> G[API 网关]
G --> P[商品服务]
G --> O[订单服务]
G --> M[会员服务]
课程采用 Spring Cloud Gateway。网关还可以结合配置和其他组件实现身份校验、限流、日志记录等公共能力，具体功能需要主动接入。
限流是限制一定范围内允许处理的请求数量或速率，防止突发流量耗尽系统资源。例如，限制秒杀入口的请求速率。
网关负责请求入口和路由，注册中心提供服务实例信息，负载均衡负责选择实例，它们共同完成一次请求的转发。
课程组件名称说明
课程原图包含不同年代的组件名称。本文保留原图用于理解架构，不将图中的所有技术都视为本项目已经确定的依赖。
| 原图组件 | 主要职责 | 阅读说明 |
|---|---|---|
| Nacos | 注册与配置管理 | 同一产品承担两类职责 |
| Feign | 声明式远程调用 | 新项目常见 Spring Cloud OpenFeign |
| Ribbon | 客户端负载均衡 | 新版 Spring Cloud 常用 LoadBalancer |
| Sentinel | 限流、熔断与降级 | 需要定义保护规则 |
| Gateway | 网关路由 | 公共能力需要配置接入 |
| Sleuth、Zipkin | 链路追踪 | 新版应用需另选兼容的追踪方案 |
| Seata | 分布式事务协调 | 根据业务一致性方案选用 |
Spring Cloud 提供微服务基础设施相关项目，Spring Cloud Alibaba 提供 Nacos、Sentinel 等组件的集成。它们的版本需要与 Spring Boot 配套选择，不能直接照搬旧课程的版本号。
谷粒商城介绍
电商模式
课程介绍了以下常见电商模式，用于理解谷粒商城的业务定位：
| 模式 | 交易关系 | 典型场景 |
|---|---|---|
| B2B | 企业对企业 | 企业采购、批发 |
| B2C | 企业对消费者 | 商城向个人销售商品 |
| C2B | 消费者对企业 | 消费需求驱动定制生产 |
| C2C | 消费者对消费者 | 个人之间交易二手商品 |
| O2O | 线上与线下结合 | 线上下单、线下履约 |
同一个商业平台可能包含多种业务模式。这里按交易关系理解概念，不将整个企业固定归入某一种模式。
项目定位
谷粒商城是一个销售自营商品的 B2C 电商教学项目。 用户在商城浏览和购买商品，运营人员通过管理后台维护商品及相关业务数据。
可以从两个使用入口理解项目：
- 商城用户端：面向消费者，承载浏览、搜索、购物车、下单和支付等流程。
- 管理后台：面向运营人员，承载商品、分类、品牌、库存等管理功能。
管理后台是整个商城的一个入口，其前端模板和基础后端框架可以替换，商城业务仍需要根据业务规则和接口文档实现。
学习内容
课程以电商业务为载体，覆盖以下技术方向：
- 前后端分离，以及基于 Vue 的管理后台开发。
- 服务注册、配置管理、远程调用、网关和服务保护。
- 分布式事务、分布式锁及跨服务数据一致性。
- 线程池、异步编排、高并发处理和性能优化。
- 集群、应用监控、日志、链路追踪与持续交付。
这些能力在完整课程中逐步引入。本阶段先理解整体架构和服务职责，不要求一次性部署所有组件。
谷粒商城架构
课程原始架构图
下图提取自 PDF 第 3 页，保留课程中的技术名称和部署设想。
原图可以按照“流量入口 → 业务服务 → 数据与中间件 → 治理与交付”阅读。以下是用于理解的简化示意，不表示所有请求都必须经过同一条链路。
flowchart TB
U[浏览器、App、小程序] --> E[流量接入：Nginx 等]
E --> G[API 网关]
G --> S[商品、订单、会员、库存等业务服务]
S --> DB[(MySQL：业务数据)]
S --> R[(Redis：缓存等)]
S --> MQ[RabbitMQ：消息通信]
S --> ES[Elasticsearch：商品检索]
S --> OSS[对象存储：图片等文件]
S -.注册、发现与配置.-> N[Nacos]
S -.运行数据.-> M[日志、监控与链路追踪]
流量入口
原图在外部访问区域展示了防火墙、WAF、CDN 和 Nginx 集群，用于表达安全防护、静态资源分发和流量转发等能力。
进入内部服务区域后，请求由 Gateway 路由到业务服务。服务之间也会直接远程调用，例如订单服务调用库存服务，不要求每一次内部调用都重新经过外部入口。
数据与中间件
| 组件 | 主要用途 | 商城示例 |
|---|---|---|
| MySQL | 持久化业务数据 | 商品、订单、库存 |
| Redis | 缓存与共享状态等 | 热点商品缓存 |
| RabbitMQ | 异步消息通信 | 订单事件通知 |
| Elasticsearch | 全文检索与聚合 | 商品关键词搜索 |
| OSS | 对象存储 | 商品图片 |
| ShardingSphere | 数据库分片等能力 | 数据规模增长后的扩展 |
课程图中的 Redis、MySQL、RabbitMQ 和 Elasticsearch 使用了多实例部署示意。这些属于后续的集群与扩展方案，不代表基础学习阶段必须全部搭建。
缓存不能随意替代数据库；消息队列也不会自动保证跨服务业务一致性。这些组件需要与具体的数据更新和失败处理方案一起设计。
治理、监控与交付
原图还展示了几类支撑能力：
- 服务治理：Nacos、Sentinel、远程调用、认证等，支撑服务协作和故障处理。
- 日志检索：ELK，即 Elasticsearch、Logstash、Kibana，用于收集和检索日志。
- 监控告警：Prometheus、Grafana、Alertmanager，用于采集指标、展示图表和发送告警。
- 链路追踪：Sleuth、Zipkin 等课程组件，用于分析一次请求经过哪些服务。
- 持续交付：Git 仓库、Docker 镜像、Jenkins Pipeline、Kubernetes，表达从代码到部署的自动化流程。
Docker 可以用于构建镜像和运行容器。Kubernetes（K8s）用于编排和管理容器，包括调度、副本维护和滚动更新。已有云服务器可以先承载学习环境，是否引入 Kubernetes 再按后续学习目标决定。
微服务划分
课程原始划分图
原图从客户端、业务微服务、第三方服务、服务治理和数据支撑几个方向展示系统组成。客户端包括后台前端、商城前端、App 和小程序，它们是可能的访问入口，不表示本阶段需要全部实现。
核心业务服务
下面按照原图列出服务职责。业务示例是为理解边界补充的说明，具体接口以后续设计为准。
| 服务 | 主要职责 | 业务示例 |
|---|---|---|
| 商品服务 | 维护商品资料 | 分类、品牌、属性、SPU、SKU |
| 优惠服务 | 管理营销优惠 | 优惠券、促销活动 |
| 仓储服务 | 管理仓库与库存 | 库存查询、锁定和扣减 |
| 订单服务 | 管理订单生命周期 | 创建、取消、关闭订单 |
| 中央认证服务 | 处理用户身份认证 | 登录与身份校验 |
| 支付服务 | 对接支付流程 | 支付请求与结果通知 |
| 用户服务 | 管理用户相关资料 | 会员信息、收货地址 |
| 秒杀服务 | 处理秒杀业务 | 活动资格与抢购请求 |
| 检索服务 | 提供商品搜索 | 关键词、筛选与排序 |
| 购物车服务 | 管理待购买商品 | 加购、改数量、勾选商品 |
| 后台管理 | 提供后台基础能力 | 管理账号、角色、菜单 |
划分图表达的是业务能力边界，不直接规定每一项都必须对应一个独立部署工程。例如，支付能力可以先作为订单服务中的模块，后续再根据课程安排或实际需要拆分。
后台页面可以调用独立的商品服务。商品资料应由商品服务负责，不能仅因为页面位于后台，就将所有商城业务都放入后台系统模块。
第三方服务
原图列出了物流、短信、金融和身份认证等外部能力。它们通常由外部平台提供，商城通过接口接入。
第三方业务接口与 OSS 这类基础存储服务职责不同。项目可以根据业务需要增加适配模块，封装调用、超时和错误处理，但不能把外部接口可用性视为始终有保证。
一次购买流程
以下流程用于说明服务如何协作，不是最终接口设计或事务方案：
- 用户浏览商品，商品服务提供商品资料。
- 用户搜索商品，检索服务提供搜索结果。
- 用户将商品加入购物车，由购物车服务保存选择。
- 用户提交订单，订单服务校验商品、优惠和库存等信息。
- 仓储服务按订单流程锁定库存，订单服务创建待支付订单。
- 用户完成支付，相关服务根据支付结果更新订单和库存状态。
- 订单取消或超时关闭时，按业务规则释放已锁定库存。
订单、支付、库存之间需要处理超时、重复通知和部分失败。后续学习分布式事务与消息队列时，应结合这些具体问题理解方案。
本项目当前约定
以下内容来自当前项目讨论，与课程原始方案分别记录。
| 项目 | 当前约定 |
|---|---|
| 开发方式 | 重新编写商城业务代码 |
| 管理前端技术栈 | Vue 3 + TypeScript + Element Plus |
| 后台框架推荐 | RuoYi-Vue-Plus + plus-ui，待落地 |
| 页面实现 | 根据接口文档手写业务页面 |
| 页面类型 | 表格、树形页面、多步骤表单等 |
| 权限功能 | 当前阶段暂不涉及 |
| 环境基础 | 已有云服务器 |
后台框架尚未重新搭建。即使后续采用 RuoYi-Vue-Plus，也只按当前需要引入基础能力，不因框架具备多租户、工作流等功能就将它们纳入商城需求。
本阶段先明确商品分类、品牌、属性等业务边界，再逐步实现页面和接口。中间件、监控、集群和自动化部署随课程进度引入。
参考资料
- 《分布式基础与项目环境搭建》PDF：第 2～4 页为「一、项目简介」，第 5～8 页为「二、分布式基础概念」。
- 两张课程原图均提取自上述 PDF 第 3 页，保留原始内容，便于与本文说明对照阅读。