Simon Kölsch innoQ

„Consul steht in Konkurrenz zu einer ganzen Reihe an weiteren Lösungen, mit denen eine Service Discovery aufgebaut werden kann. Oft sind diese Lösungen allerdings nur Key-Value Stores und müssen entweder durch eigene Services erweitert oder mit anderen Projekten ergänzt werden, um eine vollständige Discovery-Lösung zu bieten.“

HashiCorp hat mit Consul eine inzwischen fest etablierte Service-Discovery-Lösung geschaffen. Ein Konsul ist ein entsandter Beamter, der in einem fremden Staat die Interessen der eigenen Bevölkerung wahrt und den Handel fördert. Betrachtet man eine Microservice-Landschaft als fremdes Land und die Einwohner als einzelne Services, die sich austauschen, kann man mit etwas Wohlwollen die Namensgebung nachvollziehen. Einen Überblick über Einsatzzweck, Features und Aufbau bietet dieser Artikel.

In einer verteilten Systemlandschaft gilt es irgendwann, das Problem zu lösen, wie Services sich gegenseitig im Netz finden. Der einfachste Ansatz ist es, in den betreffenden Services eine feste Konfiguration zu hinterlegen. Meist finden sich dann hinter einem Servicenamen eine IP-Adresse und der dazugehörige Port wieder. Eine etwas dynamischere Lösung ist es, anstatt IP-Adressen einen DNS-Eintrag zu verwenden. Dabei können Adresse und Port z. B. in einem DNS SRV Record hinterlegt werden. Auch ist es möglich, mehreren Instanzen der gleichen Services zur Verfügung zu stellen, indem man ein Round-Robin-Verfahren nutzt. Vereinfacht ausgedrückt wird bei jeder Anfrage die IP-Adresse einer anderen Instanz zurückgegeben.

Welche Probleme löst dann eigentlich noch Consul? Zum reinen Auflösen von Namen und Ports kommen in einem moderneren verteilten System schnell weitere Anforderungen dazu: Services sollen sich oft an einem zentralen API registrieren können. Bereits registrierte Dienste müssen per Health Check auf ihre Erreichbarkeit geprüft werden, um sie im Fehlerfall automatisiert aus der Registry auszutragen. Außerdem ist die Discovery ein fester Teil der Infrastruktur und muss damit natürlich auch eine entsprechende Robustheit und Ausfallsicherheit bieten. Kann mein Service die anderen Systeme nicht finden, ist das oft mit einem Netzwerkausfall gleichzusetzen. Außerdem benötigt man häufig eine zentrale Stelle, um systemweite Konfiguration wie „Feature Toggles“ ablegen zu können. Traditionelle DNS-Server sind mit anderen Zielen entwickelt worden, und eine selbstgebaute Lösung entspricht vom Aufwand eher einem eigenen Projekt. Aus diesem Grund lohnt sich ein Blick auf Consul.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Entwickler Magazin Spezial Vol. 9: Microservices - "Microservices"

Alle Infos zum Heft
275521Consul: Service Discovery für den Microservices-Stack
X
- Gib Deinen Standort ein -
- or -