{"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\/nl\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","title":{"rendered":"Kafka en microservices: een overzicht","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Kafka en microservices: een overzicht\" src=\"\/wp-content\/uploads\/2019\/09\/ab0534ad5d28b3c3aa03e4e0b2d3101b.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hallo allemaal. In dit artikel vertel ik waarom we bij Avito negen maanden geleden voor Kafka hebben gekozen en wat het precies inhoudt. Ik deel een van de gebruikscases \u2014 een message broker. Tot slot bespreken we de voordelen die we hebben behaald door de aanpak van Kafka als een service toe te passen.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1 id=\"problema\">Probleem<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka en microservices: een overzicht\" src=\"\/wp-content\/uploads\/2019\/09\/dfa5e231847cee67259da17867a11812.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Laten we beginnen met wat context. Een tijd geleden zijn we begonnen met het afstappen van een monolithische architectuur en momenteel zijn er bij Avito al enkele honderden verschillende services. Ze hebben hun eigen opslag, eigen technologie stack en zijn verantwoordelijk voor hun deel van de business logica. <\/p>\n<p><\/p>\n<p>Een van de problemen met een groot aantal services is communicatie. Service A wil vaak informatie hebben die beschikbaar is in service B. In dat geval vraagt service A aan service B via een synchrone API. Service B wil weten wat er gebeurt bij services G en D, en die zijn op hun beurt benieuwd naar services A en B. Wanneer er veel van zulke 'nieuwsgierige' services zijn, worden de verbindingen tussen hen een verwarrende knoop.<\/p>\n<p><\/p>\n<p>Daarnaast kan service A op elk moment onbereikbaar worden. Wat te doen in dat geval voor service B en alle andere services die afhankelijk van hem zijn? En als een reeks opeenvolgende synchrone aanroepen nodig is om een zakelijke operatie uit te voeren, wordt de kans dat de hele operatie mislukt nog groter (en naarmate deze keten langer is, is die kans nog groter). <\/p>\n<p><\/p>\n<h1 id=\"vybor-tehnologii\">Keuze van technologie<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka en microservices: een overzicht\" src=\"\/wp-content\/uploads\/2019\/09\/3acd7bcf3dded8093bdef6d627eb4071.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ok\u00e9, de problemen zijn duidelijk. We kunnen ze oplossen door een gecentraliseerd systeem voor het uitwisselen van berichten tussen de services aan te maken. Nu hoeft elke service alleen maar te weten over dit berichtenuitwisselingssysteem. Bovendien moet het systeem zelf falen-bestendig en horizontaal schaalbaar zijn, en in geval van een storing een buffer van aanvragen opslaan voor latere verwerking. <\/p>\n<p><\/p>\n<p>Laten we nu de technologie kiezen die de levering van berichten zal realiseren. Hiervoor moeten we eerst begrijpen wat we van haar verwachten:<\/p>\n<p><\/p>\n<ul>\n<li>berichten tussen services mogen niet verloren gaan;<\/li>\n<li>berichten mogen gedupliceerd worden;<\/li>\n<li>berichten kunnen opgeslagen en meerdere dagen lang gelezen worden (permanente buffer);<\/li>\n<li>services kunnen zich abonneren op de gegevens die hen interesseren;<\/li>\n<li>meerdere services kunnen dezelfde gegevens lezen;<\/li>\n<li>berichten kunnen een gedetailleerde, omvangrijke payload bevatten (event-carried state transfer);<\/li>\n<li>soms is een garantie van de volgorde van berichten nodig.<\/li>\n<\/ul>\n<p><\/p>\n<p>Het was ook van cruciaal belang voor ons om een systeem te kiezen dat maximaal schaalbaar en betrouwbaar is, met een hoge doorvoersnelheid (minimaal 100k berichten van enkele kilobytes per seconde).<\/p>\n<p><\/p>\n<p>Op dit punt hebben we afscheid genomen van RabbitMQ (moeilijk stabiel te houden bij hoge rps), PGQ van SkyTools (niet snel genoeg en slecht schaalbaar) en NSQ (niet persistent). Al deze technologie\u00ebn worden binnen ons bedrijf gebruikt, maar waren niet geschikt voor de op te lossen taak. <\/p>\n<p><\/p>\n<p>Daarna begonnen we naar nieuwe technologie\u00ebn te kijken \u2014 Apache Kafka, Apache Pulsar en NATS Streaming.<\/p>\n<p><\/p>\n<p>We hebben Pulsar als eerste buitengesloten. We besloten dat Kafka en Pulsar redelijk vergelijkbare oplossingen zijn. En hoewel Pulsar is gevalideerd door grote bedrijven, nieuwer is en theoretisch lagere latency biedt, hebben we ervoor gekozen om Kafka als de de facto standaard voor dergelijke taken te behouden. We zullen waarschijnlijk in de toekomst terugkeren naar Apache Pulsar. <\/p>\n<p><\/p>\n<p>En zo bleven er twee kandidaten over: NATS Streaming en Apache Kafka. We hebben beide oplossingen grondig bestudeerd en beide voldeden aan de vereisten. Uiteindelijk waren we echter terughoudend vanwege de relatief jonge aard van NATS Streaming (en het feit dat een van de belangrijkste ontwikkelaars, Tyler Treat, besloot om het project te verlaten en zijn eigen project \u2014 Liftbridge \u2014 te beginnen). Bovendien bood de clusteringmodus van NATS Streaming geen sterke horizontale schaalbaarheid (mogelijk is dit al geen probleem meer na de toevoeging van partitionering in 2017).<\/p>\n<p><\/p>\n<p>Desondanks is NATS Streaming een geweldige technologie, geschreven in Go en ondersteund door de Cloud Native Computing Foundation. In tegenstelling tot Apache Kafka heeft het geen Zookeeper nodig om te functioneren (mogelijk, <noindex><a rel=\"nofollow\" href=\"https:\/\/cwiki.apache.org\/confluence\/display\/KAFKA\/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum\">kunnen we binnenkort hetzelfde zeggen over Kafka<\/a><\/noindex>), aangezien het intern RAFT implementeert. Bovendien is NATS Streaming eenvoudiger te beheren. We sluiten niet uit dat we in de toekomst nog terugkomen op deze technologie. <\/p>\n<p><\/p>\n<p>Toch is Apache Kafka momenteel onze keuze. Tijdens onze tests toonde het zich als voldoende snel (meer dan een miljoen berichten per seconde tijdens lezen en schrijven met een berichtgrootte van 1 kilobyte), behoorlijk betrouwbaar, goed schaalbaar en bewezen in productie door grote bedrijven. Bovendien ondersteunt Kafka ten minste enkele grote commerci\u00eble bedrijven (wij gebruiken bijvoorbeeld de Confluent-versie), en heeft het ook een uitgebreide ecosysteem.<br \/>\n<br clear=\"left\">\n <\/p>\n<p><\/p>\n<h1 id=\"obzor-kafka\">Overzicht van Kafka<\/h1>\n<p><\/p>\n<p>Voordat we beginnen, raad ik meteen een geweldig boek aan \u2014 <em>\u00abKafka: The Definitive Guide\u00bb<\/em> (er is ook een Engelse vertaling, maar de termen kunnen verwarrend zijn). Hier vind je informatie die nodig is voor een basisbegrip van Kafka en zelfs iets meer. De documentatie van Apache en de blog van Confluent zijn ook uitstekend geschreven en gemakkelijk te lezen. <\/p>\n<p><\/p>\n<p>Laten we eens kijken naar de opbouw van Kafka vanuit vogelperspectief. De basis topologie van Kafka bestaat uit producer, consumer, broker en zookeeper.<\/p>\n<p><\/p>\n<h3 id=\"broker\">Broker<\/h3>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka en microservices: een overzicht\" src=\"\/wp-content\/uploads\/2019\/09\/82f34b5a1aadcdc07eef58eb5414b553.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>De broker is verantwoordelijk voor het opslaan van je gegevens. Alle gegevens worden in binaire vorm opgeslagen, en de broker weet weinig over wat deze gegevens zijn of hoe ze zijn gestructureerd. <\/p>\n<p><\/p>\n<p>Elke logische type gebeurtenis bevindt zich meestal in zijn eigen topic. Bijvoorbeeld, een evenement van het aanmaken van een advertentie kan in het topic item.created terechtkomen, terwijl een wijziging daarvan in item.changed komt. Topics kunnen worden beschouwd als classificators van gebeurtenissen. Op het niveau van een topic kunnen configuratieparameters zoals het volgende worden ingesteld: <\/p>\n<p><\/p>\n<ul>\n<li>de hoeveelheid opgeslagen gegevens en\/of hun leeftijd (retention.bytes, retention.ms); <\/li>\n<li>de datastructuur redundantie (replication factor);<\/li>\n<li>de maximale grootte van \u00e9\u00e9n bericht (max.message.bytes);<\/li>\n<li>het minimale aantal overeenkomende replica's waarop gegevens in het topic kunnen worden geschreven (min.insync.replicas);<\/li>\n<li>de mogelijkheid om failover te maken naar een niet-synchroon achterlopende replica met een potenti\u00eble gegevensverlies (unclean.leader.election.enable);<\/li>\n<li>en nog veel meer (<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>Elke topic wordt op zijn beurt onderverdeeld in een of meer partities. Het zijn deze partities waarin de gebeurtenissen uiteindelijk terechtkomen. Als er meer dan \u00e9\u00e9n broker in het cluster is, worden de partities gelijkmatig over alle brokers verdeeld (zo veel als mogelijk), wat het mogelijk maakt om de hoeveelheid schrijf- en leesbelasting van \u00e9\u00e9n topic over meerdere brokers te schalen.<\/p>\n<p><\/p>\n<p>Op de schijf worden de gegevens voor elke partitie opgeslagen in de vorm van segmentbestanden, die standaard gelijk zijn aan \u00e9\u00e9n gigabyte (dit wordt beheerd via log.segment.bytes). Een belangrijke eigenschap is dat het verwijderen van gegevens uit partities (bij het activeren van retention) gebeurt in segmenten (je kunt geen enkel evenement uit een partitie verwijderen, je kunt alleen een heel segment verwijderen, en dat alleen als het niet actief is).<\/p>\n<p><\/p>\n<h3 id=\"zookeeper\">Zookeeper<\/h3>\n<p><\/p>\n<p>Zookeeper functioneert als opslagplaats voor metadata en als co\u00f6rdinator. Hij kan namelijk aangeven of de brokers levend zijn (dit kan worden bekeken met de zookeeper-shell via het commando <code>ls \/brokers\/ids<\/code>), welke broker de controller is (<code>get \/controller<\/code>), zijn de partities in synchroon met hun replicas (<code>get \/brokers\/topics\/topic_name\/partitions\/partition_number\/state<\/code>). Ook gaan de producer en consumer eerst naar zookeeper om te achterhalen op welke broker welke topics en partities zijn opgeslagen. In gevallen waarin de replication factor voor een topic groter is dan 1, zal zookeeper aangeven welke partities de leiders zijn (waarop schrijfacties plaatsvinden en waarvan gelezen wordt). In het geval van een brokerstoring zullen de nieuwe leider-partities specifiek in zookeeper worden geregistreerd (vanaf versie 1.1.0 asynchroon, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.confluent.io\/blog\/apache-kafka-supports-200k-partitions-per-cluster\">en dit is belangrijk<\/a><\/noindex>).<\/p>\n<p><\/p>\n<p>In oudere versies van Kafka was zookeeper ook verantwoordelijk voor het opslaan van offsets, maar tegenwoordig worden deze bewaard in een speciale topic <code>__consumer_offsets<\/code> op de broker (hoewel je zookeeper nog steeds voor deze doeleinden kunt gebruiken). <\/p>\n<p><\/p>\n<p>De eenvoudigste manier om je gegevens in een pompoen te veranderen, is het verliezen van informatie met zookeeper. In dit scenario zal het heel moeilijk zijn om te begrijpen wat en waarvan je moet lezen. <\/p>\n<p><\/p>\n<h3 id=\"producer\">Producer<\/h3>\n<p><\/p>\n<p>Een Producer is meestal een service die direct gegevens in Apache Kafka schrijft. De Producer kiest de topic waarin zijn specifieke berichten worden opgeslagen en begint informatie erin te schrijven. Bijvoorbeeld, een producer kan een advertentieservice zijn. In dat geval zal deze gebeurtenissen zoals 'advertentie gecre\u00eberd', 'advertentie bijgewerkt', 'advertentie verwijderd', enzovoort in de thematische topics verzenden. Elk evenement is op zijn beurt een sleutel-waarde paar.<\/p>\n<p><\/p>\n<p>Standaard worden alle evenementen round-robin over de partities van de topic verdeeld als er geen sleutel is ingesteld (waardoor de volgorde verloren gaat), en via MurmurHash (sleutel) als er een sleutel aanwezig is (volgorde binnen \u00e9\u00e9n partitie).<\/p>\n<p><\/p>\n<p>Hier moet meteen worden opgemerkt dat Kafka de volgorde van gebeurtenissen alleen binnen \u00e9\u00e9n partitie garandeert. Maar in de praktijk is dit vaak geen probleem. Bijvoorbeeld, je kunt gegarandeerd alle wijzigingen van dezelfde advertentie aan \u00e9\u00e9n partitie toevoegen (waarmee de volgorde van deze wijzigingen binnen de advertentie wordt behouden). Je kunt ook een volgnummer in een van de velden van het evenement doorgeven.<\/p>\n<p><\/p>\n<h3 id=\"consumer\">Consumer<\/h3>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka en microservices: een overzicht\" src=\"\/wp-content\/uploads\/2019\/09\/1f69a53dc19bb6c587883b8754cde29f.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Een consumer is verantwoordelijk voor het ontvangen van gegevens uit Apache Kafka. Terugkomend op het bovenstaande voorbeeld kan de consumer een moderatiedienst zijn. Deze dienst zal zich abonneren op het topic van de advertentiedienst, en wanneer er een nieuwe advertentie verschijnt, zal deze deze ontvangen en analyseren op overeenstemming met bepaalde vastgestelde beleidsregels.<\/p>\n<p><\/p>\n<p>Apache Kafka onthoudt welke laatste gebeurtenissen de consumer heeft ontvangen (hiervoor wordt een interne topic gebruikt <code>__consumer__offsets<\/code>), waardoor wordt gegarandeerd dat wanneer een consumer succesvol leest, deze niet hetzelfde bericht twee keer ontvangt. Echter, als je de optie enable.auto.commit = true gebruikt en de taak van het bijhouden van de positie van de consumer in de topic volledig aan Kafka overdraagt, kan je <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.newrelic.com\/engineering\/kafka-consumer-config-auto-commit-data-loss\/\">gegevens verliezen<\/a><\/noindex>. In productiecode wordt de positie van de consumer meestal handmatig beheerd (de ontwikkelaar beheert het moment waarop een commit van het gelezen evenement noodzakelijk moet plaatsvinden).<\/p>\n<p><\/p>\n<p>In situaties waarin \u00e9\u00e9n enkele consumer niet voldoende is (bijvoorbeeld als de stroom van nieuwe gebeurtenissen zeer groot is), kunnen er meerdere consumers worden toegevoegd die samen in een consumer group zijn verbonden. Een consumer group vertegenwoordigt logisch dezelfde consumer, maar met een verdeling van gegevens tussen de groepsleden. Dit stelt elk van de deelnemers in staat om hun deel van de berichten te ontvangen, waardoor de leessnelheid wordt opgeschaald. <\/p>\n<p><\/p>\n<h1 id=\"rezultaty-testirovaniya\">Testresultaten<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka en microservices: een overzicht\" src=\"\/wp-content\/uploads\/2019\/09\/f7abe4bcf34fdb0d762c8a928bd873ee.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hier zal ik niet veel toelichting geven, ik deel gewoon de verkregen resultaten. De tests werden uitgevoerd op 3 fysieke machines (12 CPU, 384GB RAM, 15k SAS DISK, 10GBit\/s Net), brokers en zookeeper werden uitgerold in lxc. <\/p>\n<p><\/p>\n<p><strong>Prestatietests<\/strong><\/p>\n<p><\/p>\n<p>Tijdens de tests zijn de volgende resultaten behaald.<\/p>\n<p><\/p>\n<ul>\n<li>De schrijfsnelheid van berichten van 1KB met 9 producers tegelijkertijd \u2013 1300000 berichten per seconde.<\/li>\n<li>De leessnelheid van berichten van 1KB met 9 consumers tegelijkertijd \u2013 1500000 berichten per seconde.<\/li>\n<\/ul>\n<p><\/p>\n<p><strong>Failover-tests<\/strong><\/p>\n<p><\/p>\n<p>Tijdens de tests zijn de volgende resultaten behaald (3 brokers, 3 zookeeper).<\/p>\n<p><\/p>\n<ul>\n<li>Een onverwachte be\u00ebindiging van een van de brokers leidt niet tot een stopzetting of onbeschikbaarheid van het cluster. Het werk gaat door in normale modus, maar de resterende brokers krijgen een zwaardere belasting.<\/li>\n<li>Een onverwachte be\u00ebindiging van twee brokers in het geval van een cluster van drie brokers met min.isr = 2 leidt tot onbeschikbaarheid van het cluster voor schrijven, maar beschikbaarheid voor lezen. In het geval dat min.isr = 1, blijft het cluster beschikbaar voor zowel lezen als schrijven. Dit modus is echter in strijd met de eisen voor hoge databeveiliging.<\/li>\n<li>Een onverwachte be\u00ebindiging van een van de Zookeeper-servers leidt niet tot het stoppen of onbeschikbaar zijn van het cluster. De werking gaat door in normale modus.<\/li>\n<li>Een onverwachte be\u00ebindiging van twee Zookeeper-servers leidt tot onbeschikbaarheid van het cluster totdat minstens \u00e9\u00e9n van de Zookeeper-servers weer operationeel is. Deze bewering is waar voor een Zookeeper-cluster van 3 servers. Als gevolg van onderzoeken is besloten het Zookeeper-cluster uit te breiden naar 5 servers voor verhoogde fouttolerantie. <br clear=\"left\">\n <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"kafka-as-a-service\">Kafka als een service<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka en microservices: een overzicht\" src=\"\/wp-content\/uploads\/2019\/09\/19b2356131203cefbadfd90a25ae9674.png\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p><\/p>\n<p>We hebben vastgesteld dat Kafka een uitstekende technologie is die ons in staat stelt de opgelegde taak (de implementatie van een berichtenbroker) op te lossen. Toch hebben we besloten om services te verbieden direct toegang te krijgen tot Kafka en hebben dit bovenop afgesloten met een service data-bus. Waarom hebben we dit gedaan? Er zijn eigenlijk meerdere redenen.<\/p>\n<p><\/p>\n<ul>\n<li>\n<p>Data-bus heeft alle taken met betrekking tot integratie met Kafka overgenomen (de implementatie en configuratie van consumenten en producenten, monitoring, alarmering, logging, schaling, etc.). Hierdoor gebeurt de integratie met de berichtenbroker zo eenvoudig mogelijk. <\/p>\n<p>\n<\/li>\n<li>\n<p>Data-bus heeft de mogelijkheid geboden om zich te abstraheren van een specifieke taal of bibliotheek voor het werken met Kafka. <\/p>\n<p>\n<\/li>\n<li>\n<p>Data-bus heeft andere services in staat gesteld om zich te abstraheren van de opslaglaag. Misschien vervangen we op een gegeven moment Kafka door Pulsar, en niemand zal het opmerken (alle services kennen alleen de API van de data-bus).<\/p>\n<p>\n<\/li>\n<li>\n<p>Data-bus heeft de validatie van gebeurtenisschema's op zich genomen.<\/p>\n<p>\n<\/li>\n<li>\n<p>Met behulp van de data-bus is authenticatie ge\u00efmplementeerd.<\/p>\n<p>\n<\/li>\n<li>\n<p>Onder de dekking van de data-bus kunnen we Kafka-versies zonder downtime en onopgemerkt bijwerken, en centraal de configuraties van producenten, consumenten, brokers, etc. beheren.<\/p>\n<p>\n<\/li>\n<li>\n<p>Data-bus heeft ons in staat gesteld om noodzakelijke functies toe te voegen die niet in Kafka aanwezig zijn (zoals audit van onderwerpen, controle op anomalie\u00ebn in het cluster, het cre\u00ebren van DLQ, etc.).<\/p>\n<p>\n<\/li>\n<li>\n<p>Data-bus maakt het mogelijk om failover centraal voor alle services te implementeren.<\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Op dit moment is het voldoende om een kleine bibliotheek aan de code van je service toe te voegen om te beginnen met het verzenden van gebeurtenissen naar de berichtenbroker. Dat is alles. Je krijgt de mogelijkheid om te schrijven, te lezen en te schalen met \u00e9\u00e9n regel code. Alle implementatie is voor jou verborgen; er steken alleen een paar handvatten voor batchgrootte uit. Onder de motorkap draait de data-bus het juiste aantal producer- en consumer-instanties in Kubernetes en configureert het ze, maar dat alles is transparant voor jouw service. <\/p>\n<p><\/p>\n<p>Natuurlijk is er geen zilveren kogel, en deze aanpak heeft zijn beperkingen.<\/p>\n<p><\/p>\n<ul>\n<li>Data-bus moet door jouw eigen middelen worden ondersteund, in tegenstelling tot externe bibliotheken.<\/li>\n<li>Data-bus verhoogt het aantal interacties tussen services en de berichtenbroker, wat leidt tot een lagere prestaties in vergelijking met kale Kafka.<\/li>\n<li>Niet alles kan zo eenvoudig voor de services verborgen blijven; we willen de functionaliteit van KSQL of Kafka Streams niet dupliceren in data-bus, dus soms moeten we services toestaan om direct te communiceren. <\/li>\n<\/ul>\n<p><\/p>\n<p>In ons geval woog de voordelen op tegen de nadelen, en de beslissing om de berichtenbroker als een aparte service te maskeren was gerechtvaardigd. Gedurende een jaar van gebruik hebben we geen ernstige storingen of problemen gehad.<\/p>\n<p><\/p>\n<p>P.S. Bedankt aan mijn vriendin, Ekaterina Obalayeva, voor de geweldige afbeeldingen bij dit artikel. Als je ze leuk vindt, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.instagram.com\/o.k_o.k_\/\">here<\/a><\/noindex> zullen er nog meer illustraties beschikbaar zijn.<\/p>\n<p>Bron: <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.3 - 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\/nl\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\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\/nl\/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 en microservices: overzicht | ProHoster","description":"Hallo allemaal.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/37849","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=37849"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/37849\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/28406"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=37849"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=37849"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=37849"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}