{"id":37849,"date":"2019-10-31T22:20:09","date_gmt":"2019-10-31T19:20:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kafka-i-mikroservisy-obzor\/"},"modified":"2019-10-31T22:20:09","modified_gmt":"2019-10-31T19:20:09","slug":"kafka-i-mikroservisy-obzor","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","title":{"rendered":"Kafka und Mikrodienste: Eine \u00dcbersicht","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Kafka und Mikrodienste: Eine \u00dcbersicht\" src=\"\/wp-content\/uploads\/2019\/09\/ab0534ad5d28b3c3aa03e4e0b2d3101b.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hallo zusammen. In diesem Artikel erkl\u00e4re ich, warum wir bei Avito vor neun Monaten Kafka gew\u00e4hlt haben und was es genau ist. Ich teile einen Anwendungsfall \u2014 den Nachrichtenbroker. Zum Schluss sprechen wir \u00fcber die Vorteile, die wir durch den Einsatz von Kafka als Dienstleistung erhalten haben.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1 id=\"problema\">Das Problem<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka und Mikrodienste: Eine \u00dcbersicht\" src=\"\/wp-content\/uploads\/2019\/09\/dfa5e231847cee67259da17867a11812.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Zun\u00e4chst ein wenig Kontext. Vor einiger Zeit haben wir begonnen, von einer monolithischen Architektur abzur\u00fccken, und derzeit gibt es bei Avito mehrere Hundert verschiedene Services. Diese verf\u00fcgen \u00fcber eigene Datenbanken, eigene Technologiestacks und sind f\u00fcr ihren Teil der Gesch\u00e4ftslogik verantwortlich. <\/p>\n<p><\/p>\n<p>Ein Problem bei einer gro\u00dfen Anzahl von Services sind die Kommunikationswege. Service A m\u00f6chte oft Informationen von Service B erhalten. In diesem Fall kontaktiert Service A Service B \u00fcber eine synchrone API. Service C m\u00f6chte wissen, was bei den Services G und D passiert, w\u00e4hrend diese wiederum an den Services A und B interessiert sind. Wenn die Zahl solcher \u201eneugierigen\u201c Services w\u00e4chst, verwandeln sich die Verbindungen zwischen ihnen in ein kompliziertes Netz.<\/p>\n<p><\/p>\n<p>In diesem Zusammenhang kann der Dienst A jederzeit ausfallen. Was soll der Dienst B und all die anderen, die von ihm abh\u00e4ngen, in diesem Fall tun? Wenn f\u00fcr die Durchf\u00fchrung einer Gesch\u00e4ftsoperation eine Kette aufeinanderfolgender synchroner Aufrufe erforderlich ist, steigt die Wahrscheinlichkeit, dass die gesamte Operation fehlschl\u00e4gt, noch mehr (und je l\u00e4nger diese Kette ist, desto h\u00f6her ist sie). <\/p>\n<p><\/p>\n<h1 id=\"vybor-tehnologii\">Technologieauswahl<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka und Mikrodienste: Eine \u00dcbersicht\" src=\"\/wp-content\/uploads\/2019\/09\/3acd7bcf3dded8093bdef6d627eb4071.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Okay, die Probleme sind klar. Wir k\u00f6nnen sie beheben, indem wir ein zentrales Nachrichtenaustauschsystem zwischen den Diensten erstellen. Jetzt muss jeder Dienst nur noch von diesem Nachrichtenaustauschsystem wissen. Dar\u00fcber hinaus sollte das System ausfallsicher und horizontal skalierbar sein und im Falle eines Ausfalls einen Puffer f\u00fcr Anfragen sammeln, um diese sp\u00e4ter zu verarbeiten. <\/p>\n<p><\/p>\n<p>Lassen Sie uns nun die Technologie ausw\u00e4hlen, mit der die Nachrichten\u00fcbermittlung realisiert wird. Zuerst kl\u00e4ren wir, was wir von ihr erwarten:<\/p>\n<p><\/p>\n<ul>\n<li>Nachrichten zwischen den Diensten d\u00fcrfen nicht verloren gehen;<\/li>\n<li>Nachrichten k\u00f6nnen sich duplizieren;<\/li>\n<li>Nachrichten k\u00f6nnen \u00fcber mehrere Tage hinweg gespeichert und gelesen werden (persistenter Puffer);<\/li>\n<li>Dienste k\u00f6nnen sich f\u00fcr relevante Daten anmelden;<\/li>\n<li>Einige Dienste k\u00f6nnen die gleichen Daten lesen;<\/li>\n<li>Nachrichten k\u00f6nnen einen detaillierten, umfangreichen Payload (event-carried state transfer) enthalten;<\/li>\n<li>Manchmal ist eine Garantierung der Reihenfolge von Nachrichten erforderlich.<\/li>\n<\/ul>\n<p><\/p>\n<p>In dieser Phase war es uns auch kritisch wichtig, das maximal skalierbare und zuverl\u00e4ssige System mit hoher Durchsatzrate (mindestens 100.000 Nachrichten von mehreren Kilobyte pro Sekunde) auszuw\u00e4hlen.<\/p>\n<p><\/p>\n<p>An diesem Punkt haben wir uns von RabbitMQ verabschiedet (schwierig, bei hohen RPS stabil zu halten), PGQ von SkyTools (nicht schnell genug und schlecht skalierbar) und NSQ (nicht persistent). All diese Technologien werden bei uns im Unternehmen eingesetzt, aber f\u00fcr die zu l\u00f6sende Aufgabe waren sie nicht geeignet. <\/p>\n<p><\/p>\n<p>Dann begannen wir, neue Technologien f\u00fcr uns zu betrachten \u2013 Apache Kafka, Apache Pulsar und NATS Streaming.<\/p>\n<p><\/p>\n<p>Pulsar haben wir als erstes ausgeschlossen. Wir entschieden, dass Kafka und Pulsar recht \u00e4hnliche L\u00f6sungen sind. Und obwohl Pulsar von gro\u00dfen Unternehmen getestet, neuer und theoretisch mit niedrigerer Latenz bietet, entschieden wir uns, von diesen beiden Kafka als de facto Standard f\u00fcr solche Aufgaben zu belassen. Wahrscheinlich werden wir in Zukunft zu Apache Pulsar zur\u00fcckkehren. <\/p>\n<p><\/p>\n<p>Und so blieben zwei Kandidaten: NATS Streaming und Apache Kafka. Wir haben beide L\u00f6sungen ausf\u00fchrlich untersucht, und beide erf\u00fcllten die Anforderungen. Doch letztendlich hatten wir Bedenken bez\u00fcglich der relativen Jugend von NATS Streaming (insbesondere da einer der Hauptentwickler, Tyler Treat, beschlossen hat, das Projekt zu verlassen und sein eigenes - Liftbridge - zu starten). Zudem bot der Clustering-Modus von NATS Streaming keine starken horizontalen Skalierungsm\u00f6glichkeiten (wahrscheinlich ist das jetzt kein Problem mehr, seit der Partitionierungsmodus 2017 hinzugef\u00fcgt wurde).<\/p>\n<p><\/p>\n<p>Dennoch ist NATS Streaming eine beeindruckende Technologie, die in Go geschrieben wurde und Unterst\u00fctzung von der Cloud Native Computing Foundation erh\u00e4lt. Im Gegensatz zu Apache Kafka ben\u00f6tigt sie keinen Zookeeper f\u00fcr den Betrieb (m\u00f6glicherweise <noindex><a rel=\"nofollow\" href=\"https:\/\/cwiki.apache.org\/confluence\/display\/KAFKA\/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum\">wird man bald dasselbe \u00fcber Kafka sagen k\u00f6nnen<\/a><\/noindex>), da sie intern RAFT implementiert. Zudem ist NATS Streaming einfacher zu administrieren. Wir schlie\u00dfen nicht aus, dass wir in Zukunft zu dieser Technologie zur\u00fcckkehren. <\/p>\n<p><\/p>\n<p>Und dennoch ist Apache Kafka unser Gewinner bis heute. In unseren Tests hat sie sich als ziemlich schnell erwiesen (\u00fcber eine Million Nachrichten pro Sekunde beim Lesen und Schreiben bei einer Nachrichtengr\u00f6\u00dfe von 1 Kilobyte), ausreichend zuverl\u00e4ssig, gut skalierbar und hat sich in der Produktion bei gro\u00dfen Unternehmen bew\u00e4hrt. Dar\u00fcber hinaus unterst\u00fctzt Kafka mindestens einige gro\u00dfe kommerzielle Unternehmen (wir verwenden beispielsweise die Confluent-Version) und hat ein umfangreiches \u00d6kosystem.<br \/>\n<br clear=\"left\">\n <\/p>\n<p><\/p>\n<h1 id=\"obzor-kafka\">\u00dcberblick \u00fcber Kafka<\/h1>\n<p><\/p>\n<p>Bevor wir beginnen, m\u00f6chte ich gleich ein gro\u00dfartiges Buch empfehlen \u2014 <em>\u201eKafka: The Definitive Guide\u201c<\/em> (es gibt auch eine russische \u00dcbersetzung, aber die Begriffe sind etwas verwirrend). Darin finden sich Informationen, die f\u00fcr ein grundlegendes Verst\u00e4ndnis von Kafka erforderlich sind, und sogar noch etwas mehr. Die Dokumentation von Apache selbst und der Blog von Confluent sind ebenfalls hervorragend geschrieben und leicht verst\u00e4ndlich. <\/p>\n<p><\/p>\n<p>Schauen wir uns also an, wie Kafka aus der Vogelperspektive strukturiert ist. Die grundlegende Topologie von Kafka besteht aus Producer, Consumer, Broker und Zookeeper.<\/p>\n<p><\/p>\n<h3 id=\"broker\">Broker<\/h3>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka und Mikrodienste: Eine \u00dcbersicht\" src=\"\/wp-content\/uploads\/2019\/09\/82f34b5a1aadcdc07eef58eb5414b553.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>F\u00fcr die Speicherung Ihrer Daten ist der Broker verantwortlich. Alle Daten werden bin\u00e4r gespeichert, und der Broker wei\u00df wenig dar\u00fcber, was sie sind und wie ihre Struktur aussieht. <\/p>\n<p><\/p>\n<p>Jeder logische Ereignistyp befindet sich in der Regel in einem separaten Topic. Zum Beispiel kann das Ereignis der Erstellung eines Elements in das Topic item.created gelangen, w\u00e4hrend das Ereignis einer \u00c4nderung im item.changed landet. Topics k\u00f6nnen als Klassifizierer f\u00fcr Ereignisse betrachtet werden. Auf der Ebene des Topics k\u00f6nnen Konfigurationsparameter wie folgende festgelegt werden: <\/p>\n<p><\/p>\n<ul>\n<li>das Volumen der gespeicherten Daten und\/oder deren Alter (retention.bytes, retention.ms); <\/li>\n<li>der Datenredundanzfaktor (replication factor);<\/li>\n<li>die maximale Gr\u00f6\u00dfe einer Nachricht (max.message.bytes);<\/li>\n<li>die minimale Anzahl von \u00fcbereinstimmenden Repliken, bei der Daten in das Topic geschrieben werden k\u00f6nnen (min.insync.replicas);<\/li>\n<li>die M\u00f6glichkeit, einen Failover auf eine unsynchronisierte, nachgelagerte Replik mit potenziellem Datenverlust durchzuf\u00fchren (unclean.leader.election.enable);<\/li>\n<li>und viele weitere (<noindex><a rel=\"nofollow\" href=\"https:\/\/kafka.apache.org\/documentation\/#topicconfigs\">https:\/\/kafka.apache.org\/documentation\/#topicconfigs<\/a><\/noindex>).<\/li>\n<\/ul>\n<p><\/p>\n<p>Jedes Topic wird wiederum in eine oder mehrere Partitionen unterteilt. Tats\u00e4chlich gelangen die Ereignisse in die Partitionen. Wenn es im Cluster mehr als einen Broker gibt, werden die Partitionen gleichm\u00e4\u00dfig auf alle Broker verteilt (so weit wie m\u00f6glich), was eine Skalierung der Schreib- und Lesevorg\u00e4nge in einem Topic auf mehrere Broker gleichzeitig erm\u00f6glicht.<\/p>\n<p><\/p>\n<p>Auf der Festplatte werden die Daten f\u00fcr jede Partition in Form von Segmentdateien gespeichert, die standardm\u00e4\u00dfig eine Gr\u00f6\u00dfe von einem Gigabyte haben (steuert \u00fcber log.segment.bytes). Eine wichtige Eigenschaft ist, dass die Daten aus Partitionen (bei Ausl\u00f6sung der Aufbewahrung) genau in Segmenten gel\u00f6scht werden (man kann nicht ein einzelnes Ereignis aus einer Partition l\u00f6schen, sondern nur ein ganzes Segment, und das zudem nur, wenn es nicht aktiv ist).<\/p>\n<p><\/p>\n<h3 id=\"zookeeper\">Zookeeper<\/h3>\n<p><\/p>\n<p>Zookeeper fungiert als Metadaten-Repository und Koordinator. Er kann genau sagen, ob die Broker aktiv sind (das kann man aus der Sicht des Zookeepers mit dem Befehl <code>ls \/brokers\/ids<\/code>), welcher Broker der Controller ist (<code>get \/controller<\/code>), ob sich die Partitionen synchron mit ihren Replikaten befinden (<code>get \/brokers\/topics\/topic_name\/partitions\/partition_number\/state<\/code>). Ebenso werden zuerst Producer und Consumer zu Zookeeper gehen, um herauszufinden, auf welchem Broker welche Themen und Partitionen gespeichert sind. In F\u00e4llen, in denen f\u00fcr ein Thema ein Replikationsfaktor von mehr als 1 festgelegt ist, wird Zookeeper angeben, welche Partitionen die F\u00fchrer sind (in ihnen erfolgt das Schreiben und auch das Lesen). Im Falle eines Broker-Ausfalls wird die Information \u00fcber neue F\u00fchrungs-Partitionen ebenfalls in Zookeeper gespeichert (seit Version 1.1.0 asynchron, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.confluent.io\/blog\/apache-kafka-supports-200k-partitions-per-cluster\">und das ist wichtig<\/a><\/noindex>).<\/p>\n<p><\/p>\n<p>In \u00e4lteren Versionen von Kafka war Zookeeper auch f\u00fcr die Speicherung von Offsets zust\u00e4ndig, aber heute werden sie in einem speziellen Topic gespeichert. <code>__consumer_offsets<\/code> auf dem Broker (obwohl Sie Zookeeper weiterhin f\u00fcr diese Zwecke verwenden k\u00f6nnen). <\/p>\n<p><\/p>\n<p>Der einfachste Weg, Ihre Daten zu \"verderben\", besteht darin, Informationen durch Zookeeper zu verlieren. In diesem Szenario wird es sehr schwierig sein zu verstehen, was und wo gelesen werden muss. <\/p>\n<p><\/p>\n<h3 id=\"producer\">Producer<\/h3>\n<p><\/p>\n<p>Ein Producer ist in der Regel ein Dienst, der Daten direkt in Apache Kafka schreibt. Der Producer w\u00e4hlt das Topic aus, in dem seine Nachrichten gespeichert werden, und beginnt, Informationen hineinzuschreiben. Beispielsweise k\u00f6nnte ein Producer ein Anzeigendienst sein. In diesem Fall sendet er in entsprechende Topics Ereignisse wie \"Anzeige erstellt\", \"Anzeige aktualisiert\", \"Anzeige gel\u00f6scht\" usw. Jedes Ereignis besteht aus einem Schl\u00fcssel-Wert-Paar.<\/p>\n<p><\/p>\n<p>Standardm\u00e4\u00dfig werden alle Ereignisse rundenweise \u00fcber die Partitionen des Topics verteilt, wenn kein Schl\u00fcssel angegeben ist (was die Reihenfolge verliert), und \u00fcber MurmurHash (schl\u00fcsselbasiert), wenn ein Schl\u00fcssel vorhanden ist (Reihenfolge innerhalb einer Partition).<\/p>\n<p><\/p>\n<p>Es ist wichtig zu betonen, dass Kafka die Reihenfolge der Ereignisse nur innerhalb einer Partition garantiert. In der Praxis stellt dies jedoch oft kein Problem dar. Zum Beispiel k\u00f6nnen alle \u00c4nderungen zu einem bestimmten Angebot zuverl\u00e4ssig in eine Partition eingef\u00fcgt werden, wodurch die Reihenfolge dieser \u00c4nderungen innerhalb des Angebots erhalten bleibt. Zudem kann eine fortlaufende Nummer in einem der Felder des Ereignisses \u00fcbergeben werden.<\/p>\n<p><\/p>\n<h3 id=\"consumer\">Consumer<\/h3>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka und Mikrodienste: Eine \u00dcbersicht\" src=\"\/wp-content\/uploads\/2019\/09\/1f69a53dc19bb6c587883b8754cde29f.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Der Consumer ist verantwortlich f\u00fcr den Empfang von Daten aus Apache Kafka. Wenn wir zum obigen Beispiel zur\u00fcckkehren, k\u00f6nnte der Consumer ein Moderationsdienst sein. Dieser Dienst wird auf das Topic des Angebotsdienstes abonniert und empf\u00e4ngt neue Angebote, um sie auf \u00dcbereinstimmung mit bestimmten festgelegten Richtlinien zu analysieren.<\/p>\n<p><\/p>\n<p>Apache Kafka merkt sich, welche letzten Ereignisse der Consumer erhalten hat (daf\u00fcr wird ein spezielles Topic verwendet, <code>__consumer__offsets<\/code>), wodurch sichergestellt wird, dass der Consumer beim erfolgreichen Lesen nicht dieselbe Nachricht zweimal erh\u00e4lt. Wenn jedoch die Option enable.auto.commit = true verwendet wird und die Verantwortung f\u00fcr die Verfolgung der Position des Consumers im Topic Kafka \u00fcberlassen wird, kann man <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.newrelic.com\/engineering\/kafka-consumer-config-auto-commit-data-loss\/\">Daten verlieren.<\/a><\/noindex>. Im Produktionscode wird die Position des Consumers h\u00e4ufig manuell kontrolliert (der Entwickler steuert den Moment, wann der Commit des gelesenen Ereignisses erfolgen muss).<\/p>\n<p><\/p>\n<p>In F\u00e4llen, in denen ein Consumer nicht ausreicht (z. B. wenn der Strom neuer Ereignisse sehr gro\u00df ist), kann man mehrere Consumer hinzuf\u00fcgen und sie in einer Consumer-Gruppe verbinden. Eine Consumer-Gruppe stellt logisch einen einzelnen Consumer dar, jedoch mit einer Verteilung der Daten zwischen den Gruppenmitgliedern. Dies erm\u00f6glicht es jedem Teilnehmer, seinen Anteil an Nachrichten zu erhalten, wodurch die Lesegeschwindigkeit skaliert wird. <\/p>\n<p><\/p>\n<h1 id=\"rezultaty-testirovaniya\">Testergebnisse<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka und Mikrodienste: Eine \u00dcbersicht\" src=\"\/wp-content\/uploads\/2019\/09\/f7abe4bcf34fdb0d762c8a928bd873ee.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hier werde ich nicht viel erl\u00e4uternden Text schreiben, sondern einfach die erhaltenen Ergebnisse teilen. Die Tests wurden auf 3 physischen Maschinen durchgef\u00fchrt (12 CPU, 384GB RAM, 15k SAS DISK, 10GBit\/s Net), Broker und Zookeeper wurden in LXC bereitgestellt. <\/p>\n<p><\/p>\n<p><strong>Leistungstest<\/strong><\/p>\n<p><\/p>\n<p>Im Verlauf der Tests wurden folgende Ergebnisse erzielt.<\/p>\n<p><\/p>\n<ul>\n<li>Die Schreibgeschwindigkeit von 1KB gro\u00dfen Nachrichten bei 9 Produzenten gleichzeitig \u2013 1.300.000 Ereignisse pro Sekunde.<\/li>\n<li>Die Lesegeschwindigkeit von 1KB gro\u00dfen Nachrichten bei 9 Consumern gleichzeitig \u2013 1.500.000 Ereignisse pro Sekunde.<\/li>\n<\/ul>\n<p><\/p>\n<p><strong>Tests zur Ausfallsicherheit<\/strong><\/p>\n<p><\/p>\n<p>Im Verlauf der Tests wurden folgende Ergebnisse erzielt (3 Broker, 3 Zookeeper).<\/p>\n<p><\/p>\n<ul>\n<li>Ein unerwartetes Aussetzen eines Brokers f\u00fchrt nicht zur Stilllegung oder Nichtverf\u00fcgbarkeit des Clusters. Der Betrieb l\u00e4uft weiterhin planm\u00e4\u00dfig, jedoch wird die Last auf die verbleibenden Broker gr\u00f6\u00dfer.<\/li>\n<li>Ein unerwartetes Aussetzen von zwei Brokern in einem Cluster aus drei Brokern bei min.isr = 2 f\u00fchrt zur Nichtverf\u00fcgbarkeit des Clusters f\u00fcr Schreibvorg\u00e4nge, aber zur Verf\u00fcgbarkeit f\u00fcr Lesevorg\u00e4nge. Wenn min.isr = 1 ist, bleibt das Cluster sowohl f\u00fcr Lese- als auch Schreibvorg\u00e4nge verf\u00fcgbar. Dennoch widerspricht dieser Modus den Anforderungen an hohe Datensicherheit.<\/li>\n<li>Ein unerwartetes Aussetzen eines Zookeeper-Servers f\u00fchrt nicht zur Stilllegung oder Nichtverf\u00fcgbarkeit des Clusters. Der Betrieb l\u00e4uft weiterhin planm\u00e4\u00dfig.<\/li>\n<li>Ein unerwartetes Aussetzen von zwei Zookeeper-Servern f\u00fchrt zur Nichtverf\u00fcgbarkeit des Clusters, bis mindestens einer der Zookeeper-Server wieder verf\u00fcgbar ist. Diese Aussage trifft f\u00fcr einen Zookeeper-Cluster aus 3 Servern zu. Infolge von Untersuchungen wurde beschlossen, den Zookeeper-Cluster auf 5 Server zu erweitern, um die Fehlertoleranz zu erh\u00f6hen. <br clear=\"left\">\n <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"kafka-as-a-service\">Kafka als Dienst<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka und Mikrodienste: Eine \u00dcbersicht\" src=\"\/wp-content\/uploads\/2019\/09\/19b2356131203cefbadfd90a25ae9674.png\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p><\/p>\n<p>Wir haben festgestellt, dass Kafka eine hervorragende Technologie ist, die uns erm\u00f6glicht, die gestellte Aufgabe (die Implementierung eines Messaging-Brokers) zu l\u00f6sen. Dennoch haben wir beschlossen, den direkten Zugriff auf Kafka f\u00fcr die Services zu verbieten und es mit einem Data-Bus zu \u00fcberlagern. Warum haben wir das getan? Tats\u00e4chlich gibt es daf\u00fcr mehrere Gr\u00fcnde.<\/p>\n<p><\/p>\n<ul>\n<li>\n<p>Der Data-Bus \u00fcbernimmt alle Aufgaben im Zusammenhang mit der Integration von Kafka (Implementierung und Konfiguration von Consumer- und Producer-Instanzen, Monitoring, Alarming, Logging, Skalierung usw.). Dadurch gestaltet sich die Integration mit dem Messaging-Broker besonders einfach. <\/p>\n<p>\n<\/li>\n<li>\n<p>Der Data-Bus erm\u00f6glicht es, sich von einer bestimmten Sprache oder Bibliothek f\u00fcr die Arbeit mit Kafka zu abstrahieren. <\/p>\n<p>\n<\/li>\n<li>\n<p>Der Data-Bus erlaubt es anderen Services, sich von der Speicherschicht zu abstrahieren. k\u00f6nnten wir irgendwann Kafka durch Pulsar ersetzen, und niemand w\u00fcrde es bemerken (alle Services kennen nur die API des Data-Bus).<\/p>\n<p>\n<\/li>\n<li>\n<p>Der Data-Bus \u00fcbernimmt die Validierung von Ereignisschemas.<\/p>\n<p>\n<\/li>\n<li>\n<p>Die Authentifizierung wird \u00fcber den Data-Bus umgesetzt.<\/p>\n<p>\n<\/li>\n<li>\n<p>Mit dem Data-Bus k\u00f6nnen wir die Versionen von Kafka ohne Downtime und unbemerkt aktualisieren und zentralisierte Konfigurationen von Producer- und Consumer-Instanzen sowie Brokern verwalten.<\/p>\n<p>\n<\/li>\n<li>\n<p>Der Data-Bus erm\u00f6glicht es, notwendige Funktionen hinzuzuf\u00fcgen, die in Kafka nicht vorhanden sind (wie z. B. Audit von Topics, \u00dcberwachung von Anomalien im Cluster, Erstellung von DLQ usw.).<\/p>\n<p>\n<\/li>\n<li>\n<p>Der Data-Bus erm\u00f6glicht ein zentrales Failover f\u00fcr alle Dienste.<\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Aktuell reicht es aus, eine kleine Bibliothek in den Code Ihres Dienstes einzuf\u00fcgen, um mit dem Senden von Ereignissen an den Nachrichtenbroker zu beginnen. Das ist alles. Sie haben die M\u00f6glichkeit, zu schreiben, zu lesen und zu skalieren \u2013 und das mit nur einer Zeile Code. Die gesamte Implementierung bleibt Ihnen verborgen, nur einige Parameter wie die Batch-Gr\u00f6\u00dfe sind sichtbar. Im Hintergrund startet der Data-Bus in Kubernetes die erforderliche Anzahl an Producer- und Consumer-Instanzen und versorgt diese mit der notwendigen Konfiguration, aber all das geschieht transparent f\u00fcr Ihren Dienst. <\/p>\n<p><\/p>\n<p>Nat\u00fcrlich gibt es keine silberne Kugel, und dieser Ansatz hat seine eigenen Einschr\u00e4nkungen.<\/p>\n<p><\/p>\n<ul>\n<li>Den Data-Bus m\u00fcssen Sie eigenst\u00e4ndig unterst\u00fctzen, im Gegensatz zu externen Bibliotheken.<\/li>\n<li>Der Data-Bus erh\u00f6ht die Anzahl der Interaktionen zwischen den Diensten und dem Nachrichtenbroker, was im Vergleich zu reiner Kafka zu einer geringeren Leistung f\u00fchrt.<\/li>\n<li>Nicht alles l\u00e4sst sich so einfach vor Services verstecken, und wir m\u00f6chten die Funktionalit\u00e4t von KSQL oder Kafka Streams nicht in unserem Datenbus duplizieren. Daher m\u00fcssen wir manchmal zulassen, dass Services direkt zugreifen. <\/li>\n<\/ul>\n<p><\/p>\n<p>In unserem Fall \u00fcberwogen die Vorteile die Nachteile, und die Entscheidung, den Nachrichtenbroker als separaten Service zu betreiben, hat sich bew\u00e4hrt. In einem Jahr Betrieb hatten wir keine ernsthaften Ausf\u00e4lle oder Probleme.<\/p>\n<p><\/p>\n<p>P.S. Vielen Dank an meine Freundin, Ekaterina Obalaya, f\u00fcr die gro\u00dfartigen Bilder zu diesem Artikel. Wenn sie Ihnen gefallen haben, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.instagram.com\/o.k_o.k_\/\">hier<\/a><\/noindex> werden Sie noch mehr Illustrationen finden.<\/p>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/465315\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043f\u043e\u0447\u0435\u043c\u0443 \u043c\u044b \u0432 \u0410\u0432\u0438\u0442\u043e \u0434\u0435\u0432\u044f\u0442\u044c \u043c\u0435\u0441\u044f\u0446\u0435\u0432 \u043d\u0430\u0437\u0430\u0434 \u0432\u044b\u0431\u0440\u0430\u043b\u0438 Kafka, \u0438 \u0447\u0442\u043e \u043e\u043d\u0430 \u0438\u0437 \u0441\u0435\u0431\u044f \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442. \u041f\u043e\u0434\u0435\u043b\u044e\u0441\u044c \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u043a\u0435\u0439\u0441\u043e\u0432 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f \u2014 \u0431\u0440\u043e\u043a\u0435\u0440 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418 \u043d\u0430\u043f\u043e\u0441\u043b\u0435\u0434\u043e\u043a \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a\u0438\u0435 \u043f\u043b\u044e\u0441\u044b \u043c\u044b \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u0438 \u043e\u0442 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u043f\u043e\u0434\u0445\u043e\u0434\u0430 Kafka as a Service. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0414\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0435\u043a\u0441\u0442\u0430. \u041d\u0435\u043a\u043e\u0442\u043e\u0440\u043e\u0435 \u0432\u0440\u0435\u043c\u044f \u043d\u0430\u0437\u0430\u0434 \u043c\u044b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28406,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37849","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043f\u043e\u0447\u0435\u043c\u0443 \u043c\u044b \u0432 \u0410\u0432\u0438\u0442\u043e \u0434\u0435\u0432\u044f\u0442\u044c \u043c\u0435\u0441\u044f\u0446\u0435\u0432 \u043d\u0430\u0437\u0430\u0434 \u0432\u044b\u0431\u0440\u0430\u043b\u0438 Kafka, \u0438 \u0447\u0442\u043e \u043e\u043d\u0430 \u0438\u0437 \u0441\u0435\u0431\u044f \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442. \u041f\u043e\u0434\u0435\u043b\u044e\u0441\u044c \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u043a\u0435\u0439\u0441\u043e\u0432 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f \u2014 \u0431\u0440\u043e\u043a\u0435\u0440 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418 \u043d\u0430\u043f\u043e\u0441\u043b\u0435\u0434\u043e\u043a \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a\u0438\u0435 \u043f\u043b\u044e\u0441\u044b \u043c\u044b \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u0438 \u043e\u0442 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u043f\u043e\u0434\u0445\u043e\u0434\u0430 Kafka as a Service. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0414\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0435\u043a\u0441\u0442\u0430. \u041d\u0435\u043a\u043e\u0442\u043e\u0440\u043e\u0435 \u0432\u0440\u0435\u043c\u044f \u043d\u0430\u0437\u0430\u0434 \u043c\u044b\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Kafka \u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u044b: \u043e\u0431\u0437\u043e\u0440 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043f\u043e\u0447\u0435\u043c\u0443 \u043c\u044b \u0432 \u0410\u0432\u0438\u0442\u043e \u0434\u0435\u0432\u044f\u0442\u044c \u043c\u0435\u0441\u044f\u0446\u0435\u0432 \u043d\u0430\u0437\u0430\u0434 \u0432\u044b\u0431\u0440\u0430\u043b\u0438 Kafka, \u0438 \u0447\u0442\u043e \u043e\u043d\u0430 \u0438\u0437 \u0441\u0435\u0431\u044f \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442. \u041f\u043e\u0434\u0435\u043b\u044e\u0441\u044c \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u043a\u0435\u0439\u0441\u043e\u0432 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f \u2014 \u0431\u0440\u043e\u043a\u0435\u0440 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418 \u043d\u0430\u043f\u043e\u0441\u043b\u0435\u0434\u043e\u043a \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a\u0438\u0435 \u043f\u043b\u044e\u0441\u044b \u043c\u044b \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u0438 \u043e\u0442 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u043f\u043e\u0434\u0445\u043e\u0434\u0430 Kafka as a Service. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0414\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0435\u043a\u0441\u0442\u0430. \u041d\u0435\u043a\u043e\u0442\u043e\u0440\u043e\u0435 \u0432\u0440\u0435\u043c\u044f \u043d\u0430\u0437\u0430\u0434 \u043c\u044b\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:20:09+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:20:09+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Kafka und Mikrodienste: \u00dcbersicht | ProHoster","description":"Hallo zusammen. In diesem Artikel erkl\u00e4re ich, warum wir bei Avito vor neun Monaten Kafka gew\u00e4hlt haben und was es ist. Ich teile einen unserer Anwendungsf\u00e4lle \u2013 den Nachrichtenbroker. Und zum Schluss sprechen wir dar\u00fcber, welche Vorteile wir durch den Einsatz des Ansatzes Kafka als Service erhalten haben. Problem Zun\u00e4chst ein wenig Kontext. Vor einiger Zeit haben wir","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Kafka \u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u044b: \u043e\u0431\u0437\u043e\u0440 | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043f\u043e\u0447\u0435\u043c\u0443 \u043c\u044b \u0432 \u0410\u0432\u0438\u0442\u043e \u0434\u0435\u0432\u044f\u0442\u044c \u043c\u0435\u0441\u044f\u0446\u0435\u0432 \u043d\u0430\u0437\u0430\u0434 \u0432\u044b\u0431\u0440\u0430\u043b\u0438 Kafka, \u0438 \u0447\u0442\u043e \u043e\u043d\u0430 \u0438\u0437 \u0441\u0435\u0431\u044f \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442. \u041f\u043e\u0434\u0435\u043b\u044e\u0441\u044c \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u043a\u0435\u0439\u0441\u043e\u0432 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f \u2014 \u0431\u0440\u043e\u043a\u0435\u0440 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418 \u043d\u0430\u043f\u043e\u0441\u043b\u0435\u0434\u043e\u043a \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a\u0438\u0435 \u043f\u043b\u044e\u0441\u044b \u043c\u044b \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u0438 \u043e\u0442 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u043f\u043e\u0434\u0445\u043e\u0434\u0430 Kafka as a Service. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0414\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0435\u043a\u0441\u0442\u0430. \u041d\u0435\u043a\u043e\u0442\u043e\u0440\u043e\u0435 \u0432\u0440\u0435\u043c\u044f \u043d\u0430\u0437\u0430\u0434 \u043c\u044b","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:20:09+00:00","article:modified_time":"2019-10-31T19:20:09+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37849","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 19:31:03","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:19:23","updated":"2026-01-23 19:31:03"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/37849","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=37849"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/37849\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/28406"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=37849"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=37849"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=37849"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}