# 1 為什么要研發新的PHP框架?
PHP語言從1995年發布,至今已經有20多年的歷史,在期間涌現了成千上萬的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框架,為微服務架構打下堅實的基礎。
- 0 文檔說明
- 1 為什么研發新框架
- 1.1 傳統php-fpm工作模式的問題
- 1.2 壓測數據對比
- 1.3 小結
- 2 微服務框架研發概覽
- 2.1 通信框架技術選型
- 2.2 swoole
- 2.3 協程原理
- 2.4 異步、并發
- 2.5 小結
- 3 框架運行環境
- 3.1 環境變量
- 3.2 運行代碼
- 3.3 docker
- 3.4 小結
- 4 框架結構
- 4.1 結構概述
- 4.2 控制器
- 4.3 模型
- 4.4 視圖
- 4.5 同步任務
- 4.6 配置
- 4.7 路由
- 4.8 小結
- 5 框架組件
- 5.1 協程
- 5.2 類的加載
- 5.3 異步Http Client
- 5.4 請求上下文
- 5.5 連接池
- 5.6 對象池
- 5.7 RPC
- 5.8 公共庫
- 5.9 RESTful
- 5.10 多語言
- 5.11 雜項
- 5.12 小結
- 6 常見問題
- 7 附錄