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

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.

Beispiel Eureka

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.

@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

@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 

Fazit

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/