Django本身不是为微服务原生设计的框架，但可通过剥离状态、收敛外部依赖、约束部署契约实现高可用无状态微服务架构；关键改造包括：会话统一走Redis/Memcached、静态文件交Nginx/CDN托管、CONN_MAX_AGE设为60并配合数据库保活参数、uWSGI启用master与harakiri机制、健康检查并行验证DB/缓存/Celery、缓存键加版本前缀、集群强制chrony时间同步。
直接上结论：Django本身不是为微服务原生设计的框架，但只要剥离状态、收敛外部依赖、约束部署契约，它完全能跑在高可用无状态微服务架构里——关键不是“能不能”，而是“哪些地方必须改”。
为什么Django实例必须无状态
有状态的Django服务在扩缩容时会立刻出问题：比如用SESSION_ENGINE = 'django.contrib.sessions.backends.db'，用户登录后扩容一台新实例，后续请求被负载均衡打到新机器上，request.user就变AnonymousUser；再比如在内存里缓存了用户权限树，节点间不共享，AB测试或灰度发布时行为不一致。
- 所有会话必须走
Redis或Memcached，配置为'django.contrib.sessions.backends.cache'或'cached_db' -
STATIC_ROOT和MEDIA_ROOT不能由Django自己serve，必须交由Nginx或CDN托管，否则静态资源404率飙升 - 禁止在
models.py或views.py里用cache.get_or_set()耦合缓存逻辑——统一收口到services.py或自定义Manager
数据库与连接池怎么配才不拖垮后端
默认CONN_MAX_AGE = 0看似安全，实则让每个请求都新建DB连接，PG/MySQL连接数迅速打满；设太高又可能因连接空闲超时被中间件（如RDS Proxy）断开，抛OperationalError: server closed the connection unexpectedly。
- 推荐值：
CONN_MAX_AGE = 60（秒），配合PostgreSQL的tcp_keepalives_idle=60参数保活 - 连接池不在Django层做，而是在
pgbouncer或mysql-proxy侧统一管理，Django只当短连接用 - 避免在
__init__.py或AppConfig.ready()里执行Model.objects.all()类的全表扫描——启动阶段就可能卡住整个实例
uWSGI + Nginx负载均衡的关键三行配置
很多团队用gunicorn --workers 4硬扛，结果某次慢查询把4个worker全堵死，整台机器不可用。uWSGI的--harakiri和--master才是生产级兜底手段。
立即学习“Python免费学习笔记（深入）”；
-
--master true：必须开启，否则无法热重载、无法限制进程生命周期 -
--harakiri 30：单个请求超过30秒强制kill，防慢SQL或第三方API阻塞整条worker链 -
--processes 4 --threads 2：比纯多进程更省内存，但要确认Django中间件没用threading.local存状态（4.x起已弃用） - 检查
uwsgi --version是否≥2.0.21：旧版本在SO_REUSEPORT下有FD泄漏，报too many open files
健康检查接口为什么总误杀正常实例
/health/返回200不代表服务真能干活——DB连得上、Redis却超时了，或者Celery Broker崩了，负载均衡器照样把流量切过去。
- 检查项必须并行执行：
db.connection.is_usable()、cache.ping()、celery_app.control.inspect().ping() - 超时统一设为
2s，任一失败就返回503，别用try/except吞掉底层异常 - 加
CacheKeyPrefix字段，比如CACHES['default']['KEY_PREFIX'] = 'v3'，升级时不用清空全库，避免雪崩式回源
最常被忽略的是时间同步——集群里任意两台Django机器时间差超过5分钟，JWT签名、缓存过期、Celery定时任务都会错乱。必须用chrony而非ntpd，且配置makestep 1.0 -1允许开机快速校准。
