编程语言的生态系统中有个很重要的角色：开发者群体。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 更具优势？