再谈PHP未来之路-木庄网络博客

本文整理自网络，侵删。

这门语言现在到底处于生命周期的哪个阶段？其定位到底是怎样的？诸如 PHP7、Swoole 的出现到底能给 PHP 带来怎样的变化？

当我们拿 PHP 和 java 进行比较的时候，我们往往就两门语言本身进行比较，如一个是弱类型一个是强类型，一个是数组打天下一个是各种数据结构，甚至连花括号是不是换行写都会被讨论一番。但它们真正的区别并非这些。

当我们谈论一门语言的时候，我们是在谈它的生态。

“生态”一词在百度百科上的解释是：“生态一词，现在通常是指生物的生活状态。指生物在一定的自然环境下生存和发展的状态，也指生物的生理特性和生活习性。生态（Eco-）一词源于古希腊字，意思是指家（house）或者我们的环境”。

生态具有如下特点：

生态是系统，由多个部分组成的完整体；
生态是开放系统；
生态具有动态平衡性；
维持其动态平衡的是源动力，源动力一旦消失，生态即消亡。例如地球生态系统的源动力是太阳能；一旦太阳消失，地球生态则不复存在（想想《流浪地球》）；

一种生物的生存状态不取决于生物自身，而取决于环境，就如恐龙的灭绝并非恐龙自身退化了，而是环境改变了（或者说恐龙的进化赶不上环境的变化）。

一门语言的兴衰不取决于它自身，而取决于环境，具体来说是环境中源动力的强弱。

PHP 应 Web 而生，考查其兴衰得考查互联网的发展。

一般认为互联网大致经历了三个阶段：

阶段一：Web1.0 时代，传统的内容网站，如企业官网、行业门户网站等，网站自身产生内容，用户仅查看内容；
阶段二：Web2.0 时代，用户参与内容的创建，如论坛、博客。阶段一和阶段二都是内容为主，服务为辅（虽然内容的产生方式有所不同）；
阶段三：移动互联网时代，信息流、内容与服务并存；

以上三个阶段的演化中，用户参与度越来越高，交互方式越来越丰富，网站流量越来越大。

阶段一和阶段二是 PHP 的黄金时代，从阶段二开始悄悄发生变化，而到了阶段三，PHP 的黄金时代基本结束。

PHP 这门语言的特点是“简单、实用”，入行门槛极低，一个编程小白，一周入门，两天出个网站。一个典型的例子，在数据结构上，不像其他语言有 Array、List、Map、Set，PHP 一个 Array 搞定所有的情况。

PHP 的这种“简单”是通过牺牲性能为代价的。由于需要简单，不能有各种类型限制，PHP 必须是动态语言；由于需要简单，能封装则封装，一个 file_x_contents 搞定文件（甚至是网络）读写（该函数是一次性将文件全部加载到内存中，很多人开发不考虑其局限性而用在所有场景，导致内存溢出）；由于 Array 承包了所有集合型数据结构，其底层需要做各种处理不说，业务层也无法自主选择更合适的数据结构做针对性的优化（虽然后来 SPL 提供了一些基本数据结构）。

PHP 的这种“简单”还牺牲了另一样东西：程序员的专业素质。PHP 程序员根本不需要去了解真正的 Array 和 List 有什么区别，也不需要去管数据流、缓冲区。从长期来看，这一点是致命的，它使得 PHP 生态中的重要一环很脆弱，很可能是导致 PHP 最终衰落的真正因素。

在 Web1.0 时代，一方面内容产生者是网站自身，另一方面人们只能通过桌面浏览器上网，这些因素使得这个阶段绝大部分公司根本不会遇到高并发等性能问题，而且业务的简单性使得单体应用足以应付一切，因而这个阶段 PHP 的缺陷根本不足为患。于是，PHP 的优势（简单上手、快速开发）让这门语言大行其道，什么 JSP、ASP，根本不是对手。那个时期，人们谈论 java、C# 时，基本是在谈 ERP，只有 PHP 才是 Web。

到了 2.0 时代，论坛、博客、SNS 的出现，使得用户创建内容成为可能。由于用户的积极参与，网站服务器流量相对于 1.0 时代有了突增，特别是 SNS 的信息流特性，使得服务器面临相当的挑战。不过由于人们仍然是通过 PC 浏览器上网，在一定程度上限制了使用频率。这个时期，一些大公司针对 PHP 的性能缺陷做了自己的改造，如新浪的各种 c 扩展（yaf、yar 等），facebook 的 HVVM。

在这两个黄金时代，PHP 世界涌现了大量的经典开源项目：WordPress、ecshop、Magento、Discuz、Thinkphp、Yii 等。

彻底结束掉 PHP 黄金时代的是移动互联网的到来。iphone 改变了世界，也改变了 PHP 的命运。

移动互联网时代，人们随时随地都能上网，而且几乎每人一部手机，这带来的直接效果就是 Web 使用需求出现了数量级的增长。另外，移动互联网时代的另一个特点是内容+服务的一体化，网站不再只是提供内容，还提供服务（如各种 O2O），因而在使用频率、交互体验上的需求都大大增强。

举个例子，在 1.0 时代，浏览器和服务器根本不需要建立长连接，2.0 时代，由于信息流的出现，要求有轮询机制，但由于当时无论是浏览器还是 PHP 都不支持长连接，人们想了各种奇淫技巧来实现轮询。移动互联网时代，浏览器端有了 WebSocket，悲剧的是 PHP 本身却不支持 WebSocket（由于 PHP 的运行机制是一次请求后进程就结束了，在语言核心层面无法提供 WebSocket 机制。要想在核心层面支持 WebSocket，必须改造 PHP 的整个运行机制，这几乎是不可能的）。

至此，一方面 PHP 的性能问题成了致命问题，另一方面 PHP 各种“方便”的机制（如由 php-fpm 代替 PHP 脚本自身的常驻进程）满足不了新的场景需求，反倒成了桎梏。

在移动互联、万物成网的大背景下，微服务应运而生。一般认为微服务本身并非新的概念，早期的 SOA 就有其身影。不过我们谈论一个概念本身到底新不新没有意义（就好比有人认为中国的勾三股四弦五的发现比希腊的毕达哥拉斯定理要早，于是认为该定理是中国人发现的；有人认为中国的阴阳学说含有二进制思想，便认为二进制是中国人发明的），重要的是一个概念何时形成了一套完整的体系，以及是如何来解决实际问题的。

微服务架构是相对单体架构来说的。我们先说说微服务的缺点：服务间调用关系复杂、难治理、问题排查复杂、分布式事务问题等。既然有这么多缺点，为啥微服务架构当今能大行其道？原因在于单体架构解决不了当今面临的问题：巨大而复杂的业务群、高并发、高可用的系统需求。

微服务给 PHP 带来什么呢？

当我们将单体架构拆解成一个个小的服务的时候，我们来考查一下编程语言的选择，看看 PHP 还是不是最佳选择：

首先微服务要轻量化。
其次服务要被多个业务端调用，其运行要足够快。
另外当服务间通信非常频繁时，通信协议要保持高效，此时 HTTP 协议并非最佳，很多公司倾向于 RPC 协议。
后端服务相对于前面的业务层来说，变动频率相对要低一些，因而可以适当地牺牲一些开发效率。
要有较成熟的生态和框架支持（成熟的服务治理生态）。

从上面几点来看，PHP 并非最佳选择：

传统的 PHP 架构是 nginx + php-fpm + PHP script，显然不够轻量，成百上千个服务都驮着这么厚厚的一层壳，显然存在资源浪费问题。
PHP 作为脚本语言，由于存在脚本解析消耗，运行速度上赶不上 java、C++ 等静态语言（不过在 PHP 引入 opcode cache 后情况得到了很大改善，而且对于 Web 来说大部分时候都是 I/O 密集型操作，语言本身的性能影响对于绝大部分的公司来说并非主要问题————不过一方面心理学研究表明人类的认知并非完全理性的，人们认为 PHP 比 java 性能差那就是差，不管实际差多少（这就好比我们认为大品牌的东西一定比小品牌的好一样，编程语言的世界也有品牌效应））。
PHP 核心没有提供现成的 RPC 方案，但可以通过扩展解决，这不是问题。问题是传统的 PHP 架构（nginx + fpm + script，一次请求完成后工作进程即结束）并不能很好地应用 RPC 通信的优势。
在生态和框架上，Swoole 貌似是个不错的选择，不过 Swoole 的微服务生态目前尚不成熟。
大部分的 PHP 程序员对服务化比较陌生（以及对性能、可靠性等非功能性需求的普遍漠视），上手较慢。

综合考虑，大部分公司进行服务化的时候，会选用主流静态语言（java、C++ 以及后起之秀 golang 等）做服务，PHP 更多是来开发中间的业务聚合系统来调用这些服务。

至此，PHP 走下“神坛”，官方那句“PHP 是有史以来最好的语言”永成过去式。

阅读剩余部分