大并发下 PHP +Laravel 的部署架构应该是怎样的？

[HaroldChen]

背景：

1. 公司的开发语言是 PHP, 大部分业务是 php7+laravel5, 小部分是 php5+laravel4。
2. 电商类，日常 tcp 并发连接在 1.5W 左右，赶上活动，tcp 连接数短时间会达到 10W+。现在是靠机器去堆，但高峰期还是会看到 php-fpm 经常 cpu 100%,且 php-fpm 的端口健康检测失败。已排除数据库层面的问题。xhprof 之类的代码分析目前暂时没精力去看，以后会关注。
3. 目前正在进行服务化，已经拆出的服务数量在 10 个左右。

目前部署的架构是每个服务都购买单独的服务器（访问量最大的一个业务，用了 20 台左右的服务器支撑），每台服务器上面部署 Openresty + php-fpm，代码也在每台服务器发布。

现在其实每台服务器的冗余比较严重，非高峰期的负载不需要这么多服务器。所以考虑换一种方式，前端负载均衡（阿里云 SLB ） -> Openresty 集群（每台上都有所有业务域名的配置文件） -> php-fpm 集群 ，每台服务器只负责一个服务的运行。并发量大的时候直接扩容 php-fpm 服务器的个数。

问题：

1. 想请教下，这种部署方式有问题吗？现在主流的部署结构是怎样的？
2. 以前的那种部署方式，哪里支撑不住只会影响单个业务。现在这种部署方式如果并发上来，怎么去判断是哪个业务造成的?（查看各个业务的 pv 和 qps?）
3. 目前也在进行容器化的改造，想问下 php 部署一般是什么形式，sidecar?

[jowan]

可以尝试下抛弃 php-fpm 使用 Swoole 加速一下 Laravel qps 会有很明显的提升
第三方包有 LaravelS 无侵入式的 成本最小

[mamahaha]

很多服务器不是可以按小时计费吗？高峰期加点按小时计费的啊。

[KgM4gLtF0shViDH3]

用 go 重构😏

[Varobjs]

好奇这么重大的决定，会让一个到 v2 上找解决方案的人来搞吗，/233

[RickyC]

@Varobjs 没有不可能。你知道楼主是谁。

[xrlin]

并发量这么大？哪家大公司？

[HaroldChen]

@mamahaha 现在考虑的是上述两种部署方式怎么去选。

[HaroldChen]

@Varobjs 哈哈，只是想拓宽一下思路，看看大家怎么做的，取长补短。

[HaroldChen]

@jowan thx，从语言框架上优化性能短期可能不会考虑。部署的思路上面有推荐吗？

[myvyang]

1. 负载均衡的集群挂了的话会导致全部业务挂掉。因为负载均衡集群的配置都是 copy 的，某些 BUG 会导致全部 hang 住。但是应该大公司业务都走这种模式的，方便管控。

2. 查看各个业务的 pv 和 qps? 每个服务的 API 记录下调用量，做个大盘，除了看请求的暴增，更有意义的是，如果交易下跌，可以立马看到是哪出了问题。

[Immortal]

好奇你们这边数据库的架构
前面 20 台 php
那数据库呢 几台 主从和缓存架构

[dylan]

用 Docker 集群部署。或者做阿里云的 ECS 自动化部署，需要的时候就自动增加服务器。

[polymerdg]

比較好奇 數據層 是怎麼設計的 一般幷發問題 瓶頸都在數據層

[sagaxu]

不要问，问就是够浪

[realpg]

@Varobjs #4
人家也是有一系列备选方案的 只是上来问问其他类似经验的 哪种好 有什么坑
而不是纯按照 V2 内容来做

[HaroldChen]

@myvyang thx, 我也觉得集群模式方便管理及扩缩容。服务器上基础组件的版本都是一致且运行了很长时间的，所以 bug 这个问题就不在考虑范围内了。

[yzhfd]

单台服务器的极限是多少？我觉得架构是其次的，主要是看瓶颈在哪？有针对性的优化。 如果是活动的话，10W 的并发，是否考虑用缓存中间件？个人感觉 20 台机器是有一定浪费的。

[HaroldChen]

@realpg 谢谢理解，您说的对。想看看大家遇到这类问题时会怎么考虑，每一句话都可能是一个新的思路。

[realpg]

@HaroldChen #18
这么大规模还用 laravel 真不如 java 了……
我一直是反 laravel 这种重型框架的 真要这么开发还不如用 java 去 性能更高 轮子更多 开发更快
把 PHP 的优点严重抑制 弄得更像别人

[HaroldChen]

@yzhfd thx，性能分析这块确实要做。每次并发量上来，php-fpm 一定是 cpu 100%的。缓存目前涉及到的有 cdn, lua, opcache, redis。