单服务器部署多个Laravel应用的组织方案及优劣势咨询

各方案优缺点分析 #

方案1：单应用对应独立Laravel项目，分目录存放 #

• 优点
  • 应用完全物理隔离，不同应用的Laravel版本、依赖包、配置规则互不干扰，单个应用的故障不会波及其他应用
  • 迭代上线完全独立，不需要考虑其他应用的兼容问题，问题排查定位成本极低
  • 权限管控灵活，可针对单个应用的代码仓库单独设置开发权限，应用迁移、下线操作简单，无耦合成本
• 缺点
  • 存储占用高，每个项目都有完整的Laravel框架和重复依赖包，数十款应用的场景下会浪费大量存储空间
  • 运维成本高，每个应用需要单独配置Nginx规则、队列、定时任务，框架版本升级需要逐个项目修改，重复工作量极大

方案2：单Laravel项目内新增src目录，各应用对应src下独立子目录 #

• 优点
  • 所有应用共享同一套Laravel核心框架和公共依赖，存储占用极低
  • 仅需要维护一套运维配置，公共能力（用户认证、日志、缓存组件等）可统一封装复用，框架版本升级仅需要修改一次
• 缺点
  • 无应用隔离能力，单个应用的代码bug、内存泄漏会导致所有应用不可用
  • 所有应用必须兼容同一套Laravel版本和依赖版本，无法满足特殊应用的版本要求
  • 全量发布时任意应用的代码问题都会导致整个项目上线失败，开发权限无法细粒度管控，容易出现误改其他应用代码的问题
  • 应用数量超过10个后，项目目录会非常臃肿，路由、服务提供者的加载逻辑会变得复杂混乱

方案3：各应用封装为独立Composer库，主Laravel项目按需引入依赖 #

• 优点
  • 继承方案二的低存储、低重复运维、公共能力复用的优势
  • 应用代码独立封装、版本管理清晰，增删应用仅需要修改composer.json依赖配置，不需要改动主项目核心代码
  • 可针对单个应用的代码仓库单独设置开发权限，单个应用迭代不需要修改主项目代码
• 缺点
  • 主项目和所有应用库仍需兼容同一套Laravel版本和公共依赖版本，版本冲突问题无法避免
  • 开发调试流程复杂，修改应用代码后需要先发布包版本再拉取到主项目，或本地配置软链接，调试成本高于前两种方案
  • 跨应用问题排查需要同时核对主项目和对应依赖库的代码，排查成本更高

方案4：按属性分组应用，每个分组对应一个Laravel项目托管组内多个应用 #

• 优点
  • 平衡了隔离性和复用性：业务关联强、依赖版本一致的应用放到同一分组内共享框架能力，不同分组之间完全物理隔离，故障不会跨组传导
  • 灵活性高，不同分组可使用不同的Laravel版本，满足不同应用的技术要求
  • 运维成本远低于全独立项目的方案，单个分组内的应用数量可控，不会出现单项目过度臃肿的问题
• 缺点
  • 前期需要做好业务分组规划，后续应用跨组迁移的成本较高
  • 每个分组需要单独配置运维规则，运维成本略高于单项目方案

场景最优选型建议 #

针对「初期少量应用，后续扩展到数十款，绝大多数为Laravel项目」的场景，最优方案是方案4，分组规则可参考以下维度：

1. 按业务线划分：同一条业务线的应用放到同一分组，方便公共业务能力复用
2. 按版本要求划分：需要使用新版本Laravel特性的应用为一组，需要兼容老版本框架的应用为一组
3. 按流量等级划分：高流量核心应用单独分组，低流量内部工具类应用放到同一分组，避免低优先级应用的故障影响核心业务

如果初期团队规模小、应用数量少于5个，可先采用方案2快速落地，后续应用数量增长后再迭代为分组托管的方案4；如果对应用的权限管控、独立迭代要求高，也可以在单个分组项目内结合方案3的逻辑，将组内应用封装为Composer库引入，进一步降低耦合。

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