现在的项目是标准的 PHPStack ,目前进入项目稳定期,准备对项目前端进行重构。
目标:高性能,高可用,可扩展
目前团队只有 PHP 基础,核心业务的重构准备用其它语言实现。
现在进入选择艰难,求推荐一个坑。
1
vibbow 2016-05-16 11:05:11 +08:00 via Android
为什么 不考虑 一下 c# 呢……
|
2
looyao 2016-05-16 11:08:09 +08:00 1
为何要重构呢,有什么性能瓶颈么?还是其他因素?
|
3
hcymk2 2016-05-16 11:08:53 +08:00
只有 PHP 基础。。。。其实换语言也一样。
|
4
yangqi 2016-05-16 11:09:44 +08:00
只有 php 基础还想着用别的语言?闲的没事情做了,瞎折腾?
|
5
Moker 2016-05-16 11:09:44 +08:00
重构前端?那还是直接 Node.js 吧
|
6
chunzhenniandai 2016-05-16 11:09:48 +08:00
不作死就不会死
|
7
sun2920989 2016-05-16 11:13:20 +08:00
想好重构的出发点是什么,是否有除了重构外其他的方法,另外你这个应该叫重写 2333
|
8
vus520 OP 现在遇到性能瓶颈了,一个业务的后端机器有 8 台,未来扩展只能通过加机器来解决。
目前压力都在缓存上,业务输出算是 CPU 密集型,加解密压缩之类的,想在这一层换成其它语言来解决。 还有一块业务, php 中存在重复的计算周期,想通过内存共享来解决,减少重复计算。 考虑用其它语言的原因 1 , php 做了很久,业务也越来越复杂,也许其它语言有更好的方案 2 ,有时间,团队可以学点新东西,团队里的人各自有一些不同的语言经验,但不统一,想挑一个统一的语言来一起学习 |
9
vus520 OP @sun2920989 目的是能应付更高的请求,应付更高的平发
|
10
sun2920989 2016-05-16 11:20:56 +08:00
@vus520 目的很明确,如果没有除了换语言重写外的其他方法,就做吧,CPU 密集的话 node 貌似不如 GO,无责任瞎说,最好多求证一下
|
11
vus520 OP @sun2920989 个人比较看好 Node 或者说 js 未来的发展,顺道多积累点前端的开发,所以想入坑,不知道这样想是不是比较矫情
|
12
sun2920989 2016-05-16 11:25:25 +08:00
@vus520 主要是我记得 CPU 密集型不是 Node 的强项,你再查查资料好了,我也不敢确定
|
13
dofy 2016-05-16 11:26:57 +08:00
优化跟语言无关
PHP 是最好的语言,没必要换。 |
14
likezun 2016-05-16 11:27:29 +08:00
目前团队只有 PHP 基础,核心业务的重构准备用其它语言实现。 —— 这句就是第一个坑 , 后面有无数个。。。
|
15
thinkif 2016-05-16 11:30:18 +08:00
从实用的角度来说:挖掘一下现有 PHP 代码的潜力,而不是在一个只有 PHP 基础的团队推其他语言。
|
16
stabc 2016-05-16 11:31:25 +08:00
nodejs 不适合复杂的业务逻辑。
|
17
jedyu 2016-05-16 11:33:53 +08:00 1
为什么不先尝试一下 PHP 扩展呢?
|
18
kikyous 2016-05-16 11:35:40 +08:00 via Android
比 facebook 复杂?
|
19
sox 2016-05-16 11:36:46 +08:00 via Android
你熟悉什么用什么😊
|
20
plqws 2016-05-16 11:43:13 +08:00 via Android
Java
|
21
doublleft 2016-05-16 11:45:55 +08:00
看你们现在拿 php 来做什么了。
像你说的场景可以做离线计算,访问分层处理。用 java 之类的重构成后端,把 php 只当作前端解析模板之类的。而且这样的话方便真对业务场景快速切换前端环境, node 还是 php 还是 go 想换就换。 但不管换啥 不要把所有东西都压在一个上面,既处理请求,又操作数据库,又来做什么加解密的 |
22
ipconfiger 2016-05-16 11:47:03 +08:00
CPU 密集部分用 C++或者 C 写 PHP 的扩展模块嘛
|
23
libotony 2016-05-16 11:47:24 +08:00
Node.js 不适合做 CPU 密集型的应用,我觉得你现在的问题要在架构上做优化,或者用 Node 做胶水层,后端用 PHP 或者其他计算能力更优的语言
|
24
tabris17 2016-05-16 11:48:29 +08:00
为了重构而重构?
|
25
jhdxr 2016-05-16 11:50:56 +08:00
1. 不管用什么语言,你业务到了一定规模以后堆机器是必然的。架构上你要解决的是能够优雅地堆机器,而不是到了要堆机器的时候就换个语言。。。
2. CPU 密集的确不是 PHP 的强项,但是是 C 的强项啊。。。最直接的想法不是 C 写个模块封装下 PHP 去调么 3. 『目前团队只有 PHP 基础,核心业务的重构准备用其它语言实现』 看了你的前一个帖子,我不觉得换一个语言就能解决压缩效率的问题。。。当然如果你只是想玩玩学习下别的语言就随意了。。。只不过拿核心业务这么玩_(:з」∠)_ |
27
88250 2016-05-16 11:52:23 +08:00
Go 的 Debug 可能是一个问题。如果团队的开发成员习惯以单步调式来 debug ,那就很难搞了。
建议 Java ,成熟稳定框架多~ |
28
finian 2016-05-16 11:52:33 +08:00
取决于你们团队熟悉哪种语言,或者哪种语言容易招人(意味着有人 hold 得住),如果为了学习新语言而重构,纯粹是给团队挖坑。。。
|
29
Felldeadbird 2016-05-16 12:04:25 +08:00
楼主这个换语言时解决不了问题的。指望更换开发语言来解决现有的业务问题,很容易被新语言的坑带来其他的业务问题。
上面都说了,有些时候推硬件远比软件升级快得多。唯一缺点就是硬件的维护成本会巨大。 |
30
strwei 2016-05-16 12:31:22 +08:00
laravel 大法好
|
31
scys 2016-05-16 12:35:40 +08:00
找人: Java
实用: PHP 计算密集: C |
32
mirrosite 2016-05-16 12:36:43 +08:00
用的什么框架?
|
33
mirrosite 2016-05-16 12:40:32 +08:00
用 golang 还有点靠普,用 nodejs 重构了以后,我打赌你 100%要用 php 再重构回来
|
34
msg7086 2016-05-16 13:10:47 +08:00
8 台机器重构个毛……四五十台的时候你提重构我还能理解。
8 台机器贵还是你们这些工程师贵? 就算要优化,花点时间 profile 一下,把最慢的部分拿出来局部重写一下就行了。 |
35
redvoilin 2016-05-16 13:13:27 +08:00
把需要密集计算的那块用性能更好的语言写下不就好了嘛
|
36
iyaozhen 2016-05-16 13:14:51 +08:00
还是要喷一下楼主的,你熟悉的语言都搞不定的复杂场景换个都不了解语言能搞定?这么自信?这和谁是最好的语言无关。
「目前压力都在缓存上,业务输出算是 CPU 密集型,加解密压缩之类的,想在这一层换成其它语言来解决。 」 缓存问题和语言没有关系吧。 CPU 密集型,这个 Node 也不行。 Go 倒是挺合适,但 C 扩展成本更低呀。不要想着一个语言解决所有问题。 「还有一块业务, php 中存在重复的计算周期,想通过内存共享来解决,减少重复计算。 」这一块还是要用测试数据来说话,不要想当然, PHP 这样设计是有一定的好处的,比如内存泄露问题。话说业务上没有用 redis 吗? PHP 开启 OPcache 了吗?不考虑升级到 PHP7 ? |
37
picasso250 2016-05-16 13:16:01 +08:00
我也是这个观点,将计算密集那块用 C 扩展。
当然,如果那块的逻辑经常变,那就用 Go 吧。 以上观点本人不负任何责任。 |
38
JasperYanky 2016-05-16 13:19:37 +08:00
典型的 XY 问题
|
39
falcon05 2016-05-16 13:20:33 +08:00 via iPhone
升级到 PHP7 了吗?
|
40
wingoo 2016-05-16 13:41:40 +08:00
lz 这样搞会掉坑里啊
业务逻辑换什么语言, 该复杂还是复杂啊 密集计算确实可以尝试切换, 但仅限于瓶颈的那块 学习新东西, 这个不能摊派, 要看目前团队的水准, 为了学习而去更换, 只会比现在更头疼 |
41
lbp0200 2016-05-16 13:51:48 +08:00
自己写 php 扩展啊
|
42
xd314697475 2016-05-16 14:22:31 +08:00 via Android
|
43
shiny 2016-05-16 14:25:16 +08:00
|
44
millken 2016-05-16 14:31:48 +08:00 via Android
swoole 啊,楼🐷不差钱的话,我帮你重构。
|
45
superleexpert 2016-05-16 14:35:42 +08:00
JAVA+1
|
46
Comdex 2016-05-16 14:52:07 +08:00
go,容易迁移
|
47
plqws 2016-05-16 15:19:57 +08:00
团队只有 PHP 基础…这团队的确有些水了, Java 最合适不过,简单易学,前景良好。
Node.js 一是遇到坑解决起来不方便,社区庞大,但是水分很大 Golang 是 Native 语言,没有好用的 IDE , PHP 直接转过去的学习成本太高。 至于 Java , IDE 丰富,社区庞大,文档齐全…说不出什么不适合之处了。 |
48
vus520 OP |
49
zaishanfeng 2016-05-16 15:44:04 +08:00 via Android
新功能可以试试新语言, 不建议 go node, 如果真要换想不到除了 java 还有哪个适合。
|
50
7timesonenight 2016-05-16 15:51:07 +08:00
从成本方面、对项目的普适性、团队基础几个方面考虑,还是 PHP 最适合吧。
现在很多设计都是后端搭台,前端唱戏。既然现成的 PHP 团队,还不如学学前端,后台给完数据,在前端玩花样。 现在玩前端, node.js 顺手就拿下了,到时候再根据实际需求,把适合转换的业务,迁移到 node 即可。 |
51
agui2200 2016-05-16 15:55:31 +08:00
讲道理,用 go,做个简单的组件测试评估一下,PHP 扩展那么好写?...我宁愿学 go
|
52
audi 2016-05-16 16:04:55 +08:00
目前进入项目稳定期,准备对项目前端进行重构
。。。稳定了还要重构? |
55
surfire91 2016-05-16 16:17:48 +08:00
饱暖思淫欲
|
56
LBJames 2016-05-16 16:18:41 +08:00
楼上那么多人说继续 PHP 就好的,我记得 Livid 说过一句话:现在已经是 2014(2015?)年了,已经没有必要再用 PHP 了。
|
59
chairuosen 2016-05-16 16:41:31 +08:00
如果选 node ,没有大牛的话, hold 不住。
|
60
yxaaa123 2016-05-16 16:46:02 +08:00
最近老听说要把 php 换 java 的。。。
|
61
lualu2 2016-05-16 16:56:28 +08:00
为了重构而重构...
还不如对现有的模块重新分析,看看弱点是哪个优化下.或者对模块进行重构,方向是改的更适合和其他语言交互.这样以后新增的功能和模块或者弱项可以在将来用其他语言实现.对于老模块的整体重构,通常会越改越错.... 语言不能解决问题,每个语言都有每个语言的问题.专攻 php 如果初学其他语言,肯定会遇到坑,直接用在稳定的项目上,就是雷.所以还不如拿新语言在新项目和新模块练手,这样既熟悉了新语言,又对新老语言 /模块的交互有了更深的了解,对老模块的重构也是一种助益. |
62
surfire91 2016-05-16 16:58:46 +08:00
@vus520
针对楼主后面补充的第 4 点说下我的经验: 项目大了之后最需要做的就是拆分与解耦。将大项目维持成多个比较较独立的小项目的合集。 楼主提到目前的性能瓶颈只能通过加机器来解决,我倒反而觉得这是个很好的架构。横向可扩展的架构在扩展时的风险是非常小的。而如果只能重构 /重写来解决扩展问题都会有较大的风险。当然这与我遇到的业务相关,重构产生的一个小小的 bug 远不止几台机器的钱。 楼主闲着想折腾的话推荐静态类型语言。 |
63
gamexg 2016-05-16 17:20:18 +08:00
@plqws 目前觉得 golang 用 IntelliJ IDEA 加插件已经很好用了,有 vs 写 c# 的感觉。目前唯一的缺点是还不支持单元测试时单步调试。
|
64
veiz 2016-05-16 17:20:46 +08:00 via Android
业务拉出来遛遛,让大家看看有多复杂
|
65
gamexg 2016-05-16 17:26:13 +08:00
换语言会碰到新的坑...
golang 最近 1 星期碰到了几个坑。 一次 x86 下 int64 原子操作崩溃,提示不能对空指针操作,检查后发现是未进行内存对齐。这个是我的锅,没细看文档,但是错误提示能不能好些? windows 下获得本地时区是 "" ,用 "" 作为时区创建时间,时间变成了 UTC 时区,差了 8 个小时... github 提交后已经开始修复。 golang 1.5 升 1.6 后, http 标准库偶尔报错,还未确定原因。 |
66
raincious 2016-05-16 17:34:29 +08:00
@gamexg
https://golang.org/pkg/sync/atomic/#pkg-note-BUG 其实这个不是 Golang 的问题,而是 CPU 。 楼主如果真心想换语言(这样开销太大了,不建议,很容易项目就被打垮或者挂了),可以先将整个项目服务化,比如用户登入服务拆出来、用户私信服务、密集运算服务等等拆出来,让这些服务之间用 RPC 与主项目进行通讯。之后慢慢用 Golang 或者 Rust 重新实现这样的服务。 这样可以一点一点的将项目转换到新语言上,同时确保主要的项目一直保持可用。 |
67
gamexg 2016-05-16 17:47:20 +08:00
@raincious 后来看到了那个说明,不过当时很纳闷,错误提示不能操作 nil 。我检查了多遍,确认传递进去的不是空指针,最后到 github 搜索,发现有人报告过,回复是内存对齐问题,就有那个文档连接。主要是想吐槽下能不能使用更友好的错误提示,或者编译期检查。目前的错误提示误导人啊。
|
68
vus520 OP 那还是继续蒙头做 php 吧,哈哈
|
69
vus520 OP @veiz 业务不算复杂
场景是广告类业务,现在的数据都异步组织好,放在缓存里。 api 请求的时候,就是从缓存里把数据拿出来,根据策略排序,做压缩做加密下发。 组织的逻辑一台机器就够了,跑压缩加密的过程,却需要 8 台机器。 后来用 lua+openresty 替换了 api 端的接口进行测试,效率有很多提升,感觉 php 没有内存常驻还是会有资源浪费。 |
70
murmur 2016-05-16 18:33:46 +08:00
复杂系统 java 简单系统剥离一部分到 node.js 剩下保持 php
|
71
codingpp 2016-05-16 19:26:15 +08:00
node.js 不适合写业务,玩玩可以
|
72
fyooo 2016-05-16 19:59:54 +08:00 via Android
试试 hack 语言?
|
74
julor 2016-05-16 20:12:07 +08:00 via Android
用 golang 没商量,绝对好
|
75
jhdxr 2016-05-16 20:37:56 +08:00
@vus520 hack 指的是 hacklang.org _(:з」∠)_ 是非死不可基于 PHP 去做的改进的一个语言。。。大部分语法与 PHP 一致
|
76
lygmqkl 2016-05-16 20:54:20 +08:00 via iPhone
就说一句 PHP 应该够用,你需要的只是一个优秀的架构师
|
77
DSKcpp 2016-05-16 21:49:32 +08:00
新浪微博也是 php 啊 我觉得不是语言的问题吧。。。
|
78
rayyang88 2016-05-16 21:57:57 +08:00
absolutely golang
|
79
fyooo 2016-05-16 22:05:35 +08:00
|
80
shuimugan 2016-05-16 22:23:14 +08:00
如果觉得是 php 没有常驻内存的导致花时间在代码解析上的话,可以先试下 workerman/swoole/ReactPHP 这 3 个框架任选一个,以纯 php 的方式开个 http server,简单写个路由,去调用你的算法,压测下看性能
|
81
JoostShao 2016-05-16 22:39:43 +08:00
业务先理清楚,不理清楚,换再牛逼的语言也没啥用
|
82
liyj144 2016-05-16 23:07:07 +08:00
复杂的地方 c++,或者 nginx+lua 替换。业务部分还是 php 。 done
|
83
levon 2016-05-16 23:26:14 +08:00
重要的是做业务剥离,逐个重构,重构是个大工程,慎重
|
84
bullettrain1433 2016-05-16 23:30:21 +08:00
老实 java 吧
|
85
julor 2016-05-17 07:13:26 +08:00 via Android
@plqws 你确定没有好的 ide ?除了单步调试,其他都不是问题!我是 webstorm 加插件,相当舒服
|
86
zacard 2016-05-17 10:38:54 +08:00
java 。其实我想说 Go ,但是本人 Go 刚刚开始接触,没有发言权。
|