{"id":32632,"date":"2019-10-31T21:48:08","date_gmt":"2019-10-31T18:48:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo\/"},"modified":"2019-10-31T21:48:08","modified_gmt":"2019-10-31T18:48:08","slug":"ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo","title":{"rendered":"Non solo elaborazione: Come abbiamo trasformato Kafka Streams in un database distribuito e cosa \u00e8 successo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, Habr!<\/p>\n

Ricordiamo che, a seguito del libro su Kafka<\/a><\/noindex> abbiamo pubblicato un'opera altrettanto interessante sulla libreria Kafka Streams API<\/a><\/noindex>. <\/p>\n

\"Non
\n
\nMentre la comunit\u00e0 sta ancora esplorando i confini delle possibilit\u00e0 di questo potente strumento. Recentemente \u00e8 stato pubblicato un articolo, di cui vogliamo presentarvi la traduzione. L'autore, basandosi sulla propria esperienza, racconta come trasformare Kafka Streams in uno storage distribuito. Buona lettura!
\n<\/a><\/noindex>
\nLa libreria Apache Kafka Streams<\/a><\/noindex> \u00e8 utilizzata in tutto il mondo nelle aziende per l'elaborazione distribuita in tempo reale sopra Apache Kafka. Uno degli aspetti sottovalutati di questo framework \u00e8 che consente di mantenere uno stato locale, prodotto sulla base dell'elaborazione dei flussi.<\/p>\n

In questo articolo vi racconter\u00f2 come la nostra azienda \u00e8 riuscita a sfruttare questa opportunit\u00e0 nella progettazione di un prodotto per la sicurezza delle applicazioni cloud. Con Kafka Streams abbiamo creato microservizi con stato condiviso, ciascuno dei quali funge da fonte di informazioni affidabili e ad alta disponibilit\u00e0 sullo stato degli oggetti nel sistema. Per noi \u00e8 un passo avanti sia in termini di affidabilit\u00e0 che di facilit\u00e0 di manutenzione.<\/p>\n

Se siete interessati a un approccio alternativo che consenta di utilizzare un'unica centrale di dati per gestire lo stato formale dei vostri oggetti, leggete, sar\u00e0 interessante\u2026 <\/p>\n

Perch\u00e9 riteniamo che sia giunto il momento di cambiare il nostro approccio nella gestione dello stato condiviso <\/b><\/p>\n

Dovevamo mantenere lo stato di vari oggetti, basandoci sui rapporti degli agenti (ad esempio: il sito ha subito un attacco?). Prima di passare a Kafka Streams, spesso ci affidavamo a un'unica centrale di dati (+ API di servizio) per gestire lo stato. Questo approccio ha i suoi svantaggi: in situazioni ad alta intensit\u00e0 di dati<\/a><\/noindex> il mantenimento della coerenza e della sincronizzazione diventa una vera sfida. Il database pu\u00f2 diventare un collo di bottiglia, oppure trovandosi in stato di competizione<\/a><\/noindex> e soffrire di imprevedibilit\u00e0.<\/p>\n

\"Non
\n
\nIllustrazione 1: uno scenario tipico di separazione dello stato, riscontrato prima del passaggio a
\nKafka e Kafka Streams: gli agenti riportano le loro visioni attraverso l'API, lo stato aggiornato viene calcolato tramite una centrale di dati <\/i><\/p>\n

Incontrate Kafka Streams - ora \u00e8 facile creare microservizi con stato condiviso <\/b><\/p>\n

Circa un anno fa abbiamo deciso di rivedere approfonditamente i nostri scenari di lavoro con stati condivisi, per affrontare tali problematiche. Abbiamo subito deciso di provare Kafka Streams \u2013 noto per la sua scalabilit\u00e0, alta disponibilit\u00e0 e robustezza, e per la ricca funzionalit\u00e0 di streaming che offre (trasformazioni, incluso il mantenimento dello stato). Proprio ci\u00f2 di cui avevamo bisogno, senza contare quanto sia matura e affidabile sia diventata nel tempo la rete di messaggistica in Kafka.<\/p>\n

Ognuno dei microservizi con mantenimento dello stato che abbiamo creato \u00e8 stato costruito su un'istanza di Kafka Streams con una topologia piuttosto semplice. Essa consisteva in 1) una sorgente 2) un processore con un archivio permanente di chiavi e valori 3) un flusso:<\/p>\n

\"Non
\n
\nIllustrazione 2: la topologia predefinita dei nostri istanze di flusso per i microservizi con mantenimento dello stato. Si prega di notare: qui c'\u00e8 anche un archivio che contiene i metadati riguardanti la pianificazione. <\/i><\/p>\n

Con questo nuovo approccio, gli agenti creano i messaggi inviati nel topic sorgente, mentre i consumatori \u2013 ad esempio, un servizio di notifica via email \u2013 ricevono lo stato condiviso calcolato attraverso il flusso (topic di uscita).<\/p>\n

\"Non
\n
\nIllustrazione 3: un nuovo esempio del flusso di lavoro per uno scenario con microservizi condivisi: 1) l'agente genera un messaggio che arriva nel topic sorgente di Kafka; 2) il microservizio con stato condiviso (che utilizza Kafka Streams) lo elabora e scrive lo stato calcolato nel topic di destinazione di Kafka; quindi 3) i consumatori ricevono il nuovo stato.<\/i><\/p>\n

Ehi, questo archivio integrato di chiavi e valori \u00e8 davvero molto utile!<\/b><\/p>\n

Come menzionato in precedenza, la nostra topologia con stato condiviso contiene un archivio di chiavi e valori. Abbiamo trovato diversi usi per esso, e due di questi sono descritti di seguito.<\/p>\n

Opzione #1: utilizzo dell'archivio di chiavi e valori durante i calcoli.<\/b><\/i><\/p>\n

Il nostro primo archivio di chiavi e valori conteneva dati ausiliari necessari per i nostri calcoli. Ad esempio, in alcuni casi, lo stato condiviso veniva determinato secondo il principio della \"maggioranza dei voti\". Nell'archivio si potevano mantenere tutti gli ultimi rapporti degli agenti sullo stato di un certo oggetto. Poi, ricevendo un nuovo rapporto da uno degli agenti, potevamo salvarlo, estrarre dall'archivio i rapporti di tutti gli altri agenti sullo stesso oggetto e ripetere il calcolo.
\nDi seguito, nell'illustrazione 4, si mostra come abbiamo aperto l'accesso all'archivio di chiavi e valori al metodo di elaborazione del processore, in modo da poter gestire un nuovo messaggio.<\/p>\n

\"Non
\n
\nIllustrazione 4: apertura dell'accesso all'archivio di chiavi e valori per il metodo di elaborazione del processore (dopo questo, in ogni scenario che lavora con stato condiviso, \u00e8 necessario implementare il metodo doProcess<\/code>)<\/i><\/p>\n

Opzione #2: creazione di un'API CRUD sopra Kafka Streams<\/b><\/i><\/p>\n

Dopo aver configurato il nostro flusso di lavoro di base, abbiamo iniziato a sviluppare un'API RESTful CRUD per i nostri microservizi con stato condiviso. Volevamo poter estrarre lo stato di alcuni o tutti gli oggetti, cos\u00ec come impostare o rimuovere lo stato di un oggetto (utile per il supporto della parte server).<\/p>\n

Per supportare tutte le API Get State, ogni volta che avevamo bisogno di ricalcolare lo stato durante l'elaborazione, lo memorizzavamo a lungo nello storage incorporato chiave-valore. In tal caso, \u00e8 sufficiente implementare un'API usando un'unica istanza di Kafka Streams, come mostrato nel listing sottostante:<\/p>\n

\"Non
\n
\nIllustrazione 5: utilizzo dello storage incorporato chiave-valore per ottenere lo stato pre-calcolato di un oggetto <\/i><\/p>\n

Aggiornare lo stato di un oggetto tramite API non \u00e8 difficile da realizzare. In sostanza, \u00e8 sufficiente creare un produttore Kafka e utilizzarlo per registrare un nuovo stato. In questo modo si garantisce che tutti i messaggi generati tramite API vengano elaborati esattamente come quelli provenienti da altri produttori (ad esempio, agenti).<\/p>\n

\"Non
\n
\nIllustrazione 6: \u00e8 possibile definire lo stato dell'oggetto utilizzando il produttore Kafka <\/i><\/p>\n

Una piccola complicazione: Kafka ha molte partizioni<\/b><\/p>\n

In seguito volevamo distribuire il carico associato all'elaborazione e migliorare la disponibilit\u00e0, fornendo a ciascun scenario un cluster di microservizi con stato condiviso. La configurazione \u00e8 stata estremamente semplice: una volta configurati tutti gli istanze per lavorare con lo stesso ID dell'applicazione (e con gli stessi server di avvio), praticamente il resto \u00e8 avvenuto automaticamente. Abbiamo anche specificato che ogni topic sorgente sarebbe composto da pi\u00f9 partizioni, in modo che a ciascuna istanza potesse essere assegnato un sottoinsieme di queste partizioni.<\/p>\n

Voglio anche menzionare che \u00e8 comune qui eseguire il backup dello stato di archiviazione, in modo da poter trasferire questa copia su un altro istanza in caso di ripristino. Per ogni stato di archiviazione in Kafka Streams, viene creato un topic replicabile con un registro delle modifiche (che tiene traccia degli aggiornamenti locali). In questo modo, Kafka garantisce continuamente la sicurezza dello stato di archiviazione. Pertanto, in caso di guasto di un'istanza di Kafka Streams, lo stato di archiviazione pu\u00f2 essere rapidamente ripristinato su un'altra istanza, dove andranno le relative partizioni. I nostri test hanno dimostrato che questo avviene in pochi secondi, anche se ci sono milioni di record nello stato di archiviazione.<\/p>\n

Passando da un microservizio con stato condiviso a un cluster di microservizi, non \u00e8 cos\u00ec banale implementare il Get State API. In questa nuova situazione, nel repository di stato di ogni microservizio \u00e8 contenuta solo una parte del quadro generale (quegli oggetti i cui chiavi erano mappati su una specifica partizione). Era necessario determinare su quale istanza fosse contenuto lo stato dell'oggetto richiesto, e lo facevamo basandoci sui metadati dei flussi, come mostrato di seguito:<\/p>\n

\"Non
\n
\nIllustrazione 7: utilizzando i metadati dei flussi, identifichiamo da quale istanza richiedere lo stato dell'oggetto desiderato; un approccio simile \u00e8 stato utilizzato con il GET ALL API<\/i><\/p>\n

Conclusioni principali<\/b><\/p>\n

I repository di stato in Kafka Streams possono di fatto fungere da database distribuito, <\/p>\n