{"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\/sv\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","title":{"rendered":"Kafka och mikrotj\u00e4nster: en \u00f6versikt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Kafka och mikrotj\u00e4nster: en \u00f6versikt\" src=\"\/wp-content\/uploads\/2019\/09\/ab0534ad5d28b3c3aa03e4e0b2d3101b.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hej alla. I den h\u00e4r artikeln kommer jag att ber\u00e4tta varf\u00f6r vi p\u00e5 Avito valde Kafka f\u00f6r nio m\u00e5nader sedan och vad det egentligen inneb\u00e4r. Jag kommer ocks\u00e5 att dela med mig av ett av v\u00e5ra anv\u00e4ndningsfall \u2014 meddelandebrokers. Till sist kommer vi att diskutera vilka f\u00f6rdelar vi f\u00e5tt av att anv\u00e4nda 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 och mikrotj\u00e4nster: en \u00f6versikt\" src=\"\/wp-content\/uploads\/2019\/09\/dfa5e231847cee67259da17867a11812.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>F\u00f6rst lite kontext. F\u00f6r en tid sedan b\u00f6rjade vi \u00f6verge den monolitiska arkitekturen, och nu finns det flera hundra olika tj\u00e4nster p\u00e5 Avito. Dessa har sina egna lagringsl\u00f6sningar, sin egen teknologiska stack och ansvarar f\u00f6r sin del av aff\u00e4rslogiken. <\/p>\n<p><\/p>\n<p>Ett av problemen med ett stort antal tj\u00e4nster \u00e4r kommunikationen. Tj\u00e4nst A vill ofta f\u00e5 information fr\u00e5n tj\u00e4nst B. I det h\u00e4r fallet kontaktar tj\u00e4nst A tj\u00e4nst B via ett synkront API. Tj\u00e4nst C vill veta vad som h\u00e4nder hos tj\u00e4nsterna G och D, och dessa \u00e5 sin sida \u00e4r intresserade av tj\u00e4nsterna A och B. N\u00e4r det finns m\u00e5nga s\u00e5dana \"nyfikna\" tj\u00e4nster blir kopplingarna mellan dem en sn\u00e5rig knut.<\/p>\n<p><\/p>\n<p>Samtidigt kan tj\u00e4nst A n\u00e4r som helst bli otillg\u00e4nglig. Vad ska tj\u00e4nst B och alla andra tj\u00e4nster som \u00e4r beroende av den g\u00f6ra i det h\u00e4r fallet? Och om det f\u00f6r en aff\u00e4rshandling kr\u00e4vs en kedja av sekventiella synkront samtal, \u00f6kar risken f\u00f6r att hela operationen misslyckas ytterligare (och ju l\u00e4ngre kedjan \u00e4r, desto h\u00f6gre \u00e4r risken). <\/p>\n<p><\/p>\n<h1 id=\"vybor-tehnologii\">Val av teknik<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka och mikrotj\u00e4nster: en \u00f6versikt\" src=\"\/wp-content\/uploads\/2019\/09\/3acd7bcf3dded8093bdef6d627eb4071.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Okej, problemen \u00e4r f\u00f6rst\u00e5eliga. De kan \u00e5tg\u00e4rdas genom att skapa ett centralt meddelandesystem mellan tj\u00e4nsterna. Nu beh\u00f6ver varje tj\u00e4nst bara k\u00e4nna till detta meddelandesystem. Dessutom b\u00f6r sj\u00e4lva systemet vara felresilient och horisontellt skalbart, och i h\u00e4ndelse av incidenter b\u00f6r det spara meddelanden f\u00f6r senare behandling. <\/p>\n<p><\/p>\n<p>L\u00e5t oss nu v\u00e4lja en teknik f\u00f6r att genomf\u00f6ra meddelandetransporten. F\u00f6r detta b\u00f6r vi f\u00f6rst f\u00f6rst\u00e5 vad vi f\u00f6rv\u00e4ntar oss av den:<\/p>\n<p><\/p>\n<ul>\n<li>meddelanden mellan tj\u00e4nster f\u00e5r inte g\u00e5 f\u00f6rlorade;<\/li>\n<li>meddelanden kan dupliceras;<\/li>\n<li>meddelanden kan lagras och l\u00e4sas i flera dagar (persistenta buffertar);<\/li>\n<li>tj\u00e4nster kan prenumerera p\u00e5 data som de \u00e4r intresserade av;<\/li>\n<li>flera tj\u00e4nster kan l\u00e4sa samma data;<\/li>\n<li>meddelanden kan inneh\u00e5lla detaljerad, stor payload (event-carried state transfer);<\/li>\n<li>ibland beh\u00f6vs garantier f\u00f6r meddelandens ordning.<\/li>\n<\/ul>\n<p><\/p>\n<p>Det var ocks\u00e5 avg\u00f6rande f\u00f6r oss att v\u00e4lja ett s\u00e5 skalbart och p\u00e5litligt system som m\u00f6jligt med h\u00f6g kapacitet (minst 100 000 meddelanden p\u00e5 flera kilobyte per sekund).<\/p>\n<p><\/p>\n<p>Vid det h\u00e4r skedet sa vi farv\u00e4l till RabbitMQ (sv\u00e5rt att h\u00e5lla stabil p\u00e5 h\u00f6g rps), PGQ fr\u00e5n SkyTools (inte tillr\u00e4ckligt snabb och d\u00e5ligt skalbar) och NSQ (inte persistenta). Alla dessa teknologier anv\u00e4nds i v\u00e5rt f\u00f6retag, men de passade inte f\u00f6r det problem som skulle l\u00f6sas. <\/p>\n<p><\/p>\n<p>D\u00e4refter b\u00f6rjade vi titta p\u00e5 nya teknologier f\u00f6r oss - Apache Kafka, Apache Pulsar och NATS Streaming.<\/p>\n<p><\/p>\n<p>F\u00f6rst avf\u00e4rdade vi Pulsar. Vi ans\u00e5g att Kafka och Pulsar \u00e4r ganska likartade l\u00f6sningar. Och trots att Pulsar \u00e4r bekr\u00e4ftad av stora f\u00f6retag, \u00e4r nyare och erbjuder l\u00e4gre latens (i teorin), best\u00e4mde vi oss f\u00f6r att beh\u00e5lla Kafka av dessa tv\u00e5 som de facto-standard f\u00f6r s\u00e5dana uppgifter. Vi kommer troligen att \u00e5terv\u00e4nda till Apache Pulsar i framtiden. <\/p>\n<p><\/p>\n<p>Och nu \u00e5terst\u00e5r tv\u00e5 kandidater: NATS Streaming och Apache Kafka. Vi studerade b\u00e5da l\u00f6sningarna noggrant och b\u00e5da passade f\u00f6r uppgiften. Men till slut var vi oroade \u00f6ver den relativa ungdomligheten hos NATS Streaming (och att en av huvudutvecklarna, Tyler Treat, beslutade att l\u00e4mna projektet och starta sitt eget - Liftbridge). Samtidigt gav clustering-l\u00e4get i NATS Streaming ingen m\u00f6jlighet till stark horisontell skalning (det \u00e4r troligtvis inte l\u00e4ngre ett problem efter att partitionering-l\u00e4get lades till 2017).<\/p>\n<p><\/p>\n<p>\u00c4nd\u00e5 \u00e4r NATS Streaming en fantastisk teknologi, skriven i Go och st\u00f6dd av Cloud Native Computing Foundation. Till skillnad fr\u00e5n Apache Kafka, kr\u00e4ver den inte Zookeeper f\u00f6r att fungera (m\u00f6jligen, <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 s\u00e4ga samma sak om Kafka<\/a><\/noindex>), eftersom den implementerar RAFT internt. NATS Streaming \u00e4r enklare att administrera. Vi utesluter inte att vi i framtiden kan \u00e5terv\u00e4nda till denna teknologi. <\/p>\n<p><\/p>\n<p>Och \u00e4nd\u00e5 blev v\u00e5r vinnare idag Apache Kafka. I v\u00e5ra tester visade den sig vara tillr\u00e4ckligt snabb (\u00f6ver en miljon meddelanden per sekund b\u00e5de f\u00f6r l\u00e4sning och skrivning med meddelandevolym p\u00e5 1 kilobyte), tillr\u00e4ckligt p\u00e5litlig, v\u00e4l skalbar och bepr\u00f6vad i produktion av stora f\u00f6retag. Dessutom st\u00f6der Kafka minst flera stora kommersiella f\u00f6retag (vi anv\u00e4nder till exempel Confluent-versionen), och Kafka har ett utvecklat ekosystem.<br \/>\n<br clear=\"left\">\n <\/p>\n<p><\/p>\n<h1 id=\"obzor-kafka\">\u00d6versikt \u00f6ver Kafka<\/h1>\n<p><\/p>\n<p>Innan vi b\u00f6rjar, rekommenderar jag genast en utm\u00e4rkt bok - <em>\u00abKafka: The Definitive Guide\u00bb<\/em> (finns \u00e4ven p\u00e5 ryska, men termerna kan vara f\u00f6rvirrande). I den kan man hitta information som \u00e4r n\u00f6dv\u00e4ndig f\u00f6r en grundl\u00e4ggande f\u00f6rst\u00e5else av Kafka och \u00e4ven lite mer. Sj\u00e4lv dokumentationen fr\u00e5n Apache och bloggen fr\u00e5n Confluent \u00e4r ocks\u00e5 v\u00e4lskrivna och l\u00e4tta att l\u00e4sa. <\/p>\n<p><\/p>\n<p>S\u00e5 l\u00e5t oss ta en titt p\u00e5 hur Kafka fungerar fr\u00e5n f\u00e5gelperspektiv. Den grundl\u00e4ggande topologin av Kafka best\u00e5r av producent, konsument, broker och zookeeper.<\/p>\n<p><\/p>\n<h3 id=\"broker\">Broker<\/h3>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka och mikrotj\u00e4nster: en \u00f6versikt\" src=\"\/wp-content\/uploads\/2019\/09\/82f34b5a1aadcdc07eef58eb5414b553.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Broker (broker) ansvarar f\u00f6r lagring av dina data. All data lagras i bin\u00e4r form, och brokern vet lite om vad de representerar och vad deras struktur \u00e4r. <\/p>\n<p><\/p>\n<p>Varje logisk typ av h\u00e4ndelser finns vanligtvis i sin egen separata topic (topic). Till exempel kan en h\u00e4ndelse om skapandet av en annons hamna i topicen item.created, medan en h\u00e4ndelse om \u00e4ndringen av den hamnar i item.changed. Topics kan ses som klassificerare av h\u00e4ndelser. P\u00e5 topicsniv\u00e5 kan konfigurationsparametrar st\u00e4llas in, s\u00e5som: <\/p>\n<p><\/p>\n<ul>\n<li>volymen av lagrade data och\/eller deras \u00e5lder (retention.bytes, retention.ms); <\/li>\n<li>faktor f\u00f6r dataduplicering (replication factor);<\/li>\n<li>maximalt meddelande storlek (max.message.bytes);<\/li>\n<li>minsta antal synkrona repliker d\u00e4r data kan skrivas till topicen (min.insync.replicas);<\/li>\n<li>m\u00f6jlighet att genomf\u00f6ra failover till en osynkron f\u00f6rsenad replik med potentiell dataf\u00f6rlust (unclean.leader.election.enable);<\/li>\n<li>och m\u00e5nga fler (<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>I sin tur delas varje topic upp i en eller flera partitioner (partition). Det \u00e4r i partitionerna som h\u00e4ndelserna slutligen g\u00e5r. Om det finns mer \u00e4n en broker i klustret kommer partitionerna att f\u00f6rdelas j\u00e4mnt mellan alla brokers (s\u00e5 l\u00e5ngt det \u00e4r m\u00f6jligt), vilket m\u00f6jligg\u00f6r att skala belastningen f\u00f6r skrivning och l\u00e4sning i en topic \u00f6ver flera brokers.<\/p>\n<p><\/p>\n<p>P\u00e5 disken lagras data f\u00f6r varje partition i form av segmentfiler, som som standard \u00e4r ett gigabyte l\u00e5nga (detta kontrolleras via log.segment.bytes). En viktig egenskap \u00e4r att borttagning av data fr\u00e5n partitioner (n\u00e4r retention utl\u00f6ses) sker just i segment (det g\u00e5r inte att ta bort enskilda h\u00e4ndelser fr\u00e5n en partition, man kan bara ta bort hela segment, och endast inaktiva s\u00e5dana).<\/p>\n<p><\/p>\n<h3 id=\"zookeeper\">Zookeeper<\/h3>\n<p><\/p>\n<p>Zookeeper fungerar som en lagring f\u00f6r metadata och koordinator. Det \u00e4r den som kan s\u00e4ga om brokerna \u00e4r aktiva (att titta p\u00e5 detta ur zookeepers \u00f6gon kan g\u00f6ras genom zookeeper-shell med kommandot <code>ls \/brokers\/ids<\/code>), vilken av brokerna som \u00e4r kontrolleraren (<code>get \/controller<\/code>), \u00e4r partitionerna i synk med sina repliker (<code>get \/brokers\/topics\/topic_name\/partitions\/partition_number\/state<\/code>). Det \u00e4r ocks\u00e5 till zookeeper som producenter och konsumenter f\u00f6rst g\u00e5r f\u00f6r att ta reda p\u00e5 vilka topic och partitioner som lagras p\u00e5 vilken broker. I fall d\u00e4r topic har en replication factor st\u00f6rre \u00e4n 1 kommer zookeeper att ange vilka partitioner som \u00e4r ledare (d\u00e4r skrivning kommer att ske och fr\u00e5n vilka l\u00e4sning kommer att ske). Vid krasch av en broker kommer information om nya ledarpartitioner att registreras i zookeeper (fr\u00e5n version 1.1.0 asynkront, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.confluent.io\/blog\/apache-kafka-supports-200k-partitions-per-cluster\">och detta \u00e4r viktigt<\/a><\/noindex>).<\/p>\n<p><\/p>\n<p>I \u00e4ldre versioner av Kafka ansvarade zookeeper ocks\u00e5 f\u00f6r lagring av offsets, men nu lagras de i en speciell topic <code>__consumer_offsets<\/code> p\u00e5 brokern (\u00e4ven om du fortfarande kan anv\u00e4nda zookeeper f\u00f6r detta \u00e4ndam\u00e5l). <\/p>\n<p><\/p>\n<p>Det enklaste s\u00e4ttet att f\u00f6rvandla dina data till pumpa \u00e4r just f\u00f6rlust av information med zookeeper. I ett s\u00e5dant scenario kommer det vara mycket sv\u00e5rt att f\u00f6rst\u00e5 vad och varifr\u00e5n man beh\u00f6ver l\u00e4sa. <\/p>\n<p><\/p>\n<h3 id=\"producer\">Producer<\/h3>\n<p><\/p>\n<p>Producer \u00e4r oftast en tj\u00e4nst som direkt skriver data till Apache Kafka. Producer v\u00e4ljer topic d\u00e4r det kommer att lagra sina \u00e4mnesmeddelanden och b\u00f6rjar skriva information i den. Till exempel kan en producer vara en annonseringstj\u00e4nst. I s\u00e5 fall kommer den att skicka h\u00e4ndelser till \u00e4mnestopics s\u00e5som \"annons skapad\", \"annons uppdaterad\", \"annons borttagen\" osv. Varje h\u00e4ndelse representerar h\u00e4r ett nyckel-v\u00e4rde-par.<\/p>\n<p><\/p>\n<p>Som standard f\u00f6rdelas alla h\u00e4ndelser \u00f6ver partitionerna i topic via round-robin, om ingen nyckel anges (vilket f\u00f6rlorar ordningen), och via MurmurHash (nyckel) om en nyckel finns (ordningen inom en partition).<\/p>\n<p><\/p>\n<p>H\u00e4r b\u00f6r det omedelbart noteras att Kafka garanterar h\u00e4ndelseordningen endast inom en partition. Men i praktiken \u00e4r detta s\u00e4llan ett problem. Till exempel kan man garanterat l\u00e4gga till alla \u00e4ndringar av samma annons i en partition (och d\u00e4rigenom bevara ordningen av dessa \u00e4ndringar inom annonsen). Man kan ocks\u00e5 \u00f6verf\u00f6ra ett sekvensnummer i ett av f\u00e4lten i h\u00e4ndelsen.<\/p>\n<p><\/p>\n<h3 id=\"consumer\">Consumer<\/h3>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka och mikrotj\u00e4nster: en \u00f6versikt\" src=\"\/wp-content\/uploads\/2019\/09\/1f69a53dc19bb6c587883b8754cde29f.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Consumer ansvarar f\u00f6r att h\u00e4mta data fr\u00e5n Apache Kafka. Om vi \u00e5terg\u00e5r till exemplet ovan kan consumer vara en modereringstj\u00e4nst. Denna tj\u00e4nst kommer att prenumerera p\u00e5 \u00e4mnet f\u00f6r annonsservicen och n\u00e4r en ny annons dyker upp kommer den att ta emot den och analysera den f\u00f6r att se om den uppfyller vissa angivna policyer.<\/p>\n<p><\/p>\n<p>Apache Kafka kommer ih\u00e5g vilka de senaste h\u00e4ndelserna som consumer mottagit (detta g\u00f6rs med hj\u00e4lp av en system\u00e4mne <code>__consumer__offsets<\/code>), vilket garanterar att consumer inte f\u00e5r samma meddelande tv\u00e5 g\u00e5nger vid en framg\u00e5ngsrik l\u00e4sning. Om man d\u00e4remot anv\u00e4nder alternativet enable.auto.commit = true och helt \u00f6verl\u00e5ter ansvaret f\u00f6r att f\u00f6lja consumerns position i \u00e4mnet till Kafka, kan man <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.newrelic.com\/engineering\/kafka-consumer-config-auto-commit-data-loss\/\">f\u00f6rlora data<\/a><\/noindex>. I produktionskod kontrolleras oftast consumerns position manuellt (utvecklaren hanterar tidpunkten n\u00e4r en commit av den l\u00e4sta h\u00e4ndelsen b\u00f6r ske).<\/p>\n<p><\/p>\n<p>I de fall d\u00e4r en enda consumer inte r\u00e4cker (till exempel om fl\u00f6det av nya h\u00e4ndelser \u00e4r mycket stort), kan man l\u00e4gga till ytterligare n\u00e5gra consumers, koppla dem tillsammans i en consumer-grupp. Consumer-gruppen representerar logiskt samma consumer, men med dataf\u00f6rdelning mellan gruppens medlemmar. Detta g\u00f6r det m\u00f6jligt f\u00f6r varje medlem att ta sin andel av meddelandena, vilket d\u00e4rmed \u00f6kar l\u00e4shastigheten. <\/p>\n<p><\/p>\n<h1 id=\"rezultaty-testirovaniya\">Testresultat<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka och mikrotj\u00e4nster: en \u00f6versikt\" src=\"\/wp-content\/uploads\/2019\/09\/f7abe4bcf34fdb0d762c8a928bd873ee.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>H\u00e4r kommer jag inte att skriva mycket f\u00f6rklarande text, utan bara dela med mig av de erh\u00e5llna resultaten. Testningen utf\u00f6rdes p\u00e5 3 fysiska maskiner (12 CPU, 384GB RAM, 15k SAS DISK, 10GBit\/s n\u00e4tverk), med brokers och zookeeper distribuerade i lxc. <\/p>\n<p><\/p>\n<p><strong>Prestandatestning<\/strong><\/p>\n<p><\/p>\n<p>Under testningen erh\u00f6lls f\u00f6ljande resultat.<\/p>\n<p><\/p>\n<ul>\n<li>Skrivhastighet f\u00f6r meddelanden p\u00e5 1KB med 9 producenter samtidigt \u2014 1300000 h\u00e4ndelser per sekund.<\/li>\n<li>L\u00e4shastighet f\u00f6r meddelanden p\u00e5 1KB med 9 consumers samtidigt \u2014 1500000 h\u00e4ndelser per sekund.<\/li>\n<\/ul>\n<p><\/p>\n<p><strong>Testning av motst\u00e5ndskraft<\/strong><\/p>\n<p><\/p>\n<p>Under testningen erh\u00f6lls f\u00f6ljande resultat (3 brokers, 3 zookeeper).<\/p>\n<p><\/p>\n<ul>\n<li>Ett ov\u00e4ntat avslut p\u00e5 en av brokers leder inte till stopp eller otillg\u00e4nglighet f\u00f6r klustret. Arbetet forts\u00e4tter som vanligt, men de \u00e5terst\u00e5ende brokers f\u00e5r en st\u00f6rre belastning.<\/li>\n<li>Ett ov\u00e4ntat avslut av tv\u00e5 m\u00e4klare i en kluster med tre m\u00e4klare och min.isr = 2 leder till att klustret blir otillg\u00e4ngligt f\u00f6r skrivning, men fortsatt tillg\u00e4ngligt f\u00f6r l\u00e4sning. Om min.isr = 1 \u00e4r klustret fortsatt tillg\u00e4ngligt b\u00e5de f\u00f6r l\u00e4sning och skrivning. Detta l\u00e4ge strider dock mot kraven f\u00f6r h\u00f6g dataskydd.<\/li>\n<li>Ett ov\u00e4ntat avslut av en av Zookeeper-servrarna leder inte till att klustret stoppas eller blir otillg\u00e4ngligt. Arbetet forts\u00e4tter som vanligt.<\/li>\n<li>Ett ov\u00e4ntat avslut av tv\u00e5 Zookeeper-servrar leder till att klustret blir otillg\u00e4ngligt tills minst en av Zookeeper-servrarna \u00e5terf\u00e5r funktion. Detta p\u00e5st\u00e5ende st\u00e4mmer f\u00f6r ett Zookeeper-kluster med 3 servrar. Som ett resultat av forskningen beslutades det att \u00f6ka Zookeeper-klustret till 5 servrar f\u00f6r att \u00f6ka drifts\u00e4kerheten. <br clear=\"left\">\n <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"kafka-as-a-service\">Kafka som en tj\u00e4nst<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka och mikrotj\u00e4nster: en \u00f6versikt\" src=\"\/wp-content\/uploads\/2019\/09\/19b2356131203cefbadfd90a25ae9674.png\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p><\/p>\n<p>Vi har \u00f6vertygats om att Kafka \u00e4r en utm\u00e4rkt teknik som l\u00f6ser v\u00e5ra problem (implementering av en meddelandem\u00e4klare). \u00c4nd\u00e5 beslutade vi att f\u00f6rbjuda tj\u00e4nster att direkt interagera med Kafka och st\u00e4ngde den bakom en data-buss. Varf\u00f6r gjorde vi detta? Det finns egentligen flera anledningar.<\/p>\n<p><\/p>\n<ul>\n<li>\n<p>Data-bus tog p\u00e5 sig alla uppgifter relaterade till integrationen med Kafka (implementering och konfiguration av konsumenter och producenter, \u00f6vervakning, larm, loggning, skalning osv.). S\u00e5ledes sker integrationen med meddelandem\u00e4klaren p\u00e5 ett s\u00e5 enkelt s\u00e4tt som m\u00f6jligt. <\/p>\n<p>\n<\/li>\n<li>\n<p>Data-bus gjorde det m\u00f6jligt att abstrahera fr\u00e5n specifikt spr\u00e5k eller bibliotek f\u00f6r att arbeta med Kafka. <\/p>\n<p>\n<\/li>\n<li>\n<p>Data-bus gjorde det m\u00f6jligt f\u00f6r andra tj\u00e4nster att abstrahera fr\u00e5n lagringsskiktet. Kanske, vid n\u00e5got tillf\u00e4lle byter vi ut Kafka mot Pulsar, och d\u00e5 kommer ingen att m\u00e4rka det (alla tj\u00e4nster vet bara om API:et f\u00f6r data-bus).<\/p>\n<p>\n<\/li>\n<li>\n<p>Data-bus har tagit ansvar f\u00f6r att validera h\u00e4ndelseskeman.<\/p>\n<p>\n<\/li>\n<li>\n<p>Med hj\u00e4lp av data-bus har autentisering genomf\u00f6rts.<\/p>\n<p>\n<\/li>\n<li>\n<p>Under data-bus kan vi utan nedtid, osynligt uppdatera versionerna av Kafka, centralt hantera konfigurationerna av producenter, konsumenter, m\u00e4klare osv.<\/p>\n<p>\n<\/li>\n<li>\n<p>Data-bus m\u00f6jliggjorde att vi kunde l\u00e4gga till n\u00f6dv\u00e4ndiga funktioner som inte finns i Kafka (som \u00e4mnesrevision, \u00f6vervakning av avvikelser i klustret, skapande av DLQ osv.).<\/p>\n<p>\n<\/li>\n<li>\n<p>Data-bus m\u00f6jligg\u00f6r en centraliserad failover f\u00f6r alla tj\u00e4nster.<\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>F\u00f6r att b\u00f6rja skicka h\u00e4ndelser till meddelandebrokern r\u00e4cker det f\u00f6r tillf\u00e4llet att koppla in ett litet bibliotek i koden f\u00f6r din tj\u00e4nst. Det \u00e4r allt. Du f\u00e5r m\u00f6jligheten att skriva, l\u00e4sa och skala med en rad kod. All implementering \u00e4r dold f\u00f6r dig, bara n\u00e5gra handtag av typ batchstorlek syns ut\u00e5t. Under huven lyfter tj\u00e4nsten data-bus upp det n\u00f6dv\u00e4ndiga antalet instanser av producenter och konsumenter i Kubernetes och tillhandah\u00e5ller dem med r\u00e4tt konfiguration, men allt detta \u00e4r transparent f\u00f6r din tj\u00e4nst. <\/p>\n<p><\/p>\n<p>Sj\u00e4lvklart finns det ingen silverskjutning, och den h\u00e4r metoden har sina begr\u00e4nsningar.<\/p>\n<p><\/p>\n<ul>\n<li>Data-bus m\u00e5ste st\u00f6djas av egna resurser, till skillnad fr\u00e5n externa bibliotek.<\/li>\n<li>Data-bus \u00f6kar antalet interaktioner mellan tj\u00e4nster och meddelandebrokern, vilket leder till en minskning av prestandan j\u00e4mf\u00f6rt med ren Kafka.<\/li>\n<li>Inte allt g\u00e5r att d\u00f6lja f\u00f6r tj\u00e4nster, vi vill inte duplicera funktionalitet fr\u00e5n KSQL eller Kafka Streams i data-bus, d\u00e4rf\u00f6r f\u00e5r tj\u00e4nster ibland g\u00e5 direkt. <\/li>\n<\/ul>\n<p><\/p>\n<p>I v\u00e5rt fall v\u00e4ger f\u00f6rdelarna tyngre \u00e4n nackdelarna, och beslutet att d\u00f6lja meddelandebrokern som en separat tj\u00e4nst har visat sig vara klokt. Under ett \u00e5rs drift har vi inte haft n\u00e5gra allvarliga olyckor eller problem.<\/p>\n<p><\/p>\n<p>P.S. Tack till min flickv\u00e4n, Ekaterina Obalyayeva, f\u00f6r de fantastiska bilderna i denna artikel. Om du gillade dem, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.instagram.com\/o.k_o.k_\/\">). Ett typiskt exempel p\u00e5 anv\u00e4ndning:<\/a><\/noindex> finns det \u00e4nnu fler illustrationer.<\/p>\n<p>K\u00e4lla: <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.4 - 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\/sv\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sv_SE\" \/>\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\/sv\/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 och mikrotj\u00e4nster: en \u00f6versikt | ProHoster","description":"Hej alla.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/37849","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=37849"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/37849\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/28406"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=37849"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=37849"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=37849"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}