再谈PHP未来之路


当前第2页 返回上一页

不少人认为,PHP7 和 Swoole 给 PHP 在服务化时代带来新希望,因为理论上,上面提到的问题 PHP7 和 Swoole 都能较好的解决。

首先 PHP7 带来了极大的性能提升,而且引入强类型、严格模式等新特性,使得 PHP 越来越像强类型语言。其次 Swoole 的出现使得 PHP 很容易像 java、go 那样实现常驻进程服务而不需要依赖 nginx + php-fpm,那么 由“nginx + php-fpm + script” 的 CGI 模式在服务化时遇到的问题也都得到了很好的解决。

那么,PHP7(以及即将到来的 PHP8 的 JIT 特性)和 Swoole 能给 PHP 带来第二个黄金时代吗?

个人认为不能。还是那句话,当我们谈论语言时,实际上是在谈论生态。

编程语言的生态系统中有个很重要的角色:开发者群体。PHP 自出生时的目标就是“简单、强大、实用”,实现了高度的封装,让开发人员专心面对业务。这对工程是好事,对开发人员的成长(以及开发人员生态)来说却不是。绝大部分的 PHPer 都是业务工程师,几乎所有工作都是各种业务的 CRUD,很少涉及稍底层的东西,也鲜有关乎设计、架构的。在我周围的,以及面试遇到的,大部分人根本不了解设计模式、数据结构、算法、计算机原理,写出来的代码也仅仅是实现了业务的功能性需求,很少考虑非功能性需求。另外,在传统 PHP 的 CGI 模式下,PHP 脚本并不需要考虑自我恢复、自我保护能力如限流、重试、异步等这些在微服务架构下必须考虑的东西。

另外,由于大部分 PHP 程序员平时都是使用 MVC 框架提供的功能实现 CRUD,较少进行对象建模(PHP 并非生来就是面向对象语言,OO 特性是后面加进去的),导致大部分有相当工作经验的 PHPer 的建模能力都很弱,而微服务的一个重要工作就是对单体项目按业务领域进行拆分、建模,这对 PHPer 来说是个相当大的挑战。

一个结果是,PHP 程序员普遍专业素质都很弱,根本胜任不了复杂的系统架构————这里的复杂性有两个层面:技术层面和业务层面。

PHP7 和 Swoole 虽然弥补了语言自身的短板,却弥补不了生态中非语言部分的缺陷。有人认为这些缺陷是历史造成的,不能代表未来。万物的生命都是连续的、演化的,历史往往决定了未来,虽然身处现在的我们察觉不出。既然 PHP 生态在解决复杂系统问题时不具备优势,那么公司就会自然而然地选择其它更具优势的生态系统,自此便形成恶心循环(现实中我们遇到的情况是,很多使用 PHP 作为主要语言的中小公司业务规模上来后,不得不从外面聘请架构师,这些架构师大部分都是 java 出身,到公司第一件事就是强行 PHP 转 java)。

有人可能觉得我是 PHP 黑,毕竟我也没有做过严格的调查来得出上面的结论。但我们可以通过一些现象管中窥豹:

  • 我们可以很容易找到用 java、C++ 写的设计模式、数据结构与算法方面的畅销书,却几乎找不到 PHP 的。
  • 我们在博客园、CSDN 等技术博客上能看到大量 java、C++、C# 程序员的博客,却很少看到 PHP 的。
  • 我们看到技术博客上大量 java 程序员在谈论各种设计、服务、“三高”架构,却很少见到 PHP 的。
  • 我们能看到 java、C++ 程序员到处参加各种技术峰会,却很少见到 PHPer(除了 PHP 自己的专项会议)。

你会觉得仅凭 PHP7 与 Swoole 能让几乎不谈设计模式、不研究数据结构与算法、很少写博客、很少参加峰会的 PHPer 们开拓出一片服务化的新天地吗?

PHP 曾经辉煌过,在移动互联网之前,在单体为王的时代,就像 Delphi 在 Windows 桌面应用为王的时代取得的辉煌一样。现实的需求是语言生态系统的源动力,当需求发生不可逆转的改变时,午日终将西傍。

那么,接下来的问题是:PHP 会很快没落吗?

这个问题实际是在问:如今 PHP 是否还在某些场景下具有优势(即是否还存在现实需求这一源动力)?

PHP 的优势是简单、门槛低、实现功能快捷,很适合如下场景:

  • 业务、系统相对简单,无需服务化;
  • 对性能不是很敏感;
  • 需要快速实现、快速迭代;

在上面这些场景下,微服务(以及 java、C++ 等静态语言)的优点并不能弥补其缺点,因而推荐使用单体架构或者简单的服务化(仅仅进行主要服务拆分,并不引入复杂的服务治理体系),这种情形下 PHP 的优势就显现出来了。一般中小公司正是满足上面的场景,因而我们发现即使是在移动互联网时代 PHP 辉煌不再,但仍有大量中小公司采用 PHP 作为核心开发语言。

另外一个事实是,由于所有的大公司都是由小公司成长来的,在公司规模尚小的时候,他们大多也是采用 PHP 作为核心语言的,规模成长后,虽然 PHP 的各种短板阻碍了系统的发展,但由于已经有大量的 PHP 项目,完全重新用其他语言开发一遍不太现实,因而他们会采用各种优化手段,比如编写 PHP 扩展或者将 PHP 编译成某种静态语言(如 C++),或者将单体项目中的某些核心功能拆解成服务,单体项目调用后端服务接口————这种情况下,PHP 项目成了粘合层。

将 PHP 作为粘合语言的不光是因为历史遗留问题,还有不少公司新项目也会采用这种架构,这样既充分利用了 PHP 的开发效率(因为粘合层往往比较靠前端,需求变动较频繁,开发效率是必须要考虑的重要因素),也保证了核心服务的性能。

那么,接下来的问题是,作为快速原型语言和粘合层语言,有没有其他语言比 PHP 更具优势?

至少国内不用谈 Python 和 RoR(在国外这两者在 Web 开发上的占有率也不及 PHP),Python 程序员的重心已转大数据、人工智能了, RoR 至少在国内一直不温不火,在程序员的招聘上比 PHP 要难很多。

nodejs 曾经被认为是 PHP 的最大对手,一个很大的原因是人们认为如果一个公司使用 nodejs 作为后端语言,那么他只需要一样技术栈(前后端都是 js 程序员,而 js 程序员和 PHP 一样一抓一大把),体现了莫大的成本优势。但事实是 nodejs 并没有对 PHP 造成根本威胁,未来也不太可能会,原因是持上面观点的人认为统一技术栈就一定能节约成本,但这是个伪命题。一门语言具有解决某个问题的能力不代表人们就一定会拿它去解决问题,就好比 PHP 也能进行 socket 编程,但很少公司在生产环境大规模使用 PHP 编写服务器。js 天生就是 Web 前端语言,因而绝大部分 js 程序员都是一直做前端开发的,而前端开发和后端开发模式上有很大不同。前端在很长一段时间都是面向 DOM 编程,即使是有了模块化、React 这些新玩法后,前端开发的重心仍然是事件驱动的交互式编程。后端开发的重心在于建模(即使不对业务进行对象建模,也至少需要面向数据库进行数据建模)以及业务逻辑的实现,做后端开发,数据库、Linux 服务器是绕不开的,而这两者恰恰是大部分前端程序员所缺乏的(换句话说,要招一个既很熟悉前端开发又很熟悉后端开发的 js 程序员是非常难的)。结果就是,招一个 js 程序员用 nodejs 开发后端系统,其成本远大于招一个 PHPer。

因而,PHP 在未来可预见的很长时期内不会没落,它会作为中小公司的快速原型语言和大公司的粘合层语言长期存在。

另一个结论是:Python、Ruby On Rails、nodejs 这些语言虽然不会对 PHP 造成根本威胁,但会跟 PHP 一同在 Web 开发领域长期存在————因为它们的源动力是相同的,而 PHP 相对于它们的优势又不足以完全抹杀掉它们的存在。

总结:

最后,我将上面的分析总结成四个论断:

  • 论断一:PHP 在移动互联网到来之前出现过黄金时期,如今辉煌不再;
  • 论断二:PHP 在未来可预见的很长时期内不会没落;
  • 论断三:后黄金时代 PHP 的定位:中小公司的快速原型语言以及大公司的中间粘合层语言;
  • 论断四:PHP7 和 Swoole 让 PHP 在和其他同层级语言(如 Python、RoR、nodejs)的竞争中保持优势,但无法给 PHP 带来根本的变化(无法改变 PHP 的定位);

以上就是再谈PHP未来之路的详细内容,更多关于PHP的资料请关注其它相关文章!

更多相关Discuz论坛的内容来自木庄网络博客


标签:Discuz论坛

返回前面的内容

相关阅读 >>

网站数据自动备份方法

php代码架构的八点注意事项

使用dedecms制作英文站的技巧说明

国外著名论坛程序ipb(invision power board)在nginx下的配置示例

一段php加密解密的代码

Discuz论坛整合ucenter免激活,同步登录,同步退出解决方案

web目录下不应该存在多余的程序(安全考虑)

discuz!nt数据库读写分离方案详解

经典php加密解密函数authcode()修复版代码

使用discuz关键词服务器实现php中文分词

更多相关阅读请进入《Discuz论坛》频道 >>



打赏

取消

感谢您的支持,我会继续努力的!

扫码支持
扫码打赏,您说多少就多少

打开支付宝扫一扫,即可进行扫码打赏哦

分享从这里开始,精彩与您同在

评论

管理员已关闭评论功能...