*作者：羅松（西流）*

## 前言

PHP 的應用範圍相當廣泛，尤其是在網頁程式的開發上, 根據最新維基百科 **[1]** 顯示，2013 年 4 月的統計資料，PHP 已經被安裝在超過 2 億 4400 萬個網站和 210 萬臺伺服器上, 而根據 W3Techs **[2]**  的報告，截至 2021 年 9 月, 有 78.9%的網站使用 PHP。所以 PHP 是世界第一語言至少在 web 開發領域並不是戲稱。

而在技術選型上，PHP 主要採用的是 LAMP(全稱是Linux + apache + mysql + php) 或者 LNMP(全稱是Linux + nginx + mysql + php)，這種成熟穩定的技術框架推動 PHP web 開發生態的繁榮和商業上的成功。

![](https://img-blog.csdnimg.cn/img_convert/72d743acef93ee5a9419cc950868a058.png)

在傳統的開發模式中，開發者自己需要安裝維護各種軟體的安裝、維護升級:

-   如果您是一個**企業使用者**，如果業務體量變大或者為了生產環境的穩定和可用性，使用負載均衡是一個必然的選項：

![](https://img-blog.csdnimg.cn/img_convert/92ef4554079c2c70d8bde6e894c10c7e.png)

即此時，PHP 開發者或者線上運維的同學關心的事情多了起來：

-   每個增加的生產機器都需要重新安裝一遍相關軟體，做相同的 nginx 配置以及 php-fpm 的配置，以及維護每個生產機器的安全更新；

-   假如開發的應用需要一個新的擴充套件，可能需要人肉每臺機器去增加擴充套件；

-   負載均衡器隨著業務的變更升配，後面一臺 Worker 機器掛掉了，如何做運維處理？
-   業務的波峰波谷怎麼應對才能讓資源的利用率提高？

如果您是**專案組開發成員比較多的企業使用者**，能不能不需要給每個開發配置一個安裝的 NLP 的 Linux 機器作為開發測試機器（或者多人共享一個機器）？

如果您是一個**提供網站開發和託管的 ISV**、外包公司或者創業公司，我的客戶都是一些中小企業的入口網站，我怎麼提高我後端機器資源利用率以及更好提供定製化服務？

如果您是一個**學生或者準備學習 PHP 開發**，本地只有 Windows 電腦，能不能直接近乎免費的方式獲取 LNP(Linux+Nginx+PHP) 的環境用來學習呢？

帶著這些問題， 我們去探索一下 Serverless 是如何解決這些痛點的。

## PHP 遇見 Serverless

### 什麼是 Serverless？

Serverless = Faas (Function as a service) + Baas (Backend as a service)，我們簡單透過兩個圖快速瞭解相關概念：

-   **傳統模式**

![](https://img-blog.csdnimg.cn/img_convert/f51ed23c23e152434b5743c9be82f7ae.png)

-   **Serverless 模式**

![](https://img-blog.csdnimg.cn/img_convert/1e0624a526de8d47ae945d3e2fef4ba9.png)

圖中的 CDN 和 OSS 就是 BaaS 服務，FC 就是自定義函式邏輯的 FaaS 平臺, 透過這個對比，我們能快速得到 FaaS 的特性和好處：

-   只需要專注業務程式碼開發， 編寫對應的邏輯即可
-   極致彈性伸縮， 無需管理伺服器
-   按量付費，每次呼叫按毫秒計費
-   ...

本文後續討論的 Serverless 主要指的是 FaaS，如下示意圖，幾行程式碼編寫完畢，儲存到雲廠商的 FaaS 平臺，就完成了一個彈性高可用的 Web API。

![](https://img-blog.csdnimg.cn/img_convert/d7231c50cfbf2002f11268895d5a32bd.png)

### PHP 遇見 Serverless

PHP 作為一個開發群體的很大的語言，各大雲廠商的 FaaS，比如阿里雲的函式計算、AWS 的 Lambda (透過 Custom Runtime **[3]**  間接支援）、騰訊的 SCF 等都推出了對 PHP 語言的支援，phper 面對前端領域的 Serverless 技術革新實踐(感興趣的見本文最後的附錄)，應該不遑多讓。以阿里雲函式計算為例，有很多 PHP 的開發者有了很多有趣的實踐：

-   直接使用 gd 或者 ImageMagick 擴充套件，實現彈性高可用的圖片、水印等各種 CPU 密集型 API

-   直接使用 ffmpeg + 效能型例項 + 非同步有狀態呼叫完成影片剪輯合成等音影片處理業務

-   使用 HTTP 觸發器實現的函式， 埋點到廣告平臺， 快速實現高可用的買量業務

-   直接將之前基於框架（如 ThinkPHP）實現的 WEB API 直接遷移到 FaaS 平臺，不用再擔心當機和運維問題了

雖然 FaaS 很好地解決了 phper 如下問題：

-   新業務或者開發新的 web API

-   存量業務中， 有些 CPU 密集型或者彈性要求很高的 API 單獨抽離出來 FaaS 化

但是傳統的開發模式或者存量業務，對開發者有一定的上手和改造成本，比如某 Faas 廠商 PHP Runtime 程式設計介面示例：

```
function handler($event, $context) {
     $eventObj = json_decode($event, $assoc = true);
    // do your thhings
     // ....
     return $eventObj['key'];
}
```

但是能不能更進一步，開發者不需要按照 FaaS 廠商的約定的函式入口能實現一個個的API,  而是能直接將傳統執行在 LAMP 或者 LNMP 的專案直接 FaaS 化？答案是肯定的。

阿里雲函式計算的 Custom Runtime 以及直接基於 HTTP 協議的極簡程式設計模型走在了所有云廠商的前列。

![](https://img-blog.csdnimg.cn/img_convert/0c9c18a21991ab4642cbaf5c3adc9a4e.png)

函式計算啟動 Custom Runtime 執行環境時，會預設呼叫 bootstrap 檔案(或者您建立函式的時設定的 Args 引數)啟動您自定義的 HTTP Server，然後這個 HTTP Server 接管了函式計算系統的所有請求，即您所有的函式呼叫請求。

> 函式計算 Custom runtime 執行環境底層系統是 Linux, 並且已經內建的 nginx/1.10.3 和 php-fpm7.4,  對於 PHP 應用，您直接使用即可

以部署一個 wordpress **[3]**  專案為例, 只需要將如下目錄直接打包成一個 zip 包在函式計算平臺建立一個函式即可：

```
- bootstrap
- nginx.conf
- php-fpm.conf
- php.ini-production
- wordpress
```

其中 wordpress 目錄是對應的 web 工程,  bootstrap 是啟動 nginx 和 php-fpm 的指令碼即可:

```
...
echo "start php-fpm"
php-fpm7.4 -c /code/php.ini-production -y /code/php-fpm.conf
echo "start nginx"
nginx -c /code/nginx.conf
...
```

> bootstrap 詳情可參考 WordPress in FC **[5]** （文末附連結）

所以，使用函式計算這個 Serverless 產品和傳統的 PHP 開發相結合後，您再也不用考慮負載均衡的事情，不用考慮擴縮容的事情，不用管理機器、不用擔心當機的事情等等，只需要安安心心把業務程式碼開發好即可。

![](https://img-blog.csdnimg.cn/img_convert/5a901eb8016c7e7f26eaec3b013b4a5e.png)

從上圖可以看出：開發者只需要開發好自己的業務程式碼即可，唯一需要考慮的事情，就是函式計算這邊擴容不要太多太猛（比如直接在函式計算平臺設定下該函式能彈出的最大例項數目即可），給下游自己的 Mysql 資料庫過大的壓力即可。

![](https://img-blog.csdnimg.cn/img_convert/9c422b54b971efa4a2b7ec2e4d695801.png)

當然， 從原始的傳統的 php web 應用完全遷移到 Serverless 形態的函式計算平臺，某些場景可能需要考慮資料持久化問題，因為函式計算是無狀態的，資料持久化儲存可以藉助 NAS、Redis 等服務完成，以 NAS 為例，流程圖如下：

以 WordPress 為例，後臺系統上傳的圖片或者 Session 功能都是需要持久化到磁碟的。

-   設定 web 工程的檔案上傳目錄或者 session 目錄為 NAS 盤的某個目錄, NAS 盤實現持久化

-   甚至可以將 web 工程直接放到 NAS 盤上，此時函式計算純粹就是 LNP 執行環境

![](https://img-blog.csdnimg.cn/img_convert/b37f7af988b45ef100b502c2a94a9453.png)

比如將 wordpress 工程不作為函式的程式碼包的一部分，而已提前上傳到 NAS 盤，只需要設定好 nginx.conf 中的 root 能知道 web 工程即可，如上面的 nginx.conf，/mnt/auto 表示掛載的 NAS 目錄，mnt/auto/wordpress 則表示在 NAS 上的 web 工程。

此時對您來說，函式再也不用變了，您可能只是需要開發新的業務程式碼，然後上傳到 NAS 上即可（或者直接使用 git 直接在 NAS 操作，實現 web 工程的版本和 git 上的 commit 繫結，使用 git 實現程式碼的快速升級和混滾）

但是從安全生產的角度來說，還是建議您 web 工程變更最好和函式的變更相關聯。

## 總結

從上面的討論和陳述中，我們不難發現，PHP 遇見 Serverless 是一件令人興奮的事情，讓 phper 有了更大的想象空間。Serverless 的理念和 PHP 這個語言出現的理念也是一致的: **即讓開發者最大精力集中在自己的業務價值。** PHP 語言一直是 web 領域最好的生產力代表，而 Serverless 將會讓 PHP 如虎添翼。

## 相關連結

[1]維基百科：

[](https://zh.wikipedia.org/wiki/PHP?)

<https:>

[2]W3Techs：

[](https://w3techs.com/?)

<https:>

[3]Custom Runtime 簡介：

[](https://help.aliyun.com/document_detail/132044.html?)

<https:>

[4]wordpress 專案：

[](https://github.com/devsapp/start-web-framework/tree/master/web-framework/php/wordpress/src?)

<https:>

[5]WordPress in FC：

[https://github.com/devsapp/start-web-framework/blob/master/web-framework/php/wordpress/src/code/bootstrap?](https://github.com/devsapp/start-web-framework/blob/master/web-framework/php/wordpress/src/code/bootstrap?)

**我們最後來一一解答下前言中提出的問題：**

##### Q1：如果您是一個企業使用者，業務體量變大或者為了生產環境的穩定和可用性,如何做？

A1：如上面陳述，使用函式計算和傳統的 PHP 開發相結合後，您再也不用考慮負載均衡的事情，不用考慮擴縮容的事情，不用管理機器、擔心當機的事情等等，只需要安安心心把業務程式碼開發好即可。

##### Q1：如果您是專案組開發成員比較多的企業使用者，能不能不需要給每個開發配置一個安裝的 NLP 的 Linux 機器作為開發測試機器（或者多人共享一個機器）？

A1：是的，每個開發者在函式計算上建立一個自己的 Service/函式即可，Service/函式配置開發測試環境的 VPC，實現內網安全訪問資料庫等其他下游服務。函式呼叫的時候，函式計算會拉一個 NLP 的執行環境來執行您分支上正在開發的 PHP 程式碼。

-   每個執行環境是相互隔離的
-   按呼叫次數計費， 不需要預留機器， 免除了機器成本上的浪費
-   也可以很方便進行壓測等各種事宜

##### Q1：如果您是一個提供網站開發和託管的 ISV、外包公司或者創業公司，我的客戶都是一些中小企業的入口網站，我怎麼提高我後端機器資源利用率以及更好提供定製化服務？

A1：通常來說，很多企業入口網站訪問量不大，但是網站掛掉了會引起客戶投訴。每個客戶的網站透過 service 或者函式區分，透過函式名或者 service 去區分您自己的客戶：i. 管理方便  ii. 做定製化方便  iii. 做不同 VIP 等級服務方便。舉個例子，您可以快速透過某個函式的呼叫指標情況，可以看出哪個客戶的網站訪問量大，可以做出客戶畫像以及制定不同的收費和 VIP 服務級別。

##### Q1：如果您是一個學生或者準備學習 PHP 開發，本地只有 Windows 電腦，能不能直接近乎免費的方式獲取 LNP(Linux+Nginx+PHP)  的環境用來學習呢？

A1：是的， 只要將如下的檔案和資料夾打包成 zip 包去函式計算控制檯建立函式即可：

```
- bootstrap
- nginx.conf
- php-fpm.conf
- php.ini-production
- myweb
  | - hello.php
```

如果您對 PHP 落地 Serverless 感興趣，您有觀點、想法或者想吐槽的，可以和釘釘搜尋：31897696，歡迎進群大家一起交流。

![](https://img-blog.csdnimg.cn/img_convert/8795a610d9f440def49f632dcdfd8b45.png)

#### PHP 框架 Serverless 最佳實踐：

[1]ThinkPHP：

[](https://github.com/devsapp/start-web-framework/tree/master/web-framework/php/thinkphp/src?)

<https:>

[2]Laravel：

[](https://github.com/devsapp/start-web-framework/tree/master/web-framework/php/laravel/src?)

<https:>

[3]Wordpress：

[](https://github.com/devsapp/start-web-framework/tree/master/web-framework/php/wordpress/src?)

<https:>

[4]Z-BlogPHP：

[](https://github.com/devsapp/start-web-framework/tree/master/web-framework/php/zblog/src?)

<https:>

[5]Swoole：

[](https://github.com/devsapp/start-fc/tree/master/custom-function/php74?)

<https:>

[6]其他更多:

[]()

[ https://github.com/devsapp/start-web-framework]()

#### 參考引用

Serverless Architectures：

[](https://martinfowler.com/articles/serverless.html?)

<https:>

Backend For Frontend（BFF）in Serverless：

[](https://www.infoq.cn/article/0btajez51ysb_qehr526?)

<https:>

關於 Serverless 未來對前端開發影響的具體看法：

[](https://developer.aliyun.com/article/793492?)

<https:>

當 SSR 遇上 Serverless，輕鬆實現頁面瞬開：

[](https://cnodejs.org/topic/5e394e311225c9423dcd9754?)

<https:>

#### 附錄

##### Serverless 在前端領域如火如荼的發展

附錄1

Backend For Frontend（BFF）in Serverless 來提高生產力

• 前端開發者全棧化

• 提高開發效率，減少前端和後端介面同學的溝通聯調時間，後端同學只需要做好原子的介面的穩定性和可靠性即可，資料的聚合直接由前端同學透過 BFF 實現

![](https://img-blog.csdnimg.cn/img_convert/b0268063f1064b045684a4d646da1f29.png)

附錄2

當 SSR 遇上 Serverless，輕鬆實現頁面瞬開

• 藉助於函式即服務（FaaS）的能力，不需要再去搭建傳統的 Node 應用，一個函式就可以變成一個服務，開發者可以更純粹的關注於業務邏輯。

• FaaS 以函式為單位的形式以及彈性機制，為 SSR 應用帶來了天然的隔離性和動態修復能力，可以更好的避免頁面間的交叉汙染，或一些邊界的異常場景對應用帶來致命性的傷害。

• 無需運維、按需執行、彈性伸縮這些特性，大大降低了 SSR 應用對開發者的門檻。

附錄 1：

[](https://www.infoq.cn/article/0btajez51ysb_qehr526?)

<https:>

附錄 2：

[https://cnodejs.org/topic/5e394e311225c9423dcd9754?](https://cnodejs.org/topic/5e394e311225c9423dcd9754?)</https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:>

最佳實踐：Kubernetes 叢集中 DNS 故障的可觀測性與根因診斷

相關文章