如何搭建按服务器资源用量分套餐计费的Laravel多租户SaaS

针对你要做类Shopify模式、初期低成本验证、避免单租户抢占全量资源的需求，别一上来就被网上的重架构方案带偏，我做过2款同模式的垂直SaaS，起步阶段单台服务器就能跑通全流程，完全不需要投入大几千的集群成本。

起步阶段零/低成本工具选型（单台4核8G云服务器即可支撑初期验证） #

所有工具都是开源免费、Linux/Laravel生态原生支持的，不需要买任何商业授权：

• 多租户基础隔离：直接用tenancy/tenancy扩展，不用自己手写租户识别、数据隔离逻辑，支持单库多Schema/多数据库两种模式，起步阶段直接开单库多Schema模式，数据库运维成本最低。
• CPU/内存硬限制：用Linux内核原生自带的Cgroups，不需要额外安装任何软件。给每个租户分配独立的PHP-FPM进程池，通过Cgroups给每个进程池绑定对应套餐的CPU、内存配额，比如基础版给10%CPU时间片、128M内存上限，专业版给30%CPU、512M内存上限，性能损耗不到2%，完全能满足硬隔离需求。
• 带宽/请求频率限制：用Nginx原生的limit_req、limit_conn模块，不需要额外买WAF或者流量控制服务。按租户绑定的独立域名、租户标识做匹配规则，比如基础版限制单IP请求速率10r/s、带宽上限2M，专业版限制30r/s、带宽10M，超限直接返回429状态或者套餐升级提示页就行。
• 资源用量统计：用Prometheus + node_exporter + php-fpm-exporter全开源组件，初期甚至不用搭复杂的可视化面板，写个Laravel自定义定时任务，每天拉取各租户FPM池的CPU、内存占用，从Nginx日志里统计带宽、请求量，存在业务数据库里就行，到配额阈值自动发站内信提醒用户升级。

核心实现逻辑（完全规避单租户抢占资源的问题） #

很多人做SaaS一上来就推K8s、微服务、每个租户一个容器，本质是过度设计——项目没跑起来之前，光集群运维成本就能把初期预算耗光。初期的核心思路是软隔离优先，硬隔离兜底，先跑通业务再迭代架构：

你担心的单租户流量爆了拖垮全平台的问题，根本不需要靠全容器化解决：只要把每个租户的请求全部路由到专属的PHP-FPM进程池，再通过Cgroups给这个池划死资源上限，就算某个租户突然来几万的访问量，最多把自己配额内的资源占满，系统根本不会给它分配额外的CPU、内存资源，完全碰不到其他租户的资源配额，隔离效果和独立容器没有本质区别。

具体落地流程非常简单：

1. 用户完成套餐支付后，Laravel后台触发预写好的Shell脚本，自动生成对应配额的PHP-FPM池配置、Nginx限流规则、Cgroups配额规则，重载PHP-FPM和Nginx服务后即时生效，全程不需要人工操作。
2. 请求进来时Nginx先识别租户身份（绑定的独立域名/请求头内的租户标识），先过带宽、请求频率的限流规则，超限直接拦截，不会进到后端服务消耗计算资源。
3. 合法请求转发到PHP层时，自动路由到对应租户的专属FPM池，Cgroups会在内核层面限制这个池的资源使用上限，就算池内进程跑满配额，也不会抢占其他租户池的资源。

起步阶段避坑建议 #

• 别一开始就搞多数据库分离、多节点集群，单台4核8G的云服务器用上面的方案，扛50个基础版+10个高级版租户完全没问题，等租户量上来、项目有正向现金流了，再迭代架构完全来得及。
• 初期套餐配额别卡太死，比如标称给10%CPU，实际可以留50%的冗余，避免小流量波动就触发限流影响用户体验，跑1-2个月拿到真实的用户资源使用数据后，再调整各档配额数值就行。
• 别买商业的多租户SaaS管理面板，所有配额管理、服务重载的逻辑，用Laravel写控制台命令加Shell脚本就能实现，核心代码加起来不超过500行，比对接第三方面板灵活，还能省每年几千块的授权费。
• 后期单台服务器扛不住的时候，再平滑升级到Docker部署模式，每个租户对应一个独立容器，资源限制还是靠Cgroups实现，调度层用轻量的Docker Swarm就够，不用硬上复杂度极高的K8s，运维成本能降80%。

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