• 外包信息请发到 /go/outsourcing 节点。
• 不要把相同的信息发到不同的节点
这是一个创建于 1219 天前的主题，其中的信息可能已经有所发展或是发生改变。
主要做二次元文创相关的，公司网站 m.huabbao.com
不说官话套话了，来个有大流量、高并发经验的后端开发
公司目前用 PHP 开发，打算往 go 上转型，希望你有相关的丰富经验
给我发简历，或者打电话都行
邮件：xiaozhen0801#hotmail.com
电话：18556970801
第 1 条附言 · 2021-08-03 19:04:33 +08:00
虚心接受大家关于 PHP 在高并发情况下的优化
目前用的 K8S 来管理服务器，平台的玩法就注定每天或者几天就会有一个流量高峰，平时几十 QPS，高峰期间就会到 8000QPS 左右。PHP 每次都会打包成镜像，所以不需要检测文件变化，Opcache 基本上调到最优了。fpm 的一些配置也经过一年多的调试，基本上处于最优状态。
同样有负载均衡，数据库和缓存都是阿里云的集群。
慢查询一直在优化，很多张千万级别的数据表，目前整体查询性能都还行，该用缓存的都用缓存了，能走消息队列慢慢消费的，也走消息队列。
高峰期动态扩容到 50 核心，100g 内存，勉勉强强够用，后面的流量只会更高，1-2W 的 QPS 也就是近两个月的事。
有更适合的语言难道不该选择？不了解具体情况何必冷嘲热讽呢？小厂就不能有流量了？
目前用的 K8S 来管理服务器，平台的玩法就注定每天或者几天就会有一个流量高峰，平时几十 QPS，高峰期间就会到 8000QPS 左右。PHP 每次都会打包成镜像，所以不需要检测文件变化，Opcache 基本上调到最优了。fpm 的一些配置也经过一年多的调试，基本上处于最优状态。
同样有负载均衡，数据库和缓存都是阿里云的集群。
慢查询一直在优化，很多张千万级别的数据表，目前整体查询性能都还行，该用缓存的都用缓存了，能走消息队列慢慢消费的，也走消息队列。
高峰期动态扩容到 50 核心，100g 内存，勉勉强强够用，后面的流量只会更高，1-2W 的 QPS 也就是近两个月的事。
有更适合的语言难道不该选择？不了解具体情况何必冷嘲热讽呢？小厂就不能有流量了？
第 2 条附言 · 2021-08-04 15:17:39 +08:00
谢谢大家的一些指导，确实给我提供了不同的思路。
我的错，我本意并不想讨论太多关于语言、架构、性能方面的争吵，我就想招个开发，无论用什么方案，招人肯定是优先的。
我的错，我本意并不想讨论太多关于语言、架构、性能方面的争吵，我就想招个开发，无论用什么方案，招人肯定是优先的。
 |
1
codespots 2021-08-03 17:15:27 +08:00
有这个钱加服务器就好了
|
 |
2
hahasong 2021-08-03 17:25:34 +08:00
别人转 go 是为了微服务 和 K8s，小厂的业务，Php 完全可以胜任，支持 1L
|
 |
3
slideclick 2021-08-03 17:48:11 +08:00
这论坛好就好在大家回帖都是技术...话说现在 phper 都在学 golang 抛弃 php 所以人肉提高性能也行
|
 |
4
Rwing 2021-08-03 17:54:31 +08:00  1
太多不懂的技术的人来把控技术了，以为 go 在国内炒的热就要上 go 。以为上了 go 就牛逼加加了。
其实纯粹的业务系统上了 go 只会开发效率减减 |
 |
5
satoru 2021-08-03 18:44:42 +08:00
PHP 是世界上最好的编程语言
如果你说要转去别的语言 世界上最好的程序员就感觉被冒犯了呀 |
 |
6
xiaoshouchen OP @codespots 服务器也加，但是瞬间流量确实高，一小时，2000-3000w 的接口调用
|
|
7
xiaoshouchen OP @hahasong 小厂是小厂，但是目前用的是 k8s，高峰 7000-8000 的 QPS，PHP 真的不好撑住，ECI 动态扩容到 50 核心，100g 了，该卡还是卡
|
|
8
xiaoshouchen OP @satoru 写了 6，7 年的 PHP，go 确实比 PHP 适合高并发
|
|
9
xiaoshouchen OP @Rwing PHP 适合高并发吗？就算有 Swoole 之类的，遇到底层 bug 的时候，喊韩天峰去解决么？从 PHP 转 Java 成本高，还是 Golang 成本高呢？ Spring 那一套写业务不慢吗？
|
|
10
xiaoshouchen OP 1
@satoru 为什么要非此即彼呢？既用 PHP，也用 Go 不行么？需要高并发的用 Golang，普通的接口用 PHP，尤其是后台管理系统之类的
|
 |
11
sadfQED2 2021-08-03 19:32:34 +08:00 via Android
优化没问题，只是机器没加够，我们目前跟你们差不多的流量，线上近 1000 台容器实例。（我们优化还没你们好，但是业务营收足够，也没人在乎这点服务器开销）
|
|
12
xiaoshouchen OP @sadfQED2 一千台？这么多，那得等到我们明年下一轮融资进来才付得起。那数据库和缓存呢？消息队列，ES 之类的，都是啥样的配置？
|
|
13
xiaoshouchen OP @sadfQED2 我们没有专门的运维，现在管理个几十台服务器，就已经很吃力了。人要一个个招，只能一步步来。
|
|
14
sadfQED2 2021-08-03 20:07:52 +08:00 via Android
@xiaoshouchen 基本上都是上百台起步
|
|
15
sadfQED2 2021-08-03 20:11:54 +08:00 via Android 1
我们现在也在往 go 迁移，但是个人觉得意义不大，大家刷 kpi 的收益大于性能提升收益
|
 |
16
airqj 2021-08-03 20:15:29 +08:00
workerman/webman 可以考虑看看，迁移成本应该比 Go 低
|
 |
17
guoer 2021-08-03 20:15:41 +08:00
招人转型可能来不及，找个外部专家调优下吧。
|
 |
18
shoaly 2021-08-03 20:18:53 +08:00
说语言太泛了, 可以说一个具体的高并发的例子, 会聊到更细节的点上, 方案也好给一些, 说不定 php 也就搞定了
|
 |
19
evefree2 2021-08-03 20:20:31 +08:00 via Android
我有 php 大流量经验
|
|
20
xiaoshouchen OP 1
@sadfQED2 没办法，你相信我一个人带着一个外包，扛过了几次日千万 PV，现在才慢慢加人，小厂招人确实难。
就这样还是经常挨批，服务器超过 5000QPS 就卡，8000 基本上就死掉了。 我既要写 PHP，又要写 Go，还要写 K8s 配置文件，Dockerfile，管运维。 所以比加服务器，我需要招人，哪怕是写业务啊，人手不够用啊 |
 |
21
vjnjc 2021-08-03 20:22:16 +08:00 1
支持楼主，还是趁早换了。php 单个请求处理速度不算太慢，但是高并发不行，因为他的哲学是一个请求一个 thread，应用内并没有 thread 概念。
|
|
22
xiaoshouchen OP @airqj 常驻内存型的 PHP 扩展都了解过，说实话门槛都不低，而且担心维护的事情
|
|
23
xiaoshouchen OP @evefree2 简历拿来
|
|
24
xiaoshouchen OP @guoer go 的框架已经在用了，我预期一年左右能转移个 80%就不错了，主要还是人手不够用，有兴趣的话，简历投过来
|
|
25
evefree2 2021-08-03 20:27:35 +08:00 via Android
@xiaoshouchen 在深圳呢
|
|
26
xiaoshouchen OP @vjnjc PHP 加上缓存和一些优化，大部分接口都能控制在 100ms 以内，单个请求的响应时间还是挺快的。也有一些历史接口，从空表到千万数据，SQL 查的慢的离谱，要好几秒甚至到十几秒的，好在这种地方并发量不高，勉强还可以维持
|
 |
27
shuimugan 2021-08-03 20:46:06 +08:00 1
你这种情况直接应用打包到 docker 在阿里云的函数计算里面跑,弹性伸缩点几下配置就差不多了.不知道数据库慢查询情况如何,有钱就升个 PolarDB 试试咯.
Opcache 调到最优应该就是缓存永不过期了,这都抗不下那也没办法.个人经验用 Yii2 框架,在缓存到极致时 4 核情况大概能抗 800. 当然像 PHP-FPM 这种一个进程抗一个请求,就算配置进程池 200 个,都在等 IO 时,第 201 请求进来时就傻逼了,换非阻塞框架还是比较正确的. 个人的经验来说 PHP 转 Node.js 速度是最快的,Node.js 里像 Laravel 的框架有 AdonisJS,像 SpringBoot 的框架有 Nest.js,像 Yii2 的 ORM 有 TypeOrm,用 JavaScript 实现的 PHP 函数库有 https://github.com/locutusjs/locutus ,带团队基本上两三天就能上手了. |
|
28
xiaoshouchen OP @shuimugan 现在用的就是 PolarDb 的集群，慢日志整体都正常，主要的瓶颈出现在 PHP 上面，PHP 的高并发真的是不行
|
|
29
xiaoshouchen OP 兄弟姐妹们，有觉得可以的，简历投过来呀。期待一起把事情做好
|
 |
30
Actrace 2021-08-03 22:22:41 +08:00 3
作为 PHP + Go 的双重开发，我不建议你把业务往 Go 上面转。PHP 本身是具备弹性扩展能力的，性能相比 Go 也不差。语言只能解决场景问题，架构才能解决性能问题。
就目前而言，你实际上缺的是一个 PHP 架构师。 |
|
31
xiaoshouchen OP @Actrace 哥们有兴趣过来吗？
|
 |
32
danhahaha 2021-08-03 22:44:15 +08:00
长痛不如短痛，早转吧，省下的服务器资源也够招人了
|
 |
33
ArJun 2021-08-03 22:52:08 +08:00
GO 写业务要比 PHP 慢三分之一吧
|
|
34
xiaoshouchen OP @ArJun 旧的系统用的 TP 写的，整体代码质量很低，改起来很累，加个功能会经常出问题。举个例子，golang 可以传结构体，PHP 只能传 array，不写清楚 array 里的字段，下次改的时候，都不能一下子确定传参有哪些值。还有返回前端的数字，有时候是 int，有时候是 string，就还挺痛苦的，虽然是使用者自己挖的坑，但是在 go 上可以避免这种问题
|
|
35
airqj 2021-08-03 23:17:46 +08:00
@xiaoshouchen workerman/webman 上手太简单了，看一下文档就可以了....
非要迁移的话，感觉可以先把瓶颈接口用 Go 改掉 |
 |
36
thomaspaine 2021-08-03 23:33:01 +08:00
@xiaoshouchen 兄弟我和你说句实话，青蛙太抠，老想着招一个人就能解决问题，另外这个招聘你能拍板吗？怕不是到时候聊好了又觉得贵，不过业务发展蛮好的，不然也不会有这个问题了
|
|
37
Actrace 2021-08-04 00:25:08 +08:00 1
@xiaoshouchen https://www.php.net/manual/zh/functions.arguments.php
关于传参，PHP 的花样比你想象的还要多，实际上也可以加入类型限定，你甚至可以传一个对象，对象中设定好成员属性。唉。建议好好看看文档。 |
 |
38
x940727 2021-08-04 00:32:23 +08:00
恕我直言，如果真的大流量还是用 Java 吧……Go 的 GC 只是 low pause 上比较强，如果论吞吐量的话，被 Java 吊起来打。不过我很好奇，50C 100G 的内存，只用来对付 8000QPS 是不是有点大材小用了……
|
|
39
x940727 2021-08-04 00:36:32 +08:00
我们公司应用服务器 8C32G 2 台，数据库 4C8G 的，阿里云的控制台看 QPS 峰值 4500，全天平均 2200 左右，O2O 业务。我觉得 50C100G+一个 16C64G 的读写分离的数据库，缓存设计好点，数据库查询都走索引，抗个五万 QPS 不是问题吧，尤其是还有阿里云的负载均衡，直接带宽拉满都能处理的过来。
|
 |
40
mifar 2021-08-04 00:46:49 +08:00
LZ 在滨江哪里想来拜访一下
|
 |
41
chenqh 2021-08-04 00:58:20 +08:00
只能说羡慕 8K tps
|
|
43
satoru 2021-08-04 07:12:17 +08:00
@xiaoshouchen 忘记加 doge 了
|
 |
44
jswh 2021-08-04 08:29:37 +08:00 2
@Actrace 甚至还能传引用 （笑
看了楼主的描述，我觉得，不如再加 10k，招两个 PHP 写业务，自己来处理转型的事情。 运维可以看看 https://milletcode.com/ 前同事的产品 |
 |
45
yekern 2021-08-04 08:38:01 +08:00
像这种高并发语言出现瓶颈 不是单纯换一个语言就可以解决的, 建议还是找个架构师. 现在可以给没个接口加统计, 统计哪些接口是高并发,然后用 GO 重新构建这些接口. 可以看一下 任何一个大流量网站都不是靠一门语言就能搞定的.
|
 |
46
NjcyNzMzNDQ3 2021-08-04 09:25:47 +08:00
跟这几位的观点一样。 #4 #10 #45
golang 就那么几个函数，写业务，调试很痛苦。 并发高的接口不会特别多吧。。 单拿出来换 go 不是最快最好的方法吗？ |
 |
47
dongtingyue 2021-08-04 09:31:05 +08:00
工资好高呀，刚好两个都会但是不在杭州，想了解下会哪些可以拿这工资？
|
 |
48
wangyzj 2021-08-04 09:32:07 +08:00
我觉得转 go 需要 2-3 个月
2-3 个月去优化 PHP 也可能会有效果，比如慢查询 |
 |
49
Felldeadbird 2021-08-04 09:37:12 +08:00
如果在广州就好了。我可以速学 GO 。
|
 |
50
liuyibao 2021-08-04 09:37:41 +08:00
用 roadrunner 试试？
扛不住可能还是数据库和缓存处理的慢了，不能很快的结束请求 |
 |
51
wccc 2021-08-04 09:39:35 +08:00
没上 es?
|
 |
52
dwlovelife 2021-08-04 09:41:02 +08:00
@sadfQED2 高峰 QPS 7000-8000 正常 10 多台服务器就能搞定的，为啥要浪费 1000 台机器的成本干这事
|
|
53
liuyibao 2021-08-04 09:42:04 +08:00
@xiaoshouchen 试试用 phpstan 静态分析，你们这代码写太烂了，先尝试把 php 写好。go 写业务代码很伤的
旧的系统用的 TP 写的，整体代码质量很低，改起来很累，加个功能会经常出问题。举个例子，golang 可以传结构体，PHP 只能传 array，不写清楚 array 里的字段，下次改的时候，都不能一下子确定传参有哪些值。还有返回前端的数字，有时候是 int，有时候是 string，就还挺痛苦的，虽然是使用者自己挖的坑，但是在 go 上可以避免这种问题 |
 |
54
Evilk 2021-08-04 09:45:00 +08:00 1
过来人,浅谈一些建议
我们之前的情况跟你非常类似 1.php-fpm,有点扛不住 2.团队主战 PHP,换 go 成本远大于收益 3.换 swoole,担心出问题,没人能改 所以,最后,换的 webman(workerman 系列产品) 至少,目前,没有再遇到之前的问题了 |
 |
55
Co1a 2021-08-04 09:46:11 +08:00 via iPhone
我没记错的话飞猪哥 flypig 就是 PHP 转的 Go，招去带你体验 200 块的爱情啊🤪
|
|
56
ArJun 2021-08-04 09:47:07 +08:00
@xiaoshouchen 虽然这样说，但不太相信做二次元文创相关需要这么多机器来抗，是不是还有其他并发要求比较高的业务
|
 |
57
basefas 2021-08-04 09:57:24 +08:00 1
楼主可以不太在意劝你转不转语言的，既然用了 k8s，建议把高并发接口做简单的微服务，根据流量定时扩容。抛开 php 和 go 的性能不说，单纯启动程序的资源就少些，go 自己就是二进制，直接起，php 还要依赖 fpm 和 nginx 。
|
 |
58
fuxkcsdn 2021-08-04 10:06:13 +08:00 via iPhone
已经上 k8s 的话，直接堆机器拖个 2，3 个月，在这期间要优化还是转型都可以
php 这种堆机器就能横向拓展的，先堆起来，如果堆起来还是有瓶颈，那先看负载均衡是不是有问题，然后再看数据库，都没问题就再堆服务器 假设你堆到 100 核 200G 才能抗住，那你换语言也有个比较不是？拿对比数据给 boss 看不也更有说服力 |
|
60
xiaoshouchen OP @ArJun 有一个无料的概念，就是免费的周边，每个画师或者 IP 或定期给粉丝发福利，大的画师开个抽奖，流量立马就上来了，活动期间，一天上百个画师，摊开到每小时也有 10 来个画师同时发福利，所以瞬时流量高是很正常的，都要抢的
|
 |
61
php01 2021-08-04 10:26:33 +08:00
建议上云函数，或者先试下 RoadRunner 顶一下看看效果
|
 |
62
mosfet 2021-08-04 10:31:29 +08:00
转 JAVA 吧，杭州最不缺 JAVA 的
|
 |
63
yuandj 2021-08-04 10:54:54 +08:00
可以考虑下基于 swoole 扩展的 hyperf 框架，8 成能满足你们的需求，比 fpm 性能高的不止一两点，同是 PHP，迁移起来也方便。但话又说回来，感觉 go 也很香，但前期感觉只是新语言图个新鲜，可能是自己羡慕你们有机会从 PHP 转 go 吧，可以扩展个人的技术栈。
|
|
64
Rwing 2021-08-04 11:23:24 +08:00
纯粹的业务型系统 go 并不是更适合的语言啊
要说更适合，我推荐 C# 🙂 各大性能测试可以看看 |
 |
65
yoshiyuki 2021-08-04 11:27:30 +08:00
曾经建议过你们创始人一开始就用 go， 然而当时没有引起在意
|
 |
66
ccppgo 2021-08-04 11:27:42 +08:00
@xiaoshouchen #34 , 传 array 这个问题, PHP 也有对象啊, 甚至可以强制强类型, 没有那么夸张吧
|
|
68
yoshiyuki 2021-08-04 11:39:35 +08:00
@xiaoshouchen 你这个抽奖改成伪随机就行，参考微博抽奖的逻辑，有一部分用户，是注定抽不到这个奖的，在请求到达时就直接 return，并发压力自然小很多
|
|
70
xiaoshouchen OP @shoaly 看 APP 呀，功能都在 app 里，至于同行攻击，日志能看出来个大概的
|
|
71
xiaoshouchen OP 有人给我发了邮件，但是我回复被拒收了，我微信号就是手机，可以加我微信好友，谢谢大家的指导，但是无论什么方案，都需要有人实际去做，需求太多，进度太赶，需要招人来一起去解决。
|
|
72
sadfQED2 2021-08-04 12:16:59 +08:00 via Android
@dwlovelife 因为没人在乎这点资源，另外因为 10 多年的屎山代码太烂，能用 1000 台为什么要用十多台，出事故谁背锅
|
 |
73
yEhwG10ZJa83067x 2021-08-04 13:18:11 +08:00
我想请教下，在原有的基础上你转为 go 后能确保这几十台机器就能抗下这个并发吗？怎么判断是语言并发限制了你们？真心求教
|
 |
74
jhdxr 2021-08-04 15:00:57 +08:00
我来唱个反调，推荐 LZ 转。
从系统的角度来看，原来的实现上烂，如果想要给彻底重写找个借口，那就让语言 /框架背锅换一个，这是最省事的借口了 从个人角度来说，多掌握一门语言，或者至少去了解了解下思想，没坏处。 另外就 @xiaoshouchen 回帖里举的<del>抽奖</del>秒杀这个例子来说，只要你还在访问 RDBMS，换啥语言都没救。。。 |
|
75
xiaoshouchen OP @jhdxr 大部分逻辑走的 redis 和消息队列，但是有一些东西产品强制要求实时性，比如抽到的奖品需要支持分解，那么返回的时候就要给到抽奖记录 ID，那我必须生成抽奖记录，才能保证奖品可以正常分解，不然分解就可能存在问题。此时必须操作数据库，其他的比如积分可以用缓存，扣减的记录走队列更新数据库，特殊奖品的发放（不支持分解的）可以走队列。
|
|
76
jhdxr 2021-08-04 15:25:43 +08:00
@xiaoshouchen 先把配合业务一起去优化逻辑这一个方案放一边。『返回的时候就要给到抽奖记录 ID 』在我看来并不代表操作一定要实时入库，例如找个能保证唯一的算法生成，或者直接预先生成缓存里取，持久化的事情异步做。你如果担心用户领完奖马上分解以至于你异步操作还没完成（这用户手速真快，或者你们机器是不是都拿去前面顶着了异步就没资源了），那就分解那也顺便改改代码，不要光从数据库查，缓存也看一眼啊。。。
|
 |
77
barbery 2021-08-04 16:04:52 +08:00
高并发场景换 go 是正道
|
 |
79
alexkkaa 2021-08-06 15:57:51 +08:00 via Android
如果是为了业务稳定不如直接上 java
|
Select Language