RoadRunner: PHP ist nicht dazu gemacht, zu sterben, oder Golang kommt zur Hilfe

Hallo, Habr! Bei Badoo arbeiten wir aktiv an der Performance von PHP, da wir ein ziemlich großes System in dieser Sprache haben und die Leistungsfähigkeit eine Frage der Kosteneffizienz ist. Vor über zehn Jahren haben wir dafür PHP-FPM entwickelt, das zunächst eine Sammlung von Patches für PHP war und später in die offizielle Distribution aufgenommen wurde.

In den letzten Jahren hat sich PHP stark weiterentwickelt: der Garbage Collector wurde verbessert, und die Stabilität ist gestiegen – heute ist es problemlos möglich, Daemons und langlebige Skripte in PHP zu schreiben. Das hat es Spiral Scout ermöglicht, einen Schritt weiter zu gehen: Im Gegensatz zu PHP-FPM räumt RoadRunner den Speicher zwischen den Anfragen nicht auf, was einen zusätzlichen Leistungsgewinn bringt (obwohl dieser Ansatz den Entwicklungsprozess komplizierter macht). Wir experimentieren derzeit mit diesem Tool, haben aber noch keine Ergebnisse, die wir teilen könnten. Um das Warten angenehmer zu gestalten, veröffentlichen wir die Übersetzung der RoadRunner-Ankündigung von Spiral Scout.

Der Ansatz in dem Artikel ist uns ähnlich: Bei der Lösung unserer Aufgaben verwenden wir ebenfalls häufig die Kombination aus PHP und Go, wodurch wir die Vorteile beider Sprachen nutzen können, ohne eine für die andere aufzugeben.

Viel Spaß!

In den letzten zehn Jahren haben wir Anwendungen sowohl für Unternehmen auf der Liste der Fortune 500, als auch für Geschäftsmodelle mit weniger als 500 Nutzern entwickelt. Während dieser Zeit haben unsere Ingenieure hauptsächlich den Backend-Bereich mit PHP gestaltet. Vor zwei Jahren haben wir jedoch eine bedeutende Veränderung erlebt, die nicht nur die Leistung unserer Produkte, sondern auch deren Skalierbarkeit erheblich beeinflusste – wir haben Golang (Go) in unseren Technologiestack integriert.

Fast sofort stellten wir fest, dass Go es uns ermöglicht, größere Anwendungen zu erstellen und die Leistung um das 40-Fache zu steigern. Damit konnten wir bestehende Produkte, die in PHP geschrieben waren, erweitern und sie durch eine Kombination der Vorteile beider Sprachen verbessern.

Wir werden erläutern, wie die Verbindung von Go und PHP uns hilft, reale Entwicklungsprobleme zu lösen und wie sie für uns zu einem Werkzeug geworden ist, das uns von Teilen der Probleme befreien kann, die mit dem „Sterben“ von PHP.

Ihrer alltäglichen PHP-Entwicklungsumgebung

Bevor wir erläutern, wie Go das Modell des „Sterbens“ von PHP wiederbeleben kann, lassen Sie uns zunächst Ihre Standard-PHP-Entwicklungsumgebung betrachten.

In den meisten Fällen starten Sie Ihre Anwendung mit einer Kombination aus dem Webserver nginx und dem PHP-FPM-Server. Der erstgenannte bedient statische Dateien und leitet spezifische Anfragen an PHP-FPM weiter, während PHP-FPM den PHP-Code ausführt. Möglicherweise verwenden Sie eine weniger verbreitete Kombination aus Apache und mod_php. Auch wenn sie etwas anders funktioniert, bleiben die Prinzipien die gleichen.

Betrachten wir, wie PHP-FPM den Anwendungscode ausführt. Wenn eine Anfrage eingeht, initialisiert PHP-FPM einen Kindprozess für PHP und übergibt die Details der Anfrage als Teil seines Zustands (_GET, _POST, _SERVER usw.).

Der Zustand kann während der Ausführung des PHP-Skripts nicht verändert werden, daher gibt es nur einen Weg, um einen neuen Satz von Eingabedaten zu erhalten: den Arbeitsspeicher des Prozesses zu leeren und ihn neu zu initialisieren.

Dieses Ausführungsmodell bietet viele Vorteile. Sie müssen sich keine großen Sorgen um den Speicherverbrauch machen, alle Prozesse sind vollständig isoliert, und wenn einer von ihnen 'stirbt', wird er automatisch neu erstellt, ohne die anderen Prozesse zu beeinträchtigen. Allerdings gibt es auch Nachteile, die sich bei der Skalierung der Anwendung zeigen.

Nachteile und Ineffizienz einer herkömmlichen PHP-Umgebung

Wenn Sie professionell mit PHP entwickeln, wissen Sie, wo Sie bei einem neuen Projekt anfangen müssen – bei der Auswahl eines Frameworks. Es handelt sich um Bibliotheken für Dependency Injection, ORM, Übersetzungen und Templates. Und natürlich können Sie alle benutzereingaben bequem in ein einziges Objekt (Symfony/HttpFoundation oder PSR-7) unterbringen. Frameworks sind großartig!

Aber alles hat seinen Preis. Bei jedem Enterprise-Level-Framework müssen Sie für die Verarbeitung einer einfachen Benutzeranfrage oder einer Datenbankabfrage mindestens Dutzende von Dateien laden, zahlreiche Klassen erstellen und mehrere Konfigurationen parsen. Noch schlimmer ist, dass Sie nach Abschluss jeder Aufgabe alles zurücksetzen und von vorne anfangen müssen: Der Code, den Sie gerade initialisiert haben, ist dann nutzlos und kann für eine weitere Anfrage nicht verwendet werden. Erzählen Sie das einem Programmierer, der in einer anderen Sprache arbeitet, und Sie werden das Erstaunen auf seinem Gesicht sehen.

PHP-Entwickler haben jahrelang nach Lösungen für dieses Problem gesucht und durchdachte Methoden wie "Lazy Loading", Microframeworks, optimierte Bibliotheken, Caching usw. verwendet. Letztendlich bleibt jedoch oft keine andere Wahl, als die gesamte Anwendung zurückzusetzen und von vorne zu beginnen, immer wieder. (Anmerkung des Übersetzers: Teilweise wird dieses Problem mit der Einführung preload in PHP 7.4) durch die neuen Funktionen gelöst.

Kann PHP mit Go mehr als eine Anfrage gleichzeitig verarbeiten?

Es ist möglich, PHP-Skripte zu schreiben, die länger als nur einige Minuten laufen (bis zu Stunden oder sogar Tagen): zum Beispiel Cron-Jobs, CSV-Parser oder Queue-Manager. All diese Tools funktionieren nach dem gleichen Prinzip: Sie ziehen eine Aufgabe, führen sie aus und warten auf die nächste. Der Code bleibt dauerhaft im Speicher, was wertvolle Millisekunden spart, da das Laden des Frameworks und der Anwendung zahlreiche zusätzliche Schritte erfordert.

Doch das Entwickeln von langlebigen Skripten ist nicht so einfach. Jeder Fehler kann den Prozess vollständig zum Stillstand bringen, die Diagnose von Speicherlecks kann frustrierend sein, und eine F5-Debugging kann nicht mehr verwendet werden.

Die Situation hat sich mit der Einführung von PHP 7 verbessert: Es gibt jetzt einen zuverlässigen Garbage Collector, das Fehlerhandling ist einfacher und die Kernel-Erweiterungen sind nun vor Speicherlecks geschützt. Dennoch müssen Ingenieure weiterhin sorgfältig mit dem Speicher umgehen und potenzielle Zustandsprobleme im Code beachten (gibt es eine Programmiersprache, bei der man darauf nicht achten muss?). Trotzdem erwarten uns in PHP 7 weniger Überraschungen.

Kann man das Modell der langlebigen PHP-Skripte nehmen, es für trivialere Aufgaben wie die Verarbeitung von HTTP-Anfragen anpassen und so die Notwendigkeit beseitigen, bei jeder Anfrage alles neu zu laden?

Um dieses Ziel zu erreichen, musste zunächst eine Serveranwendung implementiert werden, die in der Lage ist, HTTP-Anfragen anzunehmen und diese nacheinander an einen PHP-Worker weiterzuleiten, ohne ihn dabei jedes Mal neu zu starten.

Wir wussten, dass wir einen Webserver mit reinem PHP (PHP-PM) oder mit einer C-Erweiterung (Swoole) schreiben könnten. Obwohl jede Methode ihre Vorteile hat, waren beide Optionen nicht das, was wir suchten – wir wollten mehr. Wir benötigten nicht einfach einen Webserver – wir strebten eine Lösung an, die uns von den Problemen des »schweren Starts« in PHP befreit und sich leicht an spezifische Anwendungen anpassen und erweitern lässt. Das heißt, wir brauchten einen Anwendungsserver.

Kann Go dabei helfen? Wir wussten, dass es das kann, denn die Sprache kompiliert Anwendungen in einzelne binäre Dateien; sie ist plattformübergreifend; verwendet ein eigenes, sehr elegantes Modell für parallele Verarbeitung (Concurrency) und eine Bibliothek zur Arbeit mit HTTP; und schließlich stehen uns tausende von Open-Source-Bibliotheken und Integrationen zur Verfügung.

Herausforderungen der Kombination von zwei Programmiersprachen

Zunächst musste festgelegt werden, wie zwei oder mehr Anwendungen miteinander kommunizieren.

Zum Beispiel mit einer großartigen Bibliothek Die Nutzung von Alexa Palæstras ermöglichte die gemeinsame Nutzung des Speichers zwischen den PHP- und Go-Prozessen (ähnlich wie mod_php in Apache). Allerdings hat diese Bibliothek Einschränkungen, die ihre Anwendung für unsere Lösung begrenzen.

Wir entschieden uns für einen anderen, weit verbreiteten Ansatz: die Interaktion zwischen den Prozessen über Sockets/Pipelines zu gestalten. Dieser Ansatz hat sich über die letzten Jahrzehnte als zuverlässig erwiesen und wurde auf Betriebssystemebene gut optimiert.

Zunächst erstellten wir ein einfaches binäres Protokoll zum Datenaustausch zwischen den Prozessen und zur Fehlerbehandlung. In seiner einfachsten Form ähnelt dieses Protokoll einem Netstring mit mit einem festen Paketheader (in unserem Fall 17 Byte), der Informationen über den Pakettyp, seine Größe und eine binäre Maske zur Überprüfung der Datenintegrität enthält.

Auf der PHP-Seite verwendeten wir die pack-Funktion, während wir auf der Go-Seite die Bibliothek encoding/binary.

verwendeten. Ein einzelnes Protokoll erschien uns als unzureichend – daher fügten wir die Möglichkeit hinzu, Go-Dienste net/rpc direkt aus PHP aufzurufen.. Später hat uns das bei der Entwicklung sehr geholfen, da wir Go-Bibliotheken leicht in PHP-Anwendungen integrieren konnten. Das Ergebnis dieser Arbeit ist beispielsweise in einem anderen unserer Open-Source-Produkte sichtbar. Goridge.

Aufteilung von Aufgaben auf mehrere PHP-Worker

Nach der Implementierung des Interaktionsmechanismus dachten wir darüber nach, wie wir Aufgaben am effizientesten an die PHP-Prozesse übergeben können. Wenn eine Aufgabe eintrifft, muss der Anwendungsserver einen freien Worker zur Bearbeitung auswählen. Falls der Worker/Prozess mit einem Fehler beendet wurde oder ‚gestorben‘ ist, entfernen wir ihn und erstellen einen neuen. Hat der Worker/Prozess erfolgreich gearbeitet, wird er wieder in den Pool der zur Verfügung stehenden Worker zurückgegeben.

Für die Verwaltung des Pools aktiver Worker haben wir einen gepufferten Kanal, hinzugefügt, um unerwartet ‚gestorbene‘ Worker durch einen Mechanismus zur Fehler- und Statusüberwachung aus dem Pool zu entfernen.

Somit haben wir einen funktionierenden PHP-Server erhalten, der in der Lage ist, beliebige, binär dargestellte Anfragen zu verarbeiten.

Damit unsere Anwendung als Webserver funktioniert, mussten wir einen zuverlässigen PHP-Standard zur Darstellung von eingehenden HTTP-Anfragen wählen. In unserem Fall wandeln wir net/http-Anfragen aus Go in das Format PSR-7, damit es mit den meisten heute verfügbaren PHP-Frameworks kompatibel ist.

Da PSR-7 als unveränderlich angesehen wird (technisch nicht ganz korrekt), müssen Entwickler Anwendungen schreiben, die Anfragen nicht als globale Entität behandeln. Dies passt hervorragend zum Konzept von langlebigen PHP-Prozessen. Unsere endgültige Implementierung, die noch keinen Namen hat, sah so aus:

Wir präsentieren RoadRunner — ein hochperformanter Server für PHP-Anwendungen

Unsere erste Testaufgabe war ein API-Backend, bei dem gelegentlich unvorhersehbare Anstiege bei den Anfragen auftraten (viel häufiger als gewöhnlich). Obwohl die Möglichkeiten von nginx in den meisten Fällen ausreichten, standen wir regelmäßig vor dem Fehler 502, weil wir das System nicht schnell genug auf die erwartete erhöhte Last ausbalancieren konnten.

Um diese Lösung zu ersetzen, haben wir Anfang 2018 unseren ersten PHP/Go-Anwendungsserver bereitgestellt. Und sofort erzielten wir unglaubliche Ergebnisse! Wir haben nicht nur den Fehler 502 vollständig beseitigt, sondern konnten auch die Anzahl der Server um zwei Drittel reduzieren, wodurch wir eine Menge Geld und viele Kopfschmerztabletten für unsere Ingenieure und Produktmanager gespart haben.

Mitte des Jahres verbesserten wir unsere Lösung, veröffentlichten sie auf GitHub unter der MIT-Lizenz und nannten sie RoadRunner, was seine unglaubliche Geschwindigkeit und Effizienz unterstreicht.

Wie RoadRunner Ihren Entwicklungsstack verbessern kann

Anwendung RoadRunner erlaubte es uns, das Middleware net/http auf der Go-Seite zu nutzen, um die JWT-Überprüfung bereits durchzuführen, bevor die Anfrage PHP erreicht, sowie um WebSockets zu verarbeiten und globalen Zustand in Prometheus zu aggregieren.

Dank des eingebauten RPC können wir APIs beliebiger Go-Bibliotheken für PHP öffnen, ohne Wrapper-Erweiterungen schreiben zu müssen. Was noch wichtiger ist, können mit RoadRunner neue Server bereitgestellt werden, die sich von HTTP unterscheiden. Beispielsweise können PHP-Handler gestartet werden, AWS Lambdarobuste Queue-Parser erstellt und sogar gRPC in unsere Anwendungen aufgenommen werden.

Durch die Community-Entwicklungen in PHP und Go haben wir die Stabilität unserer Lösung verbessert. In einigen Tests konnten wir die Anwendungsleistung um das 40-Fache steigern, Debugging-Tools optimieren, die Integration mit dem Symfony-Framework umsetzen und Unterstützung für HTTPS, HTTP/2, Plugins und PSR-17 hinzufügen.

Fazit

Einige bleiben immer noch in der veralteten Vorstellung gefangen, dass PHP eine langsame und schwerfällige Sprache ist, die nur für die Entwicklung von WordPress-Plugins geeignet ist. Diese Personen könnten sogar behaupten, dass PHP eine solche Einschränkung hat: Wenn eine Anwendung groß genug wird, muss man auf eine „reifere“ Sprache wechseln und den über viele Jahre gewachsenen Code neu schreiben.

Darauf möchten wir antworten: Denken Sie noch einmal nach. Wir sind der Meinung, dass nur Sie selbst irgendwelche Einschränkungen für PHP setzen. Sie können Ihr ganzes Leben damit verbringen, von einer Sprache zur anderen zu wechseln, während Sie versuchen, die perfekte Kombination für Ihre Bedürfnisse zu finden, oder Sie können beginnen, Sprachen als Werkzeuge zu betrachten. Die vermeintlichen Nachteile von PHP können tatsächlich Gründe für seinen Erfolg sein. Wenn Sie es mit einer anderen Sprache wie Go kombinieren, schaffen Sie viel leistungsfähigere Produkte, als wenn Sie sich auf eine einzige Sprache beschränken.

Nach der Arbeit mit der Kombination aus Go und PHP können wir sagen, dass wir sie lieben gelernt haben. Wir haben nicht vor, auf eine der beiden zugunsten der anderen zu verzichten – ganz im Gegenteil, wir werden nach Wegen suchen, um noch mehr aus diesem Dual-Stack herauszuholen.

UPD: Wir begrüßen den Schöpfer von RoadRunner und Mitautor des ursprünglichen Artikels – Lachezis

Quelle: habr.com