{"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\/da\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","title":{"rendered":"Kafka og mikroservices: en oversigt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Kafka og mikroservices: en oversigt\" src=\"\/wp-content\/uploads\/2019\/09\/ab0534ad5d28b3c3aa03e4e0b2d3101b.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hej alle sammen. I denne artikel vil jeg fort\u00e6lle, hvorfor vi hos Avito for ni m\u00e5neder siden valgte Kafka, og hvad det best\u00e5r af. Jeg vil dele en af de anvendelsessager, vi har \u2014 beskedbroker. Til sidst vil vi tale om de fordele, vi har f\u00e5et ved at anvende Kafka som en 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 mikroservices: en oversigt\" src=\"\/wp-content\/uploads\/2019\/09\/dfa5e231847cee67259da17867a11812.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Lad os starte med lidt kontekst. For nogen tid siden begyndte vi at bev\u00e6ge os v\u00e6k fra monolitisk arkitektur, og nu har Avito allerede flere hundrede forskellige tjenester. De har deres egne datalagre, deres egen teknologistak og er ansvarlige for deres del af forretningslogikken. <\/p>\n<p><\/p>\n<p>Et af problemerne med et stort antal tjenester er kommunikation. Tjeneste A vil ofte vide noget, som tjeneste B har information om. I dette tilf\u00e6lde anmoder tjeneste A tjeneste B via et synkront API. Tjeneste V \u00f8nsker at vide, hvad der foreg\u00e5r hos tjenesterne G og D, som p\u00e5 deres side er interesseret i tjenesterne A og B. N\u00e5r der bliver flere \"nysgerrige\" tjenester, bliver forbindelserne mellem dem til en forvirrende klasse.<\/p>\n<p><\/p>\n<p>Samtidig kan tjeneste A blive utilg\u00e6ngelig p\u00e5 ethvert tidspunkt. Hvad skal tjeneste B og alle de andre tjenester, der er afh\u00e6ngige af den, g\u00f8re i s\u00e5 fald? Og hvis der kr\u00e6ves en k\u00e6de af sekventielle synkrone opkald for at udf\u00f8re en forretningsoperation, bliver sandsynligheden for at hele operationen fejler endnu h\u00f8jere (og den bliver h\u00f8jere, jo l\u00e6ngere denne k\u00e6de er). <\/p>\n<p><\/p>\n<h1 id=\"vybor-tehnologii\">Valg af teknologi<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka og mikroservices: en oversigt\" src=\"\/wp-content\/uploads\/2019\/09\/3acd7bcf3dded8093bdef6d627eb4071.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Okay, problemerne er klarlagt. De kan l\u00f8ses ved at lave et centralt beskedsystem til kommunikation mellem tjenesterne. Nu beh\u00f8ver hver af tjenesterne kun at kende til dette beskedsystem. Derudover skal selve systemet v\u00e6re fejlretter og horisontalt skalerbart, samt i tilf\u00e6lde af nedbrud kunne opbevare en buffer til senere behandling. <\/p>\n<p><\/p>\n<p>Lad os nu v\u00e6lge en teknologi, som leveringen af beskederne vil blive implementeret p\u00e5. For at g\u00f8re dette lad os f\u00f8rst forst\u00e5, hvad vi forventer af den:<\/p>\n<p><\/p>\n<ul>\n<li>beskeder mellem tjenesterne m\u00e5 ikke g\u00e5 tabt;<\/li>\n<li>beskeder kan dubleres;<\/li>\n<li>beskeder kan opbevares og l\u00e6ses i flere dage (persistent buffer);<\/li>\n<li>tjenester kan abonnere p\u00e5 de data, de er interesseret i;<\/li>\n<li>flere tjenester kan l\u00e6se de samme data;<\/li>\n<li>beskeder kan indeholde detaljeret, stor payload (event-carried state transfer);<\/li>\n<li>nogle gange er der brug for en garanti for r\u00e6kkef\u00f8lgen af beskeder.<\/li>\n<\/ul>\n<p><\/p>\n<p>Det var ogs\u00e5 kritisk for os at v\u00e6lge et s\u00e5 skalerbart og p\u00e5lideligt system som muligt med en h\u00f8j b\u00e5ndbredde (mindst 100k beskeder p\u00e5 nogle f\u00e5 kilobyte i sekunder).<\/p>\n<p><\/p>\n<p>I dette trin sagde vi farvel til RabbitMQ (sv\u00e6rt at holde stabilt ved h\u00f8je rps), PGQ fra SkyTools (ikke hurtigt nok og d\u00e5rligt skalerbart) og NSQ (ikke persistent). Alle disse teknologier bruges i vores virksomhed, men de var ikke egnede til opgaven. <\/p>\n<p><\/p>\n<p>Herefter begyndte vi at se p\u00e5 nye teknologier for os - Apache Kafka, Apache Pulsar og NATS Streaming.<\/p>\n<p><\/p>\n<p>Vi udelod f\u00f8rst Pulsar. Vi besluttede, at Kafka og Pulsar er ret lignende l\u00f8sninger. Og selvom Pulsar er testet af store virksomheder, er nyere og tilbyder lavere latency (i teorien), valgte vi at holde Kafka som de facto standard for s\u00e5danne opgaver. Vi vil sandsynligvis vende tilbage til Apache Pulsar i fremtiden. <\/p>\n<p><\/p>\n<p>Og nu var der kun to kandidater tilbage: NATS Streaming og Apache Kafka. Vi unders\u00f8gte begge l\u00f8sninger grundigt, og begge passede til opgaven. Men til sidst var vi bekymrede over den relative ungdom af NATS Streaming (og det faktum, at en af hovedudviklerne, Tyler Treat, besluttede at forlade projektet og starte sit eget - Liftbridge). Samtidig gav NATS Streamings Clustering-tilstand ikke mulighed for st\u00e6rk vandret skalering (det er sandsynligvis ikke l\u00e6ngere et problem efter tilf\u00f8jelsen af partitioneringstilstand i 2017).<\/p>\n<p><\/p>\n<p>Ikke desto mindre er NATS Streaming en fantastisk teknologi skrevet i Go og har st\u00f8tte fra Cloud Native Computing Foundation. I mods\u00e6tning til Apache Kafka kr\u00e6ver den ikke Zookeeper for at fungere (m\u00e5ske, <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 man sige det samme om Kafka<\/a><\/noindex>), da den internt implementerer RAFT. Samtidig er NATS Streaming lettere at administrere. Vi udelukker ikke, at vi i fremtiden ogs\u00e5 vender tilbage til denne teknologi. <\/p>\n<p><\/p>\n<p>Alligevel er Apache Kafka vores vinder i dag. I vores tests viste den sig at v\u00e6re hurtig nok (over \u00e9n million beskeder i sekundet ved b\u00e5de l\u00e6sning og skrivning med en beskedst\u00f8rrelse p\u00e5 1 kilobyte), ret p\u00e5lidelig, godt skalerbar og testet i produktion af store virksomheder. Desuden underst\u00f8tter Kafka mindst nogle store kommercielle virksomheder (for eksempel bruger vi Confluent-versionen), og Kafka har et udviklet \u00f8kosystem.<br \/>\n<br clear=\"left\">\n <\/p>\n<p><\/p>\n<h1 id=\"obzor-kafka\">Oversigt over Kafka<\/h1>\n<p><\/p>\n<p>F\u00f8r vi begynder, vil jeg straks anbefale en fremragende bog - <em>\u00abKafka: The Definitive Guide\u00bb<\/em> (der er ogs\u00e5 en russisk overs\u00e6ttelse, men terminologien kan v\u00e6re lidt forvirrende). Her kan du finde information, der er n\u00f8dvendig for en grundl\u00e6ggende forst\u00e5else af Kafka og endda lidt mere. Selve dokumentationen fra Apache og bloggen fra Confluent er ogs\u00e5 godt skrevet og let at l\u00e6se. <\/p>\n<p><\/p>\n<p>Lad os tage et kig p\u00e5, hvordan Kafka er opbygget fra fugleperspektiv. Den grundl\u00e6ggende topologi af Kafka best\u00e5r af 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 mikroservices: en oversigt\" src=\"\/wp-content\/uploads\/2019\/09\/82f34b5a1aadcdc07eef58eb5414b553.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Det er brokerens ansvar at gemme dine data. Alle data opbevares i bin\u00e6rt format, og broker ved meget lidt om, hvad de repr\u00e6senterer, og hvad deres struktur er. <\/p>\n<p><\/p>\n<p>Hver logisk type begivenheder findes typisk i sit eget separate emne (topic). For eksempel kan en oprettelsesbegivenhed for en annonce falde ind under emnet item.created, mens en \u00e6ndringsbegivenhed kan falde ind under item.changed. Emner kan betragtes som klassifikatorer for begivenheder. P\u00e5 emneniveau kan man s\u00e6tte konfigurationselementer som: <\/p>\n<p><\/p>\n<ul>\n<li>m\u00e6ngden af gemte data og\/eller deres alder (retention.bytes, retention.ms); <\/li>\n<li>datadupliceringsfaktor (replication factor);<\/li>\n<li>den maksimale st\u00f8rrelse af en enkelt meddelelse (max.message.bytes);<\/li>\n<li>det mindste antal accepterede replikaer, som data kan skrives til emnet (min.insync.replicas);<\/li>\n<li>muligheden for at gennemf\u00f8re failover til en ikke-synkroniseret bagudg\u00e5ende replika med potentiel datatab (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 emne opdeles i en eller flere partitioner (partition). Det er i partitionen, at begivenhederne til sidst lander. Hvis der er mere end \u00e9n broker i klyngen, vil partitionerne blive fordelt j\u00e6vnt over alle brokerne (s\u00e5 vidt muligt), hvilket g\u00f8r det muligt at skalere belastningen for skrivning og l\u00e6sning til et enkelt emne p\u00e5 flere brokere.<\/p>\n<p><\/p>\n<p>P\u00e5 disken gemmes data for hver partition i form af segmentfiler, som som standard er lige \u00e9n gigabyte (kontrolleres gennem log.segment.bytes). En vigtig egenskab er, at fjernelse af data fra partitioner (ved aktivering af retention) sker i segmenter (man kan ikke fjerne \u00e9n begivenhed fra en partition, kun fjerne et helt segment, og det kun hvis det er inaktivt).<\/p>\n<p><\/p>\n<h3 id=\"zookeeper\">Zookeeper<\/h3>\n<p><\/p>\n<p>Zookeeper fungerer som datalager for metadata og koordinator. Det er ham, der kan sige, om brokerne er aktive (man kan se dette gennem zookeeper-shell med kommandoen <code>ls \/brokers\/ids<\/code>), hvilken af brokerne der er controller (<code>get \/controller<\/code>), er partitionerne synkroniseret med deres replikaer (<code>get \/brokers\/topics\/topic_name\/partitions\/partition_number\/state<\/code>). Desuden vil producer og consumer f\u00f8rst g\u00e5 til zookeeper for at finde ud af, hvilken broker hvilke emner og partitioner gemmes p\u00e5. I tilf\u00e6lde, hvor replication factor for et emne er h\u00f8jere end 1, vil zookeeper angive, hvilke partitioner der er ledere (hvor der skrives til og l\u00e6ses fra). Ved et broker-nedbrud vil information om nye leder-partitioner blive registreret i zookeeper (asynkront siden version 1.1.0, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.confluent.io\/blog\/apache-kafka-supports-200k-partitions-per-cluster\">og det er vigtigt<\/a><\/noindex>).<\/p>\n<p><\/p>\n<p>I \u00e6ldre versioner af Kafka svarede zookeeper ogs\u00e5 for opbevaring af offsets, men nu gemmes de i et s\u00e6rligt emne <code>__consumer_offsets<\/code> p\u00e5 brokeren (selvom du stadig kan bruge zookeeper til disse form\u00e5l). <\/p>\n<p><\/p>\n<p>Den nemmeste m\u00e5de at forvandle dine data til gr\u00e6skar er faktisk at miste information fra zookeeper. I et s\u00e5dant scenarie vil det v\u00e6re meget sv\u00e6rt at forst\u00e5, hvad og hvor der skal l\u00e6ses. <\/p>\n<p><\/p>\n<h3 id=\"producer\">Producer<\/h3>\n<p><\/p>\n<p>Producer er oftest en service, der direkte skriver data til Apache Kafka. Producer v\u00e6lger det emne, hvor hans tematiske beskeder skal gemmes, og begynder at skrive information til det. For eksempel kan en producer v\u00e6re en annonceservice. I s\u00e5 fald vil den sende h\u00e6ndelser som \"annonce oprettet\", \"annonce opdateret\", \"annonce slettet\" osv. i de tematiske emner. Hver h\u00e6ndelse repr\u00e6senterer et n\u00f8gle-v\u00e6rdi par.<\/p>\n<p><\/p>\n<p>Som standard distribueres alle h\u00e6ndelser j\u00e6vnt p\u00e5 partitionerne i emnet round-robin, hvis n\u00f8glen ikke er angivet (hvilket mister r\u00e6kkef\u00f8lgen), og via MurmurHash (n\u00f8gle), hvis n\u00f8glen er tilstede (bevarer r\u00e6kkef\u00f8lge inden for \u00e9n partition).<\/p>\n<p><\/p>\n<p>Her er det vigtigt at bem\u00e6rke, at Kafka kun garanterer r\u00e6kkef\u00f8lgen af h\u00e6ndelser inden for \u00e9n partition. Men i praksis er dette ofte ikke et problem. For eksempel kan man garantere, at alle \u00e6ndringer af det samme annonce emne tilf\u00f8jes til \u00e9n partition (og dermed bevarer r\u00e6kkef\u00f8lgen af disse \u00e6ndringer inden for annoncen). Man kan ogs\u00e5 overf\u00f8re en sekvensnummer i et af felterne i h\u00e6ndelsen.<\/p>\n<p><\/p>\n<h3 id=\"consumer\">Consumer<\/h3>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka og mikroservices: en oversigt\" src=\"\/wp-content\/uploads\/2019\/09\/1f69a53dc19bb6c587883b8754cde29f.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Forbrugeren er ansvarlig for at hente data fra Apache Kafka. Hvis vi vender tilbage til eksemplet ovenfor, kan forbrugeren v\u00e6re en modereringsservice. Denne service vil abonnere p\u00e5 emnet fra annonceservice, og n\u00e5r der opst\u00e5r en ny annonce, vil den modtage den og analysere den for overensstemmelse med nogle specifikke politikker.<\/p>\n<p><\/p>\n<p>Apache Kafka husker, hvilke seneste begivenheder forbrugeren har modtaget (til dette bruges en systememne __consumer__offsets), hvilket garanterer, at forbrugeren ikke modtager den samme besked to gange efter en vellykket l\u00e6sning. Men hvis man bruger indstillingen enable.auto.commit = true og overlader det til Kafka at holde styr p\u00e5 forbrugerens position i emnet, kan man <code>miste data<\/code>. I produktionskoden kontrolleres forbrugerens position ofte manuelt (udvikleren styrer, hvorn\u00e5r en commit af den l\u00e6ste begivenhed n\u00f8dvendigvis skal finde sted). <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.newrelic.com\/engineering\/kafka-consumer-config-auto-commit-data-loss\/\">I de tilf\u00e6lde, hvor \u00e9n forbruger ikke er tilstr\u00e6kkelig (f.eks. hvis str\u00f8mmen af nye begivenheder er meget stor), kan man tilf\u00f8je flere forbrugere ved at knytte dem sammen i en forbrugergruppe. Forbrugergruppen repr\u00e6senterer logisk n\u00f8jagtig samme forbruger, men med data fordelt mellem gruppe medlemmerne. Dette giver hver deltager mulighed for at tage deres del af beskederne og dermed skalere l\u00e6sehastigheden.<\/a><\/noindex>Testresultater<\/p>\n<p><\/p>\n<p>Her vil jeg ikke skrive meget forklarende tekst, jeg vil bare dele de opn\u00e5ede resultater. Testningen blev udf\u00f8rt p\u00e5 3 fysiske maskiner (12 CPU, 384GB RAM, 15k SAS-DISK, 10GBit\/s net), og enhederne broker og zookeeper blev udsat for lxc. <\/p>\n<p><\/p>\n<h1 id=\"rezultaty-testirovaniya\">Ydeevnetest<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka og mikroservices: en oversigt\" src=\"\/wp-content\/uploads\/2019\/09\/f7abe4bcf34fdb0d762c8a928bd873ee.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Under testningen blev de f\u00f8lgende resultater opn\u00e5et. <\/p>\n<p><\/p>\n<p><strong>Skrivehastighed for beskeder p\u00e5 1KB med 9 producenter samtidigt \u2014 1300000 begivenheder i sekundet.<\/strong><\/p>\n<p><\/p>\n<p>L\u00e6sehastighed for beskeder p\u00e5 1KB med 9 forbrugere samtidigt \u2014 1500000 begivenheder i sekundet.<\/p>\n<p><\/p>\n<ul>\n<li>Test af fejltolerance<\/li>\n<li>Under testningen blev de f\u00f8lgende resultater opn\u00e5et (3 enheder broker, 3 zookeeper).<\/li>\n<\/ul>\n<p><\/p>\n<p><strong>En utilsigtet afslutning af en af enhederne broker stopper ikke eller g\u00f8r klyngen utilg\u00e6ngelig. Arbejdet forts\u00e6tter i normal drift, men de resterende enheder broker m\u00e5 b\u00e6re en st\u00f8rre belastning.<\/strong><\/p>\n<p><\/p>\n<p>En utilsigtet afslutning af en af enhederne broker stopper ikke eller g\u00f8r klyngen utilg\u00e6ngelig. Arbejdet forts\u00e6tter i normal drift, men de resterende enheder broker m\u00e5 b\u00e6re en st\u00f8rre belastning.<\/p>\n<p><\/p>\n<ul>\n<li>En utilsigtet afslutning af en af enhederne broker stopper ikke eller g\u00f8r klyngen utilg\u00e6ngelig. Arbejdet forts\u00e6tter i normal drift, men de resterende enheder broker m\u00e5 b\u00e6re en st\u00f8rre belastning.<\/li>\n<li>Uventet nedlukning af to m\u00e6glere i en klynge af tre m\u00e6glere med min.isr = 2 f\u00f8rer til, at klyngen ikke er tilg\u00e6ngelig for skrivning, men er tilg\u00e6ngelig for l\u00e6sning. I tilf\u00e6lde af at min.isr = 1, forbliver klyngen tilg\u00e6ngelig for b\u00e5de l\u00e6sning og skrivning. Det skal dog bem\u00e6rkes, at denne tilstand strider mod kravet om h\u00f8j databeskyttelse.<\/li>\n<li>Uventet nedlukning af en af Zookeeper-serverne medf\u00f8rer ikke nedlukning eller utilg\u00e6ngelighed af klyngen. Arbejdet forts\u00e6tter som normalt.<\/li>\n<li>Uventet nedlukning af to Zookeeper-servere medf\u00f8rer, at klyngen bliver utilg\u00e6ngelig, indtil mindst \u00e9n af Zookeeper-serverne er genoprettet. Denne p\u00e5stand g\u00e6lder for en Zookeeper-klynge best\u00e5ende af 3 servere. Som f\u00f8lge heraf blev det besluttet at \u00f8ge Zookeeper-klyngen til 5 servere for at \u00f8ge fejltolerance. <br clear=\"left\">\n <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"kafka-as-a-service\">Kafka som en service<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka og mikroservices: en oversigt\" src=\"\/wp-content\/uploads\/2019\/09\/19b2356131203cefbadfd90a25ae9674.png\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p><\/p>\n<p>Vi har konkluderet, at Kafka er en fremragende teknologi, der g\u00f8r det muligt at l\u00f8se den opgave, vi har f\u00e5et (implementeringen af en meddelelsesm\u00e6gler). Vi har dog besluttet at forbyde tjenesterne direkte at tilg\u00e5 Kafka og har lukket den af bag ved data-bus. Hvorfor gjorde vi det? Der er faktisk flere grunde.<\/p>\n<p><\/p>\n<ul>\n<li>\n<p>Data-bus tog alle opgaver relateret til integration med Kafka (implementering og konfiguration af forbrugere og producenter, overv\u00e5gning, alarmering, logning, skalering osv.). P\u00e5 den m\u00e5de foreg\u00e5r integrationen med meddelelsesm\u00e6gleren s\u00e5 simpelt som muligt. <\/p>\n<p>\n<\/li>\n<li>\n<p>Data-bus gjorde det muligt at abstrahere fra et specifikt sprog eller bibliotek til at arbejde med Kafka. <\/p>\n<p>\n<\/li>\n<li>\n<p>Data-bus gav andre tjenester mulighed for at abstrahere fra lagringslaget. M\u00e5ske \u00e6ndrer vi p\u00e5 et tidspunkt Kafka til Pulsar, og ingen vil l\u00e6gge m\u00e6rke til det (alle tjenester kender kun API'et for data-bus).<\/p>\n<p>\n<\/li>\n<li>\n<p>Data-bus har p\u00e5taget sig valideringen af h\u00e6ndelsesskemaer.<\/p>\n<p>\n<\/li>\n<li>\n<p>Authentication er implementeret ved hj\u00e6lp af data-bus.<\/p>\n<p>\n<\/li>\n<li>\n<p>Under d\u00e6kke af data-bus kan vi opdatere versioner af Kafka uden nedetid og uden at det bliver bem\u00e6rket, og centralt styre konfigurationer af producenter, forbrugere, m\u00e6glere osv.<\/p>\n<p>\n<\/li>\n<li>\n<p>Data-bus gav mulighed for at tilf\u00f8je n\u00f8dvendige funktioner, som ikke findes i Kafka (s\u00e5som audit af emner, kontrol af anomalier i klyngen, oprettelse af DLQ osv.).<\/p>\n<p>\n<\/li>\n<li>\n<p>Data-bus muligg\u00f8r centraliseret failover for alle tjenester.<\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>I \u00f8jeblikket er det nok at tilf\u00f8je et lille bibliotek til koden af din tjeneste for at begynde at sende events til message broker. Det er alt. Du f\u00e5r mulighed for at skrive, l\u00e6se og skalere med en enkelt linje kode. Hele implementeringen er skjult for dig, kun nogle h\u00e5ndtag som batch-st\u00f8rrelse er synlige. Under motorhjelmen ops\u00e6tter data-bus servicen det n\u00f8dvendige antal instanser af producer og consumer i Kubernetes og giver dem den n\u00f8dvendige konfiguration, men alt dette er gennemsigtigt for din service. <\/p>\n<p><\/p>\n<p>Selvf\u00f8lgelig findes der ikke en s\u00f8lvkugle, og denne tilgang har sine begr\u00e6nsninger.<\/p>\n<p><\/p>\n<ul>\n<li>Data-bus skal vedligeholdes af dine egne kr\u00e6fter, i mods\u00e6tning til tredjepartsbiblioteker.<\/li>\n<li>Data-bus \u00f8ger antallet af interaktioner mellem tjenesterne og message broker, hvilket f\u00f8rer til nedsat ydeevne sammenlignet med ren Kafka.<\/li>\n<li>Det er ikke alt, der kan skjules for tjenesterne; vi \u00f8nsker ikke at duplikere funktionaliteten af KSQL eller Kafka Streams i data-bus, derfor er vi nogle gange n\u00f8dt til at tillade, at tjenesterne kommunikerer direkte. <\/li>\n<\/ul>\n<p><\/p>\n<p>I vores tilf\u00e6lde overgik fordelene ulemperne, og beslutningen om at adskille message broker som en s\u00e6rlig service har vist sig at v\u00e6re klog. I l\u00f8bet af et \u00e5r med drift har vi ikke haft alvorlige uheld eller problemer.<\/p>\n<p><\/p>\n<p>P.S. Tak til min k\u00e6reste, Ekaterina Obalaya, for de fede billeder til denne artikel. Hvis du kunne lide dem, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.instagram.com\/o.k_o.k_\/\">her<\/a><\/noindex> vil der v\u00e6re endnu flere illustrationer.<\/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.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\/da\/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=\"da_DK\" \/>\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\/da\/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 og mikrotjenester: Oversigt | ProHoster","description":"Hej alle.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/37849","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=37849"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/37849\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/28406"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=37849"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=37849"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=37849"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}