项目微服务架构图
谷粒商城微服务架构对应的技术栈如下：
一、网关层
- Web 网关：Spring Cloud Gateway ，用于实现认证授权、动态路由、令牌限流等功能
二、服务治理与配置
- 服务注册与发现：Nacos ，承担服务注册、服务发现职责
- 配置管理：Nacos ，支持动态配置、配置隔离、配置回滚
三、服务调用与容错
- 负载均衡：Ribbon
- 熔断降级：Sentinel
- 远程调用：Feign ，用于服务间调用
四、认证与安全
- 认证中心：OAuth2.0 、Spring Security ，保障系统认证授权安全
五、监控与链路追踪
- 服务追踪：Sleuth、Zipkin
- 指标监控：Metrics
- 监控告警与可视化：Prometheus、Grafana、Alertmanager ，实现监控数据采集、可视化及告警
六、日志管理
- 日志处理：ELK（Elasticsearch、Logstash、Kibana ），完成日志存储、文书检索
七、数据存储
- 缓存：Redis ，结合 Sentinel + Shard 实现分布式缓存
- 关系型数据库：MySQL ，采用 Master - Slave 主从架构
- 消息队列：RabbitMQ ，用于消息队列相关功能
- 全文检索：Elasticsearch ，支持全文检索场景
- 对象存储：OSS（对象存储服务 ）
八、持续集成与部署（CI/CD）
- 代码管理：GitHub
- 镜像构建与仓库：Docker 镜像仓库
- 容器编排：Kubernetes（K8s ），用于 UAT/PROD 环境管理
- 流水线：Jenkins Pipeline ，实现从开发到运维的 CI/CD 流程 ，涉及 Developer 开发、OP 运维环节
微服务划分图
这是一个电商系统的微服务架构图，用「分层设计 + 微服务拆分 + 云原生治理」思路，支撑多端（管理端、商家端、App、小程序 ）的电商业务，可拆解为 5 大核心层：
一、用户接入层（最左侧）
多端覆盖：
- admin-vue：运营 / 管理员的后台管理端（操作商品、订单、用户等）
- shop-vue：商家端（管理店铺、商品上架、订单处理 ）
- app：手机应用端（消费者购物）
- 小程序：微信 / 其他小程序端（轻量化购物入口）* 作用：所有用户 / 运营 / 商家的操作，都从这里进入系统，统一走 API 网关转发
二、API 网关层（蓝色竖条）
核心功能：限流、鉴权、熔断降级、过滤、路由、负载均衡
🔹 限流：防止突发大流量把系统打垮（比如秒杀时，限制每秒请求数）
🔹 鉴权：校验用户 / 商家身份（比如登录态、权限判断，确保 “运营才能改商品价格” ）
🔹 熔断降级：某个服务故障时，直接返回兜底内容（比如商品服务挂了，订单页暂时不显示商品详情，避免整个系统雪崩 ）
🔹 路由 & 负载均衡：把请求转发到对应的业务服务，还能 “均匀分配流量”（比如 100 个下单请求，分给 5 个订单服务实例 ）
三、业务层（中间两大块）
1. 业务微服务群（灰色区域）
服务拆分：把电商核心流程拆成独立小服务，每个服务专注做一件事：
🔹 商品服务：管商品增删改查、上下架
🔹 支付服务：对接支付渠道（微信 / 支付宝）、处理支付回调
🔹 优惠服务：算优惠券、满减、折扣
🔹 用户服务：管用户信息、地址、积分
🔹 仓储服务：库存管理、发货、物流追踪
🔹 秒杀服务：高并发秒杀逻辑（难点：防超卖、流量削峰 ）
🔹 订单服务：下单、拆单、订单状态流转
🔹 检索服务：商品搜索（像淘宝搜索框，快速找到商品 ）
🔹 中央认证服务：统一登录、授权（多端登录态打通 ）
🔹 购物车服务：用户购物车增删商品、算总价
🔹 后台管理：给运营 / 管理员用的功能（比如配置活动、看报表 ）
设计思路：高内聚、低耦合，比如改 “秒杀规则” 只动秒杀服务，不影响支付服务；某个服务出问题，其他服务还能跑
2. 第三方服务（橙色区域）
依赖能力：对接外部系统，让电商功能更完整：
🔹 物流：对接快递公司 API（查物流轨迹、触发发货 ）
🔹 短信：发验证码、订单通知（注册 / 下单后给用户发短信 ）
🔹 金融：可能对接征信、分期还款等
🔹 身份认证：实名验证（比如买理财类商品时，校验用户身份 ）
作用：通过 “服务化” 封装第三方接口，让内部业务调用更简单（比如下单后，订单服务发个消息给短信服务，由它调用短信 API 给用户发短信 ）
四、服务治理 + 应用监控（右侧两列）
1. 服务治理（橙色 / 绿色模块）
核心组件：
🔹 Nacos 注册中心：服务 “通讯录”，告诉系统 “商品服务在哪台机器、哪个端口”
🔹 Nacos 配置中心：统一管理配置（比如秒杀时间、优惠力度，改配置不用重启服务 ）
🔹 Seata 分布式事务：跨服务操作数据时，保证一致性（比如下单要减库存、扣积分、生成订单，这 3 个操作要么全成功，要么全回滚 ）
🔹 Sentinel 服务容错：熔断、降级、限流（和 API 网关的能力联动，保护整个服务体系 ）
🔹 Feign 远程调用：服务间互相调用的工具（比如订单服务调用商品服务查商品详情 ）
🔹 Gateway 网关：就是前面的 API 网关层（这里强调它是服务治理的一部分 ）
🔹 Sleuth 服务追踪 + Zipkin 可视化追踪：排查问题用！比如用户下单失败，能顺着 “调用链路” 找到是订单服务还是支付服务出问题
底座：基于 SpringCloud Alibaba + SpringCloud 构建，整合阿里生态和 Spring 体系的组件
2. 应用监控（黑色 / 橙色模块）
工具链：Prometheus（采集监控数据） + Grafana（可视化看板）
作用：实时看系统状态，比如：
🔹 QPS（每秒请求数）：判断流量高峰
🔹 响应时间：哪个服务变慢了
🔹 错误率：某个服务是不是频繁报错
发现异常就告警，运营 / 开发能及时介入
五、数据支撑层 + 数据层（最底部）
1. 数据支撑层
作用：把业务层的 “数据操作”，通过技术组件落地，解决数据存储、异步通信、分库分表等问题
2. 数据层（具体存储）
缓存：Redis 集群（存高频数据，比如用户购物车、热门商品，减轻数据库压力，让查询更快 ）
数据库：MySQL 集群 + ShardingSphere（分库分表）→ 应对海量数据（比如百万级订单，拆成多个库 / 表，查询不卡 ）
消息队列：RabbitMQ 集群（异步解耦，比如下单后，订单服务发个消息，仓储服务和积分服务各自去消费，不用同步等待，提升系统吞吐量 ）
搜索：Elasticsearch 集群（实现 “像百度一样的搜索”，比如按关键词、分类搜商品，比数据库模糊查询快 N 倍 ）
文件存储：OSS（存商品图片、用户头像等大文件，不占用数据库空间，访问也更快 ）
