传统框架迁移FaaS的两种部署方案

把Django、PHP等传统Web框架整体迁移到FaaS平台时，代码和依赖的存放位置有两种取舍相反的方案： 一种是像常规函数一样把代码和全部依赖打包进函数包，优点是保留版本控制、灰度发布等FaaS原生能力， 但依赖越装越多会导致包体积膨胀，进而拖慢[[代码包体积影响冷启动时长]]，而且SQLite、文件上传这类 依赖本地磁盘持久化的操作，会撞上FaaS的无状态限制；另一种是把代码和依赖整体托管到NAS等持久化 存储，函数本身只保留一个极薄的转发入口，优点是完整保留了框架原有的本地文件系统语义（SQLite、 文件上传不用改造），包体积小、冷启动快、改代码只需增量同步NAS，代价是函数包和代码解耦后version control、灰度发布这些FaaS原生能力随之失效。发散：这本质上是”紧耦合部署换原生能力，松耦合部署 换兼容性和体积”的取舍，选择取决于迁移的遗留系统对本地文件系统语义的依赖程度有多深。