Laravel 如何将部分 api 一步步使用 golang 进行重构

2019-04-28 13:44:19 +08:00
 zjtsunshine

目前状况: 1 )有 2 台 8 核 16G 服务器,tps1000 多。

2 )使用 nginx+php-fpm+laravel。

3 ) php-fpm 进程占有的 cpu 较高,经常飙到 80%以上。

目前想一步步地将 laravel 上的 api 接口,逐步使用 golang 重构,并部署到生产环境,但又不影响生产环境功能的正常使用。比如今天先把某个使用频率较高的 api,重构成 golang,部署上去;明天再部署新的 api,一步步操作。

1 )如果使用 Laravel-Swoole 测试了下并发性能确实提到了几十倍,但是有很多坑,怕部署到生产环境出问题。。。

2 )若使用 golang 重构,是要在 nginx 中配置,当请求某个 api 的时候,给他转发到 go 服务器吗?有没有具体的教程,在网上没有找到了的解决方法,有没有大神求助下

7424 次点击
所在节点    程序员
76 条回复
runningman
2019-04-28 19:32:17 +08:00
@tanszhe one 你搞连接池没 为啥快呢 或者加你微信聊聊
zhchyu999
2019-04-28 19:39:32 +08:00
低配多台机器比高配更少太机器更好用
zjtsunshine
2019-04-28 20:27:35 +08:00
@namek 感谢
king2014
2019-04-28 21:35:30 +08:00
8 核几百并发就彪到 80%,听到也有点诧异
blless
2019-04-28 22:16:13 +08:00
php 不知道 不过 python 切换过来那个延迟跟 cpu 内存突然下降成一条直线简直不能再爽
dawniii
2019-04-28 22:16:19 +08:00
@snail404
@king2014 我去年压过 laravel,开启 opcache,关闭 session debug 等。 就两行代码,sleep 50ms 模拟业务耗时,然后直接返回 4kb 数据。 100 并发 cpu 就爆了,4 核心的机器。。。
xiaolanger
2019-04-28 23:22:48 +08:00
现在是越来越感觉,laravel 似乎有些臃肿?多余?
xiaotianhu
2019-04-28 23:43:47 +08:00
swoole+laravels 基本上没啥问题,性能提升很大
xiaotianhu
2019-04-28 23:44:25 +08:00
swoole+laravels 提升很大,稳定性也 ok 没啥问题.不放心的就启一个 fpm 实例,用负载均衡兜底.

我们线上就这么干了很久了.很爽.
2kCS5c0b0ITXE5k2
2019-04-28 23:48:30 +08:00
不是有 lumen 吗...
autogen
2019-04-29 01:49:55 +08:00
额。。。遇到点问题就想着换语言。。。。

tps1000 不算高,
php-fpm 占 CPU 高可能是 php-fpm.conf 配置不正确,

1. 可以考虑固定下 php-fpm 进程数:
> pm = static
> pm.max_children = 300

2. 关闭超时链接:
> request_terminate_timeout 10s

3. 记录 slow log:
> slowlog = logs/slow.log
> request_slowlog_timeout = 3s

4. 如果 slow log 太多,考虑代码问题(有没有用 cache,db 连接数,查看 sql slow query log,优化索引、查询语句等。。)

5. 在 php-fpm 前面加一层 nginx,把静态页面(html/js/css/jpg/gif/png)放到 nginx 和 CDN


-
nine
2019-04-29 06:29:19 +08:00
用 go 就没有坑了么?
虽然 7、8 年没用过 PHP 了,也没用过 laravel,但直觉告诉我,是你运维工作没做到位。
前年受人所托,优化了一个 PHP 线上业务,每天 2000 万+访问,简单优化后单台 4 核 VPS,CPU 平均负载 25%左右。业务框架是 ThinkPHP,代码几乎没动。
lestat
2019-04-29 07:39:41 +08:00
2c4g,laravel5.5+php-fpm 7.3,并发只能到 60 多,开了 opcache 之后的...不开只有不到 20...也在考虑怎么提升性能,之前用 laravels 没有解决 jwt 在多用户表切换时候的 token 解析错误的问题,先 mark 一下
Zhongwei
2019-04-29 08:53:25 +08:00
Laravel 对于 CPU 的占用确实高的离谱,即使开了 opcache 也没法满足要求。

建议后台管理部分继续使用 Laravel ;
API 接口按照调用的频繁程度,从高到低逐步替换成 Golang。
king2014
2019-04-29 08:54:13 +08:00
@lestat
@dawniii
额,看到你们这么说,laravel 这性能可以上生产环境吗?
klgd
2019-04-29 09:01:47 +08:00
没有分析是哪里的问题吗?我们线上也有 laravel 项目在跑,目前也没遇到你这样吃 cpu 的情况
我觉得找出问题点可能比你迁移更划算
flashrick
2019-04-29 09:09:44 +08:00
我觉得 laravel 就做后台管理不错 API 还是算了吧
hanzhao
2019-04-29 09:21:29 +08:00
我司有一个项目是使用 Laravel-Swoole 部署的,不过是全新做起来的,没遇到什么问题。3 台 4 核 8G 的服务器,常年 TPS 在 2000 左右。
triptipstop
2019-04-29 09:23:09 +08:00
17 年 1 核 1G 单机 生成二维码海报 2000W PV 高峰 1000 并发 瓶颈在 MySQL
线上跑的 Laravel 一万个总有吧 你这种问题 能算万一了
tanszhe
2019-04-29 09:23:30 +08:00
@runningman 有连接池啊,github 首页就是大概介绍。看一篇你应该就知道了,最下面有 qq

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/559457

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX