实战案例：用提示词生成微服务架构设计的思路

1. 前言

在进行微服务架构设计时，很多开发者会遇到 “不知从何下手” 的问题。比如不知道如何拆分服务、选择哪些中间件、如何设计接口等。而 AI 工具能通过精准的提示词，快速生成符合需求的架构设计思路，帮我们打开设计方向。

本文会通过多个实战案例，详细讲解如何编写提示词，让 AI 输出可用的微服务架构设计思路。案例覆盖电商、物流、教育等常见业务场景，每个案例都会包含 “需求分析”“提示词设计”“AI 输出解析” 三个部分，确保大家能直接复用方法到实际工作中。

2. 微服务架构设计提示词的核心要素

在编写提示词前，需要明确几个核心要素。这些要素能让 AI 更精准地理解需求，生成贴合实际的设计思路。

2.1 业务场景说明

必须在提示词中清晰说明业务场景，比如 “电商平台的订单管理模块”“物流系统的配送跟踪功能”。业务场景决定了架构设计的核心需求，比如电商场景需要高并发支持，物流场景需要实时跟踪能力。

如果不说明业务场景，AI 可能会生成通用化的架构思路，无法匹配具体业务的特殊需求。比如只说 “设计微服务架构”，AI 输出的内容会很宽泛，没有实际参考价值；而说 “设计电商平台的订单微服务架构，支持每秒 1000 单的下单请求”，AI 会针对性地考虑高并发设计。

2.2 核心功能需求

要列出架构需要支撑的核心功能，比如订单微服务需要包含 “创建订单”“订单支付”“订单取消”“订单查询” 等功能。核心功能是服务拆分和接口设计的基础，AI 会根据功能需求拆分服务模块、设计接口参数。

例如在提示词中写 “核心功能：1. 用户注册与登录；2. 商品浏览与搜索；3. 下单与支付；4. 订单查询与售后”，AI 会围绕这些功能拆分出用户服务、商品服务、订单服务、支付服务等。

2.3 非功能需求

非功能需求包括性能、可用性、安全性、扩展性等指标，这些是架构设计的关键约束。比如 “支持每秒 500 次查询请求”“系统可用性达到 99.9%”“数据传输需加密” 等。

非功能需求会影响中间件选择和架构模式。比如要求 “高可用性”，AI 会推荐服务集群、异地多活等设计；要求 “高并发”，会推荐缓存、消息队列等组件。如果不说明非功能需求，AI 生成的架构可能无法满足实际运行要求。

2.4 技术栈偏好（可选）

如果有明确的技术栈偏好，比如 “后端用 Java Spring Cloud，数据库用 MySQL，缓存用 Redis”，可以在提示词中说明。AI 会基于指定的技术栈生成设计思路，避免推荐不熟悉的技术。

如果没有技术栈偏好，也可以不写，AI 会推荐当前主流的技术组合。比如后端推荐 Java Spring Cloud、Go Micro，前端推荐 Vue、React，中间件推荐 Redis、RabbitMQ 等。

3. 实战案例 1：电商平台订单微服务架构设计

3.1 需求分析

3.1.1 业务场景

电商平台的订单模块，负责处理用户从下单到售后的全流程，包括创建订单、支付回调、订单取消、订单退款、订单查询等操作。

3.1.2 核心功能需求

1. 创建订单：用户选择商品后生成订单，锁定库存；

1. 支付回调：支付完成后接收支付平台的回调通知，更新订单状态；

1. 订单取消：用户取消未支付订单，释放库存；

1. 订单退款：处理用户的退款申请，更新订单状态并发起退款；

1. 订单查询：支持用户查询个人订单列表和订单详情，支持商家查询订单数据。

3.1.3 非功能需求

1. 性能：每秒支持 1000 单的下单请求，订单查询响应时间小于 500ms；

1. 可用性：系统可用性达到 99.9%，订单数据不丢失；

1. 扩展性：支持后续新增 “订单拆分”“批量下单” 功能；

1. 安全性：订单数据传输需加密，支付相关信息需脱敏存储。

3.1.4 技术栈偏好

后端：Java Spring Cloud；数据库：MySQL（主从架构）；缓存：Redis；消息队列：RabbitMQ；服务注册与发现：Nacos。

3.2 提示词设计

“请基于以下需求，生成电商平台订单微服务的架构设计思路：

1. 业务场景：电商平台订单模块，处理下单到售后全流程；

1. 核心功能：创建订单、支付回调、订单取消、订单退款、订单查询；

1. 非功能需求：每秒支持 1000 单下单请求，订单查询响应时间 < 500ms，可用性 99.9%，数据不丢失，支持后续功能扩展，订单数据传输加密；

1. 技术栈：Java Spring Cloud、MySQL（主从）、Redis、RabbitMQ、Nacos。

要求包含：服务拆分方案、核心接口设计、中间件使用方案、高并发设计、数据存储方案、容错设计。”

3.3 AI 输出解析

3.3.1 服务拆分方案

根据核心功能，将订单相关功能拆分为 3 个微服务：

1. 订单服务（Order Service）：负责创建订单、订单取消、订单查询、订单退款申请处理；

1. 订单支付服务（Order Payment Service）：负责接收支付平台回调、更新订单支付状态、发起退款请求；

1. 订单库存协调服务（Order Inventory Service）：负责下单时锁定库存、取消订单时释放库存，与商品服务的库存模块交互。

拆分理由：将支付和库存协调独立为服务，避免订单服务过于庞大；同时减少服务间耦合，比如支付逻辑变更时，只需修改订单支付服务，不影响订单服务的其他功能。

3.3.2 核心接口设计

每个服务提供 RESTful 接口，核心接口如下：

1. 订单服务接口

1.1 创建订单：POST /api/order/create，请求参数：用户 ID、商品列表（商品 ID、数量、单价）、收货地址 ID、支付方式；返回参数：订单 ID、订单状态（待支付）、创建时间；

1.2 取消订单：POST /api/order/cancel，请求参数：订单 ID、用户 ID；返回参数：取消结果（成功 / 失败）、失败原因；

1.3 查询订单列表：GET /api/order/list，请求参数：用户 ID、页码、每页数量、订单状态（可选）；返回参数：订单列表（订单 ID、商品名称、订单金额、订单状态、创建时间）；

1.4 申请退款：POST /api/order/refund/apply，请求参数：订单 ID、用户 ID、退款金额、退款原因；返回参数：退款申请 ID、申请状态（待审核）。

1. 订单支付服务接口

2.1 接收支付回调：POST /api/order/payment/callback，请求参数：支付平台订单号、电商订单 ID、支付金额、支付状态；返回参数：回调处理结果（成功 / 失败）；

2.2 发起退款：POST /api/order/payment/refund，请求参数：退款申请 ID、订单 ID、退款金额；返回参数：退款结果（成功 / 失败）、支付平台退款单号。

1. 订单库存协调服务接口

3.1 锁定库存：POST /api/order/inventory/lock，请求参数：订单 ID、商品列表（商品 ID、数量）；返回参数：锁定结果（成功 / 失败）、失败商品列表；

3.2 释放库存：POST /api/order/inventory/release，请求参数：订单 ID、商品列表（商品 ID、数量）；返回参数：释放结果（成功 / 失败）。

3.3.3 中间件使用方案

1. Nacos：用于服务注册与发现，订单服务、订单支付服务、订单库存协调服务启动后，自动注册到 Nacos，服务间通过 Nacos 获取对方地址进行调用；同时 Nacos 作为配置中心，存储各服务的配置参数（如数据库连接信息、Redis 地址），支持动态配置更新。

1. Redis：主要用于缓存和分布式锁；

2.1 缓存：缓存高频查询的订单数据（如用户最近 30 天的订单列表），减少数据库查询压力，提升查询响应速度（目标 < 500ms）；

2.2 分布式锁：下单时用 Redis 分布式锁防止用户重复下单，确保同一用户同一商品不会生成多个订单。

1. RabbitMQ：用于异步通信和解耦；

3.1 下单流程：订单服务创建订单后，发送 “订单创建成功” 消息到 RabbitMQ，订单库存协调服务监听该消息，执行库存锁定操作；

3.2 支付回调：订单支付服务接收支付回调后，发送 “订单支付成功” 消息到 RabbitMQ，订单服务监听该消息，更新订单状态；同时商品服务监听该消息，扣减最终库存；

3.3 退款流程：订单服务发起退款申请后，发送 “退款申请提交” 消息到 RabbitMQ，订单支付服务监听该消息，发起退款请求到支付平台。

3.3.4 高并发设计

1. 接口限流：使用 Spring Cloud Gateway 的限流功能，对 “创建订单” 接口设置每秒 1000 单的限流阈值，超过阈值时返回 “当前下单人数过多，请稍后再试”，避免系统过载。

1. 缓存优化：

2.1 订单列表缓存：用户查询订单列表时，先从 Redis 获取缓存数据，缓存不存在时查询数据库，查询结果存入 Redis，设置 10 分钟过期时间；

2.2 热点商品库存缓存：将高频下单的商品库存缓存到 Redis，下单时先检查 Redis 缓存的库存，库存充足再锁定，减少数据库访问。

1. 数据库优化：

3.1 主从架构：MySQL 采用主从架构，主库负责写操作（创建订单、更新订单状态），从库负责读操作（订单查询），分散数据库压力；

3.2 分库分表：按 “用户 ID 取模” 的方式分表，将不同用户的订单数据存储到不同的表中，避免单表数据量过大导致查询缓慢（比如单表数据量控制在 1000 万以内）。

3.3.5 数据存储方案

1. 订单服务数据库（MySQL）：

1.1 订单主表（order_main）：存储订单核心信息，字段包括订单 ID、用户 ID、订单金额、支付方式、订单状态、创建时间、更新时间；

1.2 订单明细表（order_item）：存储订单中的商品信息，字段包括订单明细 ID、订单 ID、商品 ID、商品名称、商品单价、购买数量；

1.3 订单地址表（order_address）：存储订单的收货地址，字段包括地址 ID、订单 ID、收件人姓名、联系电话、省市区、详细地址。

1. 订单支付服务数据库（MySQL）：

2.1 支付记录表（payment_record）：存储支付相关信息，字段包括支付记录 ID、订单 ID、支付平台订单号、支付金额、支付状态、支付时间；

2.2 退款记录表（refund_record）：存储退款相关信息，字段包括退款记录 ID、订单 ID、退款金额、退款原因、退款状态、申请时间、退款完成时间。

1. Redis 缓存数据：

3.1 订单列表缓存：key 为 “user:order:list:{userID}:{page}”，value 为订单列表的 JSON 字符串；

3.2 订单详情缓存：key 为 “order:detail:{orderID}”，value 为订单详情的 JSON 字符串；

3.3 商品库存缓存：key 为 “product:inventory:{productID}”，value 为商品当前库存数量；

3.4 分布式锁：key 为 “lock:order:create:{userID}:{productID}”，value 为随机字符串，过期时间 30 秒。

3.3.6 容错设计

1. 服务降级：使用 Sentinel 实现服务降级，当订单服务压力过大（如 CPU 使用率超过 80%）时，对 “订单查询” 接口进行降级，返回缓存中的历史数据或简化的订单信息，优先保证 “创建订单”“支付回调” 等核心接口的可用性。

1. 服务熔断：当订单支付服务调用支付平台接口失败率超过 50% 时，触发熔断，暂时停止调用该接口，直接返回 “支付暂时不可用，请稍后再试”，避免大量失败请求占用系统资源；熔断后每隔 5 秒尝试恢复调用，直到失败率低于阈值。

1. 数据备份与恢复：MySQL 主库开启 binlog 日志，每天凌晨自动备份全量数据，每小时备份增量 binlog 日志；若主库数据丢失，可通过全量备份 + 增量日志恢复数据，确保订单数据不丢失。

4. 实战案例 2：物流系统配送跟踪微服务架构设计

4.1 需求分析

4.1.1 业务场景

物流系统的配送跟踪模块，负责记录快递从商家发货到用户签收的全流程状态，支持用户和商家实时查询快递位置和状态，同时支持配送员更新配送进度。

4.1.2 核心功能需求

1. 物流单创建：商家发货时生成物流单，记录快递信息（收件人、寄件人、商品信息）；

1. 状态更新：配送员通过 APP 更新配送状态（已揽件、运输中、派送中、已签收、异常）；

1. 实时跟踪：用户和商家查询物流单的实时状态和位置信息；

1. 异常处理：当物流出现异常（如丢失、延迟）时，系统自动通知用户和商家，并记录异常原因；

1. 数据统计：统计配送员的配送完成率、平均配送时间，供运营部门分析。

4.1.3 非功能需求

1. 实时性：配送状态更新后，用户查询时需在 1 秒内看到最新状态；

1. 并发：支持每秒 2000 次物流单查询请求，每秒 500 次状态更新请求；

1. 可用性：系统可用性达到 99.95%，物流状态数据不丢失；

1. 存储：物流单数据需保留 3 年，支持历史数据查询。

4.1.4 技术栈偏好

后端：Go Micro；数据库：MySQL（主从）+ Elasticsearch；缓存：Redis；消息队列：Kafka；服务注册与发现：Consul；实时通信：WebSocket。

4.2 提示词设计

“请基于以下需求，生成物流系统配送跟踪微服务的架构设计思路：

1. 业务场景：物流配送跟踪模块，记录快递全流程状态，支持实时查询和状态更新；

1. 核心功能：物流单创建、状态更新、实时跟踪、异常处理、数据统计；

1. 非功能需求：状态更新后查询延迟 < 1 秒，每秒 2000 次查询、500 次状态更新，可用性 99.95%，数据保留 3 年，不丢失；

1. 技术栈：Go Micro、MySQL+Elasticsearch、Redis、Kafka、Consul、WebSocket。

要求包含：服务拆分、接口设计、中间件方案、实时性设计、数据存储、容错与备份。”

4.3 AI 输出解析

4.3.1 服务拆分方案

根据核心功能，拆分为 4 个微服务：

1. 物流单服务（Waybill Service）：负责物流单创建、物流单信息维护（如修改收件人信息）、物流单查询（基础信息）；

1. 配送状态服务（Delivery Status Service）：负责处理配送状态更新、状态历史记录查询；

1. 实时跟踪服务（Real-time Tracking Service）：通过 WebSocket 向用户推送实时物流状态，支持用户实时查询物流位置；

1. 物流统计服务（Logistics Stat Service）：负责统计配送员业绩（完成率、配送时间）、物流异常数据，生成统计报表。

拆分理由：将实时跟踪和统计功能独立为服务，避免影响核心的物流单和状态更新功能；同时 WebSocket 的长连接管理需要单独优化，独立服务便于维护。

4.3.2 核心接口设计

1. 物流单服务接口

1.1 创建物流单：POST /api/waybill/create，请求参数：寄件人信息（姓名、电话、地址）、收件人信息、商品列表、快递公司 ID；返回参数：物流单号、创建时间；

1.2 查询物流单基础信息：GET /api/waybill/info，请求参数：物流单号；返回参数：物流单号、寄收件人信息、商品信息、快递公司名称；

1.3 修改收件人信息：PUT /api/waybill/recipient，请求参数：物流单号、新收件人姓名 / 电话 / 地址；返回参数：修改结果（成功 / 失败）。

1. 配送状态服务接口

2.1 更新配送状态：POST /api/delivery/status/update，请求参数：物流单号、配送员 ID、当前状态（已揽件 / 运输中 / 派送中 / 已签收/ 异常）、当前位置（经纬度）、备注（可选）；返回参数：更新结果（成功 / 失败）、更新时间；

2.2 查询状态历史：GET /api/delivery/status/history，请求参数：物流单号；返回参数：状态列表（状态名称、更新时间、更新人、位置信息、备注）。

1. 实时跟踪服务接口

3.1 建立实时连接：GET /api/tracking/connect，请求参数：物流单号、用户 ID；返回参数：连接 ID、当前物流状态；（通过 WebSocket 建立长连接，后续状态更新通过该连接推送）

3.2 主动查询实时状态：GET /api/tracking/realtime，请求参数：物流单号；返回参数：当前状态、位置信息、预计送达时间。

1. 物流统计服务接口

4.1 查询配送员业绩：GET /api/logistics/stat/deliveryman，请求参数：配送员 ID、统计时间范围（开始日期 - 结束日期）；返回参数：总配送单量、已完成量、完成率、平均配送时间；

4.2 查询异常数据：GET /api/logistics/stat/exception，请求参数：快递公司 ID、统计时间范围；返回参数：异常单量（丢失 / 延迟 / 破损）、异常率、各类型异常占比。

4.3.3 中间件使用方案

1. Consul：用于服务注册与发现，4 个微服务启动后自动注册到 Consul，服务间通过 Consul 获取调用地址；同时 Consul 提供健康检查功能，每隔 10 秒检查服务是否正常运行，若服务宕机，Consul 会自动将其从服务列表中移除，避免调用失败。

1. Redis：主要用于缓存和会话管理；

2.1 缓存：缓存高频查询的物流单状态（如最近 24 小时内有查询记录的物流单）和配送员基础信息，减少数据库访问，确保查询延迟 < 1 秒；

2.2 会话管理：存储 WebSocket 连接会话信息（连接 ID、物流单号、用户 ID），当服务重启时，可通过 Redis 恢复未关闭的连接，避免用户实时跟踪中断。

1. Kafka：用于异步通信和数据同步；

3.1 状态更新同步：配送状态服务更新物流状态后，发送 “状态更新” 消息到 Kafka，实时跟踪服务监听该消息，通过 WebSocket 推送给相关用户；同时物流统计服务监听该消息，更新统计数据；

3.2 异常通知：当检测到物流异常时，配送状态服务发送 “异常通知” 消息到 Kafka，消息推送服务（独立服务）监听该消息，通过短信或 APP 推送通知用户和商家。

1. Elasticsearch：用于存储和查询物流状态历史数据；

物流状态历史数据量庞大（需保留 3 年），且常需按时间范围、状态类型等条件查询，MySQL 查询效率低，因此用 Elasticsearch 存储。例如查询 “2024 年 5 月 1 日 - 5 月 10 日期间，状态为‘延迟’的物流单”，Elasticsearch 可在 1 秒内返回结果，远超 MySQL 的查询速度。

4.3.4 实时性设计

1. WebSocket 长连接：实时跟踪服务采用 WebSocket 与用户端建立长连接，当物流状态更新时，无需用户主动刷新，服务端会主动将最新状态推送给用户，确保实时性（延迟 < 1 秒）；同时长连接采用心跳机制，每隔 30 秒发送一次心跳包，检测连接是否正常，若连接断开，用户端会自动重新连接。

1. 数据分层处理：

2.1 热点数据（最近 24 小时的物流单状态）存储在 Redis，确保查询最快；

2.2 近期数据（3 个月内的物流单状态）存储在 MySQL，兼顾查询速度和数据一致性；

2.3 历史数据（3 个月前的物流单状态）存储在 Elasticsearch，支持高效的历史查询，同时减少 MySQL 存储压力。

1. 异步更新：配送状态服务更新状态时，先更新 MySQL 和 Redis（确保用户查询到最新状态），再异步发送消息到 Kafka，触发后续的推送和统计操作，避免同步操作导致状态更新延迟。

4.3.5 数据存储方案

1. MySQL 数据库（主从架构）：

1.1 物流单主表（waybill_main）：存储物流单基础信息，字段包括物流单号、寄件人 ID、收件人 ID、商品数量、快递公司 ID、创建时间、预计送达时间；（主库写，从库读）

1.2 配送员表（deliveryman）：存储配送员信息，字段包括配送员 ID、姓名、电话、所属快递公司 ID、状态（在岗 / 请假）；

1.3 物流异常表（logistics_exception）：存储异常信息，字段包括异常 ID、物流单号、异常类型（丢失 / 延迟 / 破损）、异常原因、处理状态（待处理 / 已解决）、发生时间。

1. Elasticsearch 索引：

2.1 物流状态历史索引（logistics_status_history）：字段包括索引 ID、物流单号、状态类型、更新时间、更新人 ID（配送员 ID）、位置经度、位置纬度、备注；索引按 “年 - 月” 分片（如 2024-05、2024-06），便于管理和查询。

1. Redis 缓存数据：

3.1 物流单状态缓存：key 为 “waybill:status:{waybillNo}”，value 为当前状态的 JSON 字符串（包含状态名称、更新时间、位置），过期时间 24 小时；

3.2 WebSocket 会话缓存：key 为 “ws:session:{connectionID}”，value 为会话信息（物流单号、用户 ID、连接时间），过期时间 2 小时（与心跳机制配合，连接正常则自动续期）；

3.3 配送员信息缓存：key 为 “deliveryman:info:{deliverymanID}”，value 为配送员基础信息的 JSON 字符串，过期时间 1 小时。

4.3.6 容错与备份设计

1. 服务集群：每个微服务部署至少 3 个节点，通过 Consul 实现负载均衡，当某个节点宕机时，其他节点可继续提供服务，确保系统可用性达到 99.95%；例如实时跟踪服务部署 3 个节点，某节点宕机后，Consul 会将请求转发到其他 2 个节点，用户无感知。

1. 数据备份：

2.1 MySQL：主库开启 binlog 日志，每天凌晨 2 点自动备份全量数据到云存储（如阿里云 OSS），每 30 分钟备份增量 binlog 日志；从库定期（每周）进行全量备份，避免主库备份影响业务；

2.2 Elasticsearch：开启索引快照功能，每天凌晨 3 点自动创建索引快照并存储到 OSS，若索引数据丢失，可通过快照恢复；同时配置索引副本（每个索引 2 个副本），避免单个节点故障导致数据丢失。

1. 降级策略：当系统压力过大（如查询请求超过每秒 2000 次）时，对非核心接口进行降级；例如物流统计服务的 “历史异常数据查询” 接口，降级后仅返回最近 7 天的数据，优先保证 “实时跟踪”“状态更新” 等核心接口的可用性；降级策略通过 Consul 动态配置，无需重启服务即可生效。

5. 实战案例 3：在线教育平台课程管理微服务架构设计

5.1 需求分析

5.1.1 业务场景

在线教育平台的课程管理模块，负责课程的创建、发布、更新、下架，以及课程资源（视频、课件、作业）的管理，同时支持学生选课、退课和课程学习进度跟踪。

5.1.2 核心功能需求

1. 课程管理：教师创建课程（填写课程名称、简介、大纲）、更新课程信息、发布 / 下架课程；

1. 资源管理：上传课程资源（视频、PPT、作业文档）、关联资源到课程章节、更新 / 删除资源；

1. 选课管理：学生浏览课程列表、选课（加入课程）、退课（退出课程）；

1. 学习跟踪：记录学生的课程学习进度（如视频观看进度、作业完成情况）、生成学习报告；

1. 课程搜索：支持按课程名称、教师姓名、课程分类搜索课程，支持筛选（如按评分、选课人数）。

5.1.3 非功能需求

1. 性能：课程列表查询响应时间 < 300ms，视频资源加载时间 < 2 秒；

1. 并发：支持每秒 1500 次课程查询请求，每秒 500 次选课请求；

1. 可用性：系统可用性达到 99.9%，课程资源不丢失；

1. 存储：视频资源需长期存储（至少 5 年），支持高清（1080P）视频存储；

1. 安全性：课程资源仅允许选课学生访问，防止未授权下载。

5.1.4 技术栈偏好

后端：Java Spring Cloud Alibaba；数据库：MySQL（主从）+ MongoDB；缓存：Redis；消息队列：RocketMQ；对象存储：阿里云 OSS；搜索引擎：Elasticsearch；服务注册与发现：Nacos。

5.2 提示词设计

“请基于以下需求，生成在线教育平台课程管理微服务的架构设计思路：

1. 业务场景：在线教育平台课程管理模块，负责课程创建、资源管理、选课、学习跟踪和课程搜索；

1. 核心功能：课程管理、资源管理、选课管理、学习跟踪、课程搜索；

1. 非功能需求：课程查询响应 < 300ms，视频加载 < 2 秒，每秒 1500 次查询、500 次选课，可用性 99.9%，视频存储 5 年，资源仅选课学生可访问；

1. 技术栈：Spring Cloud Alibaba、MySQL+MongoDB、Redis、RocketMQ、OSS、Elasticsearch、Nacos。

要求包含：服务拆分、接口设计、中间件方案、性能优化、数据存储、安全设计。”

5.3 AI 输出解析

5.3.1 服务拆分方案

根据核心功能，拆分为 5 个微服务：

1. 课程管理服务（Course Management Service）：负责课程创建、更新、发布 / 下架，管理课程基础信息（名称、简介、大纲）；

1. 课程资源服务（Course Resource Service）：负责课程资源（视频、PPT、作业）的上传、关联、更新 / 删除，对接 OSS 存储视频资源；

1. 选课服务（Course Enrollment Service）：负责学生选课、退课，管理选课关系，查询学生已选课程；

1. 学习跟踪服务（Learning Tracking Service）：记录学生学习进度（视频观看时长、作业完成状态），生成学习报告；

1. 课程搜索服务（Course Search Service）：负责课程搜索和筛选，对接 Elasticsearch 实现高效搜索。

拆分理由：将资源管理和搜索功能独立为服务，避免课程管理服务过于庞大；学习跟踪服务单独部署，可专注优化学习数据的实时记录，不影响其他功能。

5.3.2 核心接口设计

1. 课程管理服务接口

1.1 创建课程：POST /api/course/create，请求参数：教师 ID、课程名称、课程简介、课程分类 ID、大纲列表（章节名称、排序）；返回参数：课程 ID、创建时间；

1.2 更新课程：PUT /api/course/update，请求参数：课程 ID、教师 ID、更新字段（名称 / 简介 / 大纲）；返回参数：更新结果（成功 / 失败）；

1.3 发布 / 下架课程：POST /api/course/status，请求参数：课程 ID、教师 ID、状态（发布 / 下架）；返回参数：状态变更结果；

1.4 查询课程详情：GET /api/course/detail，请求参数：课程 ID；返回参数：课程所有信息（名称、简介、大纲、教师信息、选课人数）。

1. 课程资源服务接口

2.1 上传视频资源：POST /api/resource/video/upload，请求参数：课程 ID、章节 ID、教师 ID、视频文件（流）、视频名称、清晰度（720P/1080P）；返回参数：资源 ID、OSS 视频地址、上传时间；

2.2 关联资源到章节：POST /api/resource/associate，请求参数：课程 ID、章节 ID、资源 ID 列表（视频 / PPT / 作业）；返回参数：关联结果；

2.3 查询章节资源：GET /api/resource/chapter，请求参数：课程 ID、章节 ID；返回参数：资源列表（资源 ID、名称、类型、地址、大小）；

2.4 删除资源：DELETE /api/resource/delete，请求参数：资源 ID、教师 ID；返回参数：删除结果（成功 / 失败，失败原因：资源已被学生访问）。

1. 选课服务接口

3.1 学生选课：POST /api/enrollment/select，请求参数：学生 ID、课程 ID；返回参数：选课结果（成功 / 失败，失败原因：课程已满 / 未发布）；

3.2 学生退课：POST /api/enrollment/drop，请求参数：学生 ID、课程 ID；返回参数：退课结果（成功 / 失败，失败原因：已超过退课时间）；

3.3 查询学生已选课程：GET /api/enrollment/student/courses，请求参数：学生 ID、页码、每页数量；返回参数：已选课程列表（课程 ID、名称、教师、学习进度）；

3.4 查询课程选课人数：GET /api/enrollment/count，请求参数：课程 ID；返回参数：选课人数、剩余名额（若课程有限制）。

1. 学习跟踪服务接口

4.1 记录视频观看进度：POST /api/learning/video/progress，请求参数：学生 ID、课程 ID、章节 ID、视频资源 ID、观看时长（秒）、当前进度（百分比）；返回参数：记录结果；

4.2 提交作业：POST /api/learning/homework/submit，请求参数：学生 ID、课程 ID、作业资源 ID、作业文件（流）、提交时间；返回参数：提交结果、作业 ID；

4.3 查询学习报告：GET /api/learning/report，请求参数：学生 ID、课程 ID；返回参数：学习报告（视频完成率、作业完成情况、平均学习时长、上次学习时间）。

1. 课程搜索服务接口

5.1 关键词搜索课程：GET /api/search/course，请求参数：关键词（课程名 / 教师名）、页码、每页数量、筛选条件（评分≥4.0 / 选课人数≥100）；返回参数：课程列表（课程 ID、名称、教师、评分、选课人数、简介）；

5.2 分类筛选课程：GET /api/search/course/category，请求参数：分类 ID、排序方式（最新 / 最热 / 评分高）、页码、每页数量；返回参数：课程列表；

5.3 课程评分：POST /api/search/course/rate，请求参数：学生 ID、课程 ID、评分（1-5 分）、评价内容（可选）；返回参数：评分结果，更新后的课程评分。

5.3.3 中间件使用方案

1. Nacos：用于服务注册与发现和配置中心；

1.1 服务注册：5 个微服务启动后自动注册到 Nacos，服务间通过 Nacos 获取调用地址，如选课服务调用课程管理服务查询课程状态；

1.2 配置中心：存储各服务的配置参数（如 OSS 访问密钥、Elasticsearch 地址、课程发布审核规则），支持动态更新，例如修改课程最大选课人数时，无需重启服务，配置更新后立即生效。

1. Redis：用于缓存和分布式锁；

2.1 缓存：缓存高频查询数据（课程列表、课程详情、学生已选课程），减少数据库访问，确保课程查询响应 < 300ms；例如热门课程列表缓存到 Redis，设置 10 分钟过期时间，用户查询时直接从 Redis 获取；

2.2 分布式锁：选课和退课时用 Redis 分布式锁防止并发问题，如某课程仅剩 1 个名额，多个学生同时选课时，通过锁确保只有 1 个学生选课成功，避免超售。

1. RocketMQ：用于异步通信和解耦；

3.1 课程发布：课程管理服务发布课程后，发送 “课程发布” 消息到 RocketMQ，课程搜索服务监听该消息，将课程信息同步到 Elasticsearch，供用户搜索；

3.2 选课通知：选课服务完成选课后，发送 “选课成功” 消息到 RocketMQ，消息推送服务监听该消息，通过 APP 推送通知学生 “已成功选某某课程”；

3.3 资源更新：课程资源服务更新视频资源后，发送 “资源更新” 消息到 RocketMQ，学习跟踪服务监听该消息，重置学生该章节的学习进度（如视频替换后，进度归零）。