如何将部署在AWS Lambda的Django项目拆分为独立微服务Lambda函数

DevOps 小满

2026-10-9

整体采用「Lambda Layers共享公共代码+各业务Lambda独立打包独有逻辑」的方案，保留Django原有应用规范，最小化改造成本的同时满足拆分部署的需求。

1. 模型共享方案与Lambda Layers合理性

Lambda Layers是该场景下的最优方案，你之前的报错本质是Django无法识别未注册应用、未声明app_label的模型类，按以下规则调整即可解决：

python/
├── user_onboarding/
│   ├── __init__.py
│   └── models.py
└── user_training/
    ├── __init__.py
    └── models.py

class OnboardingRecord(models.Model):
    # 自定义字段
    class Meta:
        app_label = 'user_onboarding'
        # 其余原有Meta配置

在每个Lambda的INSTALLED_APPS中注册用到的应用，比如user_onboarding的Lambda需要注册user_onboarding，如果依赖user_training的外键模型，也需要同步注册user_training。

其他可选方案如两边各维护一份模型代码，会大幅提升维护成本，极易出现字段不一致的问题，不推荐使用。

采用「公共配置抽Layer + 独有配置本地保留」的混合方案最优：

把所有公共配置（数据库连接、DRF全局配置、公共中间件、公共INSTALLED_APPS项）抽成base_settings.py放到Layers的公共配置目录下
每个Lambda各自保留一份自己的settings.py，开头导入公共配置from common_config.base_settings import *，再补充各自独有的配置（比如专属URL路由、独有中间件、专属APP注册项等）

该方案既避免了公共配置重复维护的问题，又保留了各Lambda的配置灵活性。

不要在拆分后的Lambda中处理迁移，单独维护一套完整的全量代码库（包含两个应用所有模型），作为专门的迁移执行入口：

迁移操作统一在本地开发环境或者CI/CD的专用流程节点执行，执行标准的python manage.py makemigrations和python manage.py migrate命令
迁移流程独立于Lambda的部署流程，只在模型变更时执行，只要Layers中的模型代码和迁移用的全量代码库的模型保持一致，就不会出现ORM不兼容的问题。

如果强行在单个Lambda中执行迁移，会因为缺少关联模型的代码，生成错误的迁移文件，导致外键关联异常。

两个Lambda共享同一个数据库实例的前提下，做以下优化：

配置数据库连接复用：在settings中设置CONN_MAX_AGE = 60（取值略大于Lambda的函数超时时间即可），避免每次函数调用都重新建立数据库连接，降低冷启动耗时
对接数据库代理：如果使用AWS RDS作为数据库，建议开启RDS Proxy，统一管理所有Lambda的数据库连接，避免并发请求量过高时打满数据库连接池
权限隔离（可选）：给两个Lambda分别创建独立的数据库用户，只开放对应业务表的读写权限，提升数据安全性。

如果有跨应用使用的通用序列化器、公共工具函数，也可以一并打到Lambda Layers中共享，避免重复开发。

内容的提问来源于stack exchange，提问作者dhananjay