Es besteht kein Zweifel, dass die Entwicklung und das Testen in einer Microservice-Architektur aufgrund der vielen Abhängigkeiten schwierig ist. Dieser Artikel beschreibt, wie Hoverfly, das kleinste Tool zur Virtualisierung von Diensten, einige Probleme löst, die Ihnen bei der Arbeit begegnen könnten.
Welches Problem hatte ich?
Während des letzten Projekts haben mein Team und ich mit der Microservice-Architektur gearbeitet. Dabei wird das System in kleine Dienste aufgeteilt, die nicht kontrolliert werden und sich unterschiedlich verhalten können. Wir benötigten einen solchen Dienst für Entwicklungs- und Testzwecke. Leider stellte sich heraus, dass er instabil war und selbst wenn er funktionierte, kam es häufig zu Zeitüberschreitungen. Das war natürlich inakzeptabel, so dass wir eine Lösung finden mussten, um den ursprünglichen Dienst, der die Probleme verursachte, zu simulieren oder sogar zu ersetzen. Wir wollten eine Lösung, mit der man sich leicht vertraut machen, sie einführen und pflegen kann. Am wichtigsten war jedoch, dass sie portabel und leicht zwischen den Rechnern der Entwickler, der Entwicklungs- und der QA-Umgebung übertragbar sein musste. Nach einigen Recherchen haben wir uns für Hoverfly entschieden - und wir haben es nicht bereut!
Wichtige Konzepte: Was ist eine Schwebfliege?
Lassen Sie uns kurz etwas Theorie über Hoverfly lernen, bevor ich es in der Praxis demonstriere. Laut der Dokumentation ist Hoverfly ein leichtgewichtiges Open-Source-Tool, mit dem man APIs simulieren kann. Weitere Informationen und die Installationsanleitung finden Sie unter
Das Funktionskonzept von Hoverfly ist wirklich einfach. Kurz gesagt handelt es sich um einen Proxy-Server, der Anfragen zwischen dem Client und dem Server weiterleitet. Siehe das Diagramm unten.
Wie in der Abbildung zu sehen ist, sind die Modi "Erfassen" und "Simulieren" Schlüsselfunktionen, die Ihnen helfen zu verstehen, wie das Tool funktioniert.
Im Aufzeichnungsmodus zeichnet Hoverfly den HTTP(S)-Verkehr auf, um API-Simulationen zu erstellen, die für Tests verwendet werden können. Mit anderen Worten, es zeichnet ausgehende Anfragen des Clients und die eingehenden Antworten des ursprünglichen API-Servers transparent auf. Hoverfly speichert den aufgezeichneten Datenverkehr als Simulationen in JSON-Dateien.
Im Simulationsmodus wird jedes Mal, wenn Hoverfly eine Anfrage von der Anwendung erhält, diese nicht an den ursprünglichen Server weitergeleitet, sondern die zugehörige Antwort aus dem internen Cache oder der zuvor vorbereiteten Simulationsdatei geliefert.
Hoverfly in Aktion - einfacher Anwendungsfall
Es ist höchste Zeit, alles, was ich bisher beschrieben habe, in der Praxis auszuprobieren. Nehmen wir an, es gibt einen Dienst eines Drittanbieters, der sehr langsam auf Anfragen antwortet. Siehe unten:
Die Reaktionszeit beträgt über 30 Sekunden, was inakzeptabel ist. Um die Vorteile von Hoverfly zu nutzen, starte ich es und schalte es in den Aufnahmemodus:
hoverctl start hoverctl mode capture
Von nun an läuft Hoverfly auf Port 8500, der für Proxy-Zwecke verwendet wird, und auf Port 8888, auf dem die Webadministrationskonsole verfügbar ist.
Um nun eine Antwort zu erfassen, reicht es aus, eine Anfrage durch den Proxy zu leiten, der den Anruf tätigt:
curl --proxy http://localhost:8500 http://localhost:8080/slowResponseResources
Das Ergebnis ist sofort in der Webadministrationskonsole sichtbar, die Sie hier finden: http://localhost:8888.
Alle für die spätere Simulation benötigten Daten werden in einer simulation.json-Datei gesammelt:
{ "data": { "pairs": [ { "response": { "status": 200, "body": "["resource A","resource B","resource C"]", "encodedBody": false, "headers": { "Content-Type": [ "application/json;charset=UTF-8" ], "Date": [ "Fri, 24 Mar 2017 12:57:24 GMT" ], "Hoverfly": [ "Was-Here" ] } }, "request": { "requestType": "recording", "path": "/slowResponseResources", "method": "GET", "destination": "localhost:8080", "scheme": "http", "query": "", "body": "", "headers": { "Accept": [ "*/*" ], "Proxy-Connection": [ "Keep-Alive" ], "User-Agent": [ "curl/7.43.0" ] } } } ], "globalActions": { "delays": [] } }, "meta": { "schemaVersion": "v1", "hoverflyVersion": "v0.10.2", "timeExported": "2017-03-24T14:00:23+01:00" } }
Nachdem ich den Erfassungsschritt abgeschlossen habe, kann ich Hoverfly nun in den Simulationsmodus schalten und meinen REST-Dienst noch einmal untersuchen:
hoverctl mode simulate
curl --proxy http://localhost:8500 http://localhost:8080/slowResponseResources
Ich habe das folgende Ergebnis erhalten:
Wie auf dem Screenshot oben zu sehen ist, beträgt die Antwortzeit 0,006 Sekunden, was viel besser ist als der ursprüngliche Dienst. Ein kurzer Blick auf die Webkonsole bestätigt, dass die Simulation gut verlaufen ist.
Wie das obige Beispiel beweist, löst das Ersetzen des Originaldienstes durch einen Hoverfly-Proxy mein Problem. Der auf diese Weise simulierte Drittanbieterdienst ist effizient und angenehm in der Zusammenarbeit.
Hoverfly in Aktion - fortgeschrittener Anwendungsfall
Nach dem Basisszenario zu urteilen, das ich gerade demonstriert habe, ist Hoverfly für fortgeschrittenere Dinge in unserer Microservice-Architektur geeignet. Im nächsten Anwendungsfall möchte ich das neueste und angesagteste Muster in der Microservice-Architektur namens 'CircuitBreaker' (siehe Circuit Breaker) anwenden, um es auf integrative Weise zu testen. Auf den ersten Blick scheint es einfach zu sein, den Ausfall einer Netzwerkverbindung oder den Gesundheitszustand einer Microservice-Architektur zu simulieren, aber es ist nicht so trivial, dies automatisiert und anpassbar zu machen. Im Zusammenhang mit Hoverfly stellt sich heraus, dass dies leicht zu erreichen ist, indem man Hoverfly mit Middleware anreichert, die den Datenverkehr zwischen dem Client und der API (ob real oder simuliert) abfängt und es ermöglicht, diesen zu manipulieren.
In diesem Fall sollte die Middleware, die ich benötige, zufällig 200 oder 503 Antwortstatus zurückgeben, die Verbindungsprobleme und Timeouts widerspiegeln. Außerdem möchte ich, dass dieser Zufallsgenerator nach dem Zufallsprinzip arbeitet. Er gibt mir die Möglichkeit, die Beziehungen zwischen den 200/503-Statusereignissen zu steuern, was mein Skript flexibel und in vielen Szenarien einsetzbar macht. Zu diesem Zweck habe ich das folgende Python-Skript geschrieben:
#!/usr/bin/env python import sys import json import logging import random from numpy.random import choice logging.basicConfig(filename='middleware.log', level=logging.DEBUG) logging.debug('Middleware "CircuitBreaker" called') def main(): payload = sys.stdin.readlines()[0] logging.debug(payload) payload_dict = json.loads(payload) payload_dict['response']['status'] = choice([200, 503], p=[0.1, 0.9]) if payload_dict['response']['status'] == 503: payload_dict["response"]["body"] = "Service Unavailable" print(json.dumps(payload_dict)) if __name__ == "__main__": main()
Um mein Skript auszuführen, führe ich aus:
hoverctl start
hoverctl mode simulate
hoverctl middleware --binary python --script middleware.py
curl --proxy http://localhost:8500 http://localhost:8080/slowResponseResources
hoverctl stop
Und wenn ich das Apache Benchmark Tool verwende, erhalte ich:
Wie Sie sehen können, gibt mein Drittanbieterdienst für zehn HTTP-Aufrufe in 90% der Fälle 503 Antworten zurück. Dies wird durch eine Gewichtung im Skript bestimmt, die auf 90% eingestellt ist. Damit wird ein Fall simuliert, in dem der Dienst in hohem Maße unerreichbar ist. Je niedriger die Gewichtung ist, desto besser ist der Dienst erreichbar.
Zusammenfassung
Ich denke, Hoverfly ist eine Erkundung wert. Es ist ein leistungsstarkes Tool, das weit mehr Funktionen bietet, als ich ausprobieren konnte.
- Hinzufügen von Verzögerungen zu einer Simulation (mein erster Gedanke, als ich das sah - "Toll für Lasttests!")
- Erfassen oder Simulieren bestimmter URLs
- Lockerer Abgleich von Anfragen mit einem Request Matcher
- Und vieles mehr (siehe https://docs.hoverfly.io/en/latest/index.html)
Um mein Abenteuer mit Hoverfly zusammenzufassen, kann ich bestätigen, dass es die Prüfung in unserem Projekt bestanden hat. Außerdem ist es einfach zu erlernen und während des gesamten Entwicklungszyklus zu pflegen. Ich empfehle Ihnen dringend, es in Ihrem nächsten Projekt einzusetzen - vielleicht wird es Ihr bester Freund bei der API-Simulation werden.
Contact



