Service Discovery
Adressen von Diensten nachschlagen
Die Idee und ihr Nutzen
Der Schadendienst einer Versicherung, das Programm für die Schadenbearbeitung, fragt für jeden neuen Schaden den Vertragsdienst, der die Versicherungsverträge verwaltet, ob der Vertrag den Schaden abdeckt. Der Vertragsdienst läuft in mehreren Instanzen, also mehreren gleichzeitig laufenden Exemplaren desselben Programms, auf verschiedenen Servern, jede unter einer eigenen Netzwerkadresse. Weil alle Instanzen dasselbe Programm sind, kann jede von ihnen jede Deckungsanfrage beantworten. Wird eine Instanz neu gestartet oder ersetzt, ändert sich ihre Adresse oft, und eine im Schadendienst fest eingetragene Adresse wäre dann falsch. Deshalb meldet sich jede Instanz beim Start in einem Dienstverzeichnis an, einem Programm, das zu jedem Dienstnamen die Adressen der laufenden Instanzen führt. Der Schadendienst fragt das Dienstverzeichnis nach den aktuellen Adressen und nutzt so auch neue Instanzen, ohne dass jemand seine Einstellungen ändert. Dieses Nachschlagen heißt Service Discovery, auf Deutsch Dienstsuche.
Wie funktioniert es?
Beim Start meldet sich Kopie 1, die erste Instanz des Vertragsdienstes, mit dem Namen „Vertragsdienst“ und ihrer Adresse A beim Dienstverzeichnis an. Kopie 2, die zweite Instanz, meldet sich ebenso mit Adresse B an. Der Schadendienst soll für einen neuen Schaden die Deckung prüfen. Er fragt das Dienstverzeichnis nach dem „Vertragsdienst“ und erhält zunächst Adresse A. Seine Deckungsanfrage schickt der Schadendienst direkt an Kopie 1, nicht über das Dienstverzeichnis, und Kopie 1 antwortet „gedeckt“. Kurz darauf stoppt das Betriebsteam, das die Dienste betreibt, Kopie 1 für eine Wartung. Das Dienstverzeichnis prüft regelmäßig, ob jede angemeldete Instanz noch antwortet. Kopie 1 antwortet nicht mehr, und das Dienstverzeichnis entfernt Adresse A. Bei der nächsten Deckungsprüfung fragt der Schadendienst erneut beim Dienstverzeichnis nach, erhält nur noch Adresse B und schickt die Anfrage an Kopie 2, die sie beantwortet.
Statt der regelmäßigen Prüfung kann das Dienstverzeichnis auch verlangen, dass jede Instanz ihre Anmeldung in kurzen Abständen erneuert; sonst verfällt ihr Eintrag. Der Schadendienst kennt nur den Namen „Vertragsdienst“ und die Adresse des Dienstverzeichnisses, und er wählt selbst eine der Adressen aus, die er erhält. Dasselbe gilt für jeden anderen Dienst, der den Vertragsdienst aufruft. Aufrufende Dienste merken sich erhaltene Adressen oft für eine Weile, damit sie nicht vor jedem Aufruf nachfragen müssen. Weil sich Adressen jederzeit ändern können, brauchen gemerkte Adressen eine Ablaufzeit, nach der der aufrufende Dienst wieder beim Dienstverzeichnis nachfragt. Das Dienstverzeichnis liefert nur Adressen. Ob ein Vertrag den Schaden abdeckt, entscheidet allein der Vertragsdienst.
In einer zweiten Variante schickt der Schadendienst jede Anfrage zuerst an einen Vermittler, der das Nachschlagen und die Auswahl der Instanz übernimmt. Ein solcher Vermittler ist ein Programm, das Anfragen entgegennimmt und an eine Instanz weiterleitet. Meist ist das ein Lastverteiler, ein Programm, das Anfragen auf mehrere Instanzen verteilt. Der Schadendienst kennt dann nur die feste Adresse des Vermittlers. Der Vermittler fragt das Dienstverzeichnis nach den Adressen und leitet die Anfrage an eine der Instanzen weiter.
Stürzt eine Instanz ab, bleibt ihr Eintrag bis zur nächsten Prüfung oder bis zum Ablauf ihrer Anmeldung im Dienstverzeichnis, und der Schadendienst kann in dieser Zeit noch ihre Adresse erhalten. Auch sonst kann die gewählte Instanz zwischen Auskunft und Aufruf ausfallen. Der Schadendienst braucht deshalb weiterhin eine Zeitgrenze für seine Anfrage und eine Regel, ob er es nach einem Fehler bei einer anderen Instanz erneut versucht. Scheitert seine Anfrage an der Zeitgrenze, weiß der Schadendienst nicht, ob die Anfrage beim Vertragsdienst noch angekommen ist. Eine reine Deckungsprüfung lässt sich aber gefahrlos wiederholen, weil sie beim Vertragsdienst nichts verändert.
Service Discovery: der Schadendienst findet die laufende Kopie über das Verzeichnis
Wann ist es sinnvoll und wann nicht?
Service Discovery lohnt sich
- Instanzen von Diensten kommen häufig hinzu, fallen weg oder wechseln ihre Adressen. Das geschieht etwa, wenn die Zahl der Instanzen automatisch angepasst wird oder Dienste regelmäßig aktualisiert werden. Eine fest eingetragene Adresse wäre dann oft veraltet, und der Schadendienst schickte seine Anfragen an eine Instanz, die es nicht mehr gibt. Das Dienstverzeichnis führt dagegen stets die Adressen der laufenden Instanzen.
- Bei Lastspitzen sollen zusätzliche Instanzen sofort genutzt werden. Nach einem Sturm melden Kunden viele Schäden, und das Betriebsteam startet zwei zusätzliche Instanzen des Vertragsdienstes. Ohne Service Discovery müsste das Betriebsteam die neuen Adressen erst in die Einstellungen des Schadendienstes eintragen. Mit Service Discovery nutzt der Schadendienst die neuen Instanzen, ohne dass jemand seine Einstellungen ändert.
- Mehrere Dienste rufen denselben Dienst auf. Stünden die Adressen fest in den Einstellungen, müsste das Betriebsteam bei jeder Änderung die Einstellungen jedes aufrufenden Dienstes anpassen. Bis eine veraltete Adresse überall entfernt ist, schicken manche Dienste ihre Anfragen an eine Adresse, unter der niemand mehr antwortet, und diese Anfragen scheitern.
Service Discovery ist nicht das Richtige
- Es gibt nur wenige Dienste, und sie laufen dauerhaft unter derselben Adresse, etwa wenn der Vertragsdienst nur in einer einzigen Instanz auf einem festen Server läuft. Ein Dienstverzeichnis hätte dann nur Adressen zu führen, die sich kaum ändern. Dann trägt das Betriebsteam für jeden Dienst einen festen Namen im Domain Name System ein, abgekürzt DNS, dem Verzeichnis, das im Internet und in Firmennetzen Namen in Netzwerkadressen übersetzt. Bei einem seltenen Umzug ändert das Betriebsteam nur die Adresse zu diesem Namen im DNS. Ein eigenes Dienstverzeichnis, das ausfallsicher betrieben werden muss, entfällt.
- Die Plattform, auf der die Dienste laufen, also die Software, die die Instanzen auf den Servern startet, bietet das Nachschlagen bereits selbst an. Die Plattform kennt die Adressen ohnehin, weil sie die Instanzen selbst startet. Dann schlagen die aufrufenden Dienste die Adressen bei der Plattform nach. Das Betriebsteam muss kein eigenes Dienstverzeichnis betreiben, das dieselben Adressen ein zweites Mal führt.
- Das Betriebsteam kann kein Dienstverzeichnis ausfallsicher betreiben. Ein Dienstverzeichnis ohne Ausfallschutz würde bei einem Ausfall alle neuen Aufrufe aufhalten, obwohl alle Instanzen des Vertragsdienstes laufen. Dann trägt das Betriebsteam die Adressen fest in die Einstellungen der aufrufenden Dienste ein. Ändert sich die Adresse einer Instanz, trägt das Betriebsteam die neue Adresse dort von Hand ein.
- Kein aufrufender Dienst soll eigenen Code für das Nachschlagen brauchen, und es soll auch kein Dienstverzeichnis betrieben werden. Schlägt der Schadendienst selbst im Dienstverzeichnis nach, braucht er Code, der nachschlägt und eine Instanz auswählt. Dann schickt der Schadendienst jede Deckungsanfrage an einen Lastverteiler, wie ihn Load Balancing beschreibt. Der Lastverteiler bekommt die Adressen der Instanzen von der Plattform und leitet jede Anfrage an eine der Instanzen weiter. Der Schadendienst kennt nur die feste Adresse des Lastverteilers und braucht keinen Code für das Nachschlagen.
- Das Betriebsteam will für Nachschlagen und Weiterleiten nur ein einziges Programm betreiben. Bei Service Discovery mit Vermittler sind das zwei Programme, der Vermittler und das Dienstverzeichnis, das der Vermittler fragt. Dann richtet das Betriebsteam einen Broker ein, wie ihn das Broker Pattern beschreibt. Die Instanzen des Vertragsdienstes melden sich direkt beim Broker an. Der Schadendienst schickt jede Deckungsanfrage an den Broker, und der Broker leitet sie an eine der Instanzen weiter. Ein getrenntes Dienstverzeichnis muss das Betriebsteam dann nicht betreiben.
Nachteile und typische Fehler
Alle aufrufenden Dienste hängen vom Dienstverzeichnis ab. Das Dienstverzeichnis braucht deshalb einen eigenen Ausfallschutz. Das Betriebsteam muss festlegen, wie Instanzen sich anmelden, wie oft das Dienstverzeichnis ihre Erreichbarkeit prüft und wie lange aufrufende Dienste sich Adressen merken dürfen. Schlägt jeder aufrufende Dienst selbst nach, braucht jeder von ihnen Code für Nachschlagen und Auswahl. Sind die aufrufenden Dienste in verschiedenen Programmiersprachen geschrieben, muss dieser Code für jede Sprache eigens entstehen. Außerdem muss jeder aufrufende Dienst angepasst werden, wenn das Dienstverzeichnis ausgetauscht wird. Schicken die aufrufenden Dienste ihre Anfragen stattdessen an einen Vermittler, der nachschlägt, entfällt dieser Code. Dafür geht jede Anfrage zusätzlich über den Vermittler, und auch der Vermittler muss ausfallsicher betrieben werden.
Typische Fehler und woran man sie erkennt:
- Ausgefallenes Dienstverzeichnis: Das Dienstverzeichnis fällt aus. Der Schadendienst fragt nach dem „Vertragsdienst“ und erhält keine Adresse. Der Schadendienst kann dann keine Deckung prüfen, obwohl Kopie 2 läuft. Nur Adressen, die sich ein aufrufender Dienst schon gemerkt hat, kann er bis zu ihrer Ablaufzeit weiter nutzen. Erkennbar ist das an gescheiterten Nachfragen beim Dienstverzeichnis, während alle Instanzen des Vertragsdienstes laufen.
- Verwaister Eintrag: Eine Instanz des Vertragsdienstes stürzt ab. Bis zur nächsten Prüfung bleibt ihr Eintrag im Dienstverzeichnis, und das Dienstverzeichnis liefert dem Schadendienst noch ihre Adresse. Der Schadendienst schickt seine Deckungsanfrage an die abgestürzte Instanz und wartet bis zu seiner Zeitgrenze vergeblich auf eine Antwort. Erkennbar ist das an Zeitüberschreitungen, die sich auf eine einzelne Adresse häufen.
- Zu lange gemerkte Adresse: Der Schadendienst merkt sich Adresse A länger als vereinbart und schickt Anfragen weiter an die gestoppte Kopie 1. Erkennbar ist das an Fehlern nur beim Schadendienst, während andere aufrufende Dienste Kopie 2 erreichen.
- Kein zweiter Versuch: Die gewählte Instanz fällt zwischen Auskunft und Aufruf aus, und der Schadendienst hat weder eine Zeitgrenze noch eine Regel für einen zweiten Versuch. Erkennbar ist das an Deckungsprüfungen, die hängen bleiben oder scheitern, obwohl eine andere Instanz bereitsteht.
Weiterführend
Verwandte Ansätze
- Health Checks: die regelmäßigen Zustandsabfragen, mit denen das Dienstverzeichnis prüft, ob eine angemeldete Instanz noch antwortet.
- Timeout: begrenzt, wie lange der Schadendienst auf eine Instanz wartet, die zwischen Auskunft und Aufruf ausgefallen ist.
- Service Mesh: stellt jedem Dienst ein Hilfsprogramm zur Seite, das unter anderem das Nachschlagen im Dienstverzeichnis für diesen Dienst übernehmen kann.
Quellen
- Chris Richardson: Service registry: beschreibt das Dienstverzeichnis mit Anmeldung beim Start, Abmeldung beim Stoppen und Prüfung der Erreichbarkeit und betont, dass es hochverfügbar sein muss.
- Chris Richardson: Client-side service discovery: beschreibt, wie der aufrufende Dienst selbst im Verzeichnis nachschlägt und eine Instanz wählt, und nennt die Bindung jedes Aufrufers an das Verzeichnis als Nachteil.
- Chris Richardson: Server-side service discovery: beschreibt die Variante mit einem vorgeschalteten Vermittler unter fester Adresse und den zusätzlichen Umweg, den jede Anfrage über diesen Vermittler nimmt.