概述

PHP語言從1995年發布，至今已經有29多年的歷史，在期間涌現了成千上萬的MVC框架，大致可以將其分為以下三大類:

公司內部自研

有大量的公司會自研MVC框架，會根據自身業務的特性打造適合自身的PHP框架。

PHP開源框架

現PHP開源社區流行的PHP MVC框架有Yii、Laravel、CodeIgniter、ZendFrameWork、Symfony等;

C擴展

純C擴展的PHP MVC框架由于研發難度大，不易修改，學習成本相對較高，故直到近幾年才出現，比如Yaf、Phalcon等。

上述三類的PHP MVC運行的環境為LA(N)MP，而且其中的A(N)是不可或缺的，也就是說他們都需要依賴Web Server來承接用戶的請求,將請求轉發給PHP進程，解析并執行PHP代碼，而這樣的工作模式是所有PHPer根深蒂固的認知，甚至筆者在前幾年聽到有人說我們可以拋棄php-fpm,nginx，心想簡直是無稽之談。

隨著互聯網技術的發展，大量公司的后端技術架構都在往微服務架構變遷，微服務架構要求我們盡可能的將我們的業務拆分到獨立的部署單元，當然微服務框架的好處是很“誘人”的，但是它會帶來大量的成本開銷和性能開銷，如何在微服務架構實踐中節約成本和提升性能是我們不可邁過的溝壑。

那在PHP生態中傳統的LA(N)MP能滿足微服務框架的需求嗎?

答案顯然是不能的。就目前PHP的fastcgi進程管理器php-fpm和nginx的配合已經運行得足夠好，但是由于php-fpm本身是同步阻塞進程模型，在請求結束后釋放所有的資源（包括框架初始化創建的一系列對象），導致PHP進程空轉（創建銷毀創建） 消耗大量的CPU資源，從而導致單機的吞吐能力有限。

我們是不是應該切換開發語言?

先簡單的來看換開發語言，一個公司或者團隊切換開發語言的成本是巨大的，它直接面臨著放棄已有的技術沉淀，學習新的語言生態和習慣做法，并將現有業務的全面重構，同時整個運維技術棧也要同步更新，需要踩過無數個“坑”，所以我們這里暫不展開去講切換開發語言來解決我們的核心問題。

那我們還有什么解決方案?

我們分析我們的業務不難發現，90%以上的業務都是IO密集性業務，我們只需要提高IO復用的能力就可以提升單機吞吐能力，另外需要將php-fpm同步阻塞模式替換為異步非阻塞模式，當然不一定使用php-fpm，就可以解決我們的核心問題——性能。不幸的是目前PHP生態中還沒有一個工程級別的MVC框架能夠滿足我們的需求。

綜上所述，我們需要使用全新的現代化的PHP框架Webman，為微服務架構打下堅實的基礎。

PHP-FPM工作模式的問題

圖片

• Nginx基于epoll事件模型，一個worker同時可處理多個請求
• fpm-worker在同一時刻可處理一個請求
• master進程只負責處理worker進程的監控、日志等
• 用戶端請求由elb解析，再經過nginx解析
• fpm-worker每次處理請求前需要重新初始化mvc框架，然后再釋放資源
• 高并發請求時，fpm-worker不夠用，nginx直接響應502
• fpm-worker進程間切換消耗大（如某線上業務在4核8G內存服務器實質可利用16個進程）

壓測數據對比

目標

1. 對比在相同硬件條件下,PHP Yii2框架在PHP-5.6及PHP7下echo hello world的QPS,并觀察平均響應時間及CPU。
2. 對比現有某服務在PHP-5.6及PHP7下的QPS

工具

ApacheBench即ab。ab -n xx -c xx -k http://www.tinywan.com/

硬件

aws c4.xlarge（4核8G）

Hello World

PHP-5.6/Yii2

開啟opcache,64個php-fpm進程，輸出hello world

PHP-7/Yii2

開啟opcache,64個php-fpm進程，輸出hello world

某服務

• 1次Redis Get
• 1次 MongoDB Query
• 2個廣告接口
• 2個業務接口

PHP-5.6/Yii2

PHP-7/Yii2

結論

1. PHP-5.6升級PHP-7.0，Yii2框架的性能提升43%
2. PHP-5.6升級PHP-7.0，某服務性能提升170%
3. 單純將業務升級PHP-7.0，能夠提升很大的性能