Best Practices für die QA-Automatisierung von Microservices

Microservices sind eine Entwicklungsmethodik, bei der Dienste unabhängig voneinander entwickelt und bereitgestellt werden. Diese Art von Architektur ist in den letzten Jahren aufgrund ihrer Fähigkeit, Systeme zu entkoppeln und die Geschwindigkeit der Bereitstellung zu verbessern, populär geworden. Um diese Anwendungen effektiv zu testen, sind spezielle Tools und Prozesse erforderlich.

Angesichts der Vielzahl unabhängiger Dienste, die miteinander kommunizieren, kann die Testautomatisierung in einer Microservices-Architektur sehr komplex sein. Dennoch bietet die Microservices-Architektur mehrere überzeugende Vorteile, die wir in diesem Artikel erörtern.

Was ist ein Microservice-Architekturstil?

Definitionsgemäß wird eine Microservice-Architektur verwendet, um eine einzige Anwendung mit separaten Prozessen für jeden Mechanismus zu entwickeln. Diese „kleinen Dienste“ kommunizieren miteinander, indem sie auf die exponierten Anwendungsprogrammierschnittstellen (APIs) des jeweils anderen zugreifen.

Ein typisches Beispiel ist das Online-Shopping von Amazon. Wie im folgenden Diagramm dargestellt, läuft jeder leichtgewichtige Dienst unabhängig von den anderen. Selbst bei einem Ausfall des Zahlungs-Gateways können die Benutzer weiterhin Artikel in ihre Warenkörbe legen und sich andere Module ansehen. Auf diese Weise führt der Ausfall eines Moduls nicht zum Verlust des gesamten Systems.

Zu den Vorteilen dieses Ansatzes gehören folgende:

• Jede Komponente hat ihren Lebenszyklus. Das bedeutet, dass sie je nach Bedarf nach oben oder unten skaliert werden kann.
• Es ist einfach, einzelne Komponenten zu testen, da sie von keinem anderen Systemteil abhängig sind.
• Sie können verschiedene Bereitstellungsstrategien verwenden, z. B. Cloud-basiertes Hosting oder selbst gehostete Lösungen.
• Sie können mehrere Softwareversionen gleichzeitig bereitstellen, ohne die Gesamtleistung des Systems zu beeinträchtigen.

Warum Microservices verwenden?

Es gibt mehrere Gründe, warum Unternehmen eine Microservices-Architektur einführen sollten. Einige der häufigsten sind:

Erhöhte Agilität. Indem große monolithische Anwendungen in kleinere Teile zerlegt werden, können Teams schnell auf Änderungen reagieren und Verbesserungen vornehmen.
Verbesserte Skalierbarkeit. Eine Skalierung ist einfacher als eine Aufstockung. Wenn Sie mehr Kapazität benötigen, fügen Sie zusätzliche Server hinzu, anstatt den Code neu zu schreiben.
Schnellere Markteinführung. Sie können neue Funktionen schneller auf den Markt bringen, da Sie nicht darauf warten müssen, dass ein Team eine Anwendung komplett fertigstellt, bevor Sie sie freigeben.
Geringere Komplexität. Eine Microservices-Architektur reduziert die Anzahl der Abhängigkeiten zwischen den Komponenten. Dadurch wird das Testen wesentlich einfacher.

Abb. 1: Amazon Microservice-Architektur

Wie funktionieren Microservices?

Bei der Entwicklung einer Microservices-Architektur wird eine monolithische Anwendung in kleine Dienste aufgeteilt. Jeder Dienst stellt eine Reihe von APIs bereit, die es anderen Diensten ermöglichen, mit ihm zu interagieren.

Nehmen wir zum Beispiel an, Sie haben eine Webanwendung, mit der Kunden Konten erstellen können. Sie könnten einen Dienst erstellen, der die Benutzerregistrierung übernimmt. Ein anderer Dienst könnte die Authentifizierung übernehmen. Und ein anderer verwaltet die Kundendaten.

Wenn eine Anfrage eingeht, sendet der Client sie an den entsprechenden Dienst. Dieser Dienst führt dann seine Funktion aus und gibt die Ergebnisse an den Client zurück.

Dieses Modell funktioniert gut, wenn alle Dienste in der gleichen Umgebung ausgeführt werden. Wenn Sie diese Dienste jedoch in verschiedenen Umgebungen hosten möchten, müssen Sie die API offenlegen, damit die Clients auf sie zugreifen können.

Probleme mit Microservice-Architekturen

Obwohl der Ansatz der Microservice-Architektur für die Softwareentwicklung zahlreiche Vorteile bietet, hat er einige Nachteile bei der Berichterstattung. So kann es beispielsweise mühsam sein, Testergebnisse zu analysieren, Verhältnisse zwischen bestandenen und fehlgeschlagenen Tests sowie Trends zu ermitteln und die Gesamtausführungszeit für eine bestimmte Microservice-Regressionssuite zu verstehen. Darüber hinaus müssen Sie sicherstellen, dass die Kommunikation zwischen den Diensten sicher ist.

Betrachten wir die unten stehende Beispiel-Microservice-Architektur für Netflix, in der eine Anzahl von n Diensten ausgeführt wird. Um eine stabile Automatisierungspipeline zu erhalten, müssen Sie Daten erhalten, die die folgenden Fragen beantworten:

• Welche Dienste haben eine maximale Ausführungszeit?
• Bei welchen Diensten gibt es mehr Ausfälle?
• Welche Trends gibt es bei den Ausführungszeiten der Dienste? Steigen oder fallen sie?
• Ich habe die Namen der Dienste mit der höchsten Anzahl von Ausfällen, aber wie kann ich diese aufschlüsseln und anhand des Szenarios überprüfen?
• Kann ich eine Liste der Szenarien sehen, die über einen längeren Zeitraum ausfallen, und wenn das Alter der Ausfälle hoch ist?
• Kann ich alle Details des Dienstes erhalten, der den neuesten Build installiert hat?

Abb. 2: Netflix Microservice-Architektur

Effektives Microservice-Management

Wir haben festgestellt, dass eine Möglichkeit, die verschiedenen oben genannten Anforderungen erfolgreich zu bewältigen, darin besteht, alle Dienste in eine einzige Plattform zu integrieren. Beispielsweise haben wir für einen Kunden ein benutzerdefiniertes Dashboard entwickelt, das als Tool zur Erstellung von Berichten und zur Überwachung von mehr als 50 Microservices verwendet werden kann (mit dem Potenzial, auf 100+ erweitert zu werden).

Das Hauptziel dieses Dashboards war es, eine zentrale Anlaufstelle für alle Automatisierungsberichte, Trends und Überwachungen zu sein. Zur Erstellung dieses Dashboards haben wir die folgenden Technologien verwendet:

• Spring Boot
• Spring Thymeleaf
• Maven
• Java 1.8
• Couchbase DB (kann jede DB sein)
• Jenkins client api
• D3.js

Das Dashboard war so erfolgreich, dass wir es nun auch in anderen Projekten einsetzen. Im Folgenden finden Sie die verschiedenen Berichte, die wir erstellt haben, um unseren Automatisierungsstatus zu verbessern.

Registerkarte Microservices insgesamt

Auf dieser Registerkarte werden die meisten der unten aufgeführten Datenabfragen beantwortet, einschließlich der historischen Daten (früherer Build).

• Build-Daten für alle Microservices.
• Dauer der jeweiligen Microservice-Suite.
• Gesamtzahl der Testfälle, Anzahl der fehlgeschlagenen Testfälle, usw.

Abb. 3: Registerkarte „Microservices

Registerkarte Ausführungszeitanalyse

Bei dieser Registerkarte handelt es sich um eine grafische Darstellung der oben genannten Daten, die Trends zum Zustand Ihrer Microservice-Automatisierung anzeigt. Wir können nach Umgebung und Art des Laufs filtern (d. h. Smoke, Regression usw.).

Abb. 4: Registerkarte „Ausführungszeit-Analyse

Registerkarte Fehleranalyse

Dies ist einer meiner Lieblingsberichte. Er enthält zwei wichtige Parameter („Alter“ und „fehlgeschlagen seit“), so dass wir die Szenarien, die über einen langen Zeitraum fehlgeschlagen sind, leicht aufspüren können. Dieser Bericht hilft uns letztendlich dabei, unsere Smoke Suite zu verbessern (wenn es sich um ein Anwendungsproblem handelt) oder die Qualität des Automatisierungstestfalls (wenn es sich um ein Automatisierungsproblem handelt).

Abb. 5: Registerkarte „Ausfallanalyse“ des Szenarios

Registerkarte Zusammenfassung

Diese Registerkarte ist für Manager hilfreich, um den letzten konsolidierten Bericht für alle Microservices über ihre letzten Läufe zu erhalten.

Registerkarte Repo-Analyse

Für größere, verteilte Teams, in denen Mitarbeiter in verschiedenen Zweigen arbeiten, kann die Qualitätssicherung eine Herausforderung sein. Während sie beispielsweise ihren Code bei Zwischenläufen zusammenführen, um einen Zwischenzweig zu entwickeln, wird leicht vergessen, ihren Code in den Hauptzweig einzubinden. Dieses Versäumnis kann bei der Bereitstellung zu Problemen führen, da es immer erhebliche Unterschiede zwischen den einzelnen Entwicklern und den Hauptzweigen gibt.

Um dieses Problem zu lösen, haben wir eine Matrix entwickelt, die den Unterschied zwischen den Commits dieser verschiedenen Zweige erkennt und bei Bedarf eine Warnung auslöst – ein Auto-Scheduler löst jede Stunde aus und aktualisiert die neuesten Daten in der Datenbank.

Abb. 6: Repo Commit-Diff

Fazit

Es gibt zahlreiche Anwendungsfälle für Microservices, um die Effizienz interner Prozesse zu steigern. Mit den richtigen Tools und den oben genannten Informationen können Unternehmen eine Microservice-Architektur nahtlos integrieren.

Bei GlobalLogic hat sich die Konsolidierung von Anforderungsvariationen und Systemberichten in einem einzigen Dashboard als sehr einflussreich für die Verwaltung von Microservices erwiesen. Obwohl die spezifischen Dockerdateien für dieses Dashboard Eigentum von GlobalLogic sind, möchte ich Sie ermutigen, die Informationen zur Erstellung Ihres Microservice-Dashboards zu verwenden.