{"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: \u00dcberblick","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Kafka und Mikrodienste: \u00dcberblick\" 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 werde ich erz\u00e4hlen, warum wir bei Avito vor neun Monaten Kafka gew\u00e4hlt haben und was es genau ist. Ich werde einen der Anwendungsf\u00e4lle vorstellen \u2013 den Nachrichtenbroker. Schlie\u00dflich werden wir dar\u00fcber sprechen, welche Vorteile wir aus dem Einsatz von Kafka als Dienst erhalten haben.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1 id=\"problema\">Problem<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka und Mikrodienste: \u00dcberblick\" 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 begannen wir, von einer monolithischen Architektur abzuweichen, und heute gibt es bei Avito bereits mehrere Hundert verschiedene Dienste. Diese haben ihre eigenen Speicherl\u00f6sungen, ihren eigenen Technologiestack und sind f\u00fcr ihre eigenen Teile der Gesch\u00e4ftslogik verantwortlich. <\/p>\n<p><\/p>\n<p>Ein Problem bei einer gro\u00dfen Anzahl von Diensten ist die Kommunikation. Dienst A m\u00f6chte oft Informationen erhalten, die Dienst B hat. In diesem Fall kontaktiert Dienst A Dienst B \u00fcber eine synchrone API. Dienst V m\u00f6chte wissen, was bei den Diensten G und D passiert, und diese wiederum interessieren sich f\u00fcr die Dienste A und B. Wenn es viele solcher \"neugierigen\" Dienste gibt, werden die Verbindungen zwischen ihnen zu einem verworrenen Kn\u00e4uel.<\/p>\n<p><\/p>\n<p>Dabei kann Dienst A jederzeit nicht verf\u00fcgbar werden. Was sollen in diesem Fall Dienst B und alle anderen von ihm abh\u00e4ngigen Dienste tun? Und wenn f\u00fcr die Durchf\u00fchrung einer Gesch\u00e4ftsoperation eine Kette von aufeinanderfolgenden synchronen Aufrufen erforderlich ist, erh\u00f6ht sich die Wahrscheinlichkeit des Ausfalls der gesamten Operation (je l\u00e4nger diese Kette, desto h\u00f6her das Risiko). <\/p>\n<p><\/p>\n<h1 id=\"vybor-tehnologii\">Technologieauswahl<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka und Mikrodienste: \u00dcberblick\" 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. Man kann sie beheben, indem man ein zentrales Nachrichtenaustauschsystem zwischen den Diensten einrichtet. Nun m\u00fcssen die einzelnen Dienste nur \u00fcber dieses Nachrichtenaustauschsystem Bescheid wissen. Dar\u00fcber hinaus muss das System hochverf\u00fcgbar und horizontal skalierbar sein und im Falle eines Ausfalls einen Puffer f\u00fcr eingehende Anfragen zur sp\u00e4teren Verarbeitung speichern. <\/p>\n<p><\/p>\n<p>Lass uns jetzt die Technologie ausw\u00e4hlen, auf der die Nachrichtenzustellung umgesetzt wird. Daf\u00fcr sollten wir zun\u00e4chst verstehen, 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 dupliziert werden;<\/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 f\u00fcr sie interessante Daten anmelden;<\/li>\n<li>Mehrere Dienste k\u00f6nnen dieselben Daten lesen;<\/li>\n<li>Nachrichten k\u00f6nnen detaillierte, umfangreiche payloads enthalten (event-carried state transfer);<\/li>\n<li>Manchmal ist eine Garantie f\u00fcr die Reihenfolge der Nachrichten erforderlich.<\/li>\n<\/ul>\n<p><\/p>\n<p>Es war uns auch von entscheidender Bedeutung, ein m\u00f6glichst skalierbares und zuverl\u00e4ssiges System mit hoher Durchsatzrate (mindestens 100.000 Nachrichten mit mehreren Kilobyte pro Sekunde) auszuw\u00e4hlen.<\/p>\n<p><\/p>\n<p>In dieser Phase trennten wir uns von RabbitMQ (schwer stabil bei hohen rps), PGQ von SkyTools (nicht schnell genug und schlecht skalierbar) und NSQ (nicht persistent). All diese Technologien werden in unserem Unternehmen genutzt, aber sie waren f\u00fcr die zu l\u00f6sende Aufgabe nicht geeignet. <\/p>\n<p><\/p>\n<p>Dann begannen wir, neue Technologien zu betrachten \u2014 Apache Kafka, Apache Pulsar und NATS Streaming.<\/p>\n<p><\/p>\n<p>Zuerst schlossen wir Pulsar aus. Wir entschlossen uns, dass Kafka und Pulsar sehr \u00e4hnliche L\u00f6sungen sind. Und obwohl Pulsar von gro\u00dfen Unternehmen erprobt ist, neuer ist und theoretisch eine niedrigere Latenz bietet, beschlossen wir, von diesen beiden Kafka als de facto Standard f\u00fcr solche Aufgaben beizubehalten. 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 ziemlich ausf\u00fchrlich untersucht, und beide erf\u00fcllten die Anforderungen. Aber letztendlich hatten wir Bedenken wegen der relativen Neuheit von NATS Streaming (und dass einer der Hauptentwickler, Tyler Treat, das Projekt verlassen und sein eigenes \u2014 Liftbridge \u2014 gegr\u00fcndet hat). Zudem bot der Clustering-Modus von NATS Streaming keine starke horizontale Skalierbarkeit (m\u00f6glicherweise ist das nach der Einf\u00fchrung des Partitionierungsmodus im Jahr 2017 bereits kein Problem mehr).<\/p>\n<p><\/p>\n<p>Dennoch ist NATS Streaming eine coole Technologie, die in Go geschrieben wurde und Unterst\u00fctzung von der Cloud Native Computing Foundation hat. Im Gegensatz zu Apache Kafka ben\u00f6tigt sie kein Zookeeper f\u00fcr die Betriebsf\u00fchrung (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 werden. <\/p>\n<p><\/p>\n<p>Dennoch wurde unser Gewinner heute Apache Kafka. In unseren Tests zeigte es sich als ziemlich schnell (\u00fcber eine Million Nachrichten pro Sekunde beim Lesen und Schreiben bei einer Nachrichtenl\u00e4nge von 1 Kilobyte), zuverl\u00e4ssig, gut skalierbar und durch die Praxis in gro\u00dfen Unternehmen erprobt. Dar\u00fcber hinaus unterst\u00fctzen mehrere gro\u00dfe kommerzielle Unternehmen Kafka (wir nutzen zum Beispiel die Confluent-Version), und Kafka hat ein gut ausgebautes \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, kann ich sofort ein gro\u00dfartiges Buch empfehlen \u2014 <em>\u00abKafka: The Definitive Guide\u00bb<\/em> (es gibt auch eine russische \u00dcbersetzung, aber die Begriffe sind etwas verwirrend). Darin finden Sie Informationen, die f\u00fcr das grundlegende Verst\u00e4ndnis von Kafka und sogar etwas mehr erforderlich sind. Die Dokumentation von Apache und der Blog von Confluent sind ebenfalls hervorragend geschrieben und leicht zu lesen. <\/p>\n<p><\/p>\n<p>Schauen wir uns also an, wie Kafka aus der Vogelperspektive aussieht. 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: \u00dcberblick\" src=\"\/wp-content\/uploads\/2019\/09\/82f34b5a1aadcdc07eef58eb5414b553.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Der Broker ist verantwortlich f\u00fcr die Speicherung Ihrer Daten. Alle Daten werden in bin\u00e4rer Form gespeichert, und der Broker wei\u00df kaum, was sie sind und wie ihre Struktur aussieht. <\/p>\n<p><\/p>\n<p>Jeder logische Ereignistyp befindet sich normalerweise in seinem eigenen Topic. Zum Beispiel kann ein Ereignis zur Erstellung eines Listings in das Topic item.created und ein Ereignis zur \u00c4nderung davon in item.changed gelangen. Topics k\u00f6nnen als Klassifizierer f\u00fcr Ereignisse betrachtet werden. Auf der Ebene des Topics k\u00f6nnen Konfigurationsparameter wie definiert werden: <\/p>\n<p><\/p>\n<ul>\n<li>die Menge der gespeicherten Daten und\/oder ihr Alter (retention.bytes, retention.ms); <\/li>\n<li>der Replikationsfaktor (replication factor);<\/li>\n<li>die maximale Gr\u00f6\u00dfe einer Nachricht (max.message.bytes);<\/li>\n<li>die minimale Anzahl an \u00fcbereinstimmenden Replikaten, bei der Daten in das Topic geschrieben werden k\u00f6nnen (min.insync.replicas);<\/li>\n<li>die M\u00f6glichkeit, einen Failover auf eine asynchrone, nachfolgende Replik mit potenziellem Datenverlust durchzuf\u00fchren (unclean.leader.election.enable);<\/li>\n<li>und viele andere (<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 seinerseits in eine oder mehrere Partitionen unterteilt. In den Partitionen landen letztendlich die Ereignisse. Wenn im Cluster mehr als ein Broker vorhanden ist, werden die Partitionen gleichm\u00e4\u00dfig auf alle Broker verteilt (so weit wie m\u00f6glich), was es erm\u00f6glicht, die Schreib- und Leselast f\u00fcr ein Topic gleichzeitig auf mehrere Broker zu verteilen.<\/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 gleich einem Gigabyte sind (gesteuert \u00fcber log.segment.bytes). Eine wichtige Eigenschaft ist, dass Daten aus Partitionen (bei Erreichen der Retention) genau in Segmenten gel\u00f6scht werden (man kann kein einzelnes Ereignis aus einer Partition l\u00f6schen, sondern nur ein ganzes Segment, und zwar nur inaktives).<\/p>\n<p><\/p>\n<h3 id=\"zookeeper\">Zookeeper<\/h3>\n<p><\/p>\n<p>Zookeeper fungiert als Speicher f\u00fcr Metadaten und Koordinator. Er kann sagen, ob die Broker noch aktiv sind (man kann dies \u00fcber zookeeper-shell mit dem Befehl <code>ls \/brokers\/ids<\/code>), welcher Broker der Controller ist (<code>get \/controller<\/code>), sind die Partitionen mit ihren Replikaten synchronisiert (<code>get \/brokers\/topics\/topic_name\/partitions\/partition_number\/state<\/code>). Zun\u00e4chst werden sowohl Producer als auch Consumer zu Zookeeper gehen, um herauszufinden, auf welchem Broker welche Themen und Partitionen gespeichert sind. In F\u00e4llen, in denen der Replikationsfaktor f\u00fcr ein Thema gr\u00f6\u00dfer als 1 ist, wird Zookeeper angeben, welche Partitionen die F\u00fchrenden sind (dort werden Schreibvorg\u00e4nge durchgef\u00fchrt und von dort wird auch gelesen). Im Falle eines Broker-Ausfalls werden in Zookeeper die Informationen \u00fcber die neuen F\u00fchrungspartitionen aufgezeichnet (ab 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 verantwortlich, aber jetzt werden sie in einem speziellen Thema <code>__consumer_offsets<\/code> auf dem Broker gespeichert (obwohl Sie weiterhin Zookeeper f\u00fcr diese Zwecke verwenden k\u00f6nnen). <\/p>\n<p><\/p>\n<p>Der einfachste Weg, Ihre Daten in eine Katastrophe zu verwandeln, ist der Verlust von Informationen mit Zookeeper. In einem solchen 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 meist ein Dienst, der direkt Daten in Apache Kafka schreibt. Der Producer w\u00e4hlt das Thema aus, in dem seine thematischen Nachrichten gespeichert werden, und beginnt, Informationen dort zu schreiben. Beispielsweise k\u00f6nnte ein Producer ein Anzeige-Service sein. In diesem Fall w\u00fcrde er Ereignisse in die thematischen Themen senden, wie 'Anzeige erstellt', 'Anzeige aktualisiert', 'Anzeige gel\u00f6scht' usw. Jedes Ereignis stellt dabei ein Schl\u00fcssel-Wert-Paar dar.<\/p>\n<p><\/p>\n<p>Standardm\u00e4\u00dfig werden alle Ereignisse rundenbasiert auf die Partitionen des Themas verteilt, sofern kein Schl\u00fcssel angegeben ist (was die Reihenfolge verliert), und \u00fcber MurmurHash (Schl\u00fcssel), wenn ein Schl\u00fcssel vorhanden ist (Reihenfolge innerhalb einer Partition).<\/p>\n<p><\/p>\n<p>Hier sollte sofort angemerkt werden, dass Kafka die Reihenfolge von Ereignissen nur innerhalb einer Partition garantiert. Aber in der Realit\u00e4t ist das oft kein Problem. Zum Beispiel k\u00f6nnen Sie alle \u00c4nderungen einer einzigen Anzeige garantiert in eine Partition hinzuf\u00fcgen (so die Reihenfolge dieser \u00c4nderungen im Rahmen der Anzeige beibehaltend). Au\u00dferdem kann eine Reihenfolge-ID in eines 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: \u00dcberblick\" 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 das oben genannte Beispiel betrachten, k\u00f6nnte der Consumer ein Moderationsdienst sein. Dieser Dienst wird auf das Topic des Anzeigendienstes abonnieren und bei Erscheinen einer neuen Anzeige deren Inhalt empfangen und auf die Einhaltung bestimmter festgelegter Richtlinien analysieren.<\/p>\n<p><\/p>\n<p>Apache Kafka speichert, welche letzten Ereignisse der Consumer empfangen hat (daf\u00fcr wird ein interner Topic verwendet, <code>__consumer__offsets<\/code>), wodurch sichergestellt wird, dass der Consumer bei erfolgreichem Lesen nicht dieselbe Nachricht zweimal erh\u00e4lt. Wenn jedoch die Option enable.auto.commit = true verwendet wird und die Arbeit zur Verfolgung des Consumer-Offsets im Topic komplett Kafka \u00fcberlassen wird, k\u00f6nnte man <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.newrelic.com\/engineering\/kafka-consumer-config-auto-commit-data-loss\/\">Daten verlieren<\/a><\/noindex>. In Produktionscodes wird normalerweise die Position des Consumers manuell kontrolliert (der Entwickler steuert den Zeitpunkt, zu dem ein Commit der gelesenen Ereignisse zwingend erfolgen muss).<\/p>\n<p><\/p>\n<p>In F\u00e4llen, in denen ein Consumer nicht ausreicht (zum Beispiel wenn der Strom neuer Ereignisse sehr hoch ist), kann man mehrere Consumer hinzuzuf\u00fcgen, indem man sie zu einer Consumer-Gruppe zusammenfasst. Die 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 \u00fcbernehmen, und skaliert so die Lesegeschwindigkeit. <\/p>\n<p><\/p>\n<h1 id=\"rezultaty-testirovaniya\">Testergebnisse<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka und Mikrodienste: \u00dcberblick\" src=\"\/wp-content\/uploads\/2019\/09\/f7abe4bcf34fdb0d762c8a928bd873ee.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ich werde hier nicht viel erkl\u00e4renden Text schreiben, sondern teile einfach die erhaltenen Ergebnisse. Die Tests wurden auf 3 physischen Maschinen (12 CPU, 384 GB RAM, 15k SAS DISK, 10 GBit\/s Net) durchgef\u00fchrt, Broker und Zookeeper wurden in LXC bereitgestellt. <\/p>\n<p><\/p>\n<p><strong>Leistungstest<\/strong><\/p>\n<p><\/p>\n<p>Im Laufe der Tests wurden die folgenden Ergebnisse erzielt.<\/p>\n<p><\/p>\n<ul>\n<li>Die Schreibgeschwindigkeit von Nachrichten mit einer Gr\u00f6\u00dfe von 1 KB gleichzeitig durch 9 Producer betr\u00e4gt 1.300.000 Ereignisse pro Sekunde.<\/li>\n<li>Die Lesegeschwindigkeit von Nachrichten mit einer Gr\u00f6\u00dfe von 1 KB gleichzeitig durch 9 Consumer betr\u00e4gt 1.500.000 Ereignisse pro Sekunde.<\/li>\n<\/ul>\n<p><\/p>\n<p><strong>Test der Ausfallsicherheit<\/strong><\/p>\n<p><\/p>\n<p>Im Laufe der Tests wurden die folgenden Ergebnisse erzielt (3 Broker, 3 Zookeeper).<\/p>\n<p><\/p>\n<ul>\n<li>Der unerwartete Ausfall eines der Broker f\u00fchrt nicht zur Beendigung oder zur Nichterreichbarkeit des Clusters. Der Betrieb wird regul\u00e4r fortgesetzt, jedoch wird die Last auf die verbleibenden Broker verteilt.<\/li>\n<li>Ein unerwartetes Beenden von zwei Brokern in einem Cluster aus drei Brokern mit min.isr = 2 f\u00fchrt zur Schreibunzug\u00e4nglichkeit des Clusters, jedoch bleibt es f\u00fcr das Lesen verf\u00fcgbar. Wenn min.isr = 1 ist, bleibt der Cluster sowohl f\u00fcr das Lesen als auch f\u00fcr das Schreiben verf\u00fcgbar. Dieser Modus widerspricht jedoch dem Anspruch auf hohe Datensicherheit.<\/li>\n<li>Das unerwartete Beenden eines der Zookeeper-Server f\u00fchrt nicht zur Beendigung oder Unzug\u00e4nglichkeit des Clusters. Der Betrieb l\u00e4uft normal weiter.<\/li>\n<li>Das unerwartete Beenden von zwei Zookeeper-Servern f\u00fchrt zur Unzug\u00e4nglichkeit des Clusters, bis einer der Zookeeper-Server wiederhergestellt ist. Diese Aussage gilt f\u00fcr einen Zookeeper-Cluster mit 3 Servern. Infolgedessen wurde nach eingehenden Untersuchungen 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: \u00dcberblick\" src=\"\/wp-content\/uploads\/2019\/09\/19b2356131203cefbadfd90a25ae9674.png\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p><\/p>\n<p>Wir haben uns davon \u00fcberzeugt, dass Kafka eine hervorragende Technologie ist, die unsere Aufgabe (Implementierung eines Nachrichtenspeichers) l\u00f6sen kann. Dennoch haben wir beschlossen, den Diensten den direkten Zugang zu Kafka zu verwehren und es \u00fcber einen data-bus zu schlie\u00dfen. Warum haben wir das gemacht? Tats\u00e4chlich gibt es mehrere Gr\u00fcnde.<\/p>\n<p><\/p>\n<ul>\n<li>\n<p>Der data-bus hat alle Aufgaben in Bezug auf die Integration mit Kafka \u00fcbernommen (Implementierung und Konfiguration von Consumer und Producer, \u00dcberwachung, Alarmierung, Protokollierung, Skalierung usw.). Dadurch wird die Integration mit dem Nachrichtenspeicher so einfach wie m\u00f6glich. <\/p>\n<p>\n<\/li>\n<li>\n<p>Der data-bus erm\u00f6glicht es, sich von einer bestimmten Programmiersprache oder Bibliothek f\u00fcr die Arbeit mit Kafka zu abstrahieren. <\/p>\n<p>\n<\/li>\n<li>\n<p>Der data-bus erm\u00f6glichte es anderen Diensten, sich von der Speicherebene zu abstrahieren. Vielleicht wechseln wir irgendwann von Kafka zu Pulsar, und dabei wird niemand etwas bemerken (alle Dienste kennen nur die API des data-bus).<\/p>\n<p>\n<\/li>\n<li>\n<p>Der data-bus hat die Validierung von Ereignisschemata \u00fcbernommen.<\/p>\n<p>\n<\/li>\n<li>\n<p>Mit Hilfe des data-bus wurde die Authentifizierung implementiert.<\/p>\n<p>\n<\/li>\n<li>\n<p>Unter dem Deckmantel des data-bus k\u00f6nnen wir die Versionen von Kafka ohne Ausfallzeiten und unauff\u00e4llig aktualisieren und zentral die Konfigurationen von Produzenten, Konsumenten, Brokern usw. verwalten.<\/p>\n<p>\n<\/li>\n<li>\n<p>Der data-bus erm\u00f6glichte es, notwendige Funktionen hinzuzuf\u00fcgen, die in Kafka nicht vorhanden sind (wie das Audit von Themen, die \u00dcberwachung von Anomalien im Cluster, die Erstellung einer DLQ usw.).<\/p>\n<p>\n<\/li>\n<li>\n<p>Der data-bus erm\u00f6glicht eine zentralisierte Failover-Implementierung f\u00fcr alle Dienste.<\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Derzeit reicht es aus, eine kleine Bibliothek in den Code Ihres Dienstes einzuf\u00fcgen, um den Versand von Ereignissen an den Nachrichtenbroker zu starten. Das war's. Sie erhalten die M\u00f6glichkeit, zu schreiben, zu lesen und mit nur einer Codezeile zu skalieren. Die gesamte Implementierung bleibt von Ihnen verborgen, nach au\u00dfen ragen nur ein paar Handgriffe wie die Batch-Gr\u00f6\u00dfe heraus. Im Hintergrund startet der Dienst data-bus die erforderliche Anzahl von Instanzen von Producer- und Consumer-Diensten in Kubernetes und liefert die ben\u00f6tigte 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>Data-bus muss selbst gesteuert werden, im Gegensatz zu Drittanbieter-Bibliotheken.<\/li>\n<li>Data-bus erh\u00f6ht die Anzahl der Interaktionen zwischen den Diensten und dem Nachrichtenbroker, was zu einem R\u00fcckgang der Leistung im Vergleich zu reinem Kafka f\u00fchrt.<\/li>\n<li>Nicht alles l\u00e4sst sich so einfach vor den Diensten verbergen; wir m\u00f6chten die Funktionalit\u00e4t von KSQL oder Kafka Streams nicht im data-bus duplizieren, daher m\u00fcssen wir manchmal erlauben, dass Dienste direkt zugreifen. <\/li>\n<\/ul>\n<p><\/p>\n<p>In unserem Fall \u00fcberwiegen die Vorteile die Nachteile, und die Entscheidung, den Nachrichtenbroker durch einen separaten Dienst zu sch\u00fctzen, hat sich bew\u00e4hrt. Im Jahr unseres Betriebs gab es keine schwerwiegenden Ausf\u00e4lle oder Probleme.<\/p>\n<p><\/p>\n<p>P.S. Danke an meine Freundin, Ekaterina Obalayeva, 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 noch mehr Illustrationen zu finden sein.<\/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 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442.\" \/>\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) 5.0.1.1\" \/>\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.\" \/>\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: \u00dcberblick | ProHoster","description":"Hallo zusammen.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}