Mein Server-Setup für eine stark genutzte API

Ich werde bald eine Reihe von Servern für eine Anwendung kaufen, die ich starten werde, aber ich habe Bedenken hinsichtlich meines Setups. Ich freue mich über jedes Feedback, das ich bekomme.

Ich habe eine Anwendung, die eine von mir geschriebene API verwendet. Andere Benutzer / Entwickler werden diese API ebenfalls verwenden. Der API-Server empfängt Anforderungen und leitet sie an Arbeitsserver weiter. Die API enthält nur eine MySQL-Datenbank mit Anforderungen für Protokollierungszwecke, Authentifizierung und Ratenbegrenzung.

Jeder Arbeitsserver erledigt einen anderen Job und in Zukunft werde ich zur Skalierung weitere Arbeitsserver hinzufügen, die für die Übernahme von Jobs verfügbar sind. Die API-Konfigurationsdatei wird bearbeitet, um die neuen Arbeitsserver zu notieren. Die Worker-Server führen einige Verarbeitungen durch und einige speichern einen Pfad zu einem Image in der lokalen Datenbank, um ihn später von der API abzurufen und in meiner Anwendung anzuzeigen. Einige geben Zeichenfolgen des Ergebnisses eines Prozesses zurück und speichern diese in einer lokalen Datenbank .

Sieht dieses Setup für Sie effizient aus? Gibt es einen besseren Weg, dies umzustrukturieren? Welche Punkte sollte ich berücksichtigen? Bitte sehen Sie das Bild unten, ich hoffe, es hilft beim Verständnis.

Höhere Verfügbarkeit

Wie Chris erwähnt, ist Ihr API-Server die einzige Fehlerquelle in Ihrem Layout. Was Sie einrichten, ist eine Nachrichtenwarteschlangeninfrastruktur, die viele Leute zuvor implementiert haben.

Folgen Sie dem gleichen Weg

Sie erwähnen das Empfangen von Anforderungen auf dem API-Server und fügen den Job in eine MySQL-Datenbank ein, die auf jedem Server ausgeführt wird. Wenn Sie diesen Pfad fortsetzen möchten, empfehle ich, die API-Serverebene zu entfernen und die Worker so zu gestalten, dass sie jeweils Befehle direkt von Ihren API-Benutzern akzeptieren. Sie können so etwas wie Round-Robin-DNS verwenden, um jede API-Benutzerverbindung direkt an einen der verfügbaren Arbeitsknoten zu verteilen (und es erneut zu versuchen, wenn eine Verbindung nicht erfolgreich ist).

Verwenden Sie einen Message Queue Server

Robustere Infrastrukturen für die Nachrichtenwarteschlange verwenden für diesen Zweck entwickelte Software wie ActiveMQ . Sie können die RESTful-API von ActiveMQ verwenden, um POST-Anforderungen von API-Benutzern zu akzeptieren, und inaktive Mitarbeiter können die nächste Nachricht in der Warteschlange abrufen. Dies ist jedoch wahrscheinlich ein Overkill für Ihre Anforderungen - es ist auf Latenz, Geschwindigkeit und Millionen von Nachrichten pro Sekunde ausgelegt.

Verwenden Sie Zookeeper

Als Mittelweg möchten Sie vielleicht Zookeeper betrachten , obwohl es sich nicht speziell um einen Nachrichtenwarteschlangenserver handelt. Wir verwenden at $ work genau für diesen Zweck. Wir haben drei Server (analog zu Ihrem API-Server), auf denen die Zookeeper-Serversoftware ausgeführt wird, und ein Web-Frontend für die Bearbeitung von Anforderungen von Benutzern und Anwendungen. Das Web-Frontend sowie die Zookeeper-Backend-Verbindung zu den Workern verfügen über einen Load Balancer, um sicherzustellen, dass die Warteschlange weiterhin verarbeitet wird, auch wenn ein Server wegen Wartungsarbeiten nicht verfügbar ist. Wenn die Arbeit erledigt ist, teilt der Mitarbeiter dem Zookeeper-Cluster mit, dass der Auftrag abgeschlossen ist. Wenn ein Arbeiter stirbt, wird dieser Job zur Fertigstellung an eine andere Arbeit gesendet.

Andere Bedenken

• Stellen Sie sicher, dass Jobs abgeschlossen sind, falls ein Mitarbeiter nicht antwortet
• Woher weiß die API, dass ein Auftrag abgeschlossen ist, und kann ihn aus der Datenbank des Arbeitnehmers abrufen?
• Versuchen Sie, die Komplexität zu reduzieren. Benötigen Sie einen unabhängigen MySQL-Server auf jedem Worker-Knoten oder können diese mit dem MySQL-Server (oder dem replizierten MySQL-Cluster) auf den API-Servern kommunizieren?
• Sicherheit. Kann jemand einen Job einreichen? Gibt es eine Authentifizierung?
• Welcher Arbeiter sollte den nächsten Job bekommen? Sie erwähnen nicht, ob die Aufgaben voraussichtlich 10 ms oder 1 Stunde dauern werden. Wenn sie schnell sind, sollten Sie Ebenen entfernen, um die Latenz gering zu halten. Wenn sie langsam sind, sollten Sie sehr vorsichtig sein, um sicherzustellen, dass kürzere Anfragen nicht hinter ein paar lang laufenden Anfragen hängen bleiben.

Das größte Problem, das ich sehe, ist das Fehlen einer Failover-Planung.

Ihr API-Server ist ein großer Single Point of Failure. Wenn es ausfällt, funktioniert nichts, auch wenn Ihre Worker-Server noch funktionsfähig sind. Wenn ein Worker-Server ausfällt, ist der vom Server bereitgestellte Dienst nicht mehr verfügbar.

Ich schlage vor, dass Sie sich das Linux Virtual Server-Projekt ( http://www.linuxvirtualserver.org/ ) ansehen , um eine Vorstellung davon zu bekommen, wie Lastausgleich und Failover funktionieren, und um eine Vorstellung davon zu bekommen, wie diese Ihrem Design zugute kommen können.

Es gibt viele Möglichkeiten, Ihr System zu strukturieren. Welcher Weg besser ist, ist ein subjektiver Anruf, den Sie am besten beantworten. Ich schlage vor, Sie recherchieren; Abwägen der Kompromisse der verschiedenen Methoden. Wenn Sie Informationen zu einer Implantationsmethode benötigen, senden Sie eine neue Frage.