it-swarm.com.de

Implementieren von Heartbeat mit REST API

Ich habe einen Server, der API über REST verfügbar macht. Ich muss einen einfachen Heartbeat-Dienst implementieren, um diesen Serverstatus und die Verfügbarkeit der API zu überwachen. Das Intervall der Herzschlagprüfung beträgt alle paar Sekunden, wie alle 3 Sekunden.

Ist es gut genug, nur einen REST Endpunkt (z. B. Ping) zu definieren, der den Status des Servers und der API zurückgibt? Die Clientseite ruft diese REST API alle paar Sekunden auf.

Oder sollte ich wirklich daran denken, etwas wie WebSocket zu verwenden, um diesen Heartbeat-Service hinzuzufügen?

5
ryen

Ist es gut genug, nur einen REST Endpunkt (z. B. Ping) zu definieren, der den Status des Servers und der API zurückgibt? Die Clientseite ruft diese REST API alle paar Sekunden auf.

Hängt davon ab. Es ist wichtig, die Häufigkeit der Häufigkeit mit der Parallelität abzugleichen, da eine Handvoll Clients Pings ausführen Der Server verursacht möglicherweise keine spürbare Belastung, Hunderte oder Tausende von Clients jedoch. Stellen Sie sich vor, 1000, 10000, 100000 Clients senden alle 3 Sekunden Pings. Der Höhepunkt wird Ihren Server wahrscheinlich ins Schwitzen bringen.

HTTP-Verbindungen sind auf beiden Seiten teuer, zuverlässig, aber langsam und insgesamt sie blockieren die E/A-Kommunikation . Etwas, das Sie abmildern müssen, wenn Ihr System häufig einer hohen Parallelität ausgesetzt ist. Wenn die Parallelität jedoch gering ist, ist eine RESTful-Lösung mehr als ausreichend. Es ist zuverlässig, sicher und lässt sich gut skalieren.

Andererseits blockiert die Kommunikation über WebSockets nicht, sie funktioniert recht gut bei hoher Parallelität, wenn Client und Server wenig Informationen austauschen und die Rechenzeit auf beiden Seiten kurz ist. Dies ist der Fall bei Herzschlägen. Darüber hinaus implementiert WebSockets ein "Ping-Pong" -Protokoll in seinem "Control Frame", über das Sie das erwartete Verhalten erzielen können. Weitere Informationen finden Sie unter [~ # ~] rfc [~ # ~] .

Ob WebSockets oder HTTP REST Endpunkte verwendet werden, hängt meiner Meinung nach von der Parallelität und ihrer Häufigkeit ab.

Ich würde auch ein paar Dinge berücksichtigen:

  • Ob Clients neue Kommunikationsprotokolle übernehmen können (oder nicht). Wenn sie nicht können, gibt es keinen Raum für Diskussionen.

  • Gibt an, ob Sie mit der Infrastruktur WebSockets verfügbar machen können. Ich habe für Kunden mit sehr strengen Netzwerkregeln gearbeitet, bei denen fast alles (außer SMTP, SFTP, HTTPS) nicht zulässig war.

Nehmen wir an, wir erwarten immer noch eine hohe Parallelität, implementieren jedoch aus irgendeinem Grund keine WebSockets. Wenn ich dazu aufgefordert würde, würde ich den Server lieber dazu bringen, seinen Status mit einer festen Verzögerung irgendwo zu "pushen". Dann würde ich die Verantwortung übertragen, den Status einem anderen Dienst auszusetzen, der Async I/O unterstützt (wie zum Beispiel NodeJS). Dann würde ich Anfragen an diesen neuen Dienst umleiten. Mit anderen Worten, leiten Sie den Stress der Pings zu einem dedizierten und performanten Service um.

Ich würde den Kunden sagen, dass sie den zuletzt abgerufenen Status behalten sollen. Wenn sich der Status bei weiteren Anforderungen nicht ändert, meldet der Dienst wahrscheinlich seinen Status nicht und auf der Serverseite stimmt etwas nicht. Dieser Ansatz lässt sich gut skalieren, da Sie den Status mehrerer Dienste beibehalten, ohne deren jeweilige Leistung zu beeinträchtigen, und sie als Ganzes oder unabhängig von einem einzelnen Endpunkt aus verfolgen können.

8
Laiv

Meiner Meinung nach sollten Sie sich einfach an REST halten. Sie müssen kein weiteres Protokoll/keine weitere Technologie mit allen damit verbundenen potenziellen Problemen hinzufügen, während Sie nicht einmal Funktionen von WebSockets benötigen. Auch diese Lösung bleibt so nah wie möglich an der eigentlichen API. Es besteht (abhängig von der Implementierung) eine winzige Möglichkeit, dass das WebSocket geöffnet bleibt, während die REST API) keine neuen Anforderungen akzeptiert.

Auch eine ziemlich kampferprobte Technologie namens Spring Actuator erledigt dies über REST Endpunkte, obwohl dies mehr als nur das Überprüfen auf Herzschläge ist.

Ich stimme @Laiv zu und habe ihm eine +1 gegeben, möchte aber eine kleine Gedankenübung für Sie hinzufügen.

Was soll dir der Herzschlag sagen und wer soll ihn überprüfen?

Ich weiß, dass du denkst, du hast die erste Frage beantwortet, aber nicht wirklich.

Sie sagten, "um die Verfügbarkeit von Diensten und APIs zu überwachen". Umfasst das nur die eigentlichen API-Prozesse? Oder meinen Sie aus einer konsumierenden Anwendungsperspektive? Wenn Ihre API funktioniert, aber ein Client sie nicht treffen kann, weil die Firewall oder der Load Balancer falsch konfiguriert sind, sollte dies den Herzschlag unterbrechen? Was ist, wenn Sie auf mehrere Server verteilt sind? Ist es Ihnen wichtig, dass einer ausfällt, aber zwei in Betrieb sind? Was passiert, wenn Ihre API von Upstream-Inhalten wie einer Datenbank oder einem Drittanbieter-Service abhängig ist? Überprüft der Heartbeat dies auch?

Was die Frage „Wer“ betrifft, möchten Sie, dass alle Ihre Kunden den Heartbeat-Service nutzen und Ihre Verfügbarkeit überprüfen, oder sollten Sie dies im Auge behalten? Wie viele Informationen soll der Herzschlag ihnen zeigen?

Insgesamt bin ich nicht mit dem Prinzip einverstanden, dass ein Heartbeat-Service in den meisten Fällen speziell verwaltet und gewartet wird. Ich kann nicht genug von Ihrer Frage bekommen, um festzustellen, ob Ihre eine der Ausnahmen ist, aber im Allgemeinen würde ich eine robuste Protokollierung und einen Protokollaggregator wie ElasticStack oder NewRelic bevorzugen, um die Überwachung bereitzustellen, und wenn ich sie wirklich testen möchte, funktioniert das Zeug End-to-End aus Client-Sicht würde ich dies für einen oder mehrere der vorhandenen GET-Endpunkte tun oder sogar nur Clients einrichten, die regelmäßig eine Reihe von Integrationstests ausführen können, um mehrere wichtige Endpunkte zu erreichen (mit Rückverfolgbarkeit auf „ Testkonto, um Artefakte zu bereinigen), aber das würde nicht alle 3 Minuten sein (und muss es auch nicht sein, wenn die Protokollierungsinfrastruktur richtig konfiguriert ist).

0
Paul