Python微服务架构教程_FastAPIDjango整合开发实践

FastAPI 与 Django 是互补关系而非替代：FastAPI 负责高并发、低延迟接口（如实时通信、AI服务），Django 承担后台管理、用户权限与业务流程；二者通过职责分离、JWT 认证桥接、HTTP/消息队列通信及共享数据层协同。

FastAPI 和 Django 各有定位：FastAPI 适合构建高性能、类型安全的 API 微服务，Django 更适合需要完整生态（如 Admin、ORM、用户系统）的单体或混合应用。二者不是替代关系，而是互补——常见做法是用 FastAPI 承担高并发接口（如实时数据、AI 接口、第三方对接），Django 管理后台、用户权限和业务流程。整合的关键不在“强行合并”，而在“职责分离 + 通信解耦”。

明确边界：哪些模块交给 FastAPI，哪些留给 Django

避免把两个框架塞进同一个进程或共享数据库连接池。推荐按业务域拆分：

• FastAPI 负责：对外暴露的 REST/GraphQL 接口、WebSocket 实时通道、文件上传预处理、模型推理服务封装、第三方支付回调验证等对延迟敏感、需异步支持的场景
• Django 负责：用户注册登录、RBAC 权限控制、CMS 内容管理、订单后台、审计日志、定时任务（Celery 集成）、内部运营看板
• 共用部分（不共用代码，只共用数据）：PostgreSQL / Redis 作为统一数据层；JWT token 可由 Django 发放，FastAPI 验证（共享 secret 和算法）

Token 与用户身份互通：基于 JWT 的轻量认证桥接

Django 默认用 session，FastAPI 常用 JWT。要让两者识别同一用户，可复用 Django 的 django.contrib.auth.models.User 模型生成 token，并在 FastAPI 中解析验证：

• Django 端使用 djangorestframework-simplejwt 或自定义视图返回 {'access': 'xxx', 'user_id': 123}
• FastAPI 端用 pydantic 定义相同 token 结构，用 jwt.decode(..., key=settings.SECRET_KEY) 验证签名（注意算法一致，如 HS256）
• 验证通过后，FastAPI 不查 Django ORM，而是直接根据 user_id 查询本地缓存或调用 Django 提供的轻量用户信息接口（如 /api/v1/user/profile/{id}/）

服务间通信：HTTP 调用优于共享代码，异步调用优于同步阻塞

不要把 Django 的 models.py 或 views.py 直接 import 到 FastAPI 项目里。正确方式是：

• 将 Django 暴露为内部 REST 接口（如 http://django-app:8000/api/internal/order/create/），FastAPI 用 httpx.AsyncClient 异步调用
• 敏感操作（如扣库存、发通知）走 Celery + Redis/RabbitMQ，FastAPI 触发任务，Django Worker 执行并回写结果
• 高频读场景（如商品基础信息）用 Redis 缓存 Django 查询结果，FastAPI 直接读缓存，降低耦合与延迟

部署与可观测性：分开打包，统一追踪

两个服务独立 Docker 化，但共享日志与链路追踪配置：

• FastAPI 使用 uvicorn[standard]，Django 使用 gunicorn 或 uvicorn（兼容 ASGI），分别打镜像
• 都接入 OpenTelemetry，用同一 Jaeger 或 Zipkin 后端，Trace ID 在 HTTP Header（如 traceparent）中透传
• 日志统一输出 JSON 格式，包含 service_name、request_id、level 字段，由 Loki + Grafana 聚合查询

不复杂但容易忽略：真正的微服务整合，不是技术堆砌，而是围绕业务生命周期设计协作契约。从第一个跨服务调用开始，就该约定好错误码语义、重试策略、超时时间与降级方案。