Hallo alle! Wir haben großartige Neuigkeiten: OTUS startet den Kurs im Juni erneut , in deren Zusammenhang wir traditionell nützliches Material mit Ihnen teilen.
Wenn Sie diese ganze Microservices-Geschichte ohne jeglichen Kontext kennengelernt haben, werden Sie vielleicht denken, dass sie etwas seltsam ist. Die Aufteilung einer Anwendung in über ein Netzwerk verbundene Fragmente bedeutet zwangsläufig, dem resultierenden verteilten System komplexe Fehlertoleranzmodi hinzuzufügen.
Obwohl dieser Ansatz die Aufteilung in viele unabhängige Dienste beinhaltet, besteht das Endziel weit über die bloße Ausführung dieser Dienste auf verschiedenen Computern hinaus. Wir sprechen hier von der Interaktion mit der Außenwelt, die ihrem Wesen nach auch verteilt ist. Nicht im technischen Sinne, sondern eher im Sinne eines Ökosystems, das aus vielen Menschen, Teams, Programmen besteht und jeder dieser Teile auf die eine oder andere Weise seine Aufgabe erfüllen muss.
Unternehmen sind beispielsweise eine Reihe verteilter Systeme, die gemeinsam zur Erreichung eines bestimmten Ziels beitragen. Wir haben diese Tatsache jahrzehntelang ignoriert und versucht, eine Vereinheitlichung durch FTP-Übertragungen oder Unternehmensintegrationstools zu erreichen, während wir uns auf unsere eigenen Ziele konzentriert haben. Aber mit dem Aufkommen von Dienstleistungen hat sich alles verändert. Die Dienste haben uns geholfen, über den Tellerrand zu blicken und eine Welt interdependenter Programme zu erkennen, die zusammenarbeiten. Um jedoch erfolgreich arbeiten zu können, ist es notwendig, zwei grundlegend unterschiedliche Welten zu erkennen und zu gestalten: die äußere Welt, in der wir in einem Ökosystem aus vielen anderen Dienstleistungen leben, und unsere persönliche, innere Welt, in der wir allein regieren.
Eine solch verteilte Welt unterscheidet sich von der, in der wir aufgewachsen sind und an die wir gewöhnt sind. Die Prinzipien des Aufbaus einer traditionellen monolithischen Architektur halten der Kritik nicht stand. Um diese Systeme richtig zu machen, geht es also um mehr als nur um die Erstellung eines coolen Whiteboard-Diagramms oder eines coolen Proof of Concept. Die Idee ist, dass ein solches System lange Zeit erfolgreich funktionieren wird. Glücklicherweise gibt es Dienste schon seit geraumer Zeit, auch wenn sie anders aussehen. immer noch relevant, sogar aufgepeppt mit Docker, Kubernetes und leicht schäbigen Hipster-Bärten.
Deshalb werfen wir heute einen Blick darauf, wie sich die Regeln geändert haben, warum wir unsere Herangehensweise an Dienste und die Daten, die sie untereinander weitergeben, überdenken müssen und warum wir dafür ein völlig anderes Toolkit benötigen.
Kapselung wird nicht immer Ihr Freund sein
Microservices können unabhängig voneinander arbeiten. Es ist diese Eigenschaft, die ihnen den größten Wert verleiht. Dieselbe Eigenschaft ermöglicht die Skalierung und das Wachstum von Diensten. Nicht so sehr im Hinblick auf die Skalierung auf Billiarden Benutzer oder Petabytes an Daten (obwohl sie auch hier helfen können), sondern im Hinblick auf die Skalierung im Hinblick auf die Menschen, da Teams und Organisationen kontinuierlich wachsen.
Allerdings ist Unabhängigkeit ein zweischneidiges Schwert. Das heißt, der Dienst selbst kann einfach und natürlich ausgeführt werden. Wenn jedoch eine Funktion innerhalb eines Dienstes implementiert wird, die die Einbindung eines anderen Dienstes erfordert, müssen wir am Ende fast gleichzeitig Änderungen an beiden Diensten vornehmen. In einem Monolithen ist dies einfach. Sie nehmen einfach eine Änderung vor und senden sie zur Veröffentlichung. Bei der Synchronisierung unabhängiger Dienste treten jedoch weitere Probleme auf. Die Koordination zwischen Teams und Release-Zyklen zerstört die Flexibilität.
Im Rahmen des Standardansatzes versuchen sie lediglich, lästige End-to-End-Änderungen zu vermeiden, indem sie die Funktionalität klar auf die Dienste aufteilen. Ein gutes Beispiel hierfür kann der Single-Sign-On-Dienst sein. Es hat eine klar definierte Rolle, die es von anderen Diensten unterscheidet. Diese klare Trennung bedeutet, dass sich SSO in einer Welt, in der sich die Anforderungen an die umliegenden Dienste schnell ändern, wahrscheinlich nicht ändern wird. Es existiert in einem streng begrenzten Kontext.
Das Problem besteht darin, dass Unternehmensdienste in der realen Welt nicht immer die gleiche saubere Rollentrennung aufrechterhalten können. Dieselben Geschäftsdienste funktionieren beispielsweise besser mit Daten, die von anderen ähnlichen Diensten stammen. Wenn Sie ein Online-Händler sind, wird die Abwicklung des Bestellablaufs, des Produktkatalogs oder der Benutzerinformationen zu einer Voraussetzung für viele Ihrer Dienstleistungen. Jeder der Dienste benötigt Zugriff auf diese Daten, um funktionieren zu können.
Die meisten Unternehmensdienste nutzen denselben Datenstrom, sodass ihre Arbeit stets miteinander verflochten ist.
Damit kommen wir zu einem wichtigen Punkt, über den es sich zu sprechen lohnt. Während Dienste für Infrastrukturkomponenten gut funktionieren, die größtenteils isoliert arbeiten, sind die meisten Geschäftsdienste am Ende viel enger miteinander verknüpft.
Datendichotomie
Zwar gibt es bereits serviceorientierte Ansätze, doch gibt es noch wenig Informationen darüber, wie große Datenmengen zwischen Diensten ausgetauscht werden können.
Das Hauptproblem besteht darin, dass Daten und Dienste untrennbar miteinander verbunden sind. Einerseits ermutigt uns die Kapselung dazu, Daten zu verbergen, damit Dienste voneinander getrennt werden können und ihr Wachstum und weitere Änderungen erleichtert werden. Andererseits müssen wir wie alle anderen in der Lage sein, über gemeinsame Daten frei zu teilen und zu herrschen. Es geht darum, sofort und so frei wie in jedem anderen Informationssystem mit der Arbeit beginnen zu können.
Allerdings haben Informationssysteme wenig mit Kapselung zu tun. Tatsächlich ist es sogar umgekehrt. Datenbanken tun alles, um Zugriff auf die von ihnen gespeicherten Daten zu ermöglichen. Sie verfügen über eine leistungsstarke deklarative Schnittstelle, mit der Sie die Daten nach Ihren Wünschen ändern können. Eine solche Funktionalität ist in der Phase der Vorforschung wichtig, jedoch nicht für die Bewältigung der wachsenden Komplexität eines sich ständig weiterentwickelnden Dienstes.
Und hier entsteht ein Dilemma. Widerspruch. Dichotomie. Schließlich geht es bei Informationssystemen um die Bereitstellung von Daten und bei Diensten um das Verbergen.
Diese beiden Kräfte sind grundlegend. Sie liegen einem Großteil unserer Arbeit zugrunde und wetteifern ständig um die Vorherrschaft in den Systemen, die wir entwickeln.
Während Servicesysteme wachsen und sich weiterentwickeln, sehen wir unterschiedliche Erscheinungsformen der Auswirkungen der Datendichotomie. Entweder wird die Service-Schnittstelle wachsen, um immer mehr Funktionen bereitzustellen und wie eine sehr schicke selbst erstellte Datenbank aussehen, oder wir werden frustriert sein und eine Möglichkeit implementieren, ganze Datensätze in großen Mengen von Service zu Service zu extrahieren oder zu verschieben.
Das Erstellen von etwas, das wie eine schicke Homebrew-Datenbank aussieht, wird wiederum zu einer ganzen Reihe von Problemen führen. Wir werden nicht näher darauf eingehen, was gefährlich ist gemeinsame DatenbankSagen wir einfach, dass es einen erheblichen technischen und betrieblichen Aufwand darstellt für das Unternehmen, das es nutzen möchte.
Schlimmer noch: Die Datenmengen vervielfachen die Probleme mit Dienstgrenzen. Je mehr gemeinsame Daten innerhalb des Dienstes liegen, desto komplexer wird die Schnittstelle und desto schwieriger wird es, Datensätze verschiedener Dienste zu kombinieren.
Auch der alternative Ansatz, ganze Datensätze zu extrahieren und zu verschieben, bringt seine eigenen Probleme mit sich. Ein gängiger Ansatz für diese Frage scheint darin zu bestehen, einfach den gesamten Datensatz abzurufen und zu speichern und ihn dann lokal in jedem konsumierenden Dienst zu speichern.
Das Problem besteht darin, dass verschiedene Dienste die von ihnen verbrauchten Daten unterschiedlich interpretieren. Diese Daten sind immer griffbereit. Sie werden lokal verändert und verarbeitet. Schon bald haben sie nichts mehr mit den Daten in der Quelle zu tun.
Je veränderlicher die Kopien sind, desto stärker variieren die Daten im Laufe der Zeit.
Schlimmer noch, solche Daten sind im Nachhinein schwer zu korrigieren ( Hier ist es wirklich praktisch.) Tatsächlich sind einige der hartnäckigen technologischen Herausforderungen, mit denen Unternehmen konfrontiert sind, auf heterogene Daten zurückzuführen, die sich von Anwendung zu Anwendung vermehren.
Um eine Lösung für dieses häufige Datenproblem zu finden, müssen Sie anders denken. Sie sollten zu erstklassigen Objekten in den von uns gebauten Architekturen werden. nennt solche Daten „extern“, und das ist eine sehr wichtige Funktion. Wir brauchen eine Kapselung, damit wir die Interna eines Dienstes nicht preisgeben, aber wir müssen es den Diensten leicht machen, auf gemeinsam genutzte Daten zuzugreifen, damit sie ihre Arbeit korrekt erledigen können.
Das Problem besteht darin, dass keiner der beiden Ansätze heute relevant ist, da weder die Serviceschnittstellen noch das Messaging noch die Shared Database eine gute Lösung für die Arbeit mit externen Daten bieten. Serviceschnittstellen sind für den Datenaustausch jeglicher Größenordnung ungeeignet. Messaging verschiebt Daten, speichert jedoch nicht deren Verlauf, sodass Daten mit der Zeit beschädigt werden. Shared Databases konzentriert sich zu sehr auf einen Punkt, was den Fortschritt bremst. Wir bleiben unweigerlich in einem Kreislauf von Datenfehlern stecken:
Datenfehlerzyklus
Flows: ein dezentraler Ansatz für Daten und Dienste
Im Idealfall müssen wir die Art und Weise ändern, wie Dienste mit gemeinsam genutzten Daten arbeiten. Im Moment stößt jeder Ansatz auf die oben erwähnte Dichotomie, da es keinen magischen Staub gibt, den man großzügig darauf streuen und zum Verschwinden bringen kann. Wir können das Problem jedoch noch einmal überdenken und zu einem Kompromiss kommen.
Dieser Kompromiss impliziert einen gewissen Grad an Zentralisierung. Wir können den verteilten Protokollierungsmechanismus nutzen, da er zuverlässige, skalierbare Streams bereitstellt. Jetzt möchten wir, dass Dienste diesen gemeinsamen Threads beitreten und darauf ausgeführt werden können. Wir möchten jedoch komplexe zentralisierte God-Dienste vermeiden, die diese Verarbeitung durchführen. Daher besteht die beste Option darin, die Streaming-Verarbeitung in jeden Verbraucherdienst zu integrieren. Dies ermöglicht es Diensten, Datensätze aus verschiedenen Quellen zu kombinieren und mit ihnen auf die Art und Weise zu arbeiten, wie sie es benötigen.
Eine Möglichkeit, diesen Ansatz zu erreichen, ist die Nutzung einer Streaming-Plattform. Es gibt viele Möglichkeiten, aber heute werden wir Kafka in Betracht ziehen, da die Verwendung seines Stateful Stream Processing es uns ermöglicht, das dargestellte Problem effektiv zu lösen.
Die Verwendung des verteilten Protokollierungsmechanismus ermöglicht es uns, den ausgetretenen Pfaden zu folgen und Messaging für die Arbeit zu nutzen . Es wird davon ausgegangen, dass dieser Ansatz eine bessere Skalierung und Trennung bietet als der Anfrage-Antwort-Mechanismus, da er die Kontrolle über den Fluss dem Empfänger und nicht dem Sender überlässt. Allerdings muss man in diesem Leben für alles bezahlen, und hier braucht man einen Makler. Aber für große Systeme lohnt sich dieser Kompromiss (was man von durchschnittlichen Webanwendungen nicht sagen kann).
Wenn ein Broker für die verteilte Protokollierung verantwortlich ist und nicht ein herkömmliches Nachrichtensystem, können Sie zusätzliche Funktionen nutzen. Ein Transport kann fast genauso gut linear skaliert werden wie ein verteiltes Dateisystem. Daten können über einen langen Zeitraum in Protokollen gespeichert werden, sodass wir nicht nur Nachrichten erhalten, sondern auch einen Informationsspeicher. Skalierbarer Speicher ohne Angst vor veränderlichen gemeinsamen Zuständen.
Anschließend können Sie den Stateful-Stream-Verarbeitungsmechanismus verwenden, um Ihren konsumierenden Diensten deklarative Datenbanktools hinzuzufügen. Das ist ein sehr wichtiger Gedanke. Solange die Daten in gemeinsam genutzten Streams gespeichert sind, auf die alle Dienste zugreifen können, erfolgt die Aggregation und Verarbeitung durch den Dienst privat. Sie stehen isoliert in einem streng begrenzten Kontext.
Beseitigen Sie die Datendichotomie, indem Sie den unveränderlichen Zustandsstrom aufteilen. Fügen Sie diese Funktionalität dann mithilfe von Stateful Stream Processing zu jedem Dienst hinzu.
Wenn Ihr Dienst also mit Bestellungen, einem Produktkatalog oder einem Lager arbeiten muss, hat er vollen Zugriff: Nur Sie entscheiden, welche Daten kombiniert werden, wo sie verarbeitet werden und wie sie sich im Laufe der Zeit ändern sollen. Trotz der gemeinsamen Nutzung der Daten erfolgt die Arbeit damit vollständig dezentral. Es entsteht innerhalb jedes Dienstes, in einer Welt, in der alles nach Ihren Regeln abläuft.
Teilen Sie Daten, ohne ihre Integrität zu gefährden. Kapseln Sie eine Funktion und keine Quelle in jeden Dienst, der sie benötigt.
Es kommt also vor, dass die Daten in großen Mengen verschoben werden müssen. Manchmal benötigt ein Dienst einen lokalen historischen Datensatz in der Datenbank-Engine seiner Wahl. Der Trick besteht darin, dass durch Kontaktaufnahme mit dem verteilten Protokollierungsmechanismus gewährleistet werden kann, dass bei Bedarf eine Kopie von der Quelle wiederhergestellt werden kann. Konnektoren in Kafka leisten hier hervorragende Arbeit.
Der heute besprochene Ansatz hat also mehrere Vorteile:
- Die Daten werden in Form gemeinsam genutzter Streams verwendet, die über einen langen Zeitraum in Protokollen gespeichert werden können, und der Mechanismus für die Arbeit mit gemeinsam genutzten Daten ist in jedem einzelnen Kontext fest verdrahtet, sodass Dienste einfach und schnell funktionieren können. Auf diese Weise kann die Dichotomie der Daten ausgeglichen werden.
- Daten aus verschiedenen Diensten können einfach zu Sätzen zusammengefasst werden. Dies vereinfacht die Interaktion mit gemeinsam genutzten Daten und macht die Pflege lokaler Datensätze in der Datenbank überflüssig.
- Stateful Stream Processing speichert die Daten nur zwischen, und die gemeinsamen Protokolle bleiben die Quelle der Wahrheit, sodass das Problem der Datenbeschädigung im Laufe der Zeit nicht so akut ist.
- Dienste sind im Kern datengesteuert, was bedeutet, dass Dienste trotz des stetig wachsenden Datenvolumens immer noch schnell auf Geschäftsereignisse reagieren können.
- Skalierbarkeitsprobleme liegen beim Broker, nicht bei den Diensten. Dies reduziert die Komplexität von Schreibdiensten erheblich, da keine Rücksicht auf die Skalierbarkeit genommen werden muss.
- Das Hinzufügen neuer Dienste erfordert keine Änderung alter Dienste, sodass die Anbindung neuer Dienste einfacher wird.
Wie Sie sehen, ist es mehr als nur REST. Wir haben eine Reihe von Tools erhalten, die es Ihnen ermöglichen, dezentral mit gemeinsam genutzten Daten zu arbeiten.
Im heutigen Artikel wurden nicht alle Aspekte offengelegt. Wir müssen noch herausfinden, wie wir das Gleichgewicht zwischen dem Anfrage-Antwort-Paradigma und dem ereignisgesteuerten Paradigma herstellen können. Aber wir werden uns beim nächsten Mal damit befassen. Es gibt Themen, die Sie besser kennenlernen müssen, zum Beispiel, warum Stateful Stream Processing so gut ist. Darüber werden wir im dritten Artikel sprechen. Und es gibt noch andere mächtige Konstrukte, die wir nutzen können, wenn wir auf sie zurückgreifen, zum Beispiel: . Es verändert die Spielregeln für verteilte Geschäftssysteme, da es Transaktionsgarantien bietet in skalierbarer Form. Dies wird im vierten Artikel besprochen. Abschließend müssen wir die Einzelheiten der Umsetzung dieser Grundsätze besprechen.
Aber bedenken Sie vorerst nur Folgendes: Die Datendichotomie ist eine Kraft, mit der wir beim Aufbau von Unternehmensdienstleistungen konfrontiert sind. Und daran müssen wir uns erinnern. Der Trick besteht darin, alles auf den Kopf zu stellen und gemeinsam genutzte Daten als erstklassige Objekte zu behandeln. Stateful Stream Processing bietet hierfür einen einzigartigen Kompromiss. Es vermeidet zentralisierte „Gottkomponenten“, die den Fortschritt behindern. Darüber hinaus sorgt es für Agilität, Skalierbarkeit und Ausfallsicherheit von Daten-Streaming-Pipelines und fügt diese zu jedem Dienst hinzu. Daher können wir uns auf den allgemeinen Bewusstseinsstrom konzentrieren, mit dem sich jeder Dienst verbinden und mit seinen Daten arbeiten kann. Dadurch werden Dienste skalierbarer, austauschbarer und autonomer. Daher machen sie nicht nur auf Whiteboards und beim Testen von Hypothesen eine gute Figur, sondern funktionieren und entwickeln sich auch über Jahrzehnte hinweg.
Source: habr.com