The Doppler Quarterly (DEUTSCHE) Frühjahr 2018 | Page 66

Serviceerkennung

Sie müssen das hohe Maß an Komplexität , das mit diesen äußerst skalierbaren und entkoppelten Architekturen verbunden ist , unter Kontrolle behalten . Sie haben keine einzelne monolithische , einfache Anwendung mehr , über die Sie sich Gedanken machen müssen . Stattdessen arbeiten Sie jetzt mit einem in hohem Maße verteilten System mit komplexen Interaktionen , die effizient geplant , auf Fehler überwacht und vermittelt werden müssen , um Konflikte zwischen Ressourcen wie Ports und IP-Adressen zu vermeiden . Wir können zum Beispiel erlauben , dass Docker zufällige Ports für uns zuordnet , aber wie erfahren andere Services , welche Ports sie nutzen sollen ? Hinzu kommt : Ein verteiltes System , das Hunderte oder Tausende einzelner Computer ausführt , stellt eine hochdynamische Umgebung dar . In dieser Größenordnung werden Fehler als Norm und nicht als Ausnahme betrachtet . Wenn physische Nodes hinzugefügt und wieder entfernt werden , fallen Container-Pods aus und werden anderen Nodes im Cluster zugeordnet . Weitere Probleme sind die Vermeidung von Konflikten , die Erkennung von Services und die Sicherstellung einer effizienten Planung .

Tools für die Serviceerkennung sind für die Koordination all dieser Services erforderlich , ohne dass eine langwierige manuelle Konfiguration im gesamten Cluster notwendig ist . Im Kern ist ein Erkennungsservice ein persistenter Schlüsselwertspeicher , der selbst skalierbar und fehlertolerant sein muss , damit er nicht zu einem Engpass oder Single Point of Failure wird . Tools für die Serviceerkennung können auf verteilten Schlüsselwertspeichern wie ZooKeeper und etcd erstellt werden , bei denen sich Services selbst registrieren , sodass andere Services ihre Endpunkte finden können . Consul von HashiCorp ist ein weiteres verfügbares Tool . Dabei handelt es sich um ein Serviceerkennungssystem mit Batterien , das horizontal skalierbar ist und Statusprüfungen , Benachrichtigungen und ein persistentes Register enthält .

Serverlos

Serverlose Architekturen , die manchmal auch Function as a Service , kurz FaaS , genannt werden , stellen eine Plattform für flüchtige Services bereit , die für eine kurze Dauer ausgeführt und von klar definierten Ereignissen ausgelöst werden . Die bekannteste FaaS ist AWS Lambda . Statt eine Gruppe von Containern in einer reservierten EC2-Instanz auszuführen , für die Sie unabhängig von der Aktivität des Codes innerhalb dieser Instanz bezahlen , können Sie Ihren Code in Lambda implementieren . Lambda wird nur geplant und ausgeführt , wenn es notwendig ist ( d . h . ausgelöst durch eine Ereigniswarteschlange ). Mit Lambda definieren Sie die Ereigniswarteschlange , die Sie zu Ihrer Funktion hinzufügen wollen , und wenn das Ereignis eintritt , plant Lambda Ihre Funktion , führt sie aus ( wodurch möglicherweise Ereignisse in Warteschlangen erstellt werden , die andere Funktionen auslösen ) und beendet die Funktion beim Exit .

Der AWS-Service Alexa ist in Kombination mit den benutzerdefinierten Skills , die in AWS Lambda implementiert sind , ein sehr gutes praktisches Beispiel für FaaS . Über den AWS-Alexa-Service können Sie Ihr Alexa-Gerät registrieren und einen benutzerdefinierten Skill erstellen , der über eine Reihe von definierten Sprachbefehlen aufgerufen werden kann . So können Sie Ihr Alexa-Gerät personalisieren . Beispielsweise können Sie auf einfache Weise einen benutzerdefinierten Skill erstellen , bei dem Alexa bei der Aufforderung „ Alexa , sag mir etwas Inspirierendes “ mit einem inspirierenden Zitat für den jeweiligen Tag antwortet . Eine solche Personalisierung könnte implementiert werden , indem ein Skill im Alexa-Service definiert wird , der aus „ Äußerungen “ oder Sprachfragmenten ( z . B . „ sag mir etwas Inspirierendes “) besteht . Diese können zur Assoziation einer Absicht verwendet werden , die eine Funktion auslöst ,

Sie arbeiten jetzt mit einem in hohem Maße verteilten System mit komplexen Interaktionen , die effizient geplant , auf Fehler überwacht und vermittelt werden müssen , um Konflikte zwischen Ressourcen wie Ports und IP-Adressen zu vermeiden .

64 | THE DOPPLER | FRÜHJAHR 2018