{"id":83248,"date":"2020-05-29T19:42:48","date_gmt":"2020-05-29T17:42:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam"},"modified":"2020-05-29T19:42:48","modified_gmt":"2020-05-29T17:42:48","slug":"dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","title":{"rendered":"Dichotomie der Daten: \u00dcberdenken des Verh\u00e4ltnisses zu Daten und Dienstleistungen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo zusammen! Wir haben tolle Neuigkeiten, im Juni startet OTUS wieder einen Kurs \u201eSoftwarearchitekt\u201c<\/a><\/noindex>, weshalb wir traditionell n\u00fctzliche Materialien mit Ihnen teilen.<\/b><\/i><\/p>\n

\"Dichotomie
\n
\n Wenn Sie mit dieser gesamten Geschichte der Mikrodienste ohne jeglichen Kontext konfrontiert wurden, kann man verstehen, dass Sie sie etwas seltsam finden. Die Zerlegung einer Anwendung in Fragmente, die durch ein Netzwerk verbunden sind, bedeutet unweigerlich die Einf\u00fchrung komplexer Ausfallsicherheitsmodi in das entstandene verteilte System. <\/p>\n

Obwohl dieser Ansatz die Zerlegung in zahlreiche unabh\u00e4ngige Dienste umfasst, ist das endg\u00fcltige Ziel viel gr\u00f6\u00dfer, als nur die Funktion dieser Dienste auf verschiedenen Maschinen. Es geht vielmehr um die Interaktion mit der umliegenden Welt, die ihrer Natur nach ebenfalls verteilt ist. Nicht im technischen Sinne, sondern vielmehr im Sinne eines \u00d6kosystems, das aus vielen Menschen, Teams und Programmen besteht, wobei jedes dieser Teile auf die eine oder andere Weise seine Arbeit erledigen muss.<\/a><\/noindex><\/p>\n

Unternehmen stellen beispielsweise eine Reihe verteilter Systeme dar, die zusammen zur Erreichung eines bestimmten Ziels beitragen. Wir haben diese Tatsache jahrzehntelang ignoriert, indem wir versucht haben, zu integrieren, Dateien \u00fcber FTP auszutauschen oder Unternehmensintegrationswerkzeuge zu verwenden, w\u00e4hrend wir uns auf unsere pers\u00f6nlichen isolierten Ziele konzentriert haben. Aber mit dem Aufkommen von Diensten hat sich alles ver\u00e4ndert. Dienste haben uns geholfen, \u00fcber den Tellerrand hinauszuschauen und die Welt der wechselseitigen Abh\u00e4ngigkeiten von Programmen zu sehen, die zusammenarbeiten. Um jedoch erfolgreich zu arbeiten, ist es notwendig, zwei grundlegend unterschiedliche Welten zu erkennen und zu gestalten: die Au\u00dfenwelt, in der wir in einem \u00d6kosystem vieler anderer Dienste leben, und unsere pers\u00f6nliche, innere Welt, in der wir allein herrschen.<\/p>\n

\"Dichotomie
\n
\n Eine solche verteilte Welt unterscheidet sich von der, in der wir aufgewachsen sind und an die wir gew\u00f6hnt sind. Die Prinzipien des traditionellen monolithischen Architekturmodells halten keiner Kritik stand. Deshalb ist ein richtiges Verst\u00e4ndnis solcher Systeme mehr als nur die Erstellung eines coolen Diagramms auf einem wei\u00dfen Flipchart oder eines beeindruckenden Proof of Concept. Es geht darum, dass ein solches System \u00fcber lange Zeit erfolgreich funktioniert. Gl\u00fccklicherweise gibt es Dienste schon seit geraumer Zeit, obwohl sie unterschiedlich aussehen. Lektionen der SOA<\/a><\/noindex> sind immer noch relevant, selbst wenn sie mit Docker, Kubernetes gew\u00fcrzt und leicht von hipsterischen B\u00e4rten zerzaust sind. <\/p>\n

Heute schauen wir uns an, wie sich die Regeln ge\u00e4ndert haben, warum wir unsere Herangehensweise an die Dienste und die Daten, die sie austauschen, \u00fcberdenken m\u00fcssen und warum wir daf\u00fcr vollkommen andere Werkzeuge ben\u00f6tigen.<\/p>\n

Kapselung wird nicht immer Ihr Freund sein.<\/h3>\n

\n Mikroservices k\u00f6nnen unabh\u00e4ngig voneinander arbeiten. Gerade diese Eigenschaft verleiht ihnen den gr\u00f6\u00dften Wert. Diese Eigenschaft erm\u00f6glicht es den Diensten auch, zu skalieren und zu wachsen. Nicht nur im Sinne der Skalierung auf Quadrillionen von Nutzern oder Petabyte an Daten (obwohl sie auch hierbei helfen k\u00f6nnen), sondern im Hinblick auf das Wachstum von Teams und Organisationen.<\/p>\n

\"Dichotomie
\n
\nDie Unabh\u00e4ngigkeit ist jedoch ein zweischneidiges Schwert. Ein Dienst kann f\u00fcr sich genommen leicht und m\u00fchelos laufen. Wenn jedoch innerhalb eines Dienstes eine Funktion implementiert wird, die einen anderen Dienst erfordert, m\u00fcssen wir letztendlich nahezu gleichzeitig \u00c4nderungen in beiden Diensten vornehmen. In einem Monolithen ist das einfach, man nimmt einfach die \u00c4nderung vor und sendet sie in die Ver\u00f6ffentlichung, aber bei der Synchronisierung unabh\u00e4ngiger Dienste gibt es mehr Probleme. Die Koordination zwischen den Teams und den Ver\u00f6ffentlichungszyklen zerst\u00f6rt die Flexibilit\u00e4t.<\/p>\n

\"Dichotomie
\n
\nIm Rahmen des Standardansatzes versucht man, \u00e4rgerliche Durchgriffs\u00e4nderungen zu vermeiden, indem die Funktionalit\u00e4t klar zwischen den Diensten aufgeteilt wird. Ein Dienst als Eingangspunkt zum System kann hier ein gutes Beispiel sein. Er hat eine klar definierte Rolle, die ihn von anderen Diensten unterscheidet. Diese klare Trennung bedeutet, dass der Eingangspunkt in einer Welt, die sich schnell \u00e4ndernden Anforderungen an die ihn umgebenden Dienste stellt, wahrscheinlich nicht ver\u00e4ndert wird. Er exists in einem streng begrenzten Kontext.<\/p>\n

\"Dichotomie
\n
\n Das Problem besteht darin, dass in der realen Welt Gesch\u00e4ftsdienste nicht st\u00e4ndig eine gleichm\u00e4\u00dfige Trennung der Rollen aufrechterhalten k\u00f6nnen. Zum Beispiel arbeiten dieselben Gesch\u00e4ftsdienste in gr\u00f6\u00dferem Ma\u00dfe mit Daten, die von anderen \u00e4hnlichen Diensten stammen. Wenn Sie im Online-Handel t\u00e4tig sind, wird die Verarbeitung des Bestellflusses, des Produktkatalogs oder von Benutzerinformationen zu einer Anforderung f\u00fcr viele Ihrer Dienste. Jeder dieser Dienste ben\u00f6tigt Zugang zu diesen Daten, um zu funktionieren. <\/p>\n

\"Dichotomie
\nDie meisten Gesch\u00e4ftsdienste nutzen denselben Datenfluss, weshalb ihre Arbeit untrennbar miteinander verwoben ist.<\/i><\/p>\n

So sind wir zu einem wichtigen Punkt gekommen, \u00fcber den es sich zu sprechen lohnt. W\u00e4hrend Dienste gut f\u00fcr Infrastrukturkomponenten funktionieren, die weitgehend isoliert arbeiten, sind die meisten Gesch\u00e4ftsdienste wesentlich enger miteinander verbunden.<\/p>\n

Daten-Dichotomie<\/h3>\n

\n Service-orientierte Ans\u00e4tze existieren m\u00f6glicherweise bereits, allerdings gibt es noch wenig Informationen dar\u00fcber, wie man gro\u00dfe Datenmengen zwischen Diensten austauschen kann.<\/p>\n

Das Hauptproblem besteht darin, dass Daten und Dienste untrennbar miteinander verbunden sind. Einerseits fordert die Kapselung uns auf, Daten zu verbergen, sodass Dienste voneinander getrennt werden k\u00f6nnen, was ihr Wachstum und ihre zuk\u00fcnftigen \u00c4nderungen erleichtert. Andererseits m\u00fcssen wir die M\u00f6glichkeit haben, gemeinsame Daten genauso frei zu teilen und zu verwalten wie jede andere Art von Daten. Es geht darum, die F\u00e4higkeit zu haben, sofort und genauso frei wie in jedem anderen Informationssystem zu arbeiten.<\/p>\n

Allerdings haben Informationssysteme wenig mit Kapselung zu tun. Tats\u00e4chlich ist es eher umgekehrt. Datenbanken tun alles, was sie k\u00f6nnen, um den Zugriff auf die darin gespeicherten Daten zu erm\u00f6glichen. Sie kommen mit einer leistungsstarken deklarativen Schnittstelle, die es erm\u00f6glicht, die Daten nach Bedarf zu ver\u00e4ndern. Eine solche Funktionalit\u00e4t ist in der Phase der Voruntersuchungen wichtig, aber nicht f\u00fcr das Management der wachsenden Komplexit\u00e4t eines sich st\u00e4ndig weiterentwickelnden Dienstes.<\/p>\n

\"Dichotomie
\n
\n Hier entsteht ein Dilemma. Ein Widerspruch. Eine Dichotomie. Denn Informationssysteme dreht sich um die Bereitstellung von Daten, w\u00e4hrend Dienste sich mit deren Verbergen befassen.<\/p>\n

Diese beiden Kr\u00e4fte sind fundamental. Sie bilden die Grundlage f\u00fcr den Gro\u00dfteil unserer Arbeit und k\u00e4mpfen st\u00e4ndig um die Vorherrschaft in den Systemen, die wir erschaffen.<\/p>\n

Mit dem Wachstum und den Entwicklungen von Servicessystemen sehen wir verschiedene Erscheinungsformen der Auswirkungen der Datendichotomie. Entweder w\u00e4chst die Dienstschnittstelle und bietet immer umfangreichere Funktionen und beginnt, wie eine sehr seltsame, hausgemachte Datenbank auszusehen, oder wir erleben Frustration, und wir implementieren irgendeine M\u00f6glichkeit, gro\u00dfe Datens\u00e4tze massenhaft aus einem Dienst in einen anderen zu extrahieren oder zu \u00fcbertragen.<\/p>\n

\"Dichotomie
\n
\n Die Schaffung von etwas, das wie eine seltsame hausgemachte Datenbank aussieht, f\u00fchrt wiederum zu einer ganzen Reihe von Problemen. Wir werden nicht auf die Einzelheiten eingehen, warum shared database<\/i>bedeutende kostspielige Ingenieurs- und Betriebs schwierigkeiten<\/a><\/noindex> f\u00fcr ein Unternehmen darstellt, das versucht, sie zu nutzen.<\/p>\n

Schlimmer ist, dass die Datenmengen die Probleme mit den Grenzen der Dienste verst\u00e4rken. Je mehr gemeinsame Daten innerhalb eines Dienstes liegen, desto komplizierter wird die Schnittstelle und desto schwieriger wird es, Datens\u00e4tze aus verschiedenen Diensten zu kombinieren.<\/p>\n

Ein alternativer Ansatz zur Extraktion und \u00dcbertragung ganzer Datens\u00e4tze hat ebenfalls seine Probleme. Der h\u00e4ufigste Ansatz zu diesem Thema besteht darin, einen Datensatz komplett zu extrahieren und dann lokal in jedem Verbraucherdienst zu speichern.<\/p>\n

\"Dichotomie
\n
\n Das Problem ist, dass verschiedene Dienste die Daten, die sie konsumieren, unterschiedlich interpretieren. Diese Daten sind immer zur Hand. Sie werden lokal ge\u00e4ndert und verarbeitet. Sehr schnell haben sie nichts mehr mit den Daten aus der Quelle gemeinsam.<\/p>\n

\"Dichotomie
\n Je mutierbarer die Kopien sind, desto mehr werden die Daten mit der Zeit abweichen.<\/i><\/p>\n

Was noch schlimmer ist, solche Daten sind retrospektiv schwer zu korrigieren (MDM<\/a><\/noindex> da k\u00f6nnte wirklich Hilfe kommen). Tats\u00e4chlich entstehen einige der schwer zu l\u00f6senden technologischen Probleme, mit denen Unternehmen konfrontiert sind, durch heterogene Daten, die sich von Anwendung zu Anwendung vervielf\u00e4ltigen.<\/p>\n

Um eine L\u00f6sung f\u00fcr das Problem gemeinsamer Daten zu finden, muss man anders denken. Sie sollten in den Architekturen, die wir bauen, zu erstklassigen Objekten werden. Pat Helland<\/a><\/noindex> bezeichnet solche Daten als \"extern\", und das ist eine sehr wichtige Eigenschaft. Wir ben\u00f6tigen eine Kapselung, um die interne Struktur des Dienstes nicht offenzulegen, aber wir m\u00fcssen den Diensten den Zugang zu gemeinsam genutzten Daten erleichtern, damit sie ihre Arbeit ordnungsgem\u00e4\u00df erledigen k\u00f6nnen.<\/p>\n

\"Dichotomie
\n
\n Das Problem ist, dass heute kein Ansatz mehr relevant ist, da weder die Schnittstellen des Dienstes, noch der Nachrichtenaustausch, noch die Shared Database eine gute L\u00f6sung f\u00fcr den Umgang mit externen Daten bieten. Die Schnittstellen des Dienstes eignen sich schlecht f\u00fcr den Austausch von Daten in beliebigem Umfang. Der Nachrichtenaustausch bewegt Daten, speichert aber deren Geschichte nicht, weshalb die Daten im Laufe der Zeit besch\u00e4digt werden. Shared Databases sind zu stark auf einen Punkt fokussiert, was die Entwicklung des Fortschritts hemmt. Wir stecken zwangsl\u00e4ufig in einem Teufelskreis von Dateninkonsistenz fest:<\/p>\n

\"Dichotomie
\n Der Teufelskreis der Dateninkonsistenz<\/i><\/p>\n

Str\u00f6me: ein dezentraler Ansatz f\u00fcr Daten und Dienste<\/h3>\n

\n Idealerweise sollten wir unseren Ansatz \u00e4ndern, wie Dienste mit gemeinsamen Daten arbeiten. Momentan sieht sich jeder Ansatz der oben erw\u00e4hnten Dichotomie gegen\u00fcber, da es kein magisches Pulver gibt, mit dem man es gro\u00dfz\u00fcgig best\u00e4uben und zum Verschwinden bringen k\u00f6nnte. Wir k\u00f6nnen jedoch das Problem neu \u00fcberdenken und zu einem Kompromiss kommen.<\/p>\n

Dieser Kompromiss setzt ein gewisses Ma\u00df an Zentralisierung voraus. Wir k\u00f6nnen den Mechanismus verteilter Protokolle nutzen, da er zuverl\u00e4ssige, skalierbare Str\u00f6me bietet. Jetzt m\u00fcssen die Dienste in der Lage sein, sich diesen gemeinsamen Str\u00f6men anzuschlie\u00dfen und damit zu arbeiten, jedoch m\u00f6chten wir komplizierte zentralisierte God Services vermeiden, die solche Verarbeitungen durchf\u00fchren. Deshalb ist die beste Option, die Stream-Verarbeitung in jeden Verbraucher-Dienst zu integrieren. So k\u00f6nnen die Dienste Datens\u00e4tze aus verschiedenen Quellen zusammenf\u00fchren und damit arbeiten, wie sie es ben\u00f6tigen.<\/p>\n

Ein Weg, um einen solchen Ansatz zu erreichen, ist die Nutzung einer Streaming-Plattform. Es gibt viele Optionen, aber heute werden wir uns speziell mit Kafka befassen, da die Nutzung ihrer Stateful Stream Processing es erm\u00f6glicht, das dargestellte Problem effektiv zu l\u00f6sen.<\/p>\n

\"Dichotomie
\n
\n Die Nutzung des Mechanismus des verteilten Loggens erlaubt es uns, den bereits eingeschlagenen Weg zu gehen und den Nachrichtenaustausch zu nutzen, um damit zu arbeiten. ereignisgesteuerten Architektur<\/a><\/noindex>. Es wird angenommen, dass dieser Ansatz eine bessere Skalierbarkeit und Trennung bietet als das \u201eRequest-Response\u201c-Mechanismus, da er den Datenfluss an den Empf\u00e4nger und nicht an den Sender \u00fcbergibt. Allerdings muss man f\u00fcr alles im Leben bezahlen, und hier ben\u00f6tigen Sie einen Broker. F\u00fcr gro\u00dfe Systeme ist dieser Kompromiss jedoch von Bedeutung (was man nicht von Ihren durchschnittlichen Webanwendungen sagen kann).<\/p>\n

Wenn der Broker f\u00fcr das verteilte Logging verantwortlich ist und nicht das traditionelle Nachrichtensystem, k\u00f6nnen zus\u00e4tzliche Funktionen genutzt werden. Der Transport kann nahezu ebenso linear skalierbar sein wie ein verteiltes Dateisystem. Die Daten k\u00f6nnen lange genug in Logs gespeichert werden, sodass wir nicht nur Nachrichten, sondern auch ein Informationsspeicher erhalten. Ein skalierbarer Speicher, ohne die Bef\u00fcrchtung, einen ver\u00e4nderlichen gemeinsamen Zustand zu bekommen.<\/p>\n

Dann kann der Mechanismus der zustandsbehafteten Streamverarbeitung (Stateful Stream Processing) verwendet werden, um deklarative Datenbankwerkzeuge in den konsumierenden Diensten hinzuzuf\u00fcgen. Das ist ein sehr wichtiger Gedanke. Solange die Daten in gemeinsamen Streams aufbewahrt werden, auf die alle Dienste zugreifen k\u00f6nnen, bleiben die Kombination und die Verarbeitung, die der Dienst vornimmt, privat. Sie sind innerhalb eines streng abgegrenzten Kontexts isoliert.<\/p>\n

\"Dichotomie
\n Befreien Sie sich von der Dichotomie der Daten, indem Sie den unver\u00e4nderlichen Zustandspool trennen. F\u00fcgen Sie diese Funktion dann jedem Dienst mithilfe von Stateful Stream Processing hinzu.<\/i><\/p>\n

Somit hat Ihr Dienst vollen Zugriff, wenn er mit Bestellungen, Produktkatalogen und Lagerbest\u00e4nden arbeiten muss: Nur Sie entscheiden, welche Daten zusammengef\u00fcgt werden, wo sie verarbeitet werden und wie sie sich im Laufe der Zeit \u00e4ndern sollen. Obwohl die Daten gemeinsam sind, erfolgt die Arbeit mit ihnen vollst\u00e4ndig dezentralisiert. Sie geschieht innerhalb jedes Dienstes in einer Welt, in der alles nach Ihren Regeln geht.<\/p>\n

\"Dichotomie
\nTeilen Sie Daten so, dass ihre Integrit\u00e4t gewahrt bleibt. Kapseln Sie die Funktion und nicht die Quelle in jedem Dienst, der sie ben\u00f6tigt.<\/i><\/p>\n

Es kommt vor, dass Daten massenhaft verschoben werden m\u00fcssen. Manchmal ben\u00f6tigt der Service einen lokalen historischen Datensatz in der gew\u00e4hlten Datenbank-Engine. Der Fokus liegt darauf, dass garantiert werden kann, dass bei Bedarf eine Kopie aus der Quelle mithilfe des verteilten Logging-Mechanismus wiederhergestellt werden kann. Die Connectoren in Kafka meistern diese Aufgabe hervorragend.<\/p>\n

Der heute betrachtete Ansatz hat mehrere Vorteile:<\/p>\n