Microservices: Kong Gateway 1.4 sieht Änderungen im Datastore

Inhaltsverzeichnis

Das Unternehmen Kong hat Version 1.4 des gleichnamigen Microservices-Gateway veröffentlicht. Als Neuerungen stehen einige Funktionen im Mittelpunkt, mit denen sich Datenbankänderungen besser verwalten lassen. So reagiert das Gateway selbsttätig auf Änderungen in Apache-Cassandra-Clustern und ermöglicht das Einbinden von Funktionen, die auf das Einfügen und Ändern von Datenbankeinträgen reagieren.

Der Seher für Cassandra und DAO

Kong Gateway 1.4 überwacht die Cluster-Topologie der verteilten Open-Source-Datenbank Apache Cassandra, die es als Datastore verwenden kann. Das System passt sich bei Änderungen selbsttätig an und benötigt keinen Neustart bei Änderungen in der Cluster-Topologie. Standardmäßig prüft die Software alle 60 Sekunden die Cluster, und Administratoren können den Wert über die Konfiguration cassandra_refresh_frequency anpassen.

Außerdem kann Kong Gateway auf Änderungen in Datenbanken mit individuellen Funktionen reagieren. Dafür haben DAO-Schemas (Data Access Object) nun die neue Property transformations, über die Entwickler Funktionen definieren, die das System beim Hinzufügen oder Ändern von Datenbankeinträgen aufruft.

Flexibler Proxy

Eine weitere Neuerung ist das optionale Attribut hostname für Upstreams, das einen Host-Header für die Nutzung als Proxy zwischen Verbindungen zwischen Kong-Servern definiert. Hintergrund ist, dass Server oft veränderte Namen verwenden. Der Header soll sicherstellen, dass Kong die korrekten Servernamen beim Einsatz als Proxy und beim Überprüfen des Zustands von Hosts verwendet.

Ein neues Statusinterface ermöglicht Plug-ins die Weitergabe der von Kong ermittelten Zustandsdaten an zusätzliche Endpunkte. Damit lassen sich die Daten an eine breite Zahl von Clients verteilen, ohne dabei die Admin-API von Kong nach außen freizugeben. Außerdem ermöglicht das Interface HTTP-basierte Statusanfragen an Kong-Knoten, die ohne Administrationsschnittstelle laufen.

Außerdem können Administratoren nun über den neuen API Response Header X-Kong-Admin-Latency ermitteln, wie lang die Administations-API von Kong zum Verarbeiten einer Anfrage benötigt. Die neue Konfigurationseinstellung router_update_frequency legt fest, wie oft Kong Router und Plug-ins auf Änderungen überprüft.

Blick zurück und nach vorn

Kong verbindet ein Open-Source-API-Gateway mit einem Load Balancer. Technisch besteht das System aus einer Kombination von Kong Server und dem Kong Datastore zum Speichern und horizontalen Verteilen der Konfiguration. Als technische Grundlage für den Kong Server dient der HTTP-Server Nginx. Der Datastore setzt auf Apache Cassandra oder PostgereSQL.

Das Gateway hat italienische Wurzeln und entstand ursprünglich 2009 in Mailand. Bis zur Umbenennung 2017 hieß das dahinter stehende Unternehmen Mashape, und die Software Kong ist seit 2015 ein Open-Source-Projekt. Daneben existiert ein Enterprise-Produkt, das zusätzliche Funktionen unter anderem zur Amdinistration, für Security und Hochverfügbarkeit bietet.

Weitere Details zu Kong Gateway 1.4 lassen sich dem Blogbeitrag entnehmen. Vor kurzem ist die erste Alpha von Kong 2.0 und Kong Enterprise 2020 erschienen, die vor allem für letztere Variante zahlreiche Neuerungen für das Monitoring und Multiprotokoll-Support bietet. Kong Gateway 2.0 trennt zudem die Daten- von der Kontrollschicht, um es für den hybriden Einsatz zwischen Rechenzentrum und Cloud zu verbessern. (rme)