举个例子，在 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 是有史以来最好的语言”永成过去式。
不少人认为，PHP7 和 Swoole 给 PHP 在服务化时代带来新希望，因为理论上，上面提到的问题 PHP7 和 Swoole 都能较好的解决。
首先 PHP7 带来了极大的性能提升，而且引入强类型、严格模式等新特性，使得 PHP 越来越像强类型语言。其次 Swoole 的出现使得 PHP 很容易像 java、go 那样实现常驻进程服务而不需要依赖 nginx + php-fpm，那么 由“nginx + php-fpm + script” 的 CGI 模式在服务化时遇到的问题也都得到了很好的解决。
那么，PHP7（以及即将到来的 PHP8 的 JIT 特性）和 Swoole 能给 PHP 带来第二个黄金时代吗？
个人认为不能。还是那句话，当我们谈论语言时，实际上是在谈论生态。