可以参考一下腾讯的专栏 https://cloud.tencent.com/developer/column/1196

1 、官方自带这个框架部署
2 、数据库不要放 Serverless 里，可以用云开发里的数据库，支持无线扩容（按量计费）
3 、是的，不用基本无费用。

另外抽奖放云函数上，场景十分契合。

关于 3 ，腾讯云 web 云函数没有请求自动下线的时限是 10 分钟，每 9 分钟请求一次的话，就可以保证有至少有一个实例永不下线，而且不收费（每 10 分钟只有发生请求的几十 ms 计费），然后就是腾讯云对于一个实例能同时处理多少个请求无法设置，如果想保持多台实例在线而且不收费可能困难比较大

laravel 装 laravel-s 插件，运行时不用 php-fpm ，用 swoole ，装环境 3 个小时就够，qps 可以从 100 提升到 1000 以上

后面开发还是用 php-fpm 的方式开发 laravel ，不要用协程，可以用 Timer 、Task 和 swoole table

最后再提醒切记不要开协程，用第三方包的时候记得看官网 wiki ，注意用好 Cleaner 就行了，Cleaner 工作基本就是把$app 里面的第三方 provider 安装的 singleton 删掉

至于部署的问题，目前最方便的方法是 Custom Runtime ，他们会给你一个基础的 Docker 镜像，你拉到子网里的一台测试机上，自行创建一个容器就能测试代码能不能运行，还能连你买的 redis 跟数据库。
最麻烦的是第三方库，由于 Custom Runtime 是指定特定版本解释器的，比如阿里云的 Python 就是 3.7.4 ，所以你用的库必须与这个版本兼容才行，而且有很多库自带了上 G 的.so 链接库，这些压根没法跟业务代码一起打包传上去(代码包一般限制是 100M 左右，如果库体积不大就可以一起打包)，只能通过云函数挂载文件系统，从文件系统里临时加载，这会让冷启动时间长达十几秒。
如果你用 Docker 镜像部署的话，这个镜像本身也会限制体积必须小于 1G ，我觉得还不如 Custom Runtime 。如果你用指定版本的 PHP Runtime ，它就不能上单实例多并发，我觉得没有单实例多并发，云函数的可用性就很差，你会遇到非常频繁的冷启动。

1.最近用了一下腾讯的云函数，感觉还不错，但我这个业务目前还只是测试阶段，流量非常小，还没有接受过真正的大流量的考验。

2.用云函数主要的改造是读写本地文件系统，如果写日志建议使用他们的日志服务，永久文件存储可以使用他们的对象存储。

3.云函数的主要优势是动态缩扩容实例，流量大就自动帮你增加实例数量，流量少又会自动减少，按需收费。

4.数据库是不能放进云函数里面的，即使你使用如 sqlite 之类的文件数据库，也没有意义，因为云函数默认是多实例的，云函数的部署包内有一个 512MB 的临时读写空间，但是那个空间会在实例销毁时自动销毁，所以云函数内部是无法保存数据的，保存数据需要使用外部的数据库服务、KV 存储或者文件存储等。

5.就算 web 层面云函数能给你无限扩容的能力，后面的数据库服务仍然会有压力，像秒杀类的突增型的访问，最好是用 Redis 之类的纯内存数据库。

19 年就开始玩 serverless 的回答一下：
1 ，云函数是无状态计算，能不能把什么框架部署上去主要看你能不能把它改造成无状态计算的模式。比如说 session 就不能用本地内存而是得存到 redis 里，这台 redis 你就得单独买以配合云函数使用，否则 session 功能压根上不了云函数。所有依赖有状态计算依赖的功能都得改造成外置到中间件这种模式
2 ，腾讯云有 serverless 数据库，你可以了解一下，可以跟云函数配套使用
3 ，没问题，但是如果你一点钱也不付的话，0->1 的冷启动会卡住好几秒，不过这个可以通过保活脚本缓解(目前云函数不限制你用这种方法达到跟收费的预留实例一样的效果)

1. 这个场景确实比较适合 Serverless ，用什么框架是次要的，我试过 AWS lambda 部署 NodeJS serverless ，自动扩容很快。
2. 当前没办法把数据库也放进 Serverless 中，因为你的交易结果要持久化的。
但是市面上有 Serverless 的数据库可以供你使用，比如 AWS 有 DynamoDB / Aurora serverless / Keyspaces (cassandra compatible)，没有请求不收钱的，超大流量请求来了也能扛得住。
建议你了解下腾讯云是否有类似 Serverless 数据库方案，或者临时提高磁盘 IOPS 的方法，前提是你的瓶颈在磁盘上，或你的架构可以将下单转化为写入。
3. 上面说的就是免费运行

什么配置？

并发瓶颈是什么呢？ 500 qps 估计应该不是 service 层而是数据库的问题。
如果是数据库问题那用 serverless 的意义不大。
就算是 service 层问题，更简单有效的方式应该是搞个 cronjob 在抽奖之前执行扩容任务，因为抽奖时间应该是可以提前知道的？

500 并发只靠数据库不好抗吧，用上 redis 呢