Oftmals greift man in Symfony-Projekten auf CLI-Kommandos mit Hilfe der Symfony Console-Komponente zurück, um länger laufende Prozesse außerhalb des Webservers durchzuführen. In komplexeren Vorhaben gibt es weitere Ansätze, wie etwa eine Job Queue oder die noch relativ junge Symfony Messenger-Komponente. Diese haben gemeinsam, dass sie eine bestimmte Struktur voraussetzen. Für die Umstellung von Legacy-Code, in dem selbstgeschriebene Jobs mit ReactPHP Event-Loops zum Einsatz kommen, haben wir vorerst einen anderen Weg gewählt, um diese Worker in Einklang mit Symfony zu bringen.
Schritt 1 - ein gemeinsamer CLI-Einstiegspunkt
Zunächst haben wir ein generisches CLI-Kommando gebaut, mit dem die unterschiedlichen Jobs über einen einheitlichen Aufruf gestartet werden können. Dies hat erst einmal einige Redundanzen eliminiert. Zum Starten etwaiger untergeordneter Jobs gibt es die Möglichkeit, andere Commands programmatisch aufzurufen.
Nun gab es nur noch ein Problem: die ReactPHP-basierten Event-Loops laufen permanent und triggern regelmäßig weitere Kindprozesse zur Abwicklung anstehender Aufgaben. CLI-Kommandos sind aber nicht asynchron.
Schritt 2 - das Ganze asynchron machen
Um die Tasks nun im Hintergrund ausführen zu können, wird das KrloveAsyncServiceCallBundle verwendet. Zum Einsatz kommt konkret dieser Fork, der das Bundle kompatibel zu neueren Symfony-Versionen anbietet.
Dieses Bundle ermöglicht es, beliebige Services zu starten, entweder unter Nutzung von exec oder der Symfony Process-Komponente.
Die interne Funktionsweise des Bundles besteht darin, ein Symfony CLI-Command (krlove:service:call) im Hintergrund zu starten, welches dann die Ausführung der gewünschten Funktionalität übernimmt.
Schritt 3 - beides zusammen bringen
Unser eigenes CLI-Command arbeitet nunmehr in zwei verschiedenen Modi: wird ein optionales debug-Argument angegeben, startet es den gewünschten Job synchron im Vordergrund. Ohne dieses Argument fungiert es hingegen als Wrapper und ruft wiederum das oben beschriebene Bundle auf, um die eigentliche Ausführung des gewünschten Jobs mit Hilfe dessen CLI-Commands im Hintergrund zu starten. Also zusammengefasst ruft das eigene Command den Service des Bundles auf, welcher das Command des Bundles als Prozess im Hintergrund aufruft, der dann schließlich den eigenen Job ausführt.
Weitere Informationen
Um zu sehen, wie das Bundle intern arbeitet, empfiehlt sich erstens die Lektüre der Dokumentation und darüber hinaus ein Einblick in die Quelltexte.