{"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\/no\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","title":{"rendered":"Kafka og mikrotjenester: oversikt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Kafka og mikrotjenester: oversikt\" src=\"\/wp-content\/uploads\/2019\/09\/ab0534ad5d28b3c3aa03e4e0b2d3101b.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hei alle sammen. I denne artikkelen vil jeg forklare hvorfor vi hos Avito for ni m\u00e5neder siden valgte Kafka, og hva det er. Jeg vil dele en av bruksomr\u00e5dene \u2013 meldingsmegler. Til slutt vil vi diskutere hvilke fordeler vi har f\u00e5tt fra \u00e5 bruke tiln\u00e6rmingen Kafka as a Service.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1 id=\"problema\">Problemet<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka og mikrotjenester: oversikt\" src=\"\/wp-content\/uploads\/2019\/09\/dfa5e231847cee67259da17867a11812.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>F\u00f8rst litt kontekst. For en tid siden begynte vi \u00e5 bevege oss bort fra monolittisk arkitektur, og n\u00e5 har Avito flere hundre forskjellige tjenester. De har sine egne lagringsl\u00f8sninger, sin teknologistack og er ansvarlige for sin del av forretningslogikken. <\/p>\n<p><\/p>\n<p>Et av problemene med et stort antall tjenester er kommunikasjonen. Tjeneste A vil ofte vite informasjonen som tjeneste B har. I dette tilfellet kontakter tjeneste A tjeneste B via et synkront API. Tjeneste C \u00f8nsker \u00e5 vite hva som skjer med tjenester D og E, og de er igjen interesserte i tjenester A og B. N\u00e5r det blir mange \u00abnysgjerrige\u00bb tjenester, blir forbindelsene mellom dem til en komplisert sammenfiltring.<\/p>\n<p><\/p>\n<p>I tillegg kan tjeneste A n\u00e5r som helst bli utilgjengelig. Hva skal tjeneste B og alle andre avhengige tjenester gj\u00f8re i s\u00e5 fall? Og hvis en forretningsoperasjon krever at man utf\u00f8rer en kjede av sekvensielle synkrone anrop, \u00f8ker sannsynligheten for at hele operasjonen mislykkes enda mer (og den er desto h\u00f8yere jo lengre denne kjeden er). <\/p>\n<p><\/p>\n<h1 id=\"vybor-tehnologii\">Valg av teknologi<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka og mikrotjenester: oversikt\" src=\"\/wp-content\/uploads\/2019\/09\/3acd7bcf3dded8093bdef6d627eb4071.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Greit, problemene er klare. De kan l\u00f8ses ved \u00e5 lage et sentralisert meldingssystem mellom tjenestene. N\u00e5 trenger hver tjeneste bare \u00e5 vite om dette meldingssystemet. I tillegg b\u00f8r selve systemet v\u00e6re feilresistent og horisontalt skalerbart, samt i tilfelle av brudd lagre foresp\u00f8rslene for senere behandling. <\/p>\n<p><\/p>\n<p>La oss n\u00e5 velge teknologien som skal implementere meldingsleveransen. For dette m\u00e5 vi f\u00f8rst forst\u00e5 hva vi forventer fra den:<\/p>\n<p><\/p>\n<ul>\n<li>meldinger mellom tjenester m\u00e5 ikke g\u00e5 tapt;<\/li>\n<li>meldinger kan dupliseres;<\/li>\n<li>meldinger kan lagres og leses i flere dager (persistent buffer);<\/li>\n<li>tjenester kan abonnere p\u00e5 data de er interessert i;<\/li>\n<li>flere tjenester kan lese de samme dataene;<\/li>\n<li>meldinger kan inneholde detaljert, omfattende payload (event-carried state transfer);<\/li>\n<li>noen ganger er det behov for garantert rekkef\u00f8lge av meldinger.<\/li>\n<\/ul>\n<p><\/p>\n<p>Det var ogs\u00e5 kritisk viktig for oss \u00e5 velge et s\u00e5 skalerbart og p\u00e5litelig system som mulig med h\u00f8y kapasitet (minst 100k meldinger p\u00e5 flere kilobyte per sekund).<\/p>\n<p><\/p>\n<p>P\u00e5 dette stadiet tok vi farvel med RabbitMQ (vanskelig \u00e5 opprettholde stabilitet ved h\u00f8ye rps), PGQ fra SkyTools (ikke rask nok og d\u00e5rlig skalerbar) og NSQ (ikke persisterende). Alle disse teknologiene brukes i selskapet v\u00e5rt, men de passet ikke til oppgaven vi skulle l\u00f8se. <\/p>\n<p><\/p>\n<p>Deretter begynte vi \u00e5 se p\u00e5 nye teknologier for oss \u2014 Apache Kafka, Apache Pulsar og NATS Streaming.<\/p>\n<p><\/p>\n<p>Vi droppet Pulsar f\u00f8rst. Vi mente at Kafka og Pulsar er ganske like l\u00f8sninger. Og selv om Pulsar er testet av store selskaper, er nyere og teoretisk tilbyr lavere latency, bestemte vi oss for \u00e5 beholde Kafka av disse to, som de facto-standard for slike oppgaver. Vi kommer sannsynligvis til \u00e5 g\u00e5 tilbake til Apache Pulsar i fremtiden. <\/p>\n<p><\/p>\n<p>Og vi hadde to kandidater igjen: NATS Streaming og Apache Kafka. Vi har studert begge l\u00f8sninger ganske grundig, og begge passet oppgaven. Men til slutt var vi bekymret for den relative ungdommen til NATS Streaming (og at en av hovedutviklerne, Tyler Treat, bestemte seg for \u00e5 forlate prosjektet og starte sitt eget \u2014 Liftbridge). I tillegg ga ikke Clustering-modusen til NATS Streaming muligheten for sterk horisontal skalerbarhet (muligens er dette ikke lenger et problem etter at partitioning-modusen ble lagt til i 2017).<\/p>\n<p><\/p>\n<p>Likevel er NATS Streaming en imponerende teknologi, skrevet i Go og har st\u00f8tte fra Cloud Native Computing Foundation. I motsetning til Apache Kafka trenger den ikke Zookeeper for \u00e5 fungere (kanskje, <noindex><a rel=\"nofollow\" href=\"https:\/\/cwiki.apache.org\/confluence\/display\/KAFKA\/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum\">snart kan det sies det samme om Kafka<\/a><\/noindex>), siden den innvendig implementerer RAFT. I tillegg er NATS Streaming enklere \u00e5 administrere. Vi utelukker ikke at vi i fremtiden kanskje vil g\u00e5 tilbake til denne teknologien. <\/p>\n<p><\/p>\n<p>Og likevel ble Apache Kafka v\u00e5r vinner i dag. I testene v\u00e5re viste den seg \u00e5 v\u00e6re rask nok (over en million meldinger per sekund ved lesing og skriving med en meldingst\u00f8rrelse p\u00e5 1 kilobyte), tilstrekkelig p\u00e5litelig, godt skalerbar og bevist i produksjon av store selskaper. I tillegg st\u00f8tter Kafka minst flere store kommersielle selskaper (vi bruker for eksempel Confluent-versjonen), samt at Kafka har et utviklet \u00f8kosystem.<br \/>\n<br clear=\"left\">\n <\/p>\n<p><\/p>\n<h1 id=\"obzor-kafka\">Oversikt over Kafka<\/h1>\n<p><\/p>\n<p>F\u00f8r du begynner, vil jeg umiddelbart anbefale en utmerket bok \u2014 <em>\u00abKafka: The Definitive Guide\u00bb<\/em> (finnes ogs\u00e5 i norsk oversettelse, men begrepene kan v\u00e6re litt forvirrende). Den inneholder informasjonen som er n\u00f8dvendig for en grunnleggende forst\u00e5else av Kafka, og til og med litt mer. Selve dokumentasjonen fra Apache og bloggen fra Confluent er ogs\u00e5 godt skrevet og lett \u00e5 lese. <\/p>\n<p><\/p>\n<p>La oss se p\u00e5 hvordan Kafka er strukturert fra et fugleperspektiv. Den grunnleggende topologien til Kafka best\u00e5r av producer, consumer, broker og zookeeper.<\/p>\n<p><\/p>\n<h3 id=\"broker\">Broker<\/h3>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka og mikrotjenester: oversikt\" src=\"\/wp-content\/uploads\/2019\/09\/82f34b5a1aadcdc07eef58eb5414b553.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Brokeren (broker) er ansvarlig for lagringen av dataene dine. All informasjon lagres i bin\u00e6rt format, og brokeren vet lite om hva de representerer og hva som er strukturen deres. <\/p>\n<p><\/p>\n<p>Hver logisk type hendelse befinner seg vanligvis i sin egen separate topic. For eksempel kan en hendelse for opprettelse av et annonseinnlegg havne i topicen item.created, mens en hendelse for endringen av den havner i item.changed. Topics kan betraktes som klassifikatorer av hendelser. P\u00e5 topic-niv\u00e5 kan slike konfigurasjonsparametre settes som: <\/p>\n<p><\/p>\n<ul>\n<li>volumet av lagrede data og\/eller deres alder (retention.bytes, retention.ms); <\/li>\n<li>replikasjonsfaktor (replication factor);<\/li>\n<li>maksimal st\u00f8rrelse p\u00e5 en melding (max.message.bytes);<\/li>\n<li>minimum antall bekreftede kopier, for at data kan skrives til topicen (min.insync.replicas);<\/li>\n<li>muligheten for \u00e5 gjennomf\u00f8re failover til en usynkronisert, forsinket kopi med potensiell dataforlust (unclean.leader.election.enable);<\/li>\n<li>og mange andre (<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>Hver topic deles igjen opp i en eller flere partitioner. Det er i partitionene hendelsene havner til slutt. Hvis det er mer enn \u00e9n broker i klyngen, vil partitionene bli fordelt jevnt over alle brokerne (s\u00e5 langt det er mulig), noe som gj\u00f8r det mulig \u00e5 skalere b\u00e5de skriving og lesing i en topic til flere brokere samtidig.<\/p>\n<p><\/p>\n<p>Dataene for hver partition lagres p\u00e5 disken i form av segmentfiler, som som standard er \u00e9n gigabyte store (kontrollert via log.segment.bytes). En viktig detalj er at fjerning av data fra partitionene (n\u00e5r retention utl\u00f8ses) skjer i segmenter (man kan ikke slette \u00e9n hendelse fra en partition, man kan bare slette ett helt segment, og kun inaktivt).<\/p>\n<p><\/p>\n<h3 id=\"zookeeper\">Zookeeper<\/h3>\n<p><\/p>\n<p>Zookeeper fungerer som lager for metadata og koordinator. Det er det som kan si om brokerne er aktive (man kan se p\u00e5 dette med zookeeper via zookeeper-shell kommandoen <code>ls \/brokers\/ids<\/code>), hvilken av brokerne som er kontroller (<code>get \/controller<\/code>), er partisjonene i synkron tilstand med sine replikater (<code>get \/brokers\/topics\/topic_name\/partitions\/partition_number\/state<\/code>). Det er ogs\u00e5 til zookeeper at produsent og konsument f\u00f8rst g\u00e5r for \u00e5 finne ut hvilken broker som lagrer hvilke emner og partitioner. I tilfeller der emnet har en replikasjonsfaktor st\u00f8rre enn 1, vil zookeeper indikere hvilke partitioner som er ledere (der skriving vil skje og fra dem vil lesing ogs\u00e5 foreg\u00e5). Ved et broker-nedbrudd vil informasjon om nye leder-partitioner bli registrert i zookeeper (siden versjon 1.1.0 asynkront, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.confluent.io\/blog\/apache-kafka-supports-200k-partitions-per-cluster\">og dette er viktig<\/a><\/noindex>).<\/p>\n<p><\/p>\n<p>I eldre versjoner av Kafka var zookeeper ogs\u00e5 ansvarlig for \u00e5 lagre offsets, men n\u00e5 lagres de i et spesialemne <code>__consumer_offsets<\/code> p\u00e5 brokeren (selv om du fortsatt kan bruke zookeeper for disse form\u00e5lene). <\/p>\n<p><\/p>\n<p>Den enkleste m\u00e5ten \u00e5 gj\u00f8re dataene dine om til gresskar p\u00e5 er nettopp \u00e5 miste informasjonen fra zookeeper. I et slikt scenario vil det v\u00e6re sv\u00e6rt vanskelig \u00e5 forst\u00e5 hva og hvorfra man m\u00e5 lese. <\/p>\n<p><\/p>\n<h3 id=\"producer\">Produsent<\/h3>\n<p><\/p>\n<p>Produsent \u2014 er oftest en tjeneste som utf\u00f8rer den direkte skrivingen av data til Apache Kafka. Produsenten velger emnet der temaene skal lagres, og begynner \u00e5 skrive informasjon inn i det. For eksempel kan en annonsetjeneste fungere som produsent. I s\u00e5 fall vil den sende hendelser som \u00abannonse opprettet\u00bb, \u00abannonse oppdatert\u00bb, \u00abannonse slettet\u00bb osv. til de tematiske emnene. Hver hendelse representerer et n\u00f8kkel-verdi-par.<\/p>\n<p><\/p>\n<p>Som standard fordeles alle hendelser jevnt over partitionene i emnet med round-robin, med mindre en n\u00f8kkel er angitt (og mister rekkef\u00f8lge), og ved hjelp av MurmurHash (n\u00f8kkel) hvis en n\u00f8kkel er til stede (rekkef\u00f8lge innen en partition).<\/p>\n<p><\/p>\n<p>Her b\u00f8r det bemerkes at Kafka garanterer rekkef\u00f8lge av hendelser bare innen en partition. Men i virkeligheten er dette ofte ikke et problem. For eksempel kan man garantert legge til alle endringer av den samme annonsen i \u00e9n partition (og dermed opprettholde rekkef\u00f8lgen p\u00e5 disse endringene innenfor annonsen). Det er ogs\u00e5 mulig \u00e5 sende rekkef\u00f8lgenummeret i et av feltene i hendelsen.<\/p>\n<p><\/p>\n<h3 id=\"consumer\">Konsument<\/h3>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka og mikrotjenester: oversikt\" src=\"\/wp-content\/uploads\/2019\/09\/1f69a53dc19bb6c587883b8754cde29f.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Consumeren er ansvarlig for \u00e5 hente data fra Apache Kafka. Hvis vi g\u00e5r tilbake til eksemplet ovenfor, kan consumeren v\u00e6re en modereringstjeneste. Denne tjenesten vil abonnere p\u00e5 emnet til annonsetjenesten, og ved publisering av en ny annonse vil den motta og analysere den for \u00e5 se om den samsvarer med bestemte policyer.<\/p>\n<p><\/p>\n<p>Apache Kafka husker hvilke siste hendelser consumeren har mottatt (for dette brukes kontrolltoppikket <code>__consumer__offsets<\/code>), og dermed garanterer at n\u00e5r en consumer leser vellykket, ikke vil motta den samme meldingen to ganger. Imidlertid, hvis man bruker alternativet enable.auto.commit = true og overlater ansvaret for \u00e5 spore consumerens posisjon i emnet til Kafka, kan man <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.newrelic.com\/engineering\/kafka-consumer-config-auto-commit-data-loss\/\">miste data<\/a><\/noindex>. I produksjonskode kontrolleres som oftest posisjonen til consumeren manuelt (utvikleren styrer tidspunktet for n\u00e5r commit av den leste hendelsen n\u00f8dvendigvis m\u00e5 skje).<\/p>\n<p><\/p>\n<p>I tilfeller hvor \u00e9n consumer ikke er nok (for eksempel n\u00e5r str\u00f8mmen av nye hendelser er veldig stor), kan man legge til flere consumere og knytte dem sammen i en consumergruppe. Consumergruppen representerer logisk akkurat den samme consumeren, men med fordeling av data mellom gruppemedlemmene. Dette gj\u00f8r at hver deltaker kan ta sin andel av meldingene, og dermed skalere lesefarten. <\/p>\n<p><\/p>\n<h1 id=\"rezultaty-testirovaniya\">Testresultater<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka og mikrotjenester: oversikt\" src=\"\/wp-content\/uploads\/2019\/09\/f7abe4bcf34fdb0d762c8a928bd873ee.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Her vil jeg ikke skrive mye forklarende tekst, bare dele de innsamlede resultatene. Testingen ble utf\u00f8rt p\u00e5 3 fysiske maskiner (12 CPU, 384 GB RAM, 15k SAS DISK, 10 GBit\/s nett), og brokerne samt zookeeper ble rullet ut i lxc. <\/p>\n<p><\/p>\n<p><strong>Ytelsestesting<\/strong><\/p>\n<p><\/p>\n<p>Under testingen ble f\u00f8lgende resultater oppn\u00e5dd.<\/p>\n<p><\/p>\n<ul>\n<li>Skrivehastigheten for meldinger p\u00e5 1 KB med 9 produsenter samtidig \u2014 1,300,000 hendelser per sekund.<\/li>\n<li>Lesehastigheten for meldinger p\u00e5 1 KB med 9 consumere samtidig \u2014 1,500,000 hendelser per sekund.<\/li>\n<\/ul>\n<p><\/p>\n<p><strong>Testing av feiltoleranse<\/strong><\/p>\n<p><\/p>\n<p>Under testingen ble f\u00f8lgende resultater oppn\u00e5dd (3 brokere, 3 zookeeper).<\/p>\n<p><\/p>\n<ul>\n<li>En uventet avslutning av en av brokerne f\u00f8rer ikke til stopp eller utilgjengelighet av klyngen. Arbeidet fortsetter som normalt, men de gjenv\u00e6rende brokerne m\u00e5 h\u00e5ndtere en st\u00f8rre belastning.<\/li>\n<li>Uventet opph\u00f8r av to meglere i et kluster med tre meglere og min.isr = 2 f\u00f8rer til at klusteret ikke er tilgjengelig for skriving, men er tilgjengelig for lesing. I tilfelle min.isr = 1, vil klusteret forbli tilgjengelig for b\u00e5de lesing og skriving. Denne tiln\u00e6rmingen strider imidlertid mot kravet til h\u00f8y dataintegritet.<\/li>\n<li>Uventet opph\u00f8r av en av Zookeeper-serverne f\u00f8rer ikke til at klusteret stopper eller blir utilgjengelig. Driften fortsetter som normalt.<\/li>\n<li>Uventet opph\u00f8r av to Zookeeper-servere f\u00f8rer til at klusteret blir utilgjengelig til minst \u00e9n av Zookeeper-serverne blir gjenopprettet. Denne p\u00e5standen er sann for et Zookeeper-kluster med 3 servere. Som et resultat av unders\u00f8kelser har det blitt besluttet \u00e5 \u00f8ke Zookeeper-klusteret til 5 servere for \u00e5 forbedre feilmotstand. <br clear=\"left\">\n <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"kafka-as-a-service\">Kafka som en tjeneste<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka og mikrotjenester: oversikt\" src=\"\/wp-content\/uploads\/2019\/09\/19b2356131203cefbadfd90a25ae9674.png\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p><\/p>\n<p>Vi har bekreftet at Kafka er en utmerket teknologi som gj\u00f8r det mulig \u00e5 l\u00f8se oppgaven vi hadde (implementering av en meldingsmegler). Likevel bestemte vi oss for \u00e5 forby tjenestene \u00e5 kontakte Kafka direkte, og lukket den bak en databus. Hvorfor gjorde vi dette? Det er faktisk flere grunner.<\/p>\n<p><\/p>\n<ul>\n<li>\n<p>Databussen har tatt ansvar for alle oppgavene knyttet til integrering med Kafka (implementering og konfigurasjon av forbrukere og produsenter, overv\u00e5king, varsling, logging, skalerbarhet osv.). Dermed skjer integrasjonen med meldingsmegleren p\u00e5 en s\u00e5 enkel m\u00e5te som mulig. <\/p>\n<p>\n<\/li>\n<li>\n<p>Databussen har gjort det mulig \u00e5 abstrahere fra spesifikke spr\u00e5k eller biblioteker for \u00e5 jobbe med Kafka. <\/p>\n<p>\n<\/li>\n<li>\n<p>Databussen har gjort det mulig for andre tjenester \u00e5 abstrahere fra lagringslaget. Kanskje, p\u00e5 et tidspunkt, vil vi bytte Kafka med Pulsar, og ingen vil merke noe (alle tjenester kjenner bare API-en til databussen).<\/p>\n<p>\n<\/li>\n<li>\n<p>Databussen har p\u00e5tatt seg validering av hendelsesskjemaer.<\/p>\n<p>\n<\/li>\n<li>\n<p>Ved hjelp av databussen er autentisering implementert.<\/p>\n<p>\n<\/li>\n<li>\n<p>Under dekke av databussen kan vi oppdatere versjoner av Kafka uten nedetid, anonymt, sentralt administrere konfigurasjoner av produsenter, forbrukere, meglere osv.<\/p>\n<p>\n<\/li>\n<li>\n<p>Databussen har gjort det mulig \u00e5 legge til n\u00f8dvendige funksjoner som ikke finnes i Kafka (som auditing av emner, overv\u00e5king av anomalier i klusteret, oppretting av DLQ osv.).<\/p>\n<p>\n<\/li>\n<li>\n<p>Databussen gj\u00f8r det mulig \u00e5 implementere failover sentralt for alle tjenester.<\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>For now, to start sending events to the message broker, it's enough to connect a small library to your service's code. That's all. You gain the ability to write, read, and scale with just a line of code. All implementation details are hidden from you; only a few parameters like batch size are exposed. Under the hood, the data-bus service spins up the necessary number of producer and consumer instances in Kubernetes and provides them with the required configuration, but all of this is transparent to your service. <\/p>\n<p><\/p>\n<p>Of course, there is no silver bullet, and this approach has its limitations.<\/p>\n<p><\/p>\n<ul>\n<li>Data-bus needs to be maintained on your own, unlike third-party libraries.<\/li>\n<li>Data-bus increases the number of interactions between services and the message broker, which leads to reduced performance compared to raw Kafka.<\/li>\n<li>Not everything can be so easily hidden from services; duplicating KSQL or Kafka Streams functionality in data-bus is not what we want, so sometimes we have to allow services to access it directly. <\/li>\n<\/ul>\n<p><\/p>\n<p>In our case, the advantages outweighed the disadvantages, and the decision to shield the message broker with a separate service proved to be justified. In a year of operation, we have not encountered any serious outages or issues.<\/p>\n<p><\/p>\n<p>P.S. Thanks to my girlfriend, Ekaterina Obalayeva, for the cool illustrations for this article. If you liked them, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.instagram.com\/o.k_o.k_\/\">here<\/a><\/noindex> there will be even more illustrations.<\/p>\n<p>Kilde: <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.5 - 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\/no\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.5\" \/>\n\t\t<meta property=\"og:locale\" content=\"nn_NO\" \/>\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\/no\/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 and Microservices: Overview | ProHoster","description":"Hei alle sammen.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","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\/no\/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\/no\/wp-json\/wp\/v2\/posts\/37849","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=37849"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/37849\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/28406"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=37849"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=37849"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=37849"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}