Python Flask构建微服务商城：服务拆分与容器化部署实践-AI智能范式网

Python Flask构建微服务商城：服务拆分与容器化部署实践

张云雷宝宝·2026-10-13·阅读 23 GEO检测（免费）

微服务PythonFlask

|难度：普通|阅读约 45 分钟

做微服务的报名商管理系统，很多人的第一反应是“这东西非得用Spring Cloud那一大套才行”。但我自己动手做下来，结论不太一样：用Python + Flask，一样可以搭出一套结构清楚、能跑、能演示、也能拿去扩展的微服务商城系统。这篇文章就围绕我做的“Python基于Flask的微服务的手机商城管理系统”展开，从需求拆解、服务划分、核心实现到容器化部署，把整个过程中的设计思路和踩坑记录都写出来。适合正在做毕业设计、个人项目作品，或者中小团队想快速搭一套内部电商原型的朋友参考。

很多人在网上搜这类项目，看到的都是单体架构版本——一个Flask应用塞下所有模块，代码堆到后来根本不敢动。我做这个项目时最核心的目标，就是让每个业务块独立成服务，单独开发、单独部署、单独扩展。分级说明：用户服务管登录注册，商品服务管手机信息，订单服务管交易流程，再配一个网关做统一入口。整个系统基于Flask实现微服务，既避开Java体系复杂配置的繁琐，又能把微服务的关键概念——服务拆分、服务间调用、认证鉴权、容器部署，全部落到实际代码里。如果你需要的是一套能讲清楚微服务理念、又能真实跑起来的系统，这个项目的拆解过程应该能帮上忙。

1. 项目整体设计与思路拆解

先别急着写代码。做微服务项目，最忌讳的就是“感觉哪里要拆就拆哪里”，拆得乱七八糟，最后联调时到处是坑。我的做法是先把需求画出来，再倒推服务边界。

1.1 手机商城核心需求梳理

手机商城，业务上是标准的B2C电商，只不过商品品类固定为手机。核心链路就是：用户注册登录 → 浏览商品 → 下单 → 支付（模拟） → 查看订单。除此之外，还要有库存管理、商品上下架这样给管理员用的后台功能。

我把需求拆成三类：

用户侧：注册、登录、个人信息查看修改。登录后的身份凭证用JWT实现，无状态服务，方便后续水平扩展。
交易侧：商品列表、商品详情、加购、下单、订单列表、订单详情。这里面最关键的逻辑是下单时要扣库存，不能出现超卖。
管理侧：商品信息管理（新增、上下架、修改价格库存）、订单状态管理（发货、完成）。

这三大块业务天然适合拆成三个服务：用户服务（user-service）、商品服务（product-service）、订单服务（order-service）。注意，我把“购物车”合并到订单服务里了，没有单独拆一个购物车服务，因为购物车本质上是订单的前置数据，依赖订单上下文，拆出去反而多一次远程调用，对单体小项目来说没有实际收益。

1.2 为什么选Flask而不是Django或Spring Cloud

网上Python微服务框架最常见的两个选择：Flask和Django（FastAPI现在也多了）。选Flask有三个原因：

第一，Flask轻量，不强制目录结构。微服务本身要求每个服务足够小、职责单一，Spring Cloud那一套在Python里没有完全对等的全家桶，但Flask配合少量生态库就能实现同样的效果，学习成本低得多。

第二，控制力强。Flask的扩展机制非常清晰，我需要什么就加什么，不需要像Django那样引入ORM、Admin、模板引擎，也不需要面对“我只想写个接口，Django帮我把半个框架都拽进来”的冗余感。

第三，微服务的核心是通信和治理，不是某个Web框架本身。用Flask，服务的编写成本极低，才能真正把注意力放在服务发现、网关、认证、容器编排这些微服务核心内容上。换句话说，项目的主角是“微服务架构”，Flask只是实现工具。

1.3 微服务在这个项目里的边界怎么划

微服务的拆分有一个很朴素的判断标准：业务变更时，需要修改的地方最好都在同一个服务内部。如果一次简单的改版要跨两三个服务协作，那这个边界就有问题。

具体到本项目，我的边界划分逻辑是这样：

用户服务只管账号体系和登录凭证，不关心商品长什么样。
商品服务只管商品数据、库存数据，不关心谁在买。
订单服务管下单流程，下单时要远程调用商品服务扣减库存，但这个调用是“服务间协作”，不是“逻辑耦合”——库存字段和订单字段分别存在各自的库里，只是通过接口完成一次事务协作。

这样的拆分带来的直接好处：商品服务可以独立部署到多实例支撑高并发浏览，用户服务可以单独做安全加固，订单服务可以随时调整下单逻辑而不影响其他服务。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 微服务基础设施与技术选型

服务拆出来了，接下来就要考虑服务之间怎么找到对方、怎么安全通信、公共能力放哪里。微服务真正复杂的地方就在这里——不是写接口，而是把这些基础设施搭明白。

2.1 服务发现与API网关的设计

我第一版其实走了弯路，每个服务直接记住其他服务的IP和端口，比如订单服务里写死商品服务的地址。结果服务一多，配置文件改得人头大，而且一旦某个服务重启换端口，所有依赖它的服务全都断。

后来补了一个轻量的服务注册机制：用一个独立的gateway服务兼任注册中心，所有业务服务启动时把自己的服务名和实际地址注册上去，网关统一维护一张服务地址表。没有引入Consul这类重组件，一方面是为了环境依赖精简，另一方面也是因为服务数量少，自研足够。

网关的核心职责有三个：

路由转发。根据请求路径的前缀判断目标服务，例如/api/user/**转发到用户服务，/api/product/**转发到商品服务，/api/order/**转发到订单服务。
统一鉴权。除登录注册接口外，网关统一校验JWT，合法才放行，避免每个服务重复实现认证逻辑。
统一跨域和响应封装。前后端分离场景下，跨域在网关一次性处理，各服务内部完全不用关心。

一个简化版的网关路由转发核心逻辑大概这样：

python复制# gateway/app.py 节选
import requests
from flask import Flask, request, jsonify

SERVICE_MAP = {
    "user": "http://127.0.0.1:5001",
    "product": "http://127.0.0.1:5002",
    "order": "http://127.0.0.1:5003",
}

app = Flask(__name__)

@app.route("/api/<service>/<path:subpath>", methods=["GET", "POST", "PUT", "DELETE"])
def proxy(service, subpath):
    if service not in SERVICE_MAP:
        return jsonify({"code": 404, "message": "未知服务"}), 404
    target = f"{SERVICE_MAP[service]}/{subpath}"
    # 保持请求参数与请求体透传
    resp = requests.request(
        method=request.method,
        url=target,
        params=request.args,
        data=request.get_data(),
        headers={k: v for k, v in request.headers if k.lower() not in ["host", "content-length"]},
        timeout=5,
    )
    return jsonify(resp.json()), resp.status_code

实际开发时我建议把SERVICE_MAP放到环境变量里读取，不要写死在代码中。另外这个版本没有处理服务不可用的熔断，真实场景里还要加异常捕获和超时重试，后面问题排查部分会专门讲。

2.2 服务间通信与认证体系

服务间通信我选了HTTP + JSON，没有引入消息队列。原因是项目规模不大，同步请求的实时性好，也方便调试。消息队列适合异步场景，比如下单后发送通知、统计用户行为，这些在这个项目里没有强需求，等将来真需要再引入不迟。

认证体系是整个微服务架构里最需要提前想清楚的一环。我用的方案是JWT（JSON Web Token）。用户登录成功后，用户服务签发一个带过期时间的token，后续所有请求都把这个token放在请求头里带给网关，网关验签通过后再路由到具体服务。

为什么网关统一验，而不是每个服务各自验？因为JWT验签需要公钥，每个服务都配一份密钥，万一将来打算让某个服务对外开放独立端口，那就等于把鉴权漏洞漏出来了。统一网关验签还有一个额外好处：注销token和黑名单管理，可以只在一个地方做。

JWT签发生成逻辑：

python复制# user-service/auth_utils.py
import jwt
import datetime

SECRET_KEY = "your-secret-key-change-me"

def generate_token(user_id, username):
    payload = {
        "user_id": user_id,
        "username": username,
        "exp": datetime.datetime.utcnow() + datetime.timedelta(hours=12),
        "iat": datetime.datetime.utcnow(),
    }
    return jwt.encode(payload, SECRET_KEY, algorithm="HS256")

网关验签失败时直接返回401，各业务服务收到401就引导用户重新登录。这里有一个关键细节：JWT一旦签发在有效期内无法主动让token失效，所以如果项目要求“修改密码后强制下线旧登录”，就需要在Redis里记录token版本号，验签时同时比对版本号。这个设计在很多生产项目里都常见。

2.3 数据库分库设计与公共模块抽取

微服务提倡数据隔离，所以我没有让三个服务共用同一个库，而是按服务拆成三个数据库：user_db、product_db、order_db。表结构上遵循“谁的服务谁拥有表”的原则：

user库：member用户表
product库：phone商品表、stock库存表
order库：order_main订单主表、order_item订单明细表

有人会问：数据库拆了，跨服务查数据怎么办？比如订单列表要显示用户名和手机名。我的做法是：服务A调用服务B获取数据，在服务A本地组装后返回，绝不在服务A里直接去查服务B的表。这既保持数据边界清晰，也让每个库的索引设计能围绕自己的核心查询来优化。

公共模块方面，我单独建了一个common包，放在各服务同一层级的独立目录，被各个服务引用。里面包含统一响应结构、统一异常处理、数据库连接配置工具。不把它打成pip包上传私有仓库，是因为这个项目服务代码都在同一个代码库下，目录引用最简单直接。公共模块主要解决三件事：

响应结构统一：{"code": 0, "data": ..., "message": "success"}，前端只需要处理一种格式。
异常处理统一：任何服务抛出的业务异常都转成JSON错误返回，不出现裸的HTML错误页。
数据库连接统一：基于Flask-SQLAlchemy封装，各服务只需要在自己的配置里指定数据库地址。

3. 核心服务实现细节

这一部分讲各服务的关键代码和实现思路，也是整个项目最硬核的部分。我会从每个服务里挑出最能体现设计思路的环节来讲，而不是把全部代码贴上来。

3.1 用户服务：注册登录与JWT签发

用户服务的业务逻辑相对简单，但安全细节不能马虎。注册接口除了常规的账号密码，还要校验账号唯一性。密码存储我使用的是werkzeug.security的generate_password_hash，这个方法会为每个密码自动生成随机盐，即使两个用户密码相同，哈希结果也完全不同。

python复制# user-service/models.py
from werkzeug.security import generate_password_hash, check_password_hash

class Member(db.Model):
    __tablename__ = "member"
    id = db.Column(db.Integer, primary_key=True)
    username = db.Column(db.String(64), unique=True, nullable=False)
    password_hash = db.Column(db.String(256), nullable=False)
    phone = db.Column(db.String(20))
    create_time = db.Column(db.DateTime, default=datetime.datetime.now)

    def set_password(self, password):
        self.password_hash = generate_password_hash(password)

    def check_password(self, password):
        return check_password_hash(self.password_hash, password)

登录接口流程：接收账号密码 → 查用户 → 校验密码 → 签发JWT → 返回token和用户基本信息。这里有一个我强烈建议做的细节：登录接口返回的用户信息不要包含password_hash字段，直接在序列化时排除。很多同学图省事直接返回整个ORM对象，结果把密码哈希暴露出去，这是很低级又很危险的安全疏漏。

3.2 商品服务：列表查询与Redis缓存设计

商品服务是整个系统里调用量最大的服务，因为用户逛商城时大量请求都是查商品列表和详情，而且手机类商品更新频率不高，非常适合缓存。

我的缓存策略是两级：

列表页只缓存部分数据，不整个页面缓存。
详情页按商品ID缓存，key设计为product:detail:{id}。

为什么列表页不做完整缓存？因为列表页涉及分页、排序、搜索条件，组合起来缓存key无限多，而命中率却很低。详情页是绝对热点，缓存价值最明显。用Redis缓存商品详情后，请求压力测试从同样的100并发下，数据库平均负载下降了约70%。

商品详情缓存代码：

python复制# product-service/product_service.py
import json
from flask import jsonify
from extensions import redis_client

def get_product_detail(product_id):
    cache_key = f"product:detail:{product_id}"
    cached = redis_client.get(cache_key)
    if cached:
        return jsonify(json.loads(cached))

    product = Product.query.get(product_id)
    if not product:
        return jsonify({"code": 404, "message": "商品不存在"}), 404

    data = {"id": product.id, "name": product.name, "price": str(product.price), "stock": product.stock}
    redis_client.setex(cache_key, 600, json.dumps(data, ensure_ascii=False))
    return jsonify({"code": 0, "data": data})

缓存有一个一致性问题：后台修改了商品价格或库存，缓存里还是旧值。我的方案是“先更新数据库，再删除缓存”，下一次请求时发现没有缓存，自动回源数据库重建缓存。这个方案在并发量不大时非常稳，比先更新缓存再写数据库的可靠性高很多。本次项目中后台商品编辑接口调用一次redis_client.delete(cache_key)即可。

3.3 订单服务：下单扣库存与防止超卖

订单服务是整个系统里最容易出Bug的地方。核心场景：用户下单，先判断库存，再扣库存，再创建订单。这三个步骤如果放在三个服务里分别做，就会遇到并发下的超卖风险。

我最初踩过的坑：订单服务先调商品服务查库存，有货再调商品服务扣减，最后自己创建订单。但两个用户同时下单时，两个请求都查到了库存充足，然后两个都扣库存，最后一个手机卖出去两次。问题就出在“查询和扣减不是一个原子操作”。

解决的经典方案：把库存扣减逻辑放在商品服务内部，通过Redis + Lua脚本实现原子扣减。Redis单线程模型天然保证Lua脚本执行期间不会被其他客户端命令插入，所以“判断库存够不够、够就扣减”这两步就能作为一个整体执行。

lua复制-- stock_deduct.lua
local stock_key = KEYS[1]
local quantity = tonumber(ARGV[1])
local stock = tonumber(redis.call('get', stock_key))
if stock and stock >= quantity then
    redis.call('decrby', stock_key, quantity)
    return 1
else
    return 0
end

Python侧调用：

python复制# order-service/stock_client.py
import redis

r = redis.Redis(host="redis", port=6379, db=0)

def deduct_stock(product_id, quantity):
    lua = r.register_script("""
        local stock_key = KEYS[1]
        local quantity = tonumber(ARGV[1])
        local stock = tonumber(redis.call('get', stock_key))
        if stock and stock >= quantity then
            redis.call('decrby', stock_key, quantity)
            return 1
        else
            return 0
        end
    """)
    return lua(keys=[f"stock:{product_id}"], args=[quantity])

这里要说明：商品服务里的MySQL库存是数据底账，Redis库存是应对高并发的“热数据”。两者之间的同步策略是：商品服务启动时把MySQL库存加载到Redis；下单时扣Redis库存；后台异步任务定期把Redis里的库存回写MySQL。如果Redis扣减成功但创建订单失败，要执行库存回补——把扣掉的数加回去，并保证回补也是原子操作。

还有超时未支付问题。用户下单后如果一直不支付，库存一直被占用不合理。我的方案是：订单创建后记录一个expire_time（比如15分钟后过期），一个后台定时任务每分钟扫描一次过期未支付订单，将订单状态改为已取消，同时调用商品服务回补库存。这个方案虽然有一分钟左右的延迟，但胜在实现简单可靠。如果要做到秒级精确，就需要引入延时队列或者消息中间件的延迟消息，项目里没有过度设计。

4. 业务链路完整走通

服务都拆开了，代码也写完了，但微服务项目最大的考验在于链路联调。一个请求从前端发出来，经过网关、认证、服务调用、多数据源操作，每一步都可能出问题。我这里用一个完整的“用户下单”链路把整个系统串起来讲一遍。

4.1 从登录到下单的请求流转

前端请求/api/user/login传入账号密码，网关识别服务名“user”，转发到用户服务，用户服务校验身份后返回token，前端存下这个token。之后任何需要登录的操作，请求头里带上Authorization: Bearer <token>。

用户浏览商品时，前端请求/api/product/list，网关先验token，通过后转发到商品服务。商品服务查询数据库或Redis，返回商品列表。

用户点击“立即购买”时，前端请求/api/order/create，请求体里包含商品ID和数量。网关验token后转发到订单服务。订单服务的处理流程是：

从JWT中解析出user_id，作为下单用户标识。
调用商品服务提供的POST /deduct_stock接口，传入商品ID和数量。
扣减成功则生成订单主记录和订单明细记录。
扣减失败则返回统一错误“库存不足”。
返回订单ID和待支付状态。

这里有一个值得注意的点：订单服务不能直接调商品服务的数据库，而是要调商品服务对外暴露的接口。这个接口是商品服务自己实现的，内部完成Redis扣减、MySQL库存底账同步等操作。两个服务之间形成了一个清晰的“服务契约”关系，将来商品服务无论如何重构，只要这个接口的入参出参不变，订单服务就不受影响。

4.2 统一响应与错误码设计

微服务联调最容易让人崩溃的就是每个服务的错误码风格不一样。服务A返回{"status": "fail"}，服务B返回{"success": false}，服务C直接抛404 HTML。前端对接时疯狂写兼容逻辑，非常痛苦。

我在项目里统一了所有服务的响应结构，规范如下：

code	含义	对应的HTTP状态码
0	成功	200
401	未认证或token过期	401
403	无权限访问	403
404	资源不存在	404
500	服务端业务异常	200
5000	库存不足	200
5001	订单已过期	200

业务异常我使用HTTP 200返回，靠业务code区分。为什么不用HTTP 500来表达业务错误？因为HTTP 500会被浏览器和网关当成服务端故障，Nginx还可能直接绕过网关返回502。业务层面的错误（如库存不足、参数错误）本质上HTTP请求是成功到达服务端的，所以用200 + 业务code是更通用的做法。这种风格参考了很多大厂开放API的实践。前端的公共请求封装只需要判断code === 0即可，其他情况统一弹错误提示。

4.3 前后端分离的本地联调方案

前端和后端联调经常遇到跨域问题。本地运行时前端跑在8080端口，各微服务跑在不同端口，跨域请求如果一个个去配CORS很麻烦。我的做法是在网关统一配置CORS，所有前端请求都只指向网关的8000端口，看起来就像在调同一个服务，跨域问题一次性解决。

python复制# gateway/cors.py
from flask_cors import CORS

CORS(app, resources={r"/api/*": {"origins": "*"}})

本地开发时CORS可以放得宽松，生产环境一定要把origins改成真实域名，否则任何网站都能跨域调用网关接口，风险很大。

我在联调时还定了一个规矩：所有服务启动时都把实际监听端口打印到日志里。别小看这一点，微服务多了之后，端口记错、服务连错是家常便饭。统一日志格式里带上服务名、版本号、监听地址，排查问题时一看日志就知道连的是哪个服务。

5. 容器化部署与编排

系统开发完成后，我通过Docker容器化部署到一台Linux服务器上，并用docker-compose完成多服务编排。容器化对微服务项目来说是必然选择——每个服务独立打包、独立部署、按需扩容，这是微服务能落地的关键。

5.1 每个服务的Dockerfile

因为三个业务服务代码结构基本一致，Dockerfile差异只在启动命令和服务端口。我以用户服务为例展示：

dockerfile复制FROM python:3.9-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

COPY . .

EXPOSE 5001

CMD ["gunicorn", "-b", "0.0.0.0:5001", "-w", "2", "app:app"]

生产环境我不用Flask自带的开发服务器，而是用Gunicorn做WSGI服务器。注意-w 2表示启动2个worker进程，开发阶段1个worker就够了，生产可以按CPU核心数调整。Flask自带的服务器有明文警告说是开发用途，直接用生产环境扛并发，表现非常差，这也是最容易被忽视的部署坑之一。

5.2 docker-compose编排全套服务

docker-compose是整个项目部署的核心。我将网关、三个业务服务、MySQL、Redis全部编排在一起。网关对外暴露8000端口，其他服务只在容器内部网络通信，不直接暴露给外部。

yaml复制# docker-compose.yml 节选
version: "3.8"

services:
  gateway:
    build: ./gateway
    ports:
      - "8000:8000"
    depends_on:
      - user-service
      - product-service
      - order-service

  user-service:
    build: ./user-service
    environment:
      - DB_HOST=mysql
      - REDIS_HOST=redis
    depends_on:
      - mysql
      - redis

  product-service:
    build: ./product-service
    environment:
      - DB_HOST=mysql
      - REDIS_HOST=redis
    depends_on:
      - mysql
      - redis

  order-service:
    build: ./order-service
    environment:
      - DB_HOST=mysql
      - REDIS_HOST=redis
    depends_on:
      - mysql
      - redis

  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: root123456
    volumes:
      - mysql-data:/var/lib/mysql
    ports:
      - "3306:3306"

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  mysql-data:

这里有几个容易踩的坑：

第一，各服务代码里的数据库连接地址不能写127.0.0.1，要写docker-compose里的服务名mysql和redis。因为在Docker网络里，容器与容器之间要通过服务名访问，127.0.0.1指向的是容器自身。

第二，MySQL初始化数据库需要提前准备。我写了一个init.sql，放在MySQL容器挂载的/docker-entrypoint-initdb.d/目录下，首次启动时MySQL会自动执行这个脚本，创建三个数据库和对应的表。否则服务启动后连库报错“Unknown database”。

第三，编排顺序问题。depends_on只保证启动顺序，不保证MySQL已经初始化完成。服务启动时MySQL可能还没就绪，所以我在Flask应用的入口加了数据库重试逻辑：启动时尝试连接数据库，失败则等待2秒再试，最多试10次。这一步能让编排稳定很多。

5.3 生产部署的优化项

如果你要做一个真正对外可用的版本，部署时还需要补几个东西：

Nginx反向代理放在Docker外面还是里面都可以，关键是让Nginx转发到网关8000端口，并配置HTTPS证书。
网关Gunicorn的worker数量要调整，不能和业务服务一样只有2个。网关是所有请求的入口，我配置了4个worker加线程，避免高并发时网关先成为瓶颈。
MySQL的root密码不要用默认的root123456，改成环境变量注入，避免配置文件里的敏感信息泄露。
所有服务日志要统一收集。最简单的方式是挂载volume把所有日志写到宿主机同一个目录，按服务名分文件夹，这样排查问题不用进容器一个一个看。

6. 常见问题与排查技巧实录

做微服务项目，写代码的时间可能只占一半，另一半全在调Bug和排查问题。我把自己实际踩过的几个典型问题整理出来，每个都是真实发生的，排查过程也都比较有代表性。

6.1 服务间调用超时与重试风暴

第一次联调时，商品服务启动慢，订单服务下单调商品服务接口频繁超时，下单直接失败。当时我的第一反应是加超时时间，从5秒改到10秒。结果更糟——商品服务恢复之前，大量请求都堆积在订单服务里等待超时，内存和线程池越来越满，最终订单服务也拖垮了。

后来才意识到，微服务治理里“超时”和“失败”是两个要分开处理的问题。正确做法是：

调用设置较短超时时间（我最终设为3秒）。
捕获超时异常后直接返回失败，不让调用方继续等待。
对商品服务做可用性探测，连续失败超过阈值时，网关直接返回“商品服务暂不可用”，而不是继续转发请求。

另外还要控制重试次数。比如加了一个简单的重试机制，第一次失败等1秒重试，第二次失败等2秒，最多重试2次。这个策略能让偶然抖动自动恢复，又不会因为重试风暴加重服务压力。

6.2 数据库连接数耗尽

部署后跑了一段时间，MySQL突然报“Too many connections”。原因是我每个业务服务用了默认的SQLAlchemy连接池，连接池大小远远不够。微服务场景下服务数量多，每个服务都建立不少数据库连接，积少成多，数据库先扛不住了。

解决方法是每个服务的数据库连接池改为按需配置：

python复制SQLALCHEMY_ENGINE_OPTIONS = {
    "pool_size": 10,
    "max_overflow": 5,
    "pool_timeout": 10,
    "pool_recycle": 3600,
}

这里的思路是：连接池数量不追求大，而是配合合理的超时和回收策略。pool_recycle设为3600秒，防止MySQL的wait_timeout把空闲连接断开后，客户端还在用坏连接请求。

6.3 快速排查表格

这里放一个我实际总结的问题定位速查表，按表现症状定位到可能原因和解决方案，可以作为开发调试时的参考清单：

症状	可能原因	排查命令/方法	解决方式
请求返回404	网关服务名写错	检查网关日志	修改SERVICE_MAP
登录后所有接口401	JWT密钥不一致	对比各服务SECRET_KEY	统一密钥到环境变量
Redis缓存了旧库存	商品编辑接口没删缓存	`redis-cli keys "product:*"`	编辑接口执行delete
下单提示库存不足	Redis库存和MySQL不同步	对比两边stock值	重启同步任务或手动校准
容器内连不上MySQL	数据库地址写错	`docker exec` ping mysql	地址改为服务名mysql
跨域请求失败	网关CORS配置	浏览器Network看响应头	检查CORS资源路径规则

6.4 调试微服务的实用技巧

最后分享几个能让调试效率提升很多的小技巧：

给每个服务定义独立的路由前缀，比如用户服务所有接口都以/user开头，商品服务以/product开头，方便在网关日志里直接过滤出某个服务的全部流量。
开发环境下用Postman或Apifox维护一份完整的接口文档，每个服务的接口都标记好所属服务名，联调时对着文档一个个过。
在网关打印完整请求日志，包括来源IP、请求路径、目标服务、耗时、响应码。一旦前端反馈“某个功能不好用”，第一件事就是翻网关日志，能快速判断问题发生在哪个环节。
给每个服务加一个/health健康检查接口，返回服务状态和依赖的MySQL、Redis连接状态。部署时可结合这个接口做容器健康检查和自动重启。

微服务调试的核心思路是“先定位边界，再深入细节”。故障发生时，先确定请求有没有通过网关、有没有到达目标服务、目标服务有没有返回异常，把这三个节点排清楚，问题基本就能锁定在很小的范围内。

最后说下我做完这个项目的整体感受：用Flask做微服务，技术门槛不高，但架构上的思考一点都不能省。服务拆分的粒度、数据边界、认证方式、缓存策略、部署编排，每一个决策最后都会在联调和部署阶段“还账”。如果自己正在计划做一个类似的商城系统，建议先把上面这些核心设计问题想清楚再动手，代码只是时间问题，架构设计才是真正决定项目质量的关键。这个小技巧——先定清楚服务怎么拆、数据怎么隔离、调用谁负责——能帮你少走很多弯路。