第33周JavaSpringCloud微服务 实现电商项目

Spring Cloud 电商实战课程笔记

课程安排

1. 电商项目重构 🌟🌟🌟

• 项目背景: Spring Cloud 电商实战周介绍
• 项目任务: 对 Spring Boot 电商项目进行重构
• 重构方法: 应用 Spring Cloud 进行改造及开发
• 学习要点: 服务拆分规则与分析
• 分析内容: 模块应如何合理组合与拆分
• 原项目基础: 已完成用户、商品、分类、购物车、订单等模块开发
• 重构说明: 非简单代码拷贝，需进行转换工作

2. 服务拆分规则

• 单体应用与微服务差异: 部分单体下的方法和规则在微服务中不适用
• 服务拆分必要性: 开发过程中需改造和升级，将在编码中讲解
• 拆分模块关注: 涉及拆分的一个模块

3. Common 模块

• Common 模块定义: 可复用的代码和工具类组成的模块
• Common 模块特点: 拆分出可复用的部分
• 其他模块举例: 用户模块、商品分类和商品模块
• Spring Cloud 电商实战应用: 使用 Eureka Server 作为注册中心

4. 服务调用 🌟

• 服务调用方式: 使用 Feign
• 服务调用问题: Session 处理方案
• Session 共享需求: 分布式系统中共享方法

5. 网关

• 网关引入: 在 Spring Cloud 电商中引入网关
• 网关作用: 聚合各个模块
• 项目效果: 形成强大的项目

6. 广告系统 🌟🌟

• 大作业布置: 开发广告系统
• 功能要求: 排序、过滤
• 提交与评估: 提交系统、批改评分、提升编码能力

模块拆分

1. 电商模块拆分

1.1 尤瑞卡 Server

• 模块拆分个性化: 模块拆分与业务强相关，无通用标准
• 尤瑞卡 Server 作用: 作为服务注册与发现的大脑，独立存在
• 尤瑞卡 Server 拆分: 不适合与业务模块放在一起

1.2 网关模块

• 网关模块重要性: 重要模块
• 网关模块功能: 汇聚流量、进行转发
• 网关模块压力: 相对较大
• 网关模块部署建议: 不与业务模块放在一起
• 网关模块操作: 扩容、缩容、独立升级
• 网关模块拆分: 独立拆分开是较好选择

1.3 公共模块 🌟🌟🌟

• 公共模块拆分的必要性: 密码 MD5 加密工具类
• 工具类不应放在业务模块中的原因: 会被多个模块共同用到、避免重复开发浪费
• 工具类放公共模块的好处: 有利于工具类的升级和迭代
• 其他应放公共模块的内容: 统一 API 返回、常量类、异常处理器、异常的枚举、二维码生成等

1.4 用户模块

• 用户模块独立性: 保持模块间独立且内部聚合
• 用户模块功能: 注册、登录、更新个性签名、登出、检查管理员权限等
• 用户模块特点: 用户动作相对独立，不涉及其他模块信息

1.5 商品分类和商品模块 🌟

• 商品分类与商品合作模块的原因: 关系紧密
• 展示商品列表的需求: 同时展示商品及对应目录信息
• 列出分类下所有商品的方法: 对商品分类进行递归，获取所有子目录商品

1.6 购物车与订单模块 🌟🌟

• 购物车与订单模块关系: 紧密相关
• 订单模块生成订单过程: 查找购物车中已勾选商品，并清空购物车
• 电商项目业务模块拆分: 用户模块、商品分类与商品模块、购物车与订单模块
• 业务模块拆分原则: 根据业务和功能增多可拆更细，但目前规模不需过度拆分

功能模块介绍

1. 前台

1.1 用户模块

• 用户模块功能介绍: 介绍各模块主要功能，开发围绕功能进行
• 前台用户模块功能: 注册、登录、更新签名、身份认证、登出
• 功能针对对象: 前台普通用户

1.2 商品分类与商品模块 🌟

• 商品分类: 多级目录的层级关系、涉及递归查询
• 商品分类优化: 被访问次数高、需加缓存
• 商品模块: 包含商品搜索、商品排序、商品列表、商品详情等功能
• 商品分类与商品模块关系: 相互配合

1.3 购物车和订单模块 🌟🌟🌟

• 购物车功能概述: 显示商品列表、更改数量、删除商品、勾选反选、全选功能
• 订单功能概述: 下单流程与注意点、订单详情接口、取消订单功能
• 订单支付与后续: 生成二维码扫码支付、个人订单列表、确认收货动作

2. 后台

2.1 用户模块

• 用户模块概述: 属于后台管理员登录的管理内容
• 用户模块功能: 对管理员进行身份认证
• 认证应用场景: 商品上下架、目录删除等操作
• 操作限制: 普通用户无法进行后台操作
• 用户模块能力: 支持登录登出

2.2 商品分类与商品模块 🌟🌟

• 商品分类功能: 分类列表、增加分类、修改分类、删除分类
• 前后台分类列表差异: 前台分类列表给用户看，后台分类列表展示分类名字、排序、父类关系
• 商品模块功能: 商品列表、新增商品、图片上传、商品更新、商品删除、商品上下架（单独与批量）

2.3 订单模块

• 后台订单模块概述: 后台无购物车管理
• 购物车功能体现: 主要体现在前台
• 订单模块后台功能: 包括订单列表、地址信息、发货订单完结

项目初始化 🌟

创建项目 🌟🌟

• 项目开发首个模块: Eureka Server
• Eureka Server 开发步骤: 引入依赖、调整配置文件、加上启动注解
• 项目初始化: 新建 Spring Cloud 电商项目的第一个模块，包含项目初始化和依赖配置
• 新建项目步骤: 打开 IDE，选择 Maven，选择 1.8 版本，选择地址和命名，点击 finish
• 项目设置: 点击 enable auto import、调整字体大小和颜色、删除 src 目录内容
• 创建子项目: 选中 cloud-more-practice，在 file 里选择 new 和 module

创建模块 🌟🌟🌟

• 新建模块步骤: 选择 Maven，命名模块，点击 finish
• 模块命名规则: 前缀为 cloud-more，后缀为具体名称，如 eureka-server
• pom 文件编写与调整: 引入依赖，包括 group ID、artifact ID、packing、modules 等
• 依赖引入说明: Spring Boot Starter Parent 为 parent，指定 JAVA 版本 1.8，引入 Spring Boot Starter、test、web 等依赖，Spring Cloud 版本依赖声明
• 插件引入: Spring Boot 与 Maven 结合必备插件，MyBatis Generator 所需插件

尤瑞卡 Server 开发

包名分析

• 开发模块: 尤瑞卡 Server
• 包新建位置: main 下 JAVA 文件夹
• 包名规则: 以域名逆序为基础，确保唯一性，如 com.imook.cloud.morepractice.eureka
• 包名设计考虑: 避免冲突，清理隐患
• 后续操作: 新建 Spring Boot 启动类

启动类新建

• 类名: EurekaServerApplication
• 功能描述: 服务注册与发现
• 编写启动类前步骤: 进行依赖和配置文件的编写
• 依赖特点: 比副项目少，功能专一

补充 POM 文件

• 依赖配置 🌟

  • pom 文件补充: 规定版本与打包方式
  • 版本: 1.0-snapshot
  • 打包方式: packaging，选择 jar 类型
  • 模块属性配置: 名称与描述
  • 名称: 与 artifact ID 保持一致
  • 描述: description，例如 “spring cloud eureka server”
  • 依赖配置: 添加主依赖与插件
  • 主依赖: group ID 为 org.springframework.cloud，artifact ID 为 spring-cloud-starter-netflix-eureka-server
  • 插件: 复制相同的插件配置至每个 Spring Boot 的 Maven 项目

• 配置文件编写

  • 配置内容 🌟🌟🌟
  • 配置文件命名与位置: 在 resources 下新建名为 application.properties 的文件
  • server 配置: 指定名字和端口号，名字与 Maven 名字独立
  • 同步节点信息配置: eureka.client.fetch-registry 设置为 FALSE，因为单节点无需同步
  • 服务注册配置: eureka.client.register-with-eureka 设置为 FALSE，因为 server 只提供服务注册与发现能力
  • server 地址配置: eureka.client.service-url 配置为 defaultZone，使用变量 ${eureka.instance.hostname} 和端口号变量
  • 端口号配置: 采用 ${} 形式作为变量处理，便于后续修改
  • 完成配置文件编写: 下一步进行启动类编写

完善启动类

• 注解分析

  • 项目基础: Spring Boot 项目
  • 注解一: SpringBootApplication
  • 注解二: EnableEurekaServer
  • 对外服务: 成为尤瑞卡 Server 对外提供服务
  • 编写技巧: 使用 ps vm 快速生成 main 函数
  • 启动类编写: SpringApplication.run，传入类与 args
  • 开发习惯: 每开发一段程序立刻检查，遵循最小变更原则

• 启动项目

  • 启动程序: 在浏览器中查看程序运行
  • 程序状态: 无人注册时显示 “no instances available”
  • 配置调整: 修改配置文件中的设置以影响程序实例状态

• 重新启动项目 🌟🌟

  • 项目重新启动步骤: 先停止再重启
  • 程序启动完毕检查: 在浏览器中刷新页面，确认尤瑞卡 Server 及其状态正确
  • 尤瑞卡 Server 配置: 根据实际需要调整，本项目设置为 FALSE
  • 下一小节内容预告: 编写第一个业务模块，即 user 模块

用户模块介绍和设计

用户模块知识点 🌟🌟🌟

• 用户模块功能概述: 包括登录、注册、重名校验、密码加密存储等功能
• 登录: 验证用户名和密码，将登录信息存到 session 中
• 注册: 进行密码加密（如 MD5），确保用户名唯一性，进行重名校验
• 密码加密存储: 使用哈希算法（如 MD5）加密存储，防止数据泄露
• 越权校验: 在编辑用户信息时进行身份校验，防止编辑其他用户信息

用户模块开发测试 🌟

• 用户模块开发流程
  • 表设计: 进行表设计
  • 开发阶段: 开发阶段
  • 测试阶段: 测试阶段

用户模块表设计 🌟🌟

• 用户模块表设计概览: 介绍用户模块表的重要字段及含义
• 主键自增 ID: 用户模块表的第一个字段
• 用户名与密码: 长度分别为 32，密码经过加密存储
• 个性签名: personalized signature 字段的含义
• 用户角色: row 字段，1 代表普通用户，2 代表管理员
• 创建与更新时间: create_time 和 update_time 字段的含义

用户模块初始化 🌟🌟

创建 user 模块

• 创建 user 模块: 停止当前模块，右键 new module，选择 Maven，命名为 cloud-more-user
• 新建包的规范: 在 r3c 的 main 里面的 JAVA 新建包，包名为 com.imook.cloud.more.practice.user，以体现微服务拆分原则
• 包名的重要性: 包名需带上模块前缀以区分不同模块下的相同包名，避免模块增多时造成混淆
• 模块开发顺序: 先开发 user 模块，后续会利用到工具类，根据模块拆分原则，也会新建 common 模块，两个模块一起开发

配置 user 模块的 pom 文件 🌟🌟🌟

• 配置 user 模块的 pom 文件: 介绍与来源

• pom 文件即依赖配置文件

• 参考 Spring Boot 内容或 Spring Cloud 源码

• 必备外部功能和数据库连接: 依赖项说明

  • MySQL Connector: 数据库连接
  • MyBatis: 数据库与 JAVA、XML 的连接桥梁
  • Netflix Eureka Client: 模块注册，作为 client 注册到尤瑞卡 Server
  • Common 依赖: 暂不加入，未来会引进，暂时不需要
  • Redis 相关依赖: session 存储，操作 Redis，spring-session-redis：用于 session 存储，实现不同模块间 session 共享
  • OpenFeign: 服务调用，在 Spring Cloud 课程项目中多次使用
  • Spring Boot 的 Maven 插件: 按照课程配置，无特殊之处，按照课程内容配置

• 依赖导入与问题处理: 操作指南

  • 右键选择 Maven，reimport 重新导入
  • 爆红处理: Reimport 或重启项目刷新依赖

编写 user 模块的主要代码

• 编写 user 模块主要代码前的准备: 在包下建立必备的包，如 controller
• 复制 user controller: 打开 Spring Boot 项目，复制 user controller 到新的包下
• 解决依赖问题: 分析需要哪些依赖才能利用 user controller，首先确认统一的响应对象 API RestResponse 是必不可少的

创建公共模块

• 创建新模块: 右键选择 new，module，选择 Maven
• 选择副项目: 在多个选项中选择 cloud-more-practice 副项目
• 命名模块: 将新模块命名为 cloud-more-common，用于存放公共包
• 完成创建: 选择 finish 完成模块创建
• 模块内容规划: 提出模块内容规划的疑问，为后续讲解做铺垫

公共模块内容

• 常量

  • 公共模块定义: 是多模块项目中必不可少的内容
  • 公共模块包含内容: 常量、异常、工具类
  • 常量包含内容举例: IMOOK_MORE_USER、哈希颜值、文件路径、枚举（商品上下架、是否在购物车、订单状态）

• 异常 🌟

  • 异常概述: 存在异常包 exception
  • Global Exception Handler: 统一处理异常、打印错误日志、返回系统错误
  • 异常类型: 包含 DefaultException 和 ImookMoreException 等、返回对应的错误码
  • MethodArgumentNotValidException: 不符合参数要求时触发
  • ImookMoreException: RuntimeException 的异常继承、含错误码和错误信息
  • ImcomoExceptionEnum: 定义各种类型异常、使前端清晰识别错误
  • 异常处理: 灵活统一处理异常
  • 异常在 PPT 中的位置: 公共模块的主要部分

• 工具类

  • 工具类介绍: 工具类位于 util 包下，包含 MD5Utils、OrderCodeFactory 和 QRCodeGenerator 三个类
  • MD5Utils 类用途: 用于注册和登录时的密码检查，将明文密码转化为加密密码
  • MD5Utils 加密过程: 传入 string value（原文密码）→ 通过 MessageDigest.getInstance 获取加密工具 → 对值进行加密（加 constant 的 salt 增加破解难度）→ 进行 Base64 编码获取加密内容

公共模块

公共模块的特点

• 公共模块已介绍部分: 常量异常和工具类
• 公共模块特点: 非 Spring Boot 项目
• 公共模块功能: 类的复用

公共模块的编写

• 创建包

  • 编写公共模块开始: 确定最急迫的类
  • 复制 API Response 类: 在 common 模块中新建对应的包
  • 新建包命名规则: com.imc.cloud.more.dpractice.common
  • 包下新建层级: common、exception 等不同内容
  • 粘贴 API RestResponse 类: 在 common 层级下

• ApiRestResponse 类 🌟🌟

  • ApiRestResponse 类作用: 在接口最终返回时构建对象
  • ApiRestResponse 类内容: 状态、提示、message、data
  • 状态作用: 表示状态码，约定一万为正常，一万以上有异常
  • message 作用: 提供错误信息，前端可提取并展示给用户
  • data 作用: 放置返回的各种信息，如商品详情或列表
  • 构造函数特点: 多样化，可传入不同参数数量
  • 两参构造函数意义: 不需要具体返回内容，只需错误码和信息
  • 无参构造函数行为: 调用两参构造函数，并传入默认的成功状态和 message
  • success 方法功能: 新建默认的成功返回
  • error 方法使用: 发生错误时使用，可手动传参或传入枚举

• ImoocMallExceptionEnum 类 🌟🌟🌟

  • ImoocMallExceptionEnum 类概述: 类中定义多个枚举，每个枚举有 code 和 message 属性
  • 类的复制与粘贴: 将 inner 复制到 exception 包下，只保留需要的枚举状态
  • 解决包路径问题: 修改路径或删除后自动寻找，或手动补全包路径，或直接删除错误行让 IDE 自动补全
  • 导入问题
    • import 不写时的处理: 在依赖中找类名
    • 类名唯一性: 不存在模糊，引用准确
    • 类在多个包下存在: 要求选择具体包
    • package 报错处理: 可自动修复
  • 自动修复包位置 🌟
    • 操作开始: 按 alt 加回车
    • 提示选择: 选择将类挪到规定包下
    • 操作结果: 类的 package 位置变更，不再报错
    • 后续任务: 完成 API response 后，继续迁移其他类
    • 迁移示例: 将 GlobalExceptionHandler 和 ImookMoreException 复制到 exception 下
    • 迁移后处理: 删除原位置类，使其重新查找
    • 错误处理: enum 中无对应枚举时，需编写新枚举
    • 枚举编写示例: 编写 request parameter 枚举，表示参数类型错误

• 请求参数错误

  • 新建枚举名称: request parameter
  • 枚举值设定: 10001
  • 枚举含义: 参数有误，请重试
  • 修改效果: Global handler 不再报红，类修改完毕

• ImoocMallException 类

  • ImoocMallException 类依赖内容: 少且直接可用
  • ImoocMallException 类转移工作: 已完成
  • 其他相关类: common 下的 constant 类

• 常量类

  • 常量类的复制: 将 constant 复制至 common
  • 异常相关类的处理: 删除错误行后系统自动定位正确位置
  • 枚举错误解决: 定义错误类型 “找不到枚举” 为 10002，解决类爆红问题
  • 包的创建: 新建包以包含 common exception 及其他必要内容
  • util 包的查看与新建: 确认 util 包内包含 MD5Utils，并新建该包

• MD5Utils 类

  • 操作 MD5 值: 复制与粘贴
  • 问题定位: 常量位置错误
  • 解决方案: 删除错误行
  • 结果确认: 常量发挥作用，完成类转移

完善异常

任务进度

• 已完成大部分工作
• 下一步任务: 建立异常
• 异常名称: name existed
• 异常添加位置: 指定位置
• 异常提示信息: 用户名不得重名或用户名已被注册
• 注册方法: 查看注册方法以确认异常处理

完善注册方法 🌟🌟

用户名重名校验

• 查询用户名是否存在
• 用户名存在处理: 抛出异常，不允许注册
• 用户名不存在处理: 新建 user 对象，设置用户名和密码
• 密码加密方式: 使用 MD5 工具进行加密
• 用户插入数据库: 使用 insert selective 方法
• 插入失败处理: 抛出 insert field 异常，异常码 10007，提示插入失败请重试

完善登录方法 🌟

登录验证核心

• 校验用户名和密码是否匹配
• 密码处理: 将用户传入的明文密码进行转换，与存储的 MD5 密码比对
• 验证过程: 使用 select login 方法，从 user 表中查找用户名和密码同时匹配的数据
• 登录结果: 找到匹配数据则登录成功，返回 user 对象；未找到则抛出 “用户名密码不匹配” 异常

完善更新个性签名方法

主题内容

• 完善更新个性签名方法
• 操作数据库方法: update by primary key selective
• 方法要求: 必须有主键
• 主键获取方式: 用户 login 时返回用户信息中获得
• 更新判断: 更新数量大于一提示更新错误

完善判断管理员角色方法

不接受用户直接传值

• 避免伪造
• 判断用户角色: 程序内部调用，从 session 获取 user
• 角色扩展性: 目前角色三保留，未来可扩展更多角色如区域管理员等
• 判断管理员方法: 返回表达式，echos 1 为普通用户，非 1（如 echos 2）为管理员
• 调整思路贯穿项目: 整个 Spring Cloud 项目采用相同调整思路
• 复习业务逻辑: 调整过程中复习每个方法的主要业务逻辑

完善用户控制器

爆红问题处理

• 爆红问题处理背景: 是编写的最后一个部分，存在爆红情况
• 初步处理方法: 删除并重新导入相关部分
• 爆红原因分析: get user 爆红是因为 user service 里没有该方法
• 问题解决方法: 删除 ctrl 对外暴露的不需要的接口
• 后续规划: 根据其他需求，可能会补充 get user 方法
• 当前行动: 为避免混淆，先删除不需要的内容

注册功能实现

• 注册功能实现位置: ctrl 层
• ctrl 层作用: 校验用户名和密码
• 校验内容: 用户名和密码是否为空、密码长度
• 注册流程: 进行注册并返回成功

登录功能实现

• 登录接口主要逻辑: 判断用户名和密码是否为空
• 非空处理: 调用 login 获取 user 对象，进行信息过滤，不返回密码
• Session 处理: 通过 session.setAttribute 存储 user 对象，key 为 IMOOK_MORE_USER

更新个性签名 🌟🌟🌟

• 更新个性签名前提条件: 必须已经登录
• 判断登录状态方法: 从 session 中取出 current user，调用 login 接口
• 未登录处理方式: 提示用户登录，抛出 “请登录，未登录” 异常
• 已登录操作步骤: 新建 user 对象并设置 ID，设置个性签名字段，调用 update information 方法
• update information 底层实现: 使用 update by primary key selective 方法，根据主键更新字段，只更新传入的字段，其他字段保持不变
• 更新成功操作: 返回成功信息

登出功能实现

• 清除 session 方法: 使用 session 的 removeAttribute
• 清除结果: 再 get 时返回为空
• 清除 session 意义: 登录失效

管理员登录接口

• 管理员登录接口逻辑: 先判断用户名和密码是否符合规定
• 调用 check admin row 功能: 登录时获取 user 对象，判断是否为管理员
• 管理员验证结果处理: 是管理员则返回用户对象，不是管理员则拦截并提示 “need admin” 异常

用户控制器启动类

指定 MyBatis 扫描路径

• 创建启动类: 新建 Spring Boot 启动类 UserApplication
• 添加注解: 添加 SpringBootApplication 和 EnableEurekaClient 注解
• 指定 MyBatis 扫描路径: 设置 @MapperScan 等于 com.imook.cloud.more.practice.user.mapper

编写主函数

• 主函数编写位置: 在指定区域编写
• 主函数名称: SpringApplication.run
• 主函数内容: UserApplication.class, args
• 配置文件: 需补充配置文件

引入配置文件

• 引入配置文件: 开始操作
• 操作步骤: 选择 new file application.properties

配置 application.properties 🌟🌟

• 配置内容: 按需配置数据库连接、Eureka 客户端等信息

启动 Eureka Server 和 User 模块 🌟🌟

• 启动目标: Eureka Server 和 User 模块同时启动
• 启动顺序: 先启动 Eureka Server，再启动 User 模块
• 启动显示: 右下角提示多个 Spring Boot，选择第一个
• 调试便利性: 两个模块在左侧同时显示，方便调试
• Common 模块状态: 始终未被启动，且无 Spring Boot 启动类
• 模块职责差异: 不同模块职责不同，结构上有所区别

验证注册成功

• 端口启动情况: 八零八幺端口已启动
• 验证方法: 通过浏览器尤瑞卡 server 查看
• 验证结果: cloud-more-user 已启动，注册成功

测试用户模块

项目接口概览

• 接口状态检查: 使用 Postman 进行
• 接口来源: Spring Boot 单体项目
• 接口变化情况: 大部分未发生巨大变化

创建新集合

• 新建集合: cloud-more-practice
• 集合内容: Spring Cloud 相关

用户模块文件夹

• 新建文件夹: 用户模块
• 用户模块内容: 新建请求
• 请求对应: 部分请求

注册新用户测试

• 注册新用户步骤: 首先进行注册
• 端口号: 注册端口为八零八幺
• 用户名规则: 用户名不能重名，需确保唯一性
• 注册成功示例: 将 “陌陌五” 改为 “陌陌九” 后注册成功

登录功能测试

• 登录功能测试概述: 进行登录测试，端口需改为 8081
• 测试账户信息: 用户名为木木九，密码为 1 到 8
• 登录问题及原因: 登录失败，提示 cannot serialize，因为 user 类需实现 Serializable 接口
• 解决登录问题方法: 重启程序以应用 Serializable 接口的实现

更新个性签名 🌟🌟🌟

• 接口准备: 登出、管理员登录等五个接口
• 测试登录接口: 确认登录成功
• 更新个性签名: 登录后更新，端口需改成 8081，确认更新成功
• 测试管理员登录: 非管理员无法操作，需修改数据库身份为管理员
• 测试登出接口: 确认成功登出，登出后无法更新个性签名

商品分类与商品模块开发详细笔记

一、商品分类与商品模块初始化

1. 创建模块

• 操作: 右键新建 module，命名为 cloud-more-category-product
• 包名: com.imac.cloud.more.practice.category.product

2. 配置文件

• 复制文件: 从 user 模块复制 pom 和配置文件
• 修改端口: 从 8081 改为 8082
• 模块名: 从 cloud-more-user 改为 cloud-more-category-product

3. 创建必要的包结构

• controller: 复制 category-controller
• service: 复制 category-service 及其实现类
• model: 包括 do, po, ro, request, vo 等

4. 处理爆红问题

• 替换 user service 为 Feign client
• 删除不必要的代码: 如管理员校验相关代码

二、商品分类开发与测试

1. 后台添加目录

• 功能: 检查数据库中是否存在同名目录
• 逻辑:
  • 重名: 提示名字已存在，不允许添加
  • 无重名: 成功添加目录

2. 更新目录

• 逻辑:
  • 检查同名目录: 若 ID 不符则提示重名错误
  • 更新操作: 使用 update by primary key selective

3. 删除目录

• 参数: ID
• 操作:
  • 查找记录: 找不到提示删除失败
  • 删除操作: 使用 delete by primary key

4. 后台目录列表

• 功能: 分页查找
• 输入参数: 目录大小和页码
• 排序: 按 type 和 order number

5. 目录列表用户看

• 生成方式: 递归查找
• 思路: 查找所有 parent ID 为给定 ID 的目录
• 结果: 返回前台目录列表

6. 目录模块测试 🌟🌟

• 启动类: 添加 Spring Boot 启动类，命名为 CategoryProductApplication
• 注解配置:
  • @SpringBootApplication
  • @EnableRedisHttpSession
  • @EnableFeignClients
• 缓存处理: 确保商品目录和商品模块能获取 user 类
• 依赖处理: 在 pom 文件中添加 user 模块依赖

三、缓存配置 🌟

• 必要性: 配置 Redis 以实现 session 共享
• 过程:
  • 新建 config 包
  • 创建缓存配置类
  • 复制至 Spring Cloud 的 config 包
• 应用场景:
  • 用户共享 session
  • 商品目录缓存
  • 使用 @Cacheable 注解缓存目录列表
• 效果: 提升性能，尤其在大流量下效果明显

四、网关配置

• 模块名称: cloud-more-category-product
• 前缀: category-product

五、接口测试 🌟🌟🌟

• 启动相关模块:
  • 商品目录与商品模块
  • 尤瑞卡 server
  • 用户模块
  • 网关
• 测试内容:
  • 新增、更新、删除目录
  • 目录列表展示
• 测试流程:
  • 验证权限设置
  • 登录和登出操作

六、商品模块

1. 表设计

• 商品表结构字段:
  • 主键 ID
  • 商品名称
  • 图片（存储 URL）
  • 商品详情
  • 目录 ID
  • 价格
  • 库存（stock）
  • 是否上下架（status）
  • 创建时间
  • 更新时间
• 图片存储方式: 推荐存储 URL 地址，减轻数据库压力，提高加载速度

2. 接口设计 🌟

• 功能:
  • 新增、更新、删除商品
  • 上传图片
  • 批量上下架商品
• 上传图片: 微服务架构下位置变动
• 批量上下架: 处理前台和后台商品列表

3. 商品模块重点讲解 🌟🌟🌟

商品模块迁移和调整 🌟

• 迁移内容:
  • controller 层
  • service 层
  • model 相关类
• 调整:
  • 处理标红内容
  • 调整实现类和控制器

产品服务实现类

1. 增加商品 🌟🌟

   • 方法: 在 product-service-impl 中实现
   • 操作:
     • 新建 product 类
     • 使用 BeanUtils.copyProperties 复制字段
     • create time、update time、ID 等字段不传递
   • 验证:
     • 使用 productMapper.selectByName 检查重名
     • 抛出异常 CategoryNameAlreadyExistException

2. 更新商品

   • 方法: update by primary key selective
   • 逻辑:
     • 检查重名
     • 更新商品信息

3. 删除商品

   • 方法: delete by primary key
   • 验证: ID 是否存在

4. 批量更新 🌟

   • 参数: ID 数组和状态
   • SQL: 使用 ID in 策略

5. 管理员列表

   • 功能: 分页显示
   • 排序: 按更新时间倒序

6. 商品详情

   • 查询: 通过 ID
   • 复杂度: 商品模块中最复杂的方法

7. list 方法 🌟🌟🌟

   • 功能: 查询商品列表
   • 处理:
     • 关键字
     • 目录
     • 排序

七、启动服务 🌟

• 操作: 启动相关服务
• 验证: 检查服务状态

八、前台商品详情

• 问题: 添加前缀 category-product
• 验证: 返回商品信息

九、前台商品列表

• 操作: 添加前缀并发送请求
• 验证: 返回商品列表

十、新增商品

• 操作: 添加前缀，发送请求
• 验证: 检查数据库

十一、更新商品

• 操作: 修改库存数量
• 验证: 数据库刷新查看变化

十二、删除商品

• 操作: 发送删除请求
• 验证: 数据库确认删除

十三、批量上下架商品和上传图片

批量上下架商品

• 操作: 修改商品状态
• 验证: 数据库状态变化

上传图片接口

• 功能: 上传图片并返回地址
• 问题: 内网 IP 访问
• 解决:
  • 配置文件中设置 IP 和端口
  • 使用 @Value 注解引用配置文件中的值

十四、访问图片 🌟🌟

• 问题: 浏览器无法访问
• 解决:
  • 添加前缀
  • 配置网关过滤器

一、购物车与订单模块介绍

1. 购物车和订单模块的主要内容

1）购物车模块

• 表设计和接口设计

  • 表设计 ：购物车表设计包含主键 ID、商品 ID、用户 ID、数量、选中状态、创建及更新时间。其中，商品 ID 用于查询商品信息，用户 ID 确定商品归属，数量表示商品件数，选中状态决定商品是否加入订单，创建及更新时间记录商品加入购物车的时间信息。
  • 接口设计 ：共有六个重要接口。
    • 添加商品到购物车接口 ：参数为商品 ID、数量，不传用户 ID，通过 session 获取用户信息以防止攻击。
    • 更新购物车接口 ：参数与添加商品接口一致，修改商品数量后请求该接口。
    • 删除购物车接口 ：参数为商品 ID，后台直接获取用户 ID，无需传入。
    • 选择与不选择购物车接口 ：参数为商品 ID、选择状态（0 或 1），针对单个商品的选择操作。
    • 全选择和不选择购物车接口 ：参数为 selected（0 或 1），操作对象为购物车中所有商品。
    • 购物车列表接口 ：唯一的 GET 请求，不需要传参数，后台获取用户信息并查询购物车商品。

• 添加商品到购物车的业务流程

  • 添加商品到购物车的初步判断 ：判断商品是否在售及库存情况。若商品未上架或库存不足，则提示用户无法加入购物车；若满足条件，则新商品插入购物车或更新购物车中商品数量。

2. 远程调用

• 模块设计原则 ：避免模块间耦合，利用远程调用获取商品相关能力。
• 远程调用前准备 ：确认商品模块提供的接口，复制并分析 product map 的功能，主要功能是调用 select by primary key 方法获取商品详情。下一步行动是在商品模块中添加所需接口以支持远程调用。

3. 商品分类与商品模块

• 新增接口目的 ：获取商品详情。
• 接口 URL 与命名 ：URL 为内部专用，命名为 for e fine，方法名为 detail for frame。
• 内外部调用差异 ：外部调用有 API response 包装，包含商品信息、错误码、状态码及状态信息；内部调用无需包装，直接返回商品详情。
• 商品详情获取方式 ：通过 product service detail 方法，调用 product map 的 select by primary key 方法获取 product 实体类。
• 返回类型调整 ：原返回类型为 API response，需调整为 product 类型以匹配内部调用需求。
• 接口作用 ：专为服务与服务之间的内部调用编写的接口。

4. 购物车与订单模块

• 新建 fin 包与类 ：在购物车预订单模块中新建 fin 包，并在其中创建 product.fin client 类。
• 模块交互原则 ：模块间应通过 fin client 方式交互，避免直接引入对方 map，以减少耦合。
• 编写类内容 ：定义 detail 方法，返回值为 product，参数为 integer 类型的 ID，并添加 request param 注解。
• 引入依赖 ：因缺少相关依赖导致 product 无法识别，需引入 cloud more category product 依赖。
• 调整类为 interface ：product.fin client 应为 interface，不需具体实现，只定义参数和返回值。
• 指定请求地址 ：使用 get mapping 指定请求地址，注意为内部调用，不经过网关，地址应直接以 product 开头。
• 添加 fin client 注解 ：为接口添加 fin client 注解，并设置 value 为对应模块名，如 cloud-more-cat-grey-product。

5. 重新编写购物车与订单模块

• 替换 product mapper ：使用 fin client 替换原有的 product mapper。
• 重写方法 ：方法名变更为 detail for f，但目标作用一致。
• 异常处理 ：补充商品未上架和库存不足的异常。
• 错误枚举修正 ：添加商品未上架（10016）和商品库存不足（10017）的错误描述。

6. 获取当前用户

• 检查爆红状态 ：通过 cut controller 中的红色波浪线识别。
• 编译状态更新 ：card service 的波浪线状态会随编译检查更新。
• 获取用户信息方法 ：在接口请求时获取用户信息。单体应用中通过 user filter 保存和轻松拿取用户信息；模块分离后需通过用户模块对外暴露的接口获取用户信息。

7. 完善方法

• 获取当前登录用户 ：通过 session 获取，使用 session.getAttribute，参数为 constant 的 im more user，返回对象类型为 Object，需手动转换为 User 类型，命名为 currentUser，并返回。
• 购物车列表接口 ：目的为让其他模块访问，通过 get mapping 实现，地址为 get user，返回 JSON 格式，规定返回格式为 json，返回内容位于 response body，包裹在 API rest response 中。
• 内部调用优化 ：减少通信层包裹，提高效率。在 cut order 中新建 interface，命名为 user fan client，添加注解 fin clint。
• UserFeignClient 接口 ：value 值为 cloud-more-user，方法返回类型为 User，名称为 getUser，请求类型为 Get，地址为 /getUser，功能是获取当前登录的 user 对象，在 CartController 中使用。
• CartController 中使用 UserFeignClient ：引入 UserFeignClient，用其替换原来的 UserFilter，获取当前用户。
• 空判断与代码健壮性 ：获取对象时进行空判断，避免报错，可在过滤器中提前拦截空对象，保证代码在各种情况下正常运行。
• 替换 UserFilter 为 UserFeignClient ：在多个接口中替换 UserFilter，共替换六次，使左侧代码不再报错。

8. 购物车模块

• 购物车列表 ：获取用户 ID 并传给 list 方法，ID 传给 select list 方法，调整 XML 文件关联，替换 cart 和 mapper 的地址，校正 vo 位置，关联购物车和商品表，根据 product ID 和上架状态获取购物车列表，遍历 vo 列表，计算并设置 total price。
• 添加商品到购物车 ：需要传入 user ID、商品 ID、数量，校验商品是否存在、商品状态是否为上架、库存是否足够。购物车中不存在该商品记录则新增，存在则增加数量，返回更新后的购物车情况。
• 更新购物车 ：调用 cut service 的 update 方法，对当前商品进行校验，构造数量 ID、商品 ID、user ID 及选中状态，使用 update by primary key selective 方法更新，通过主键 ID 定位。
• 删除购物车 ：调用 cut service 的 delete 方法，按用户 ID 和商品 ID 查找购物车，找到则调用 delete by primary key 方法删除，记录为空则抛出异常，返回当前购物车的详情。
• 选择 / 不选择购物车的商品 ：针对单个购物车记录，记录为空则抛出异常，不为空则调用 selector not 方法修改状态，传入选中状态、user ID 和商品 ID 定位记录并修改选中字段。
• 全选择 / 全不选择购物车的商品 ：调用 selector not 方法，传入参数 now，传入 null 时不添加条件限制，逻辑部分复用选中 / 不选中单个商品的逻辑。
• 测试购物车模块 ：启动商品分类、商品尤瑞卡 server、用户模块、网关模块，在 postman 中新建 “购物车和订单” 文件夹，复制六个请求至该文件夹，配置新增模块，在网关中配置新增的 cut order 模块，设置模块名为 cloud more cut order，并定义前缀为 cut order，重启网关使配置生效。

二、订单模块的设计与开发

1. 表设计和接口设计

1）订单主表

• 表结构特点 ：比普通表字段更多，包含订单特有字段。主键 ID 保留自增 ID，但对外不暴露，新增 order_no 字段（VARCHAR 128），具有随机性生成规则，防止通过连续 ID 推测业务数据。关键字段包括 user_id、total_price、收货信息（receiver_name、receiver_mobile、receiver_address）、order_status（包含 0：用户已取消，10：未付款，20：已付款，30：已发货，40：交易完成这 5 种状态）、时间字段（delivery_time、pay_time、end_time）。

2）订单明细表

• 表关系 ：通过 order_no 字段与主表关联（一对多关系）。
• 设计特点 ：快照机制，记录下单时的商品信息（product_name、product_img、unit_price），不随商品信息变更而改变，与购物车区别在于购物车实时获取最新商品信息，订单则固定历史快照。核心字段有 product_id、quantity、total_price。

3）接口设计

• 核心接口 ：

  • 生成订单（POST） ：自动获取购物车已勾选商品，需传入收货人三要素：姓名、手机号、地址。
  • 支付相关 ：生成支付二维码（POST）、支付订单（POST）。
  • 状态变更 ：取消订单（POST）将状态从未付款（10）改为已取消（0）；订单发货（POST）商家专用，状态变更为已发货（30）；订单完结（POST）状态变更为交易完成（40）。
  • 查询接口 ：订单列表（GET）用户视角，仅返回当前用户订单；管理员订单列表（GET）返回所有用户订单；订单详情（GET）包含商品明细及快照信息。

• 注意事项 ：状态设计原则是数值递增对应业务推进流程（0→10→20→30→40）。发货时间空值表示未发货，支付方式默认为 1（在线支付），运费字段 postage 默认值为 0。

2. 知识小结

• 订单模块设计核心要素 ：表设计与接口设计是订单模块开发前的关键环节，需重点关注关联表结构（如主表 im_ook_more_order 与子表 im_ook_more_order_item）和状态机逻辑（订单状态从 0 到 40 的递进关系）。订单编号（order_number）与主键 ID 的区别在于订单编号需随机生成以避免泄露业务敏感数据，而 ID 仅用于内部关联。订单主表结构包含订单基础信息、状态字段、时间戳。状态字段的数值设计逻辑是数值递增对应业务流。订单子表结构记录订单中每种商品的快照信息，与主表通过 order_number 关联。快照机制的必要性在于商品信息变更不影响历史订单数据。接口设计逻辑共 9 个接口，核心包括生成订单、支付二维码生成、状态变更接口、分权查询接口。生成订单接口的隐式参数是自动从购物车获取商品列表，仅需传递收货人信息。安全与业务逻辑方面，订单编号随机化防止竞品推测业务数据，状态变更权限控制，时间戳字段的判空逻辑需结合状态字段综合校验。

3. 订单相关类的迁移和重构

1）修改订单服务

• 删除旧代码，使用 product fin clint 的 update stock 方法，传入 productid 和 stock。
• 解决 order 类未找到问题，手动指定 order 类。
• 替换数据库操作方法，使用 product fin clint 的 detail for fin 替换直接操作数据库的方法。
• 新增枚举和错误处理，添加订单不存在的错误枚举，判断订单是否属于当前用户。
• 列出和取消订单接口，利用 use rf in clint 获取当前用户，进行订单操作。
• 订单状态验证，在取消订单时验证订单状态，抛出异常 if 不符。
• 补充二维码依赖，在 common 包中引入二维码依赖，解决 writer exception 问题。
• 结束订单逻辑修改，管理员可结束任何订单，普通用户需校验订单归属。
• 调整完毕后，检查 order service 和 order admin controller 的编译情况。

2）修改订单控制器

• 调整 order controller，重新导入四行代码。
• 检查 map 错误，手动修改。
• 调整包的位置，修改 order item map 和 order item po 的包名位置，保留 order item。

3）修改订单项目其他的类

• 整体替换方式适用于快速调整。
• 特殊返回值处理需逐个调整。
• order mapper 调整思路与整体替换一致，替换操作步骤为复制、定位、替换、检查，处理标红问题，调整 map 位置，确认无特殊类型返回。

4. cutOrder 模块

1）controller

• 聚焦点确定为 cut order 模块，类引入与订单相关的类，首要关注 controller，order controller 分为用户用与管理员用两类，管理员用 controller 标识带有 admin 字样。操作步骤是复制两个类至 controller 并粘贴，初步操作后存在报错，需后续调整。

2）service

• 处理对象为 service，操作步骤是复制 order service 到 service 包，复制 order service 实现类到对应包，针对 order 展开左侧内容，需要很多实体类。

3）dao

• 获取 dao 的步骤是获取 order item map 和 order map，订单模块设计包含两张表，实体类涉及较多，操作方式为复制粘贴生成两个新类。

4）pojo

• 主题内容是 po 中订单相关类，操作是复制相关类并粘贴。

5）request

• 主题是 request 的复制与新建，操作步骤是复制原有 request，新建 request 包并粘贴，最终状态应有两个 request。

6）vo

• 复制 vo 相关的类并粘贴，u 中有订单相关类，包括订单号生成、二维码生成，考虑订单相关类的放置位置。

7）二维码工具类

• 类的位置考量是从作用出发，订单号生成类放在购物车订单模块，二维码工具类放在 common 模块以便复用，mapper 转移是复制 order 相关的 mapper 到 resources mapper 下。

8）ctrl 层

• orderService ：从 order admin controller 开始查看 ctrl 层，处理 order service 问题，删除两行代码以解决报错，order service 实现类代码繁琐复杂，需后续详细讲解。
• productMapper ：提出 product map 的问题，其与商品相关，解决方法是使用 product fin client，已利用 client 获取商品详情。
• userService ：user service 调用方式不可直接调用，使用 user 的 fin clint 调用 user 相关方法，利用 use rf inclined 的 get user 方法替换获取 user 的 ID 方法。
• 购物车为空异常 ：复制异常至枚举汇总类，定义新增 “购物车为空” 异常枚举，触发条件是购物车为空时无法生成订单，替换 product mapper 的 select by primary key 方法，使用 product fin client 中的 detail for fin 方法，识别缺失的 product mapper 使用 update by primary key selective 方法，需新增该方法以增强 product fin client 的库存更新能力，库存更新需求是下单成功需扣减库存，在 controller 中给予库存更新能力。
• 更新库存方法 ：新增接口目的实现更新库存功能，接口参数为商品 ID、更新后的库存，接口注解为 @PostMapping，地址是 /product/updateStock，参数来自 RequestParam。实现类方法为 public void updateStock(ProductID, Stock)，步骤是构建新的 Product 对象、设置 ID 定位商品、设置新的库存值、使用 updateByPrimaryKeySelective 方法更新。方法区别在于 updateByPrimaryKey 与 updateByPrimaryKeySelective，后者为部分更新，适用于本场景。完成更新后，在方法上加 @Override，提升至接口层，供 Controller 调用，在 Controller 中使用 ProductService 的 updateStock 方法，并传入 ProductID 和 Stock，FinClient 需有相应体现以完成整个功能的对接。产品 FeignClient 方法名称为 void update stock，方法参数为 request parent, integer product ID, integer stock，方法定义为接口方法，以分号结尾，路径注解为 @PostMapping(“product/updateStock”)。

5. 生成订单接口

1）订单业务逻辑概述

• 用户下单接口说明：入参包括收货人、收货地址和收货手机号。
• 商品状态检查：查找购物车中已勾选的商品，并确认商品存在且处于上架状态。
• 库存判断与更新：判断商品库存，避免超卖，并远程调用商品服务更新库存。
• 购物车商品移除：生成订单前，循环遍历并删除购物车中对应的商品。
• 订单生成环节：注意订单号的生成规则，并循环保存订单中的每个商品至相关表。

2）订单生命周期

• 订单生命周期流程概述：用户与订单的交互情况，下单前操作包括用户登录、浏览商品、加购物车，下单后选择扫码支付后发货收货或取消订单，订单状态变化依次为未付款、已付款、已发货、交易完成、用户已取消，订单状态存储方式为通过枚举值存储。下一步操作是查看具体代码实现。

3）订单主流程

• Order Controller 主要方法 ：调用 Order Service 的 create 方法，返回值为 Order Number，请求参数为三个必填参数，postage 和支付方式默认设置为零和一。
• 创建订单接口实现 ：
  • 创建订单 ：操作失败则全部回滚，获取购物车列表通过 user ID 获取并过滤选中商品，判断购物车是否为空使用 collections utils 的 is empty 方法，验证商品状态及库存需遍历购物车，检查商品存在性、上下架状态和库存数量，购物车对象转换订单商品对象利用 cart view list to order item list 方法，扣减商品库存循环遍历 order item，更新商品库存数量。
  • 清空购物车 ：目标是实现购物车已勾选商品删除，采用 clean cart 方法，传入 cut view list（已勾选商品列表），操作步骤是遍历列表，将每个 ve o 的 ID 传给购物车 map 的 delete by primary key 方法进行删除。
  • 生成订单 ：在清空购物车之后，新建 order 对象，设置订单编号、用户 ID、总价等信息，订单编号生成使用 order code factory 工具类的 get order code 方法，传入 user ID 生成带随机数的编号，订单状态初始设置为 “十”，对应 “未付款” 状态，状态码包括已取消、未付款、已付款、已发货和完成，插入 order 表前设置默认运费和支付方式，然后将记录插入 order 表，插入 order item 表时遍历已初始化的 order item list，将每一项作为内容插入表中。
  • 插入订单项 ：存在 string 类型的 order number，其作用是标明订单项所属的主订单，创建订单流程是给 order number 赋值，插入 order item 表，返回 order number。

6. 验证订单接口

• 验证订单接口使用需启动服务，服务数量为五个，电脑压力大，可能卡顿，耗时长。

7. 地址映射配置

1）生成订单接口配置

• 准备接口：在 Postman 中准备生成订单相关接口。
• 接口转移：将生成订单等九个接口转移到 “订单” 文件夹。
• 生成订单前置条件：购物车需有商品，否则无法生成订单。
• 测试接口全面性：清空购物车，测试购物车为空时生成订单是否会报错。
• 生成订单操作：在购物车有商品时生成订单，返回随机订单号。

2）支付二维码接口配置

• 子节点 1：访问 404 问题 ：

  • 例题 # 接口访问 404 问题判断 ：

    • 接口 404 原因分析 ：问题出现模块为购物车与订单模块，原因是缺少 config 配置，导致路径无法转换。
    • 配置转换规则 ：
      • 新建配置包与类 ：新建名为 config 的包，创建配置类 im como web mvc config。
      • 配置类描述与接口 ：描述为地址映射配置，实现 web mvc configure 接口。
      • 地址映射配置方法 ：重写 add resource handlers 方法，指定地址映射关系，参数为当前映射地址（images），调用 AD resource locations 方法，设置转移地址（file 前缀 + file upload DIR）。
      • 优点 ：只需修改配置文件地址，即可更新所有引用地址。

  • 配置应用 ：为模块提供地址映射关系，使 Spring 能读到配置，未配置路由地址转发会导致无法正常显示图片。

  • 配置重启 ：目的为应用新规则，完成编译后重新启动，对比之前状态，分析配置问题，验证方法是浏览器刷新查看二维码图片，正确显示条件是图片正常生成且路径正确，路由正确。

一、课程回顾和总结

1. 课程主体内容回顾

1) 重难点回顾

课程总结主题 ：Spring Cloud 电商部分

• 项目介绍与模块拆分 ：基于 spring 电商项目，遵循力度适中原则，从人员角度、业务相关性、独立性角度出发，拆分为多个模块，包括 uri ka server、用户模块、公共模块、网关模块、商品分类与商品模块、购物车与订单模块等。
• 项目基础与改造 ：基于 spring boot 电商项目，引入微服务思想和概念。
• 前台功能与用户模块 ：涵盖注册、登录、更新、签名、身份认证、登出接口、递归查询商品分类、搜索排序商品列表、商品详情、购物车功能（加入、显示、数量更改、删除、选择和不选择等）、订单功能（下单、查询订单详情、取消订单、显示二维码确认收货等）。
• 后台功能与管理 ：包括管理员登录、登出、身份认证、商品分类管理（增加、修改、删除分类）、商品管理（商品列表、新增商品、图片上传、更新、删除、批量上下架）、订单管理（订单列表、发货、订单完结等操作）。

2) 购物车和订单模块开发

• 尤瑞卡 server 开发 ：介绍尤瑞卡及服务注册与发现。
• 用户模块开发 ：进行表设计、完整测试。
• 公共模块开发 ：包含常量、异常和工具类，不属 spring boot 项目。
• 网关模块开发 ：完成统一健全，利用过滤器进行拦截处理。
• 商品分类模块 ：进行表设计、接口设计、session 处理。
• 商品模块开发 ：进行表设计、接口设计，常量转移，解决图片上传问题。
• 购物车模块开发 ：熟悉业务流程，开发相关模块。
• 订单模块开发 ：进行表设计、接口设计、熟悉下单流程、订单生命周期及状态，处理多种接口，使用 postman 测试。

3) Spring Cloud 特有重难点

• 模块拆分 ：需要合理地根据业务进行拆分，避免拆分力度不合适。
• 公共模块内容 ：将常量、异常和工具类等公共内容抽离出来，形成公共模块，以便各微服务复用。
• 网关过滤器设计 ：通过网关过滤器实现统一鉴权、限流等功能，对请求进行拦截处理。
• 共享 session 处理 ：使用 redis 等中间件实现 session 的共享，保证用户登录状态在各微服务之间的一致性。
• fin 调用 ：利用 fin 调用实现微服务之间的通信，需注意调用过程中的数据传输、错误处理等问题。

4) 模块设计建议

• 避免力度不合适 ：根据业务需求合理拆分模块，既能保证模块的独立性，又要避免过度拆分导致的复杂性。
• 设置公共模块 ：将公共的工具类、常量、异常等抽取到公共模块，减少重复代码。
• 不使用独立校验 ：避免在每个微服务中独立进行校验，可统一在网关或公共模块中进行校验。
• 使用 redis 共享 session ：通过 redis 存储 session 信息，实现 session 共享，保证用户登录状态的一致性。
• 使用 fin 进行模块调用 ：利用 fin 调用实现微服务之间的通信，提高系统的可维护性和扩展性。

5) 购物车与订单模块重难点

• 订单表与状态设计 ：合理设计订单表结构，包括订单状态字段，明确订单的各个状态及其转换逻辑。
• 购物车与下单流程 ：熟悉购物车的业务流程，包括商品的添加、删除、数量更改等操作，以及下单流程中的商品信息获取、库存校验、订单生成等环节。
• fin 调用时 session 丢失解决 ：在 fin 调用过程中，由于跨服务调用可能导致 session 丢失，可通过使用 redis 共享 session 等方式来解决。

6) 常见错误提醒

• 费用调用获取不到 user 对象 ：可能是因为 session 共享未正确配置或 fin 调用时未正确传递 user 信息，需检查 redis 配置、fin 调用代码等。
• 错误拦截所有请求 ：在网关过滤器或拦截器中，若配置不当可能会导致所有请求都被拦截，需仔细检查拦截规则，确保合法请求能够正常通过。
• 路由配置不完整 ：若路由配置不完整，可能会导致请求无法正确转发到目标服务，需检查网关的路由配置，确保各微服务的路由规则正确无误。

7) 项目升级掌握情况

完成从 Spring Boot 到 Spring Cloud 微服务项目的升级，掌握微服务架构下的项目开发方法和技巧，包括模块拆分、服务注册与发现、网关路由、微服务间通信等方面的知识。