{"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":"Daten-Dichotomie: Eine Neubewertung der Beziehung zu Daten und Dienstleistungen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo zusammen! Wir haben gro\u00dfartige Neuigkeiten: Im Juni startet OTUS erneut einen Kurs \u201eSoftwarearchitekt\u201c<\/a><\/noindex>, weshalb wir wie gewohnt n\u00fctzliche Materialien mit Ihnen teilen.<\/b><\/i><\/p>\n

\"Daten-Dichotomie:
\n
\n Falls Sie auf all diese Geschichte mit Mikrodiensten ohne jeglichen Kontext gesto\u00dfen sind, k\u00f6nnen Sie es als verst\u00e4ndlich ansehen, dass Sie es etwas merkw\u00fcrdig finden. Die Aufspaltung einer Anwendung in Fragmente, die \u00fcber ein Netzwerk verbunden sind, bedeutet unweigerlich, dass komplexe Ausfallsicherheitsmechanismen in das resultierende verteilte System integriert werden. <\/p>\n

Obwohl dieser Ansatz die Zerlegung in zahlreiche unabh\u00e4ngige Dienste umfasst, geht das Endziel weit \u00fcber die blo\u00dfe Ausf\u00fchrung dieser Dienste auf unterschiedlichen Maschinen hinaus. Es geht um die Interaktion mit der umliegenden Welt, die von ihrer Natur aus ebenfalls verteilt ist. Nicht im technischen Sinne, sondern eher im Sinne eines \u00d6kosystems, das aus vielen Menschen, Teams und Programmen besteht, wobei jeder dieser Teile auf die eine oder andere Weise seine Aufgaben erf\u00fcllen muss.<\/a><\/noindex><\/p>\n

Unternehmen zum Beispiel bestehen aus einer Reihe von verteilten Systemen, die zusammen eine bestimmte Zielsetzung unterst\u00fctzen. Diesen Fakt haben wir \u00fcber Jahrzehnte ignoriert, indem wir versuchten, durch FTP-Datei\u00fcbertragungen oder mit Unternehmensintegrationswerkzeugen eine Einheit herzustellen, w\u00e4hrend wir uns auf unsere pers\u00f6nlichen, isolierten Ziele konzentrierten. Doch mit dem Aufkommen von Services \u00e4nderte sich alles. Services erm\u00f6glichten es uns, \u00fcber den Tellerrand hinauszuschauen und eine Welt von wechselseitigen Programmen zu erkennen, die zusammenarbeiten. Um jedoch erfolgreich zu sein, ist es notwendig, zwei grundlegend verschiedene Welten zu erkennen und zu konzipieren: die Au\u00dfenwelt, in der wir in einem \u00d6kosystem aus zahlreichen anderen Services leben, und unsere pers\u00f6nliche, innere Welt, in der wir allein herrschen.<\/p>\n

\"Daten-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 traditioneller monolithischer Architektur sind nicht haltbar. Daher ist das richtige Verst\u00e4ndnis solcher Systeme mehr als nur das Erstellen eines coolen Schemas auf einem Whiteboard oder einem beeindruckenden Proof of Concept. Es geht darum, dass ein solches System \u00fcber einen langen Zeitraum hinweg erfolgreich funktioniert. Gl\u00fccklicherweise existieren Services schon seit geraumer Zeit, auch wenn sie unterschiedlich aussehen. SOA Lektionen<\/a><\/noindex> sind nach wie vor relevant, selbst wenn sie mit Docker, Kubernetes gew\u00fcrzt und ein wenig von hipsterhaften B\u00e4rten gezeichnet sind. <\/p>\n

Heute werden wir also betrachten, wie sich die Regeln ver\u00e4ndert haben, warum wir unseren Ansatz f\u00fcr Services und die Daten, die sie austauschen, neu \u00fcberdenken m\u00fcssen und warum wir daf\u00fcr ganz andere Werkzeuge ben\u00f6tigen.<\/p>\n

Kapselung wird Ihnen nicht immerfreundlich sein.<\/h3>\n

\n Mikrodienste k\u00f6nnen unabh\u00e4ngig voneinander agieren. Diese Eigenschaft verleiht ihnen den gr\u00f6\u00dften Wert. Sie erm\u00f6glicht es den Diensten, zu skalieren und zu wachsen. Nicht nur in Bezug auf die Skalierung auf Quadrilliarden von Nutzern oder Petabytes an Daten (obwohl sie auch dabei helfen k\u00f6nnen), sondern in Bezug auf die Menschen, da Teams und Organisationen kontinuierlich wachsen.<\/p>\n

\"Daten-Dichotomie:
\n
\nUnabh\u00e4ngigkeit ist jedoch ein zweischneidiges Schwert. Ein Dienst kann f\u00fcr sich allein leicht und unkompliziert sein. Doch wenn innerhalb eines Dienstes eine Funktion implementiert wird, die einen anderen Dienst ben\u00f6tigt, m\u00fcssen wir letztendlich nahezu gleichzeitig an beiden Diensten \u00c4nderungen vornehmen. In einem Monolithen ist das einfach; man nimmt einfach eine \u00c4nderung vor und ver\u00f6ffentlicht sie. Im Fall von synchronisierten unabh\u00e4ngigen Diensten treten jedoch wesentlich mehr Probleme auf. Die Koordination zwischen den Teams und den Releasezyklen beeintr\u00e4chtigt die Flexibilit\u00e4t.<\/p>\n

\"Daten-Dichotomie:
\n
\nIm Rahmen des Standardansatzes wird versucht, unangenehme durchgehende \u00c4nderungen einfach zu vermeiden, indem die Funktionalit\u00e4t klar zwischen den Diensten aufgeteilt wird. Ein Service f\u00fcr den einheitlichen Zugang 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 einheitliche Zugang in einer Welt mit schnell wechselnden Anforderungen an die umgebenden Dienste wahrscheinlich nicht ver\u00e4ndert wird. Er existiert in einem streng begrenzten Kontext.<\/p>\n

\"Daten-Dichotomie:
\n
\n Das Problem ist, dass in der realen Welt Gesch\u00e4ftsdienste nicht st\u00e4ndig eine so klare Trennung der Rollen aufrechterhalten k\u00f6nnen. Zum Beispiel arbeiten diese Gesch\u00e4ftsdienste \u00fcberwiegend mit Daten, die von anderen \u00e4hnlichen Diensten geliefert werden. Wenn Sie im Online-Einzelhandel t\u00e4tig sind, wird die Verarbeitung des Bestellstroms, des Produktkatalogs oder von Benutzerinformationen eine Anforderung f\u00fcr viele Ihrer Dienste darstellen. Jeder dieser Dienste ben\u00f6tigt Zugriff auf diese Daten, um effektiv arbeiten zu k\u00f6nnen. <\/p>\n

\"Daten-Dichotomie:
\nDie meisten Gesch\u00e4ftsdienste nutzen denselben Datenstrom, weshalb ihre Arbeit unweigerlich verflochten ist.<\/i><\/p>\n

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

Daten-Dichotomie<\/h3>\n

\n Serviceorientierte Ans\u00e4tze existieren m\u00f6glicherweise bereits, jedoch gibt es immer noch wenig Informationen dar\u00fcber, wie gro\u00dfe Datenmengen zwischen den Diensten ausgetauscht werden k\u00f6nnen.<\/p>\n

Das Hauptproblem ist, dass Daten und Dienste untrennbar sind. Einerseits fordert die Kapselung uns auf, Daten zu verbergen, damit die Dienste voneinander getrennt werden k\u00f6nnen und ihr Wachstum sowie weitere \u00c4nderungen erleichtert werden. Andererseits m\u00fcssen wir die M\u00f6glichkeit haben, gemeinsame Daten genauso frei zu teilen und zu verwalten wie jede andere. Es geht darum, in der Lage zu sein, sofort loszulegen, ebenso unbeschwert wie in jedem anderen Informationssystem.<\/p>\n

Informationssysteme haben jedoch wenig mit Kapselung gemein. Tats\u00e4chlich ist es sogar das Gegenteil. Datenbanken tun alles, was sie k\u00f6nnen, um den Zugriff auf die darin gespeicherten Daten zu erm\u00f6glichen. Sie bieten eine leistungsstarke deklarative Schnittstelle, die es erm\u00f6glicht, die Daten nach Bedarf zu transformieren. Diese Funktionalit\u00e4t ist in der Phase der Voruntersuchungen wichtig, jedoch nicht f\u00fcr das Management der wachsenden Komplexit\u00e4t eines st\u00e4ndig sich entwickelnden Dienstes.<\/p>\n

\"Daten-Dichotomie:
\n
\n Hier entsteht ein Dilemma. Ein Widerspruch. Eine Dichotomie. Denn Informationssysteme stehen f\u00fcr die Bereitstellung von Daten, w\u00e4hrend Dienste f\u00fcr das Verbergen stehen.<\/p>\n

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

Mit dem Wachstum und der Evolution von Service-Systemen beobachten wir verschiedene Auswirkungen der Datendichotomie. Entweder w\u00e4chst die Benutzeroberfl\u00e4che des Dienstes, bietet immer umfassendere Funktionen und beginnt, wie eine sehr merkw\u00fcrdige Eigenbau-Datenbank auszusehen, oder wir sehen uns mit Entt\u00e4uschung konfrontiert und finden einen Weg, um ganze Datens\u00e4tze massenhaft von einem Dienst in einen anderen zu extrahieren oder zu verschieben.<\/p>\n

\"Daten-Dichotomie:
\n
\n Die Schaffung von etwas, das wie eine merkw\u00fcrdige Eigenbau-Datenbank aussieht, f\u00fchrt ihrerseits zu einer ganzen Reihe von Problemen. Wir werden nicht im Detail darauf eingehen, was gef\u00e4hrlich ist, shared database<\/i>, aber wir sagen einfach, dass sie erhebliche kostenintensive Ingenieur- und Betriebsschwierigkeiten f\u00fcr ein Unternehmen darstellt, das versucht, sie zu nutzen.<\/a><\/noindex> Schlimmer ist, dass die Datenmengen die Probleme an den Grenzen der Dienste multiplizieren. Je mehr gemeinsame Daten innerhalb eines Dienstes liegen, desto komplexer wird die Benutzeroberfl\u00e4che und desto schwieriger wird es, Datens\u00e4tze aus verschiedenen Diensten zu kombinieren.<\/p>\n

Schlimmer ist, dass die Datenmengen die Probleme an den Schnittstellen verst\u00e4rken. Je mehr gemeinsame Daten innerhalb des Dienstes liegen, desto komplexer wird die Benutzeroberfl\u00e4che, und desto schwieriger wird es werden, Datens\u00e4tze aus verschiedenen Diensten zu kombinieren.<\/p>\n

Ein alternativer Ansatz, bei dem ganze Datens\u00e4tze extrahiert und verschoben werden, hat ebenfalls seine Probleme. Der g\u00e4ngige Ansatz besteht darin, einen Datensatz vollst\u00e4ndig zu extrahieren und dann lokal in jedem konsumierenden Dienst zu speichern.<\/p>\n

\"Daten-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 ver\u00e4ndert und verarbeitet. Sehr schnell haben sie kaum noch etwas mit den Daten in der Quelle gemein.<\/p>\n

\"Daten-Dichotomie:
\n Je mehr ver\u00e4nderlich die Kopien sind, desto mehr werden die Daten im Laufe der Zeit voneinander abweichen.<\/i><\/p>\n

Was noch schlimmer ist, solche Daten sind im Nachhinein schwer zu korrigieren (MDM<\/a><\/noindex> hier kann es wirklich zur Hilfe kommen). Tats\u00e4chlich entstehen einige der schwer l\u00f6sbaren technologischen Probleme, mit denen Unternehmen konfrontiert sind, aufgrund heterogener Daten, die sich von Anwendung zu Anwendung vervielfachen.<\/p>\n

Um eine L\u00f6sung f\u00fcr dieses Problem mit gemeinsamen Daten zu finden, m\u00fcssen wir anders denken. Sie sollten zu erstklassigen Objekten in den Architekturen werden, die wir bauen. Pat Helland<\/a><\/noindex> nennt solche Daten \"extern\", und das ist eine sehr wichtige Eigenschaft. Wir ben\u00f6tigen Kapselung, um die interne Struktur des Services nicht offenzulegen, aber wir m\u00fcssen den Services den Zugang zu gemeinsam genutzten Daten erleichtern, damit sie ihre Arbeit korrekt ausf\u00fchren k\u00f6nnen.<\/p>\n

\"Daten-Dichotomie:
\n
\n Das Problem ist, dass keiner der heutigen Ans\u00e4tze mehr aktuell ist, da weder die Service-Schnittstellen, noch der Nachrichtenaustausch, noch die Shared Database eine gute L\u00f6sung f\u00fcr den Umgang mit externen Daten anbieten. Service-Schnittstellen eignen sich schlecht f\u00fcr den Datenaustausch in irgendeinem Ma\u00dfstab. Der Nachrichtenaustausch bewegt Daten, speichert jedoch nicht ihre Historie, weshalb die Daten im Laufe der Zeit besch\u00e4digt werden. Shared Databases konzentrieren sich zu stark auf einen einzigen Punkt, was den Fortschritt behindert. Wir stecken unvermeidlich in einem Kreis von Dateninkonsistenzen fest:<\/p>\n

\"Daten-Dichotomie:
\n Kreis der Dateninkonsistenzen<\/i><\/p>\n

Fl\u00fcsse: dezentraler Ansatz f\u00fcr Daten und Services<\/h3>\n

\n Idealerweise m\u00fcssen wir unseren Ansatz \u00e4ndern, wie Dienste mit gemeinsamen Daten umgehen. Aktuell sieht sich jeder Ansatz der oben erw\u00e4hnten Dichotomie gegen\u00fcber, da es kein Wundermittel gibt, mit dem man gro\u00dfz\u00fcgig dar\u00fcber streuen kann, um sie verschwinden zu lassen. Wir k\u00f6nnen jedoch das Problem neu \u00fcberdenken und zu einem Kompromiss kommen.<\/p>\n

Dieser Kompromiss erfordert einen gewissen Grad an Zentralisierung. Wir k\u00f6nnen einen Mechanismus f\u00fcr verteilte Protokolle nutzen, da er zuverl\u00e4ssige, skalierbare Datenstr\u00f6me bietet. Jetzt m\u00fcssen die Dienste in der Lage sein, sich anzuschlie\u00dfen und mit diesen gemeinsamen Str\u00f6men zu arbeiten. Dabei m\u00f6chten wir jedoch komplizierte zentrale God Services vermeiden, die solche Verarbeitungen durchf\u00fchren. Daher ist der beste Ansatz, die Streaming-Verarbeitung in jeden konsumierenden Dienst einzubauen. So k\u00f6nnen die Dienste Datens\u00e4tze aus verschiedenen Quellen kombinieren und damit so arbeiten, wie sie es ben\u00f6tigen.<\/p>\n

Eine M\u00f6glichkeit, einen solchen Ansatz zu erreichen, ist die Verwendung einer Streaming-Plattform. Es gibt viele Optionen, aber heute konzentrieren wir uns auf Kafka, da ihre Stateful Stream Processing dazu beitr\u00e4gt, das dargestellte Problem effizient zu l\u00f6sen.<\/p>\n

\"Daten-Dichotomie:
\n
\n Die Nutzung eines verteilten Logging-Mechanismus erm\u00f6glicht es uns, den gewohnten Pfad zu beschreiten und Nachrichten zu verwenden, um mit ereignisgesteuerten Architekturen<\/a><\/noindex>. Man glaubt, dass dieser Ansatz eine bessere Skalierbarkeit und Trennung bietet als das \u201eRequest-Response\u201c-Modell, da er die Kontrolle \u00fcber den Datenfluss dem Empf\u00e4nger und nicht dem Sender \u00fcberl\u00e4sst. Allerdings hat alles im Leben seinen Preis, und daf\u00fcr ben\u00f6tigen Sie einen Broker. Aber f\u00fcr gro\u00dfe Systeme ist dieser Kompromiss es wert (was man von Ihren durchschnittlichen Webanwendungen nicht 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 l\u00e4sst sich nahezu linear skalieren, \u00e4hnlich wie ein verteiltes Dateisystem. Daten k\u00f6nnen lange in Logs gespeichert werden, sodass wir nicht nur eine Nachrichten\u00fcbermittlung erhalten, sondern auch einen Informationsspeicher. Ein skalierbarer Speicher, ohne Sorge, einen ver\u00e4nderbaren Gesamtzustand zu empfangen.<\/p>\n

Anschlie\u00dfend kann der Mechanismus der stateful stream processing (Zustandsbehaftete Stream-Verarbeitung) genutzt werden, um deklarative Datenbankwerkzeuge in Verbraucherdienste einzubinden. Das ist ein sehr wichtiger Gedanke. Solange die Daten in gemeinsamen Streams gespeichert sind, auf die alle Dienste Zugriff haben, sind die Zusammenf\u00fchrung und Verarbeitung, die der Dienst vornimmt, privat. Sie sind innerhalb eines streng begrenzten Kontextes isoliert.<\/p>\n

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

Wenn Ihr Service mit Bestellungen, einem Produktkatalog oder einem Lager arbeitet, haben Sie vollst\u00e4ndigen Zugriff: Sie entscheiden allein, welche Daten zusammengef\u00fchrt, wo sie verarbeitet und wie sie sich im Laufe der Zeit \u00e4ndern sollen. Obwohl die Daten gemeinsam genutzt werden, bleibt die Arbeit mit ihnen v\u00f6llig dezentralisiert. Sie erfolgt innerhalb jedes Services, in einer Welt, in der alles nach Ihren Regeln l\u00e4uft.<\/p>\n

\"Daten-Dichotomie:
\nTeilen Sie Daten so, dass ihre Integrit\u00e4t nicht gef\u00e4hrdet wird. Kapseln Sie die Funktion, nicht die Quelle, in jedem Service, der sie ben\u00f6tigt.<\/i><\/p>\n

Es kommt vor, dass Daten in gro\u00dfem Umfang verschoben werden m\u00fcssen. Manchmal ben\u00f6tigt ein Service eine lokale historische Datensammlung 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 Protokollmechanismus wiederhergestellt werden kann. Die Konnektoren in Kafka erledigen diese Aufgabe hervorragend.<\/p>\n

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