Bei traditionellen Load-Balancing-Ansätzen wird die Algorithmusauswahl meist auf eine einvariable Liste reduziert: der Reihe nach verteilen, an die wenigsten Verbindungen senden, nach Quelladresse fixieren oder Gewichte verwenden. Dieses Modell mag unter normalem Verkehr ausreichend erscheinen; sobald jedoch eine Kampagne, ein API-Burst, Streaming-Verkehr oder eine plötzliche Benutzerlast einsetzt, bleibt es als alleinige Entscheidungsgrundlage schwach.
Geben beispielsweise zwei Backends dieselbe Antwortzeit, verteilt sich der Verkehr willkürlich, wenn das System keine Möglichkeit für einen zweiten Vergleich hat. Es kann ein Service ausgewählt werden, der zwar eine niedrige Antwortzeit aufweist, aber eine volle Warteschlange hat; ein Service, der wenige Verbindungen zu haben scheint, aber bereits Fehler erzeugt, kann weiterhin Kandidat bleiben.
Diese Unentschlossenheit wirkt sich besonders auf die Extremwerte der Latenz aus. Während die durchschnittliche Antwortzeit akzeptabel erscheint, kann sich die Benutzererfahrung in den hohen Perzentilen verschlechtern. Wenn auch die durch Sicherheit, Zugriffskontrolle oder Anwendungsschicht-Kontrollen hinzugefügte Latenz nicht einberechnet wird, können Kandidaten in den Vordergrund treten, die schnell erscheinen, sich aber tatsächlich langsam verhalten.
Das richtige Modell muss zum Entscheidungszeitpunkt Live-Service-Signale lesen und ungesunde oder im Wartungsmodus befindliche Kandidaten automatisch eliminieren. Ist die Session-Affinität aktiv, darf es die bestehende Benutzerbindung nicht stören; nur bei freien Anfragen sollte es den am besten geeigneten Service auswählen.
Genau das ist das Kernproblem, das Fastest+ Routing löst: die Load-Balancing-Entscheidung nicht an ein einzelnes Label, sondern an das Echtzeit- und zweistufige Service-Verhalten zu binden.
TR7 behandelt Fastest+ Routing mit Live-Signal-Lesen, zweistufiger Bewertung, Gesundheitsbewusstsein und oberflächenbasierter Konfiguration.
Die Entscheidungslogik läuft in die Datenebene eingebettet und liest bei jeder HTTP- oder TCP-Anfrage Live-Service-Statistiken. Der ausgewählte Service wird in die Routing-Variable geschrieben und der Verkehr gemäß dieser Entscheidung weitergeleitet. Der Operator erhält eine dynamische Auswahl pro Anfrage, ohne speziellen Code zu schreiben.
In der ersten Stufe werden die Services mit dem besten Wert im primären Signal in die Kandidatenliste aufgenommen. Teilen sich mehrere Services denselben Score, kommt in der zweiten Stufe das sekundäre Signal zum Einsatz. So werden praktische Entscheidungen wie "bei gleicher Antwortzeit den mit der leereren Warteschlange wählen" innerhalb eines einzigen Algorithmus umgesetzt.
Services im Wartungsmodus oder mit ungeeignetem Gesundheitsstatus werden nicht in die Kandidatenliste aufgenommen. Ist die dynamische Session-Affinität aktiv, wird die Fastest+-Auswahl übersprungen und die bestehende Session-Bindung beibehalten. Dieser Ansatz stört bei der Performance-Optimierung keine Benutzersessions.
Der Operator wählt nur das primäre und das sekundäre Entscheidungssignal. Das System erzeugt die erforderlichen Routing-Zeilen in der Konfigurationserzeugungsphase automatisch. Komplexe Entscheidungslogik wird für den täglichen Betrieb zu einer einfachen Richtlinienauswahl.
Fastest+ Routing bietet fortgeschrittene Routing-Fähigkeiten, die Live-Performance, Gesundheit und Session-Bindung zwischen Backends gemeinsam bewerten.
Wird im primären Entscheidungssignal ein neuer bester Wert gefunden, wird die Kandidatenliste zurückgesetzt; Services, die denselben Wert teilen, werden der Liste hinzugefügt. In der zweiten Stufe werden diese Kandidaten erneut nach dem sekundären Signal eingegrenzt. In der Standardkonfiguration bevorzugt Fastest+ unter den Kandidaten mit niedriger Antwortzeit den Service mit der niedrigeren momentanen Session-Last. Dadurch wird unter den schnell erscheinenden Services derjenige mit der niedrigeren Last bevorzugt.
Der Operator wählt für Fastest+ zwei Entscheidungssignale: durchschnittliche Antwortzeit, Verbindungsaufbauzeit, Wartezeit in der Warteschlange, momentane Session-Last, momentane Warteschlangenauslastung, Verbindungsfehler, clientseitige Fehlerdichte, serverseitige Fehlerdichte, servicebedingte Abbrüche oder genutzte Verbindungskapazität. Diese Signale werden systemintern mit den entsprechenden Live-Service-Zählern verknüpft; der Benutzer befasst sich nicht mit rohen Metriknamen. So kann der Verkehr nicht nur an den "schnell erscheinenden" Service geleitet werden, sondern an das Backend, das in diesem Moment gesünder, leerer oder weniger fehleranfällig ist.
In Service-Pools, in denen kein zweiter Vergleich nötig ist, kann der Einzelsignal-Modus verwendet werden. In diesem Modus wird die Entscheidung nur nach dem besten Wert des ausgewählten primären Signals getroffen. Für einfachere Service-Gruppen wird keine unnötige Entscheidungstiefe hinzugefügt. Der Operator kann sowohl den Einzelsignal- als auch den Zweisignal-Modus über dieselbe Oberfläche verwalten.
Befindet sich ein Backend im Wartungsmodus oder ist sein Gesundheitsstatus ungeeignet, gelangt es nicht in die Kandidatenliste. Dieses Verhalten ist in den Algorithmus eingebettet; es erfordert keine zusätzliche manuelle Regel, keine zusätzliche Zugriffskontrollliste und keinen operativen Eingriff. Geplante Wartung, Ausgliederung problematischer Services und vorübergehende Service-Entfernung wirken sich automatisch auf die Verkehrsentscheidung aus. So wählt das System nur unter geeigneten Kandidaten aus.
Wenn die Bedingungen der Session-Affinität erfüllt sind, wird die Fastest+-Auswahl deaktiviert. Die Anfrage wird an den Service geleitet, der durch die bestehende Sticky-Session-Logik bestimmt wurde. Die erzeugte Routing-Bedingung wird vom System transparent konfiguriert. Dadurch verdrängt die Performance-Optimierung nicht die Kontinuität der Benutzersession.
Fastest+ kann sowohl in der HTTP-Anfragephase als auch in der TCP-Content-Inspection-Phase laufen. Bei TCP-Services wird das für die Entscheidung erforderliche Inspektionsfenster automatisch erzeugt. So werden Anwendungsschicht-Verkehr und TCP-basierte Services in demselben Verwaltungsmodell behandelt. Der Operator muss nicht je nach Service-Typ unterschiedliche Produktlogiken erlernen.
Wird die dynamische Affinität verwendet, läuft Fastest+ nur für Clients, die noch keine fixierte Session haben. Während bestehende Sessions beibehalten werden, werden neue oder freie Anfragen nach Live-Signalen verteilt. Dieses Modell bietet einen ausgewogenen Ansatz für sowohl Benutzerkontinuität als auch momentane Kapazitätsnutzung. Besonders unter hohem und schwankendem Verkehr trägt es zu einer effizienteren Nutzung des Service-Pools bei.
Wird im Entscheidungsprozess kein geeignetes Backend gefunden, bleibt die spezielle Routing-Entscheidung leer. In diesem Fall greift das Standard-Load-Balancing-Verhalten. In Situationen, in denen das System keine spezielle Routing-Entscheidung erzeugen kann, kehrt es zum bekannten Standardverhalten zurück, statt den Verkehr ins Leere fallen zu lassen. Diese Rückfalllogik reduziert operative Risiken.
Fastest+ Routing ist nicht nur eine Algorithmusauswahl; es ist zusammen mit Hochverfügbarkeit, Sichtbarkeit, Reload- und Integrationsverhalten konzipiert.
Die Entscheidungslogik wird beim Service-Start geladen und als zwei separate Actions definiert: Einzelsignal und Zweisignal. Die Einzelsignal-Action arbeitet mit einem Entscheidungs-Input, die Zweisignal-Action mit zwei Entscheidungs-Inputs. Die Actions können in den HTTP- und TCP-Anfragephasen verwendet werden.
Service-Statistiken werden aus einer In-Memory-Tabelle gelesen; es ist kein zusätzlicher Socket, kein Dateilesevorgang und keine externe Abfrage erforderlich. Der Entscheidungsprozess führt einen linearen Scan nach Anzahl der Services durch. Diese Struktur hält die Routing-Entscheidung selbst in Pools mit zahlreichen Backends nahe an der Datenebene.
In einer Hochverfügbarkeitsinstallation mit zwei Nodes führt jeder Node denselben Algorithmus unabhängig aus. Da Live-Signale Node-lokal ausgewertet werden, trifft der neue aktive Node nach einem Failover weiterhin Entscheidungen mit den von ihm selbst beobachteten Statistiken. Es entsteht keine Abhängigkeit von einem externen gemeinsamen Score-Speicher.
Das ausgewählte Backend wird in der Routing-Variable gehalten und kann dem Logformat hinzugefügt werden. Dadurch kann rückblickend untersucht werden, welche Anfrage an welchen Service geleitet wurde. Operationsteams können Verkehrsentscheidungen nicht nur als Ergebnis, sondern als nachverfolgbaren Routing-Trail sehen.
Während eines Soft-Reloads wird der Entscheidungskontext neu geladen und der Algorithmus startet mit einem neuen Speicherzustand. Da keine historische Antwortzeit-Beobachtung übertragen wird, basieren die Entscheidungen bei den ersten Anfragen auf den aktuellen momentanen Daten. Dass Konfigurationsänderungen ohne Neustart des Pools angewendet werden können, reduziert operative Unterbrechungen.
Blockiert die WAAP-Schicht eine Anfrage, wird Fastest+ nicht aufgerufen; so wird keine unnötige Service-Auswahl getroffen. Fastest+ gilt nur in HTTP- und TCP-Service-Pools. In Layer-4-Services werden die Layer-4-Algorithmusoptionen der Plattform verwendet.
In intensiven Verkaufsphasen erhalten zahlreiche Backends gleichzeitig Verkehr. Fastest+ bewertet Signale wie Antwortzeit und Warteschlangenauslastung gemeinsam und verhindert, dass schnelle, aber mit voller Warteschlange ausgestattete Services unnötig in den Vordergrund treten. Das Ergebnis ist eine ausgewogenere Service-Nutzung und eine kontrolliertere Benutzererfahrung.
In finanziellen API-Schichten reicht eine schnelle Antwort allein nicht aus; auch das Fehlererzeugungsverhalten muss Teil der Entscheidung sein. Fastest+ kann Services mit niedriger serverseitiger Fehlerdichte in den Vordergrund stellen und bei Gleichstand die momentane Session-Last berücksichtigen. Diese Struktur ermöglicht eine bewusstere Verteilung bei kritischem API-Verkehr.
Bei Streaming- und Media-Verkehr liefert der am wenigsten belastete Node nicht immer die beste Benutzererfahrung. Fastest+ bewertet mit der Kombination aus genutzter Verbindungskapazität und Antwortzeit sowohl die aktuelle Verbindungsnutzung als auch das Antwortverhalten gemeinsam. So wird eine präzisere Verkehrsverteilung zwischen Edge-Services erreicht.
In Multi-Tenant-Strukturen kann jede zu einem Tenant gehörende Service-Gruppe ein unterschiedliches Verhalten zeigen. Fastest+ kann mit Signalen wie servicebedingten Abbrüchen und Verbindungsaufbauzeit die stabiler arbeitenden Services bevorzugen. Dieser Ansatz macht die tenant-basierte Servicequalität besser verwaltbar.
Zweistufige, mit Live-Signalen und ohne Code zu schreiben konfigurierte Verkehrsverteilung. Lassen Sie uns das in einer Live-Einrichtung auf Ihren eigenen Services durchgehen.