Wichtige Punkte:
- Die direkte Interaktion zwischen Komponenten kann zu unerwartetem Verhalten führen, das für Entwickler, Betreiber und Geschäftsanalysten schwer zu verstehen ist.
- Um die Nachhaltigkeit Ihres Unternehmens sicherzustellen, müssen Sie alle Interaktionen sehen, die im System auftreten.
- : , -; , ; , ; (process mining), ; , .
- , , , .
2018 traf ich einen Architekten einer großen Internetfirma. Er sagte mir, dass sie alle korrekten Richtlinien befolgen und die Funktionalität in kleine Teile in verschiedenen Bereichen unterteilen, obwohl sie diesen Architekturstil nicht als "Microservices" bezeichnen. Anschließend haben wir darüber gesprochen, wie diese Services miteinander interagieren, um Geschäftslogik zu unterstützen, die Service-Grenzen überschreitet, da hier die Theorie in die Praxis umgesetzt wird. Er sagte, dass ihre Dienste über Ereignisse interagieren, die im Bus veröffentlicht wurden - dieser Ansatz wird als " Choreografie " bezeichnet (ich werde weiter unten ausführlicher darauf eingehen). Das Unternehmen hält dies für optimal, um den Zusammenhalt zu verringern. Sie standen jedoch vor einem Problem: Es ist schwierig zu verstehen, was im System geschieht, und es ist noch schwieriger, es zu ändern. "" Dies ist nicht der choreografierte Tanz, den Sie in Microservices-Präsentationen sehen, sondern unkontrollierbares Pogo-Springen! "
Dies steht im Einklang mit dem, was mir andere Kunden wie Josh Wolfe von Credit Sense gesagt haben. " Das System, das wir ersetzen, verwendet komplexe Peer-to-Peer-Choreografien, für deren Verständnis mehrere Codebasen erforderlich sind. "
Lassen Sie uns diese Situation anhand eines vereinfachten Beispiels verstehen. Angenommen, Sie erstellen eine Auftragserfüllungsanwendung. Sie haben sich für eine ereignisgesteuerte Architektur entschieden und beispielsweise Apache Kafka als Ereignisbus ausgewählt. Wenn jemand eine Bestellung aufgibt, generiert der Checkout-Service ein Ereignis, das vom Zahlungsservice abgeholt wird. Dieser Zahlungsservice erhält Geld und generiert ein Ereignis, das vom Inventarservice abgeholt wird.
Choreografierter Strom von Ereignissen.
Der Vorteil dieses Ansatzes besteht darin, dass Sie dem System problemlos neue Komponenten hinzufügen können. Angenommen, Sie möchten einen Benachrichtigungsdienst erstellen, der E-Mails an Ihre Kunden sendet. Sie können einfach einen neuen Dienst hinzufügen und die entsprechenden Ereignisse abonnieren, ohne den Rest des Systems zu berühren. Und jetzt können Sie Ihre Interaktionseinstellungen und die Komplexität von Benachrichtigungen, die den Anforderungen der DSGVO (EU-Datenschutzverordnung) entsprechen, zentral verwalten .
Dieser Architekturstil wird als Choreografie bezeichnet, da kein Orchestrator den anderen Komponenten mitteilen muss, was zu tun ist. Hier generiert jede Komponente Ereignisse, auf die andere Komponenten reagieren können. Dieser Stil soll die Kopplung zwischen Komponenten verringern und das Entwerfen und Ändern des Systems erleichtern, wie dies für unsere Übersicht über den Benachrichtigungsservice gilt.
Verlust der Transparenz im Ablauf der Ereignisse
Ich möchte mich auf die Frage konzentrieren, die am häufigsten auftaucht, wenn ich an Diskussionen über diese Architektur teilnehme: "Wie kann vermieden werden, dass die Transparenz (und wahrscheinlich die Kontrolle) über den Ereignisfluss verloren geht?" In einer Studie fragte Camunda (wo ich arbeite) nach der Verwendung von Microservices. 92% der Befragten haben sie zumindest berücksichtigt, und 64% haben sie bereits in der einen oder anderen Form verwendet. Dies ist kein Hype mehr. In dieser Studie haben wir jedoch auch nach den Schwierigkeiten gefragt und eine klare Bestätigung unserer Befürchtungen erhalten: Am häufigsten wurde uns über den Verlust der End-to-End-Transparenz von Geschäftsprozessen mit mehreren Diensten berichtet.
Erinnern Sie sich an Architekturen, die auf mehreren Datenbank-Triggern basieren? Architekturen, in denen Sie nie genau wissen, was als Reaktion auf eine Aktion passieren wird, und warum wird dies passieren? Manchmal erinnere ich mich an die Schwierigkeiten, die mit reaktiven Mikrodiensten verbunden sind, obwohl ein solcher Vergleich eindeutig unangemessen ist.
Transparenz gewährleisten
Was kann in einer solchen Situation getan werden? Die folgenden Ansätze helfen Ihnen dabei, die Transparenz wiederzugewinnen, aber jeder hat seine eigenen Vor- und Nachteile:
- Verteilte Verfolgung (wie Zipkin oder Jaeger).
- Datenseen oder Analysewerkzeuge (wie Elastic).
- Kontrolle und Analyse des Process Mining (z. B. ProM).
- Tracking mithilfe der Taskflow-Automatisierung (wie Camunda).
Beachten Sie, dass alle diese Ansätze das Beobachten eines laufenden Systems und das Untersuchen der darin enthaltenen Datenflüsse umfassen. Ich kenne kein statisches Analysetool, das nützliche Informationen extrahieren kann.
Verteilte Rückverfolgung
Dieser Ansatz überwacht den Aufrufstapel zwischen verschiedenen Systemen und Diensten. Hierzu werden eindeutige Bezeichner verwendet, die normalerweise bestimmten Headern hinzugefügt werden (z. B. in HTTP- oder Nachrichtenkopfzeilen). Wenn jeder in Ihrem System diese Header versteht oder zumindest weiterleitet, können Sie den Austausch von Anforderungen zwischen Diensten verfolgen.
In der Regel wird die verteilte Ablaufverfolgung verwendet, um zu verstehen, wie Anforderungen im System fließen, um festzustellen, wo Fehler auftreten, und um die Ursachen für Leistungseinbußen zu untersuchen. Zu den Vorteilen des Ansatzes gehören die Reife des Toolkits und das lebende begleitende Ökosystem. Daher ist es für Sie relativ einfach, mit der Verwendung der verteilten Ablaufverfolgung zu beginnen, selbst wenn Sie Ihre Anwendungen oder Container normalerweise (möglicherweise aggressiv) anweisen müssen.
Warum also nicht diesen Ansatz verwenden, um zu verstehen, wie Geschäftsprozesse Ereignisse erzeugen? Dafür gibt es normalerweise zwei Gründe:
- . , , . . , -.
- . , , 90 % . Three Pillars with Zero Answers — towards a New Scorecard for Observability. .
Die Rückverfolgung allein ist für uns also kaum geeignet. Es wäre logisch, sich einem ähnlichen Ansatz zuzuwenden, aber unsere spezifische Aufgabe zu berücksichtigen. Dies bedeutet normalerweise, dass Sie keine Spuren sammeln, sondern wichtige geschäftliche oder thematische Ereignisse, auf die Sie möglicherweise bereits gestoßen sind. Häufig besteht die Lösung darin, einen Dienst zu erstellen, der alle Ereignisse abhört und in der Datenbank speichert, wodurch die Systemlast erhöht werden kann. Heutzutage verwenden viele Leute Elastic dafür.
Es ist ein leistungsfähiger Mechanismus, der relativ einfach zu implementieren ist. Und es wurde bereits von den meisten unserer ereignisgesteuerten Kunden implementiert. Das Haupthindernis für die Implementierung ist normalerweise die Frage, wer in einem großen Unternehmen ein solches Tool verwalten wird, da es auf jeden Fall zentral verwaltet werden muss. Es ist für Sie einfach, eine eigene Benutzeroberfläche für die Arbeit mit diesem Mechanismus zu erstellen, mit der Sie schnell Informationen finden können, die für bestimmte Abfragen relevant sind.
Ein Beispiel für eine Ereignisüberwachungsschnittstelle .
Zu den Nachteilen gehört das Fehlen von Diagrammen, die das Arbeiten mit der Liste der Ereignisse erleichtern. Sie können sie jedoch zur Infrastruktur hinzufügen, indem Sie beispielsweise Ereignisse in einen Renderer wie BPMN projizieren. Mit kleinen Frameworks wie bpmn.io können Sie Diagrammen Informationen hinzufügen, die als einfache HTML-Seiten ( Beispiel ) angezeigt werden und in das Kibana-Plugin gepackt werden können.
Dieses Modell kann mit keinem Geschäftsprozessmanagementmodul ausgeführt werden. Es ist lediglich ein Diagramm zur Visualisierung protokollierter Ereignisse. Unter diesem Gesichtspunkt haben Sie eine gewisse Freiheit bei der Auswahl der Anzeigedetails. Wenn Sie sich besonders für das Gesamtbild interessieren, können Sie Modelle erstellen, die Ereignisse von verschiedenen Mikrodiensten in einem Diagramm anzeigen. Ein solches Diagramm hindert Sie nicht daran, Änderungen an einzelnen Services vorzunehmen, sodass die Flexibilität Ihres Unternehmens nicht beeinträchtigt wird. Es besteht jedoch die Gefahr, dass die Diagramme im Vergleich zum aktuellen Status des Betriebssystems veraltet sind.
Process Mining-Tools
Im vorherigen Ansatz müssten Sie das Diagramm, das für das Rendern verwendet werden soll, explizit modellieren. Wenn wir jedoch die Art des Ereignisflusses nicht im Voraus kennen können, müssen wir ihn zuerst untersuchen.
Dies kann mithilfe von Tools zur Überwachung und Analyse von Prozessen erfolgen. Sie können ein vollständiges Diagramm erstellen und grafisch anzeigen, sodass Sie häufig die Details untersuchen können, insbesondere im Zusammenhang mit Systemengpässen oder möglichen Optimierungen.
Klingt nach der perfekten Lösung für unser Problem. Leider werden solche Tools am häufigsten zur Untersuchung von Prozessen in Legacy-Architekturen verwendet. Daher konzentrieren sie sich auf die Analyse von Protokollen und arbeiten mittelmäßig mit Live-Ereignisströmen. Ein weiterer Nachteil ist, dass es sich um rein wissenschaftliche Werkzeuge handelt, die schwer zu verwenden (z. B. ProM) oder sehr schwer (z. B. Celonis) sind. Nach meiner Erfahrung ist es unpraktisch, diese Art von Werkzeugen in typischen Mikroservice-Bestrebungen zu verwenden.
In jedem Fall bieten die Prozessexploration und Datenanalyse interessante Möglichkeiten, um Einblick in Ereignisströme und Geschäftsprozesse zu erhalten. Hoffentlich gibt es bald eine Technologie mit ähnlichen Funktionen, die jedoch leichter, entwicklerfreundlicher und einfacher zu implementieren ist.
Tracking mit Taskflow-Automatisierung
Ein weiterer interessanter Ansatz besteht darin, Aufgabenabläufe zu modellieren und sie dann über das Steuermodul bereitzustellen und auszuführen. Dieses Modell ist insofern besonders, als es nur Ereignisse verfolgt und nichts aktiv tut. Das heißt, es verwaltet nichts - es registriert nur. Ich habe auf dem Kafka Summit San Francisco 2018 darüber gesprochen und Apache Kafka und das Open-Source- Zeebe- Workflow-Modul zur Demonstration verwendet .
Diese Gelegenheit ist besonders interessant. Auf dem Gebiet der Steuermodule gibt es viele Innovationen, die zur Entwicklung von Werkzeugen führen, die kompakt, einfach zu entwickeln und hoch skalierbar sind. Ich habe darüber in Events, Flows und Long-Running Services geschrieben: Ein moderner Ansatz zur Workflow-Automatisierung . Zu den offensichtlichen Nachteilen gehört die Notwendigkeit einer vorläufigen Modellierung des Aufgabenflusses. Andererseits kann dieses Modell im Gegensatz zur Ereignisüberwachung mit dem Prozesssteuerungsmodul ausgeführt werden. Grundsätzlich starten Sie Prozessinstanzen für eingehende Ereignisse oder ordnen Ereignisse einer Instanz zu. Außerdem können Sie überprüfen, ob die Realität mit Ihrem Modell übereinstimmt.
Darüber hinaus können Sie mit diesem Ansatz die gesamte Toolkette nutzen, die von der Taskflow-Automatisierungsplattform bereitgestellt wird. Sie können den tatsächlichen Status des Systems anzeigen, SLAs verfolgen, Fehler von Prozessinstanzen erkennen oder eine gründliche Analyse historischer Überwachungsdaten durchführen.
Ein Beispiel für die Überwachung eines Taskflows.
Als ich diesen Ansatz mit unseren Kunden testete, war es einfach einzurichten. Wir haben gerade eine generische Komponente zusammengestellt, die Ereignisse vom Bus empfängt, und sie mit dem Task-Flow-Steuermodul abgeglichen. Wenn das Ereignis nicht abgeglichen werden konnte, haben wir eine kleine Entscheidungstabelle verwendet, um festzustellen, ob es ignoriert werden kann oder ob das Ereignis zu einem Vorfall führen würde, der später untersucht werden müsste. Wir haben auch die Task-Flow-Steuerungsmodule verbessert, die in Microservices zum Ausführen von Geschäftslogik verwendet werden, sodass sie bestimmte Ereignisse generieren (z. B. wird eine Prozessinstanz gestartet, abgeschlossen oder hat eine Phase abgeschlossen), die Teil des Gesamtbilds sind.
All dies ähnelt der Ereignisüberwachung, wobei der Schwerpunkt auf Geschäftsprozessen liegt. Im Gegensatz zur Rückverfolgung erfasst der Ansatz alle Geschäftsereignisse und zeigt das Gesamtbild in verschiedenen Formaten an, die für verschiedene Stakeholder geeignet sind.
Geschäftsausblick
Durch die Verfügbarkeit von Geschäftsprozessen für die Überwachung können Sie den Kontext verstehen. Sie können für eine bestimmte Instanz sehen, wie, wann und in welchem Zustand sie beendet wurde. Dies bedeutet, dass Sie verstehen können, welchem Pfad dieser Prozess nicht gefolgt ist (und andere folgen ihm häufig) und welche Ereignisse oder Daten zu bestimmten Entscheidungen geführt haben. Sie können auch verstehen, was in naher Zukunft passieren kann. Andere Arten der Überwachung erlauben dies nicht. Während es heutzutage oft nicht üblich ist, das Problem der Konsistenz zwischen Geschäft und IT zu diskutieren, ist es unerlässlich, dass auch Nichtfachleute in der Lage sind, Geschäftsprozesse und den Ablauf von Ereignissen durch verschiedene Mikrodienste zu verstehen.
Von der Verfolgung bis zur Verwaltung
Die Prozessverfolgung ist ein hervorragendes Tool zur Bereitstellung von Betriebsüberwachung, Berichterstellung, KPIs und Transparenz. Dies sind alles wichtige Faktoren für die Aufrechterhaltung der Flexibilität des Unternehmens. In aktuellen Projekten ist das Tracking jedoch nur der erste Schritt zu einer tieferen Verwaltung und Orchestrierung in Ihrem Microservices-Ökosystem.
Sie können beispielsweise damit beginnen, End-to-End-Zeitüberschreitungen zu überwachen. Wenn eine Zeitüberschreitung auftritt, wird automatisch eine Aktion ausgeführt. Im folgenden Beispiel werden wir den Kunden nach 14 Tagen über die Verzögerung informieren, aber wir werden trotzdem warten. Und nach 21 Tagen stornieren wir die Bestellung.
Seltsamerweise ist das Senden eines Teams, um eine Bestellung hier zu stornieren, eine Orchestrierung, die oft kontrovers diskutiert wird.
Orchestrierung
Ich höre oft, dass Orchestrierung vermieden werden sollte, weil sie zu Kohärenz führt oder die Autonomie einzelner Mikrodienste stört und natürlich schlecht implementiert werden kann. Es ist aber auch möglich, Orchestrierung so zu implementieren, dass sie den Prinzipien von Microservices entspricht und dem Unternehmen einen hohen Mehrwert bringt. Ich habe auf der InfoQ New York 2018 ausführlich darüber gesprochen .
Orchestrierung bedeutet für mich, dass ein Dienst einem anderen anweisen kann, etwas zu tun. Und alle. Dies ist keine enge Verbindung, sondern eine andere Art von Verbindung. Erinnern wir uns an unser Beispiel mit einer Bestellung. Es kann ratsam sein, dass der Registrierkassendienst nur eine Bestellung generiert und in den Veranstaltungsbus einfügt, ohne zu wissen, wer sie bearbeiten wird. Der Bestellservice nimmt das Ereignis über die Bestellung auf, die erschienen ist. Der Empfänger erfährt von dem Ereignis und beschließt, etwas dagegen zu unternehmen. Das heißt, der Zusammenhalt ist auf der Empfängerseite vorhanden.
Bei der Zahlung ist die Situation anders, da es ziemlich seltsam ist, wenn der Zahlungsdienst weiß, wofür die Zahlung eingegangen ist. Dieses Wissen benötigt er jedoch, um auf die richtigen Ereignisse wie das Aufgeben oder Aufgeben einer Bestellung reagieren zu können. Dies bedeutet auch, dass der Service jedes Mal geändert werden muss, wenn Sie Zahlungen für neue Produkte oder Services erhalten möchten. In vielen Projekten wird diese unangenehme Verbindung umgangen, indem die erforderlichen Zahlungsereignisse generiert werden. Dies sind jedoch keine Ereignisse, da der Absender möchte, dass jemand etwas dagegen unternimmt. Das ist ein Team! Der Bestellservice befiehlt dem Zahlungsservice, Geld zu erhalten. In diesem Fall weiß der Absender, welchen Befehl er senden soll, und dies bedeutet, dass der Zusammenhalt auf der Seite des Absenders vorhanden ist.
Damit jede Interaktion zwischen zwei Diensten effektiv ist, ist ein gewisser Grad an Kopplung erforderlich. Abhängig von der spezifischen Aufgabe kann es jedoch ratsam sein, die Konnektivität auf einer der Seiten zu implementieren.
Der Bestellservice kann sogar für die Orchestrierung und andere Services verantwortlich sein und die Phasen der Auftragserfüllung verfolgen. Ich habe die Vorteile dieses Ansatzes im obigen Vortrag ausführlich erörtert. Der Trick ist, dass eine gute Architektur ein Gleichgewicht zwischen Orchestrierung und Choreografie erfordert, was nicht immer einfach ist.
In diesem Artikel wollte ich mich jedoch auf Transparenz konzentrieren. Die Orchestrierung mit dem Task-Flow-Modul bietet einen offensichtlichen Vorteil: Ein Modell ist nicht nur Code für die Ausführung durch den Orchestrator, sondern kann auch zur Bereitstellung von Flow-Transparenz verwendet werden.
Fazit
Es ist sehr wichtig, die Transparenz Ihrer Geschäftsprozesse unabhängig von deren Implementierung sicherzustellen. Ich habe verschiedene Ansätze in Betracht gezogen, und in realen Projekten läuft alles normalerweise auf eine Art Ereignisüberwachung mit Tools wie Elastic oder auf die Verfolgung von Prozessen mithilfe von Steuermodulen hinaus. Zum Teil kann die Wahl vom konkreten Fall und den Rollen der beteiligten Personen abhängen. Beispielsweise muss ein Geschäftsanalyst die von allen Prozessinstanzen gesammelten Daten mit dem erforderlichen Detaillierungsgrad verstehen, während ein Betriebsleiter einen bestimmten Prozess in unterschiedlichen Detaillierungsgraden analysieren und wahrscheinlich Tools erwerben muss, um Vorfälle auf Systemebene schnell zu lösen.
Wenn Ihr Projekt stark von Choreografie abhängt, kann die Prozessverfolgung dazu führen, dass Sie Orchestrierung hinzufügen. Und ich denke, dies ist ein sehr wichtiger Schritt, um Ihre Geschäftsprozesse langfristig zu kontrollieren. Andernfalls können Sie „ein sorgfältig entkoppeltes ereignisgesteuertes System erstellen, ohne zu bemerken, dass Sie mit zunehmender Anzahl von Ereignissen und Prozessen an Transparenz verlieren und sich dadurch in den kommenden Jahren Probleme sichern“, sagte Martin Fowler . Wenn Sie an einem völlig neuen System arbeiten, finden Sie von Anfang an ein Gleichgewicht zwischen Orchestrierung und Choreografie.
Stellen Sie jedoch unabhängig von den Besonderheiten der Implementierung des Systems sicher, dass das Unternehmen eine verständliche Darstellung der Geschäftsprozesse erhält, die mithilfe interaktiver Services implementiert wurden.