PHP 在Swoole中使用雙IoC容器實作無污染的依賴注入-有解無憂

簡介:

容器(container)技術(可以理解為全域的工廠方法), 已經是現代專案的標配. 基于容器, 可以進一步實作控制反轉, 依賴注入. Laravel 的巨大成功就是構建在它非常強大的IoC容器 illuminate/container 基礎上的. 而 PSR-11 定義了標準的 container , 讓更多的 PHP 專案依賴容器實作依賴解耦, 面向介面編程.

另一方面, PHP 天生一個行程回應一次請求的模型, 已經不能完全適應開發的需要. 于是 Swoole, reactPHP, roadrunner 也越來越流行. 它們共同的特點是一個 php worker 行程在生命周期內要回應多個請求, 甚至同一時間同時運行多個請求 (協程).

在這些引擎上使用傳統只考慮單請求的容器技術, 就容易發生單例相互污染, 記憶體泄露等問題 (姑且稱之為”IoC容器的請求隔離問題” ). 于是出現了各種策略以解決之.

多輪對話機器人框架 CommuneChatbot 使用 swoole 做通信引擎, 同時非常廣泛地使用了容器和依賴注入. 在本專案中使用了 “雙容器策略” 來解決 “請求隔離問題” .

所謂”雙容器策略”, 總結如下:

同時運行 “行程級容器” 與 “請求級容器”
“行程級容器” :

傳統的IoC 容器, 例如 Illuminate/container

“請求級容器” :

所有工廠方法注冊到容器的靜態屬性上
在 worker 行程初始化階段注冊服務
每個請求到來后, 實體化一個請求容器.
請求中生成的單例, 掛載到容器的動態屬性上.
持有”行程級容器”, 當系結不存在時, 到”行程級容器” 上查找之.
請求結束時進行必要清理, 防止記憶體泄露

解決方案的代碼在 https://github.com/thirdgerb/container 創建了一個 composer 包 commune/container

容器的”請求隔離”問題

關于容器, 控制反轉與依賴注入

為防止部分讀者不了這些概念, 簡單說明一下.

所謂容器, 相當于一個全域的工廠. 可以在這里 “注冊” 各種服務的工廠方法, 再使用容器統一地獲取. 例如

 1 $container = new Container();
 2 
 3 // 系結一個單例
 4 $container->singleton(
 5     // 系結物件的ID, 通常是 interface, 以實作面向介面編程.
 6     UserInterface::class,
 7     // 生成實體的工廠方法.
 8     function() {
 9         return new class implements UserInterface{};
10     }
11 );
12 
13 // 從容器中獲取實體
14 $user = $container->get(UserInterfacle::class);
15 
16 $user instanceof UserInterface; //  true

當一個類的實體在容器中生成, 或者一個方法被容器呼叫時, 就可以方便地實作依賴注入.

簡單來說, 容器通過反射機制可獲取目標方法的依賴 ( laravel 用反射來獲取 typehint 型別約束, 而 Swoft專案似乎與spring 相似, 是從注釋上獲取的).

然后容器查找是否已注冊了依賴 (dependency) 的實作 (resolver), 如果已注冊, 就從容器中生成該依賴, 再注入給目標方法.

具有依賴注入能力的容器, 我們稱之為 IoC (控制反轉) 容器. 關于IoC 容器的好處不是本文重點, 先跳過去了.

IoC 容器的請求隔離問題

容器最典型的應用場景之一, 就是持有單例. 但在 swoole 等引擎上, 一個 worker 行程要回應多個請求, 單例的資料就容易相互污染.

例如我們把 session 的資料放在一個 SessionInterface 中, 每個邏輯呼叫時都用容器來取:

$sessionInstance = container()->make(SessionInterface::class);

由于單例在容器內只生成一次, 那第二次請求時, 容器會給出第一次請求的session單例, 從而邏輯就亂套了.

所以容器要運行在 swoole 等引擎上, 必須做到請求與請求相隔離.

常見的解決策略

由于 Laravel 等使用了IoC 容器的專案能帶來極好的工程體驗, 而Swoole 能帶來極大的性能提升, 于是有許多試圖結合兩者的專案, 都面臨了 “請求隔離問題”.

我個人看到過的解決策略有以下三種, 都能一定程度解決問題, 但也有美中不足之處.

克隆策略:

方案: 每次請求, 克隆一個新的 container
問題:

要遞回地 clone 屬性, 才能避免淺拷貝導致的污染
無法區分行程共享的單例, 和請求隔離的單例.

清洗策略:

方案: 每次請求結束時, 主動清洗掉已注冊的單例
問題:

定義類時就要考慮清洗邏輯, 可能要實作interface, 耦合較重
swoole 發展到協程后, 同時可能相應多個請求, 清晰策略失效了.

重新注冊:

方案: 每個請求到來時, 實體化一個新容器, 重新注冊所有服務
問題:

注冊服務其實開銷很大, 尤其是需要大量讀檔案的初始化(比如翻譯組件)
無法區分行程共享的單例, 和請求隔離的單例.
利用不了 swoole 的優勢, 比起多行程模型只少了 composer autoloader 的加載.

CommuneChatbot 遇到的請求隔離問題

多輪對話機器人框架 CommuneChatbot 在啟動時需要加載大量多輪對話的邏輯, 消耗時間長 (>100ms), 但實際回應對話的時間不到 10ms. 所以本專案必須使用 swoole 這類引擎, 不可能用PHP天生的多行程, 那樣就只是一個低性能的玩具了.

另一方面, 為了實作

可配置化
組件化
面向介面編程
靈活的閉包

等 feature, CommuneChatbot 嚴重依賴 IoC 容器. 所以識別要解決請求隔離的問題.

由于原有三種策略的不足之處都是本專案無法繞開的, 因此設計了 “雙容器策略”.

CommuneChatbot 的雙容器策略

本專案使用的雙容器策略是一個通用的策略, 代碼在 https://github.com/thirdgerb/container, 是由 Illuminate/Container 專案修改而來.

暫未發布版本, clone 后可以查看實作.

簡單來說, 就是在一個 worker 行程中, 存在兩種級別的容器:

行程級容器: 一個行程只有一個實體
請求級容器: 每一個請求擁有一個獨立的實體

“行程級” 與 “請求級” 容器分開注冊服務

CommuneChatbot 中, 類似 laravel 的 serviceProvider 分兩處注冊.

 1 // 在worker中注冊的服務, 多個請求共享
 2 'processProviders' => [
 3 
 4     // 基礎組件加載
 5     Studio\Providers\StudioServiceProvider::class,
 6     // 默認的情感單元, 可以把意圖或者message 映射成情感
 7     Studio\Providers\FeelingServiceProvider::class,
 8 
 9 ],
10 
11 // 在conversation開始時才注冊服務, 其單例在每個請求之間是隔離的.
12 'conversationProviders' => [
13 
14     // 資料讀寫的組件, 用到了laravel DB 的redis 和 mysql
15     \Commune\Chatbot\Laravel\Providers\LaravelDBServiceProvider::class,
16     // 各種權限功能的管理.
17     Studio\Providers\AbilitiesServiceProvider::class,
18 
19 ],

服務開發者不需要太多考慮是行程級, 還是請求級, 只要避免用到靜態屬性. 系統搭建者才要考慮

“請求級”容器持有”行程級”容器

CommuneChatbot 使用 trait 改造了 laravel 的 illuminate/container, 以此為基礎實作了遞回容器 RecursiveContainer.

 1 trait RecursiveContainer
 2 {
 3     use ContainerTrait;
 4     /**
 5      * 不用靜態屬性, 靜態屬性在子類繼承上會有問題.
 6      *
 7      * @var ContainerContract
 8      */
 9     protected $parentContainer;
10     /**
11      * RecursiveContainer constructor.
12      * @param ContainerContract $parentContainer
13      */
14     public function __construct(ContainerContract $parentContainer)
15     {
16         $this->parentContainer = $parentContainer;
17     }
18 
19     public function getParentContainer() : ContainerContract
20     {
21         return $this->parentContainer;
22     }
23 
24     public function has($abstract)
25     {
26         return $this->bound($abstract) || $this->parentContainer->has($abstract);
27     }
28 
29     /**
30      * @param string $abstract
31      * @param array $parameters
32      * @return mixed
33      * @throws
34      */
35     public function make(string $abstract, array $parameters = [])
36     {
37         // 做個最高效的判斷環節. 絕大部分都是單例.
38         if (isset($this->shared[$abstract])) {
39             return $this->shared[$abstract];
40         }
41         // 優先自己系結的物件.
42         // 只有自己沒有系結, 且父容器有系結的情況下, 才通過父類來做實體化.
43         if (!$this->bound($abstract) && $this->parentContainer->has($abstract)) {
44             return $this->parentContainer->make($abstract, $parameters);
45         }
46         return $this->resolve($abstract, $parameters);
47     }

簡單來說, 每個遞回容器都可以持有一個父容器. 如果某個服務呼叫在自己內未注冊, 就會到父容器里查找. 父容器也是遞回容器的話, 就會遞回式查找.

這樣, 行程級共享的單例, 就可以注冊到 “行程級容器” . 而請求相互隔離的單例, 就注冊到 “請求級容器”.

請求內都用 “請求級容器” 來獲取實體, 這樣就充分靈活了.

“請求級” 容器用靜態屬性注冊服務, 動態屬性持有單例

偽代碼如下:

 1 trait ContainerTrait
 2 {
 3 
 4    /**
 5     * 請求級容器持有的單例
 6     * @var array
 7     */
 8    protected $shared = [];
 9 
10    /**
11     * 請求級容器注冊的服務
12     *
13     * @var callable[]
14     */
15    private static $bindings = [];

這樣, 所有服務只需要注冊一次, 但服務的單例在每個請求內會重新生成一次.

“請求級容器” 在worker行程初期boot, 每個請求到來時實體化

CommuneChatbot 中的一個代碼示例

偽代碼如下:

 1 class SwoolServer
 2 {
 3     /**
 4      * Swoole/Server
 5      */
 6     protected $server;
 7 
 8     protected $app;
 9 
10     public function run()
11     {
12         $this->bootstrap();
13     }
14 
15     public function bootstrap()
16     {
17         // 注冊 service provider
18         // 運行 service provider 的boot 方法
19         // 行程級和請求級都在這個環節完成初始化
20         $this->app->bootWorker();
21 
22         $this->server->on(
23             'receive',
24             function($server, $fd, $rid, $data){
25 
26                 // 獲取 請求級容器 的 公共容器.
27                 $container = $this->app->getRequestContainer();
28 
29                 // 實體化一個請求隔離的 容器
30                 $requestContainer = $container->new($server, $fd, $rid, $data);
31 
32                 // 運行請求內的邏輯
33                 $requestContainer->run();
34             }
35         );
36     }
37 
38 
39 }

使用 Laravel Application 作為行程級容器

CommuneChatbot 的 framework 是不依賴大型專案的. 但在開發 Studio 時, 發現還是需要一個類似 Laravel 的全堆疊框架.

所以直接使用了 Laravel 的 Application 做 “行程級容器”, 確保自己請求中用到的核心業務邏輯都不注冊到 laravel中, 避免污染.

由于雙容器策略基于共同的 interface 開發, 所以只需要為 Laravel Application 定制一個 illuminateAdapter 就可以了

防止記憶體泄露

使用 swoole, 如果邏輯寫得不好導致一些物件相互持有, 無法釋放, 則會導致記憶體泄露. 而且 php 目前排查記憶體泄露挺有難度.

使用雙容器技術, 反而某種意義上方便了排查記憶體泄露.

因為 CommuneChatbot 是基于依賴注入來啟動, 運行的, 請求內生成的絕大多數物件都來自于 IoC 容器, 并為之持有.

一旦 IoC 容器自身在請求結束后無法釋放, 就一定發生了請求內的記憶體泄露.

CommuneChatbot 定義的請求級容器, 在 __construct 和 __destruct 方法中做了簡單的埋點, 偽代碼如下:

 1 class Container {
 2 
 3     protected static $running = [];
 4 
 5     protected $traceId;
 6 
 7     public function __construct(string $traceId)
 8     {
 9         $this->traceId = $traceId;
10         self::$running[$traceId] = true;
11     }
12 
13 
14     public function __destruct()
15     {
16         unset(self::$running[$this->traceId]);
17     }

就可以通過靜態屬性查看運行中的 container 實體個數.

CommuneChatbot 甚至在 Demo 中提供了一個 #runningSpy -a 的命令. 在公眾號中隨時輸入它, 可以查看當前 worker 行程中幾個關鍵物件的實體數量.

如果實體數隨請求線性上升, 那就一定是嚴重的記憶體泄露了. 如果只是很少概率的記憶體泄露, 問題還不大. Swoole 有引數 max_request 定期重啟 worker 行程.

就我發現, 最容易導致記憶體泄露的兩種情況:

某個閉包在每次請求時生成一個閉包實體, 被每個容器持有
容器生成的某個服務是匿名類, 導致相互持有

簡單來說, 就是定義閉包和匿名類時, 慎重考慮記憶體泄露的可能性就行.

雙容器策略在 CommuneChatbot 專案中的效果

CommuneChatbot 目前使用雙容器, Demo 在微信公眾號 CommuneChatbot 上運行.

專案默認啟動要 80 ms 以上, 而不用讀寫資料庫完成單個請求平均在 3ms 左右.

[2019-07-20 12:20:03] chatbot.INFO: end chat pipe {"gap":2791,"memory":10485760}

Swoole 除了免去了每次請求啟動系統的開銷之外, 還帶來了額外的性能提升:

由于大量使用 PHP 的反射特性來實作復雜的依賴注入, 所以反射本應該是性能開銷的大頭. 但 PHP 其實有個內部機制, 反射呼叫一次就會快取起來, 下次呼叫的開銷是之前的幾十分之一.

所以用swoole, 還可能提升了整體依賴注入的性能.

微信公眾號上的 CommuneChatbot Demo 目前運行了數千個請求, 查看日志還沒有發生一例記憶體泄露.

行程級容器 Laravel Application 也與 CommuneChatbot 自己的 ConversationContainer 結合得很好. 目前沒發現任何問題.

整體結果令人樂觀, 對我而言這是目前最合適的解決策略.

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/125409.html

標籤：PHP

上一篇：php程式記憶體優化之陣列操作優化

下一篇：[MySQL] docker下安裝使用mysql配置主從復制

PHP 在Swoole中使用雙IoC容器實作無污染的依賴注入

簡介: