{"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\/it\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","title":{"rendered":"Kafka e microservizi: panoramica","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Kafka e microservizi: panoramica\" src=\"\/wp-content\/uploads\/2019\/09\/ab0534ad5d28b3c3aa03e4e0b2d3101b.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ciao a tutti. In questo articolo vi racconter\u00f2 perch\u00e9 noi di Avito abbiamo scelto Kafka nove mesi fa e cosa rappresenta. Condivider\u00f2 uno dei casi d'uso: il broker di messaggi. Infine, parleremo dei vantaggi che abbiamo ottenuto adottando l'approccio Kafka as a Service.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1 id=\"problema\">Problema<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka e microservizi: panoramica\" src=\"\/wp-content\/uploads\/2019\/09\/dfa5e231847cee67259da17867a11812.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Iniziamo con un po' di contesto. Qualche tempo fa abbiamo iniziato a allontanarci dall'architettura monolitica e ora in Avito ci sono gi\u00e0 diverse centinaia di servizi diversi. Ciascuno ha il proprio storage, il proprio stack tecnologico e si occupa della propria parte di logica di business. <\/p>\n<p><\/p>\n<p>Uno dei problemi legati a un numero elevato di servizi \u00e8 la comunicazione. Il servizio A spesso desidera conoscere informazioni che possiede il servizio B. In questo caso, il servizio A contatta il servizio B tramite un API sincrono. Il servizio C desidera sapere cosa accade ai servizi G e D, mentre questi ultimi sono a loro volta interessati ai servizi A e B. Quando ci sono molti servizi \"curiosi\", le connessioni tra di essi si trasformano in un groviglio complicato.<\/p>\n<p><\/p>\n<p>In qualsiasi momento, il servizio A pu\u00f2 diventare non disponibile. E cosa devono fare in questo caso il servizio B e tutti gli altri servizi dipendenti da esso? E se, per completare un'operazione di business, \u00e8 necessario effettuare una catena di chiamate sincrone in sequenza, la probabilit\u00e0 di fallimento dell'intera operazione aumenta (e aumenta tanto pi\u00f9 lunga \u00e8 questa catena). <\/p>\n<p><\/p>\n<h1 id=\"vybor-tehnologii\">Scelta della tecnologia<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka e microservizi: panoramica\" src=\"\/wp-content\/uploads\/2019\/09\/3acd7bcf3dded8093bdef6d627eb4071.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Va bene, i problemi sono chiari. Possiamo eliminarli creando un sistema centralizzato di scambio di messaggi tra i servizi. Ora ciascuno dei servizi deve sapere solo di questo sistema di scambio di messaggi. Inoltre, il sistema stesso deve essere resistente ai guasti e scalabile orizzontalmente, e in caso di guasti deve accumulare un buffer di richieste per un successivo trattamento. <\/p>\n<p><\/p>\n<p>Ora scegliamo la tecnologia con cui implementeremo la consegna dei messaggi. Per farlo, iniziamo a capire cosa ci aspettiamo da essa:<\/p>\n<p><\/p>\n<ul>\n<li>i messaggi tra i servizi non devono perdersi;<\/li>\n<li>i messaggi possono essere duplicati;<\/li>\n<li>i messaggi possono essere memorizzati e letti anche con un ritardo di alcuni giorni (buffer persistente);<\/li>\n<li>i servizi possono iscriversi ai dati di loro interesse;<\/li>\n<li>pi\u00f9 servizi possono leggere gli stessi dati;<\/li>\n<li>i messaggi possono contenere payload dettagliato e voluminoso (event-carried state transfer);<\/li>\n<li>a volte \u00e8 necessaria la garanzia dell'ordine dei messaggi.<\/li>\n<\/ul>\n<p><\/p>\n<p>\u00c8 stato inoltre fondamentale per noi scegliere un sistema il pi\u00f9 scalabile e affidabile possibile, con un'alta capacit\u00e0 di elaborazione (non meno di 100k messaggi di qualche kilobyte al secondo).<\/p>\n<p><\/p>\n<p>In questa fase, abbiamo detto addio a RabbitMQ (difficile da mantenere stabile con alti rps), PGQ di SkyTools (non abbastanza veloce e scarsamente scalabile) e NSQ (non persistente). Tutte queste tecnologie sono utilizzate nella nostra azienda, ma non si adattavano al compito che dovevamo affrontare. <\/p>\n<p><\/p>\n<p>Successivamente abbiamo iniziato a esplorare nuove tecnologie per noi: Apache Kafka, Apache Pulsar e NATS Streaming.<\/p>\n<p><\/p>\n<p>Innanzitutto, abbiamo scartato Pulsar. Abbiamo ritenuto che Kafka e Pulsar fossero soluzioni piuttosto simili. E nonostante Pulsar sia stato testato da grandi aziende, sia pi\u00f9 recente e offra una latenza pi\u00f9 bassa (in teoria), abbiamo deciso di mantenere Kafka tra queste due come standard de facto per tali compiti. \u00c8 probabile che in futuro torneremo a considerare Apache Pulsar. <\/p>\n<p><\/p>\n<p>E cos\u00ec sono rimasti due candidati: NATS Streaming e Apache Kafka. Abbiamo esaminato entrambi in dettaglio e entrambi si sono rivelati adatti al compito. Ma alla fine abbiamo esitato a causa della relativa giovinezza di NATS Streaming (e del fatto che uno dei principali sviluppatori, Tyler Treat, ha deciso di lasciare il progetto e avviare il proprio \u2014 Liftbridge). Inoltre, la modalit\u00e0 di clustering di NATS Streaming non offriva la possibilit\u00e0 di un forte scaling orizzontale (probabilmente non \u00e8 pi\u00f9 un problema dopo l'aggiunta della modalit\u00e0 di partizionamento nel 2017).<\/p>\n<p><\/p>\n<p>Tuttavia, NATS Streaming \u00e8 una tecnologia notevole, scritta in Go e supportata dalla Cloud Native Computing Foundation. A differenza di Apache Kafka, non ha bisogno di Zookeeper per funzionare (forse, <noindex><a rel=\"nofollow\" href=\"https:\/\/cwiki.apache.org\/confluence\/display\/KAFKA\/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum\">presto si potr\u00e0 dire lo stesso di Kafka<\/a><\/noindex>), dato che al suo interno implementa RAFT. Inoltre, NATS Streaming \u00e8 pi\u00f9 semplice da amministrare. Non escludiamo di tornare a questa tecnologia in futuro. <\/p>\n<p><\/p>\n<p>Eppure, al giorno d'oggi, il nostro vincitore \u00e8 stato Apache Kafka. Nei nostri test ha dimostrato di essere abbastanza veloce (oltre un milione di messaggi al secondo in lettura e scrittura con una dimensione dei messaggi di 1 kilobyte), sufficientemente affidabile, ben scalabile e collaudata in produzione da grandi aziende. Inoltre, Kafka \u00e8 supportata da almeno alcune grandi compagnie commerciali (noi, ad esempio, utilizziamo la versione di Confluent), e ha anche un ecosistema ben sviluppato.<br \/>\n<br clear=\"left\">\n <\/p>\n<p><\/p>\n<h1 id=\"obzor-kafka\">Panoramica su Kafka<\/h1>\n<p><\/p>\n<p>Prima di cominciare, raccomando subito un ottimo libro \u2014 <em>\u00abKafka: The Definitive Guide\u00bb<\/em> (c'\u00e8 anche una traduzione in russo, ma i termini un po' disturbano). Qui puoi trovare informazioni necessarie per una comprensione di base di Kafka e anche qualcosa in pi\u00f9. La documentazione di Apache e il blog di Confluent sono anche ben scritti e facili da leggere. <\/p>\n<p><\/p>\n<p>Quindi, diamo un'occhiata a come \u00e8 strutturato Kafka dall'alto. La topologia di base di Kafka \u00e8 composta da producer, consumer, broker e zookeeper.<\/p>\n<p><\/p>\n<h3 id=\"broker\">Broker<\/h3>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka e microservizi: panoramica\" src=\"\/wp-content\/uploads\/2019\/09\/82f34b5a1aadcdc07eef58eb5414b553.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Il broker \u00e8 responsabile della memorizzazione dei tuoi dati. Tutti i dati vengono memorizzati in formato binario, e il broker sa poco di ci\u00f2 che rappresentano e quale sia la loro struttura. <\/p>\n<p><\/p>\n<p>Ogni tipo logico di eventi si trova generalmente in un topic separato. Ad esempio, un evento di creazione di un annuncio pu\u00f2 finire nel topic item.created, mentre un evento di modifica pu\u00f2 andare in item.changed. I topic possono essere considerati come classificatori di eventi. A livello di topic, \u00e8 possibile specificare parametri di configurazione come: <\/p>\n<p><\/p>\n<ul>\n<li>la quantit\u00e0 di dati memorizzati e\/o la loro et\u00e0 (retention.bytes, retention.ms); <\/li>\n<li>il fattore di ridondanza dei dati (replication factor);<\/li>\n<li>la dimensione massima di un singolo messaggio (max.message.bytes);<\/li>\n<li>il numero minimo di repliche concordate, al quale sar\u00e0 possibile scrivere dati nel topic (min.insync.replicas);<\/li>\n<li>la possibilit\u00e0 di effettuare failover su una replica non sincronizzata con una potenziale perdita di dati (unclean.leader.election.enable);<\/li>\n<li>e molte altre (<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>A sua volta, ogni topic \u00e8 suddiviso in una o pi\u00f9 partizioni. Sono proprio nelle partizioni che alla fine vanno a finire gli eventi. Se nel cluster ci sono pi\u00f9 broker, le partizioni saranno distribuite su tutti i broker in modo uniforme (per quanto possibile), il che consente di scalare il carico di scrittura e lettura in un singolo topic su pi\u00f9 broker.<\/p>\n<p><\/p>\n<p>Sulla disco, i dati per ogni partizione sono memorizzati come file segmenti, solitamente della dimensione di un gigabyte (controllato tramite log.segment.bytes). Una caratteristica importante \u00e8 che l'eliminazione dei dati dalle partizioni (quando avviene il retention) avviene proprio per segmenti (non \u00e8 possibile eliminare un singolo evento da una partizione, \u00e8 possibile eliminare solo un intero segmento, e solo se non \u00e8 attivo).<\/p>\n<p><\/p>\n<h3 id=\"zookeeper\">Zookeeper<\/h3>\n<p><\/p>\n<p>Zookeeper funge da archivio di metadati e coordinatore. \u00c8 in grado di dire se i broker sono vivi (puoi guardarlo dagli occhi di zookeeper tramite il comando zookeeper-shell <code>ls \/brokers\/ids<\/code>), quale broker \u00e8 il controller (<code>get \/controller<\/code>), le partizioni sono in uno stato di sincronizzazione con le loro repliche (<code>get \/brokers\/topics\/topic_name\/partitions\/partition_number\/state<\/code>). Inoltre, \u00e8 proprio a zookeeper che i producer e i consumer si collegheranno per sapere su quale broker sono memorizzati quali topic e partizioni. Nei casi in cui il fattore di replica per un topic \u00e8 impostato su un valore superiore a 1, zookeeper indicher\u00e0 quali partizioni sono i leader (in esse verranno effettuate le scritture e da esse verranno letti i dati). In caso di crash di un broker, zookeeper registrer\u00e0 le informazioni sulle nuove partizioni leader (a partire dalla versione 1.1.0 in modo asincrono, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.confluent.io\/blog\/apache-kafka-supports-200k-partitions-per-cluster\">ed \u00e8 importante<\/a><\/noindex>).<\/p>\n<p><\/p>\n<p>Nelle versioni pi\u00f9 vecchie di Kafka, zookeeper era responsabile anche della memorizzazione degli offset, ma ora sono conservati in un topic speciale <code>__consumer_offsets<\/code> sul broker (anche se \u00e8 possibile continuare a utilizzare zookeeper per questi scopi). <\/p>\n<p><\/p>\n<p>Il modo pi\u00f9 semplice per trasformare i tuoi dati in una zucca \u00e8 proprio perdere informazioni con zookeeper. In uno scenario del genere, capire cosa e da dove leggere sar\u00e0 molto difficile. <\/p>\n<p><\/p>\n<h3 id=\"producer\">Produttore<\/h3>\n<p><\/p>\n<p>Il Producer \u00e8 solitamente un servizio che effettua direttamente la scrittura dei dati in Apache Kafka. Il Producer sceglie il topic in cui saranno memorizzati i suoi messaggi tematici e inizia a scriverci dentro informazioni. Ad esempio, un producer pu\u00f2 essere un servizio di annunci. In tal caso, invier\u00e0 nei topic tematici eventi come \"annuncio creato\", \"annuncio aggiornato\", \"annuncio eliminato\" e cos\u00ec via. Ogni evento rappresenta una coppia chiave-valore.<\/p>\n<p><\/p>\n<p>Per impostazione predefinita, tutti gli eventi vengono distribuiti tra le partizioni del topic secondo il principio round-robin, se la chiave non \u00e8 impostata (perdendo l'ordinamento), e attraverso MurmurHash (chiave), se la chiave \u00e8 presente (ordinamento all'interno di una singola partizione).<\/p>\n<p><\/p>\n<p>Qui vale la pena notare che Kafka garantisce l'ordine degli eventi solo all'interno di una singola partizione. Ma in realt\u00e0 spesso questo non \u00e8 un problema. Ad esempio, \u00e8 possibile aggiungere in modo garantito tutte le modifiche dello stesso annuncio in una partizione (mantenendo cos\u00ec l'ordine di queste modifiche nell'ambito dell'annuncio). \u00c8 inoltre possibile comunicare un numero di sequenza in uno dei campi dell'evento.<\/p>\n<p><\/p>\n<h3 id=\"consumer\">Consumer<\/h3>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka e microservizi: panoramica\" src=\"\/wp-content\/uploads\/2019\/09\/1f69a53dc19bb6c587883b8754cde29f.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Il consumer \u00e8 responsabile per la ricezione dei dati da Apache Kafka. Tornando all'esempio precedente, il consumer pu\u00f2 essere un servizio di moderazione. Questo servizio si iscriver\u00e0 al topic del servizio di annunci e, quando appare un nuovo annuncio, lo ricever\u00e0 e lo analizzer\u00e0 per verificarne la conformit\u00e0 a determinate politiche prefissate.<\/p>\n<p><\/p>\n<p>Apache Kafka memorizza quali sono gli ultimi eventi ricevuti dal consumer (per questo si utilizza il topic di servizio <code>__consumer__offsets<\/code>), garantendo cos\u00ec che, dopo una lettura riuscita, il consumer non riceva lo stesso messaggio due volte. Tuttavia, se si utilizza l'opzione enable.auto.commit = true e si affida completamente a Kafka il monitoraggio della posizione del consumer nel topic, \u00e8 possibile <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.newrelic.com\/engineering\/kafka-consumer-config-auto-commit-data-loss\/\">perdere dati<\/a><\/noindex>. Nel codice di produzione, la posizione del consumer viene di solito gestita manualmente (lo sviluppatore controlla quando deve necessariamente avvenire il commit dell'evento letto).<\/p>\n<p><\/p>\n<p>Nei casi in cui un solo consumer non sia sufficiente (ad esempio, se il flusso di nuovi eventi \u00e8 molto elevato), si possono aggiungere ulteriori consumer, collegandoli insieme in un consumer group. Il consumer group rappresenta logicamente un unico consumer, ma con la distribuzione dei dati tra i membri del gruppo. Questo consente a ciascun membro di prendere la propria parte di messaggi, aumentando cos\u00ec la velocit\u00e0 di lettura. <\/p>\n<p><\/p>\n<h1 id=\"rezultaty-testirovaniya\">Risultati dei test<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka e microservizi: panoramica\" src=\"\/wp-content\/uploads\/2019\/09\/f7abe4bcf34fdb0d762c8a928bd873ee.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Qui non scriver\u00f2 molto testo esplicativo, semplicemente condivider\u00f2 i risultati ottenuti. I test sono stati condotti su 3 macchine fisiche (12 CPU, 384GB RAM, 15k SAS DISK, 10GBit\/s Net), i broker e lo zookeeper sono stati distribuiti in lxc. <\/p>\n<p><\/p>\n<p><strong>Test di prestazioni<\/strong><\/p>\n<p><\/p>\n<p>Durante i test sono stati ottenuti i seguenti risultati.<\/p>\n<p><\/p>\n<ul>\n<li>La velocit\u00e0 di scrittura dei messaggi di dimensioni 1KB con 9 producer contemporaneamente \u00e8 di 1.300.000 eventi al secondo.<\/li>\n<li>La velocit\u00e0 di lettura dei messaggi di dimensioni 1KB con 9 consumer contemporaneamente \u00e8 di 1.500.000 eventi al secondo.<\/li>\n<\/ul>\n<p><\/p>\n<p><strong>Testing della resilienza<\/strong><\/p>\n<p><\/p>\n<p>Durante i test sono stati ottenuti i seguenti risultati (3 broker, 3 zookeeper).<\/p>\n<p><\/p>\n<ul>\n<li>Il crash anomalo di uno dei broker non provoca l'interruzione o l'inaccessibilit\u00e0 del cluster. Il lavoro continua normalmente, ma i broker rimanenti sono sottoposti a un carico maggiore.<\/li>\n<li>La chiusura anomala di due broker in un cluster di tre broker con min.isr = 2 porta all'inaccessibilit\u00e0 del cluster in scrittura, ma \u00e8 accessibile in lettura. Se min.isr = 1, il cluster rimane accessibile sia in lettura che in scrittura. Tuttavia, questa modalit\u00e0 contraddice il requisito di elevata integrit\u00e0 dei dati.<\/li>\n<li>La chiusura anomala di uno dei server Zookeeper non comporta l'arresto o l'inaccessibilit\u00e0 del cluster. Il funzionamento continua normalmente.<\/li>\n<li>La chiusura anomala di due server Zookeeper comporta l'inaccessibilit\u00e0 del cluster fino al ripristino dell'operativit\u00e0 di almeno uno dei server Zookeeper. Questa affermazione \u00e8 valida per un cluster Zookeeper di 3 server. Di conseguenza, dopo alcune ricerche, \u00e8 stato deciso di aumentare il cluster Zookeeper a 5 server per migliorare la resilienza. <br clear=\"left\">\n <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"kafka-as-a-service\">Kafka come servizio<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka e microservizi: panoramica\" src=\"\/wp-content\/uploads\/2019\/09\/19b2356131203cefbadfd90a25ae9674.png\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p><\/p>\n<p>Abbiamo constatato che Kafka \u00e8 una tecnologia eccellente che ci permette di risolvere il compito che ci era stato assegnato (l'implementazione di un broker di messaggi). Tuttavia, abbiamo deciso di impedire ai servizi di accedere direttamente a Kafka e l'abbiamo chiusa tramite un servizio data-bus. Perch\u00e9 abbiamo fatto questo? In realt\u00e0 ci sono diverse ragioni.<\/p>\n<p><\/p>\n<ul>\n<li>\n<p>Il data-bus ha assorbito tutte le attivit\u00e0 relative all'integrazione con Kafka (implementazione e configurazione di consumer e producer, monitoraggio, alerting, logging, scalabilit\u00e0, ecc.). Cos\u00ec, l'integrazione con il broker di messaggi avviene nel modo pi\u00f9 semplice possibile. <\/p>\n<p>\n<\/li>\n<li>\n<p>Il data-bus ha permesso di astrarsi dal linguaggio o dalla libreria specifica per lavorare con Kafka. <\/p>\n<p>\n<\/li>\n<li>\n<p>Il data-bus ha consentito ad altri servizi di astrarsi dallo strato di archiviazione. Potrebbe darsi che, in un certo momento, cambiamo Kafka con Pulsar, senza che nessuno se ne accorga (tutti i servizi conoscono solo l'API del data-bus).<\/p>\n<p>\n<\/li>\n<li>\n<p>Il data-bus si \u00e8 occupato della validazione degli schemi degli eventi.<\/p>\n<p>\n<\/li>\n<li>\n<p>Con il data-bus \u00e8 stata implementata l'autenticazione.<\/p>\n<p>\n<\/li>\n<li>\n<p>Sotto la copertura del data-bus possiamo aggiornare le versioni di Kafka senza downtime, in modo invisibile, gestendo centralmente le configurazioni di producer, consumer, broker, ecc.<\/p>\n<p>\n<\/li>\n<li>\n<p>Il data-bus ha permesso di aggiungere le funzionalit\u00e0 necessarie che non sono presenti in Kafka (come l'audit dei topic, il controllo delle anomalie nel cluster, la creazione di DLQ, ecc.).<\/p>\n<p>\n<\/li>\n<li>\n<p>Il data-bus consente di implementare failover in modo centralizzato per tutti i servizi.<\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Attualmente, per iniziare a inviare eventi al broker di messaggi, \u00e8 sufficiente collegare una piccola libreria al codice del proprio servizio. \u00c8 tutto. Avete la possibilit\u00e0 di scrivere, leggere e scalare con una sola riga di codice. Tutta l'implementazione \u00e8 nascosta da voi, ci\u00f2 che appare all'esterno sono solo alcune manopole per il formato del batch. Sotto il cofano, il servizio data-bus avvia nel Kubernetes il numero necessario di istanze di producer e consumer, fornendo loro la configurazione necessaria, ma tutto questo \u00e8 trasparente per il vostro servizio. <\/p>\n<p><\/p>\n<p>Certo, non esiste una soluzione miracolosa e questo approccio ha le sue limitazioni.<\/p>\n<p><\/p>\n<ul>\n<li>Il data-bus deve essere mantenuto con le proprie forze, a differenza delle librerie di terze parti.<\/li>\n<li>Il data-bus aumenta il numero di interazioni tra i servizi e il broker di messaggi, il che porta a una diminuzione delle prestazioni rispetto a Kafka nudo.<\/li>\n<li>Non tutto pu\u00f2 essere cos\u00ec facilmente nascosto dai servizi, non vogliamo duplicare la funzionalit\u00e0 di KSQL o Kafka Streams nel data-bus, perci\u00f2 a volte \u00e8 necessario consentire ai servizi di accedere direttamente. <\/li>\n<\/ul>\n<p><\/p>\n<p>Nel nostro caso, i vantaggi hanno superato gli svantaggi e la decisione di nascondere il broker di messaggi dietro a un servizio separato si \u00e8 rivelata utile. In un anno di utilizzo non abbiamo avuto seri guasti n\u00e9 problemi.<\/p>\n<p><\/p>\n<p>P.S. Grazie alla mia ragazza, Ekaterina Obalayaeva, per le fantastiche immagini di questo articolo. Se vi sono piaciute, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.instagram.com\/o.k_o.k_\/\">qui<\/a><\/noindex> ce ne saranno ancora di pi\u00f9.<\/p>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/465315\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043f\u043e\u0447\u0435\u043c\u0443 \u043c\u044b \u0432 \u0410\u0432\u0438\u0442\u043e \u0434\u0435\u0432\u044f\u0442\u044c \u043c\u0435\u0441\u044f\u0446\u0435\u0432 \u043d\u0430\u0437\u0430\u0434 \u0432\u044b\u0431\u0440\u0430\u043b\u0438 Kafka, \u0438 \u0447\u0442\u043e \u043e\u043d\u0430 \u0438\u0437 \u0441\u0435\u0431\u044f \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442. \u041f\u043e\u0434\u0435\u043b\u044e\u0441\u044c \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u043a\u0435\u0439\u0441\u043e\u0432 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f \u2014 \u0431\u0440\u043e\u043a\u0435\u0440 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418 \u043d\u0430\u043f\u043e\u0441\u043b\u0435\u0434\u043e\u043a \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a\u0438\u0435 \u043f\u043b\u044e\u0441\u044b \u043c\u044b \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u0438 \u043e\u0442 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u043f\u043e\u0434\u0445\u043e\u0434\u0430 Kafka as a Service. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0414\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0435\u043a\u0441\u0442\u0430. \u041d\u0435\u043a\u043e\u0442\u043e\u0440\u043e\u0435 \u0432\u0440\u0435\u043c\u044f \u043d\u0430\u0437\u0430\u0434 \u043c\u044b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28406,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37849","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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\/it\/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 e microservizi: panoramica | ProHoster","description":"Ciao a tutti.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/37849","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=37849"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/37849\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/28406"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=37849"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=37849"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=37849"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}