主要做二次元文创相关的,公司网站 m.huabbao.com
不说官话套话了,来个有大流量、高并发经验的后端开发
公司目前用 PHP 开发,打算往 go 上转型,希望你有相关的丰富经验
给我发简历,或者打电话都行
邮件:xiaozhen0801#hotmail.com
电话:18556970801
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 @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 @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
|