Zehn Diskussionen zur Linux-Hochleistungsnetzwerkprogrammierung

Die zehn technischen Blogs von „Ten Talks on Linux High-Performance Network Programming“ wurden mehrere Monate lang geschrieben. Ich dachte, ich würde eine Zusammenfassung meiner beiden Erfahrungen in den letzten Jahren schreiben ist fast 8 Obwohl ich viel Zeit damit verbracht habe, an Schrauben zu arbeiten, habe ich dennoch viel aus meiner Erfahrung in der Entwicklung der Hochleistungsarchitektur gelernt, von der Teilnahme über die Optimierung bis hin zum endgültigen Entwurf der Architektur.

1. Design im Voraus oder Geschäftsentwicklung?

Jeder sollte den Prozess eines Projekts von 0 bis 1 erlebt haben. Ich möchte eine Frage stellen: Entwickelt sich die Architektur in vielen Fällen mit dem Unternehmen weiter oder wird sie im Voraus entworfen

Einige Leute haben möglicherweise verwandte Architekturbücher studiert. Die meisten dieser Bücher glauben, dass sich Architektur mit der Geschäftsentwicklung weiterentwickelt. Allerdings gibt es auch viele Architekten, die darauf bestehen, dass Architektur im Voraus entworfen werden sollte. Hier werde ich vorerst keine Schlussfolgerungen ziehen, sondern die Entwicklung der Architektur anhand meiner eigenen Erfahrung untersuchen.

2. Von PHP nach C++

2.1 Einfache PHP-Architektur

PHP sollte als einfache und praktische Sprache in allen Abteilungen großer Fabriken vorhanden sein. Damals habe ich zwei Sprachen für die Arbeit verwendet: C++ und PHP, um Funktionen zu entwickeln Es gibt viele ausgereifte Bibliotheken, daher wurde die klassische Nginx-+PHP-FPM+Memcache-Architektur gebildet.

php-Architektur

Unter der aktuellen Architektur stellt es für eine einzelne 8c8g-Maschine kein großes Problem dar, 1000 qps zu unterstützen. Für Unternehmen sind es derzeit also weniger als 1 wqps. Offensichtlich können einige weitere Maschinen dies unterstützen. In Bezug auf das Design der Cache-Ebene war Memcache zu dieser Zeit die gängige Cache-Komponente, als Redis noch nicht gut entwickelt war, und es war einfach für Unternehmen und das Andocken an PHP. Mit der Geschäftsentwicklung könnte es jedoch laut der damaligen Berechnungskurve innerhalb eines Jahres 5 WQPS erreichen. Ist es sinnvoll, Nginx + PHP-FPM + Memcache-Architektur zu verwenden? Seite, also starteten wir eine leistungsstarke Entdeckungsreise.

2.2 Multiprozess-Framework

Um ein leistungsstarkes serverseitiges Framework zu implementieren, versuchten die Leute damals einige Lösungen. Eine davon bestand darin, die PHP-Plugin-Funktion zu verwenden, um die Funktionen des Servers in die Skriptsprache zu integrieren. Dieser Ansatz erreicht das Ziel einer hohen Leistung bis zu einem gewissen Grad. Beispielsweise ist PHPs Swoole jetzt ein Entwicklungsergebnis dieser Methode.

php-server

Allerdings wird es hier einige Probleme geben, die gelöst werden müssen:

Machen Sie sich mit den Einsatzszenarien von PHP-Erweiterungen vertraut, um Fallstricke zu vermeiden

• Speicherleckproblem bei der Verwendung von PHP selbst
• Die Kosten für die Fehlerbehebung, wenn ein Problem auftritt. Wenn beispielsweise ein Problem auftritt, müssen wir manchmal den PHP-Quellcode verstehen, aber bei Hunderttausenden Codezeilen sind diese Kosten ziemlich hoch
PHP ist relativ einfach zu verwenden. Mit dem Aufstieg von Docker wird das PHP-Ökosystem zwangsläufig vorübergehen.
• …
Basierend auf der obigen Überlegung und Analyse der Geschäftsentwicklung ist es für uns tatsächlich sinnvoller, einen Server selbst zu implementieren oder das vorhandene C++-Framework zu verwenden, um eine Reihe von Business-Layer-Servern zu implementieren. Daher haben wir nach Überlegung das SPP-Framework des Unternehmens übernommen , dessen Architektur wie folgt ist:

SPP-Framework-Architektur

Es ist ersichtlich, dass SPP eine Multiprozessarchitektur ist. Seine Architektur ähnelt Nginx und ist in Proxy-Prozesse und Worker-Prozesse unterteilt, darunter:

Der Proxy-Prozess verwendet handle_init, um die Initialisierung durchzuführen, handle_route wird an den angegebenen Verarbeitungsprozess des Ausführungsarbeiters weitergeleitet und handle_input verarbeitet den Paketeintrag der Anforderung

Der Arbeitsprozess verwendet handle_init, um die Initialisierung durchzuführen, handle_process verarbeitet das Paket und die Geschäftslogik und gibt zurück

Nach der Verwendung der C++-Architektur wird die Leistung einer einzelnen Maschine direkt auf 6 kqps verbessert, was im Wesentlichen den Leistungsanforderungen entspricht. Es scheint, dass die Architektur stabilisiert werden kann.
2.3 Einführung in Coroutinen

Die Verwendung von C++ hat die Leistungsanforderungen erfüllt, es gibt jedoch viele Probleme bei der Entwicklungseffizienz, z. B. beim Zugriff auf Redis. Um die hohe Leistung des Dienstes aufrechtzuerhalten, verwendet die Codelogik asynchrone Rückrufe, ähnlich den folgenden:

...
int ret = redis->GetString(k, getValueCallback)
...

GetValueCallback ist die Rückruffunktion. Selbst wenn sie in einer ähnlichen Synchronisierungsmethode gekapselt ist, ist die Handhabung von std::future sehr schwierig std::async wurden nicht eingeführt.

Auf der anderen Seite werden Coroutinen aufgrund der Tatsache, dass nachfolgende QPS das Niveau von 10 bis 20 W erreichen können, mehr Vorteile bei der Leistung der Multi-IO-Dienstverarbeitung haben. Daher haben wir begonnen, die Coroutine-Methode zu transformieren und alle IO-Stellen zu ersetzen Mit Coroutinen sieht der Code für die Geschäftsentwicklung wie folgt aus:

...
int ret = redis->GetString(k, value)
...

Der Wert ist der Rückgabewert, der direkt verwendet werden kann. Sobald io im Code vorhanden ist, ersetzt die unterste Ebene io durch die API der Coroutine. Auf diese Weise werden alle blockierten io-Operationen zu Synchronisationsprimitiven, Codestruktur und Die Entwicklungseffizienz hat sich erheblich verbessert (Informationen zur spezifischen Coroutine-Implementierung finden Sie in der Artikelreihe „Zehn Vorträge zur Linux-Hochleistungs-Netzwerkprogrammierung | Coroutinen“).

Coroutine

Es gibt immer noch nicht viele Änderungen in der Architektur. Der Multiprozess + Coroutine-Ansatz unterstützt die Geschäftsentwicklung seit mehreren Jahren. Obwohl es kein exponentielles Leistungswachstum gibt, haben wir mehr Erfahrung in der Hochleistungsexploration und -ausfällung gesammelt.

3. Cloud-nativ

Das Geschäft entwickelt sich weiter und Ingenieure verfolgen stets die modernsten Konzepte. Cloud Native ist in den letzten Jahren ein beliebter Technologiepunkt, der jedoch vor dem Einstieg in Cloud Native nicht ignoriert werden kann Das DevOps-Entwicklungskonzept wird ein schmerzhafter Prozess sein, der die Rückzahlung technischer Schulden für Architekturdesign und Framework-Auswahl erfordert.

3.1 DevOps-Konzept umsetzen

In der Vergangenheit habe ich bei der Architektur über hohe Leistung nachgedacht. Aufgrund meines Verständnisses von Architektur ist hohe Leistung nur ein kleiner Bereich des Architekturdesigns. Wenn Sie eine gute Architektur erstellen möchten, benötigen Sie agilere Prozesse Die spezifischen Überlegungen werden wie folgt zusammengefasst:

• Kontinuierliche Integration: Entwickler integrieren Code mehrmals täglich in ein gemeinsames Repository, und jede einzelne Änderung am Code wird sofort getestet, um Integrationsprobleme zu erkennen und zu verhindern
• Continuous Delivery: Continuous Delivery (CD) stellt sicher, dass jede im CI-Repository getestete Codeversion zur Veröffentlichung bereit ist
• Kontinuierliche Bereitstellung: Dies umfasst die Graustufenbereitstellung, die Blau-Grün-Veröffentlichung usw. Der Zweck besteht darin, nach relativ vollständigen Integrationstests eine Graustufenüberprüfung zu erreichen
Serviceerkennung: Verwandeln Sie Services in Microservices, um Anrufe zwischen Services zu vereinfachen
RPC-Framework: Das Server-Framework, das eine hohe Leistung anstrebt, muss auch die Unterstützung grundlegender Komponenten wie Strombegrenzung und Leistungsschalter berücksichtigen
Überwachungssystem: Integriert in Promethues, OpenTracing und andere Funktionen, kann es Online-Probleme im agilen Entwicklungsprozess schnell erkennen
Containerisierung: Um die Umgebung zu vereinheitlichen und Cloud-native-Szenarien im Voraus zu berücksichtigen, ist Containerisierung im Entwicklungsprozess unerlässlich
…

DevOps

An diesem Punkt werden Sie feststellen, dass ein einfacher Hochleistungsserver zum Ziel der Architektur geworden ist. Daher ist es notwendig, die Architektur erneut zu untersuchen und zu entwerfen, um das DevOps-Konzept erfolgreich umzusetzen.

3.2 Multithreading

Basierend auf DevOps in Kombination mit dem oben genannten C++-Server-Framework wurde festgestellt, dass Multiprozesse die Anforderungen der Architektur nicht mehr erfüllen können. Die Gründe sind folgende:

Mehrere Prozesse stehen im Widerspruch zum Einzelprozesskonzept von Docker-Containern
Worker-Prozessauslastung ist ungleichmäßig, wie man Multi-Cores besser nutzt
Effektive Schnittstelle zum Überwachungssystem
Die Business-Konfiguration wird immer wieder geladen und das Konfigurationscenter muss neu angepasst werden
Es ist nicht sehr sinnvoll, mehrere Prozesse zur Bereitstellung zustandsbehafteter Dienste zu verwenden
…

Das Geschäft ist auch auf eine Million QPS gewachsen, um das Servicemanagement und die Serviceanrufkosten zu verbessern, müssen wir eine andere Architektur in Betracht ziehen:

(1)Recherche zu gRPC

gRPC

gRPC ist ein Multithread-RPC

Server. Er verfügt über ein ausgereiftes Ökosystem, verschiedene Middleware, unterstützt mehrere Sprachen usw. Er ist eine gute Wahl für die Geschäftsentwicklung von 0 auf 1, steht jedoch vor Herausforderungen bei der Geschäftsmigration, z Ihre eigene Middleware-Anpassungsdiensterkennung, Konfigurationszentrale usw., Transformationsprotokoll gemäß benutzerdefinierter Codierung und Decodierung, Kombination von Coroutinen usw., damit einige Unternehmen zufrieden sein können, aber noch besser in den RPC
Server integriert werden müssen der Komponenten des Unternehmens.

(2)Verwenden Sie tRPC

Es kam vor, dass tRPC im Unternehmen entwickelt wurde. Nach einer Recherche stellten wir fest, dass es im Wesentlichen den Anforderungen entsprach, und versuchten daher, die C++-Version von tRPC in den frühen Entwicklungsstadien an unser System anzupassen. Das leistungsstarke RPC-Framework wurde migriert und im Geschäftssystem verwendet. Nun die Architektur von tRPC:

https://trpc.group/zh/docs/what-is-trpc/archtecture_design/

Basierend auf den oben genannten Überlegungen und der Geschäftsentwicklung begannen wir zu versuchen, das RPC-Server-Framework basierend auf hoher Leistung zu vereinheitlichen, um es an nachfolgende RPC-diversifizierte Szenarien anzupassen. Daher implementierten wir einen Basissatz von RPC

Server, der sich an unser Geschäftssystem anpasst. Rahmen:

Neue Architektur

3.3. Gehe zu k8s

Nachdem wir die obige Auswahl und Transformation durchlaufen haben, können unsere Dienste während der Migration zu k8s Schritt für Schritt verbunden werden. Der Dienst muss nicht allzu viele Transformationen durchlaufen, um auf seiner Plattform ausgeführt zu werden, und jede Plattform, mit der er verbunden ist, kann dies auch tun voll unterstützt.

Es scheint, dass Sie einfach neuere Technologien verfolgen und auf den nächsten Trend warten können? Aufgrund der Bequemlichkeit der Cloud und der ungeordneten Ausweitung der Migrationsdienstarchitektur gibt es Geschäftsdienste und logische Ebenen Gleichzeitig werden die Downstream-Links, auf die ein Dienst angewiesen ist, immer länger. Obwohl unser Framework die Linkverfolgung unterstützt, wird die Kontrollierbarkeit und Stabilität des Dienstes immer schlechter Es wird mehr menschliche Unterstützung für die täglichen Einsätze verschwendet.

Was tun?…

Sollten wir die Geschäftslogik zusammenführen und die Architektur vereinfachen? Das Problem besteht darin, dass der Zyklus bei komplexer Geschäftslogik oft lange dauert, aus Kostengründen relativ hoch ist und die Vorteile nicht sehr groß sind.

Sollten wir eine neue Architektur neu entwickeln, die verfallenen Architekturen so belassen, wie sie sind, oder sie aufgeben und neue Architekturen verwenden, um sie an die nächste Entwicklung anzupassen?

Das obige ist der detaillierte Inhalt vonZehn Diskussionen zur Linux-Hochleistungsnetzwerkprogrammierung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!