7 Minuten Lesezeit (1439 Worte)

Service Registry & Discovery - Kein ewiges Suchspiel in der Microservices-Landschaft

Donnerstag, 01. März 2018

Um stabile und hochwertige Software schnell ausliefern zu können, müssen die Unternehmen auf Veränderungen flexibel reagieren. Dazu gehört auch die IT des Unternehmens und damit die eingesetzten Tools und Technologien. Die Microservices-Architektur ermöglicht bereits durch die Struktur der Software, dass neue oder geänderte Anforderungen schnell umzusetzen und auszuliefern sind. Die Kommunikation zwischen den einzelnen Microservices spielt bei dieser Architektur eine große Rolle. Dementsprechend muss es einen Weg geben, um in der Microservices-Landschaft einzelne Microservices zu finden und somit auch ansprechen zu können.

Was sind Microservices?

Viele große Unternehmen wie Netflix, Amazon oder Otto nutzen erfolgreich Microservices. Aber was versteht man überhaupt darunter? Microservices sind ein Architekturmuster, bei welchem die Anwendung aus vielen kleinen Diensten zusammengesetzt wird. Diese Dienste setzen jeweils eine bestimmte Aufgabe um, sind alleine für diese verantwortlich und sollen leicht zu verstehen sein. Funktional zusammengehöriger Programmcode wird so zusammengehalten. Jeder Microservice ist ein eigenständiges Gebilde und kommuniziert mit den anderen Services durch Aufrufe über das Netzwerk, sodass diese nicht fest miteinander gekoppelt sind.

Vorteile von Microservices

Die Verwendung von Microservices bringt viele verschiedene Vorteile mit sich. Unter anderem sorgt die Eigenständigkeit der Dienste dafür, dass jeder Microservice eine andere Technologie einsetzen kann. Anstatt sich für die gesamte Anwendung für beispielsweise eine Programmiersprache zu entscheiden, kann bei jedem Service – und somit bei jeder zu erledigenden Aufgabe – die Technologie ausgewählt werden, die dafür am besten geeignet ist. Auch die Speicherung der benötigten Daten kann auf verschiedene Arten umgesetzt werden. Zusätzlich können die einzelnen Dienste unabhängig voneinander deployed werden, sodass neue Funktionen unabhängig vom restlichen System zur Verfügung gestellt werden.

Der modulare Aufbau sorgt dafür, dass jeder Dienst beliebig wiederverwendet werden kann. Die in den Microservices gekapselten Funktionalitäten können auf verschiedene Weisen im System eingesetzt werden. Zusätzlich ist der Aufwand für das Ersetzen eines Services ziemlich gering, da eine neue Implementierung durch dessen geringe Größe relativ schnell durchgeführt ist. Eine verbesserte Umsetzung der Funktionalität oder der Einsatz neuer bzw. anderer Technologien, kann so schnell realisiert werden. Außerdem können die Microservices aufgrund ihrer Eigenständigkeit ohne weitere Probleme entfernt oder ausgetauscht werden, wenn einzelne oder sogar alle Dienste nicht mehr zu gebrauchen sind.

Service Registry & Discovery

Eine Microservices-Architektur besteht aus vielen kleinen, eigenständigen Diensten, die miteinander über das Netzwerk kommunizieren. Damit diese Kommunikation gelingt, müssen die Dienste andere Microservices finden und somit ansprechen können. Demnach wird eine zentrale Adressverwaltung für die Microservices benötigt. Zudem kann es praktisch sein, alle vorhandenen beziehungsweise laufenden Services zu kennen. Es erleichtert unter Umständen die Arbeit des Entwicklers, wenn dieser weiß, welche Funktionalitäten bereits implementiert sind und wo diese zu finden sind.

Die Adressverwaltung der Microservices ist nur möglich, wenn dieser Dienst aus zwei Teilen besteht: zuerst muss es einen Mechanismus geben, um einen Dienst anzumelden bzw. zu registrieren. Dies wird als Service Registry bezeichnet und enthält ein Verzeichnis aller laufenden Services mit deren jeweiligen Netzwerkadresse. Dann muss es außerdem einen Weg geben, um einen bestimmten Microservice mithilfe dieses Verzeichnisses zu finden. Dies wird als Service Discovery bezeichnet.

Es gibt verschiedene Möglichkeiten diese Mechanismen umzusetzen. Bei der sogenannten Self Registration sind die Services selbst für die Registrierung zuständig. Beim Starten eines Services muss dieser sich mit seiner Netzwerkadresse an der Service Registry anmelden. Die Registrierung muss in periodischen Abständen erneuert werden, damit die Service Registry weiß, dass der Service noch aktiv ist. Auch beim Stoppen eines Services meldet sich dieser eigenständig von der Registrierungseinheit ab. Dieses Verfahren ist in Abbildung 1 dargestellt.

Eine andere Variante ist die 3rd-Party-Registration, bei der ein Service Manager für die Verwaltung der Services an der Service Registry zuständig ist. Beim Starten eines Services wird dieser angemeldet, beim Stoppen abgemeldet. Außerdem erkennt der Service Manager, wenn ein Service abstürzt.

Service Discovery kann client- oder serverseitig geschehen. Bei der Client-Side Service Discovery fragt der Client die Netzwerkadresse des gewünschten Services bei der Service Registry an und kann nach Erhalt der Adresse mit dem Service kommunizieren (siehe Abbildung 2). Bei der Server-Side Service Discovery wiederum kommuniziert der Client mit einem ihm bekannten Router, wenn er einen Service benutzen möchte. Dieser fragt die Service Registry nach der Netzwerkadresse des Service und ruft diesen danach auf.

Abb. 1: Self Registration

Abb. 2: Client-Side Service Discovery

Beispiel Eureka

Netflix als einer der Vorreiter der Microservices-Architektur hat in den letzten Jahren einige Open Source Frameworks veröffentlicht. Das Spring-Team hat daraufhin Spring Boot mit einigen Netflix-Bibliotheken in dem Projekt „Spring Cloud Netflix" integriert. Dort wird die bekannte Autokonfiguration von Spring Boot mit eingebunden und ermöglicht durch einfache Annotationen die entsprechenden Komponenten von Netflix zu integrieren, konfigurieren und zu nutzen. Im Netflix-Stack übernimmt Eureka die Aufgabe der Service Registry & Discovery. Dabei werden Self Registration und Client-Side Service Discovery verwendet.

Eureka-Server

Der Eureka-Server ist die zentrale Anlaufstelle für die Eureka-Clients – also die Microservices – und wird als eigen- ständiger Dienst innerhalb einer Microservices-Architektur betrieben. Da dieser die Service Registry bereitstellt, kennt der Eureka-Server alle angemeldeten Clients. Auskunft über deren Status und einige Serverdetails gibt das mitgelieferte Dashboard, welches in Abbildung 3 dargestellt ist.

Um den Eureka-Server nutzen zu können, muss die Abhängigkeit spring-cloud-starter-eureka-server in der Maven pom.xml angegeben werden. Durch die Annotation @EnableEurekaServer wird die Service Registry in einer regulären Spring-Applikation aktiviert. Die Umsetzung dessen ist in Abbildung 4 gezeigt.

Abb. 3: Eureka-Dashboard

@EnableEurekaServer
@SpringBootApplication
public class EurekaApplication {
           public static void main(String[] args) {
              SpringApplication.run(EurekaApplication.class, args);
     }
}

Abb. 4: Aktivierung des Eureka Server

Die Service Registry muss nun noch konfiguriert werden, da dieser als Standard versucht sich selbst auch zu registrieren. Außerdem muss ein HTTP-Port angegeben werden, auf welchem der Server laufen soll. Die Konfiguration im YAML-Format ist in Abbildung 5 dargestellt.

eureka:
     instance:
        hostname: localhost
        client: # Not a client, don’t register with yourself
           registerWithEureka: false
           fetchRegistry: false
server:
    port: 1111 # HTTP port

Abb. 5: Konfiguration des Eureka-Server

Eureka-Client

Eureka-Clients können sowohl als Application Clients als auch als Application Services auftreten. Application Clients sind Dienste, die andere Dienste kontaktieren möchten und dafür die Netzwerkadresse beim Eureka-Server anfragen. Application Services bieten selbst Dienste an und werden daher vom Client am Eureka-Server registriert. Nach der Registrierung ist ein Heartbeat-Prozess dafür zuständig, in regelmäßigen Abständen dem Eureka-Server den aktuellen Status zu übermitteln. Fehlen die Heartbeats eine längere Zeit über, so wird der Service als inaktiv markiert und danach aus der Serviceliste entfernt. Oftmals ist es so, dass ein Dienst beide Funktionen (Client und Service) bereitstellt. Daher werden beim Eureka-Client diese beiden Typen nicht voneinander getrennt.
Um den Eureka-Client nutzen zu können, muss die Abhängigkeit spring-cloud-starter-eureka in der Maven pom.xml angegeben werden. Die Registrierung des Client am Eureka-Server erfolgt durch die Annotation @EnableDiscoveryClient in der Spring-Applikation, die den Dienst implementiert. Dies ist in Abbildung 6 dargestellt:

@EnableDiscoveryClient
@SpringBootApplication
public class ClientApplication {
    public static void main(String[] args) {
    SpringApplication.run(ClientApplication.class, args);
    }
}

Abb. 6: Aktivierung des Eureka-Client

Der Eureka-Client muss nun noch konfiguriert werden. Zum einen benötigt dieser einen Namen mit dem er angesprochen werden kann und einen Port auf dem die Applikation laufen soll. Zum anderen muss angegeben werden, unter welcher URL der Eureka-Server zu finden ist. Die Konfiguration im YAML-Format ist in Abbildung 7 gezeigt.

# Spring Properties
spring:
        application:
           name: myService
# Discovery Server Access
eureka:
          client:
            serviceUrl:
            defaultZone: http://localhost:1111/eureka/
# HTTP port
server:
      port: 2000

Abb. 7: Konfiguration des Eureka-Client

Fazit

Um in einem System voller kleiner und eigenständiger Microservices die Kommunikation unter den verschiedenen Diensten zu ermöglichen, muss es eine Adressverwaltung geben. An der sogenannten Service Registry melden sich die Microservices an und bei Bedarf auch wieder ab. Service Discovery wird der Mechanismus des Auffindens eines bestimmten Microservice anhand des Adressverzeichnisses genannt. Eureka zum Beispiel übernimmt die Aufgaben von Service Registry & Discovery und kann in Spring Boot relativ leicht eingebunden und genutzt werden. Eureka ist aber nur eine von vielen Möglichkeiten – eine Alternative hierzu ist beispielsweise Consul von HashiCorp [1].

Links

[1] Produktseite Consul: https://www.consul.io/

[Q1] Newman, Sam (2015): „Microservices: Konzeption und Design", MITP-Verlags GmbH & Co. KG

[Q2] Thönes, Johannes (2015): „Microservices: Software Engineering, In: IEEE Software, Januar/Februar, S. 113-116

[Q3] Pelka, Carsten und Michael Plöd (2017): „Microservices à la Netflix: Die Bestandteile von Spring Cloud Netflix", In: Java Magazin, 1, S. 110–113

[Q4] Richardson, Chris (2016): „Microservices: From Design to Deployment"

[Q5] Richardson, Chris (2017): „Pattern: Self Registration" http://microservices.io/patterns/self-registration.html

[Q6] Richardson, Chris (2017): „Pattern: 3rd Party Registration" http://microservices.io/patterns/3rd-party-registration.html

[Q7] Richardson, Chris (2017): „Pattern: Client-side service discovery" http://microservices.io/patterns/client-side-discovery.html

[Q8] Richardson, Chris (2017): „Pattern: Server-side service discovery" http://microservices.io/patterns/server-side-discovery.html

[Q9] Long, Josh (2015): „Microservice Registration and Discovery with Spring Cloud and Netflix's Eureka", Hrsg. Pivotal Software https://spring.io/blog/2015/01/20/microservice-registration-and-discovery- with-spring-cloud-and-netflix-s-eureka

Cover Credit: https://auth0.com/blog/getting-a-competitive-edge-with-a-microservices-based-architecture/

Veronika Schäfers

Alle Beiträge anzeigen

Consultant bei ORDIX

Markiert in:

Kommentare

Derzeit gibt es keine Kommentare. Schreibe den ersten Kommentar!