{"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 quale risultato abbiamo ottenuto","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, Habr!<\/p>\n

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

\"Non
\n
\nMentre la comunit\u00e0 sta ancora esplorando i limiti delle capacit\u00e0 di questo potente strumento. Recentemente \u00e8 stato pubblicato un articolo di cui vogliamo presentarvi la traduzione. Con la propria esperienza, l'autore racconta come trasformare Kafka Streams in un sistema di archiviazione distribuita dei dati. Buona lettura!
\n<\/a><\/noindex>
\nLa biblioteca Apache Kafka Streams<\/a><\/noindex> \u00e8 utilizzata in tutto il mondo nel settore enterprise per l'elaborazione distribuita in streaming sopra Apache Kafka. Uno degli aspetti sottovalutati di questo framework \u00e8 che consente di memorizzare stati locali, generati sulla base dell'elaborazione in streaming.<\/p>\n

In questo articolo spiegher\u00f2 come nella nostra azienda siamo riusciti a sfruttare favorevolmente questa possibilit\u00e0 nello sviluppo di un prodotto per la sicurezza delle applicazioni cloud. Con Kafka Streams abbiamo creato microservizi con stato condiviso, ognuno dei quali funge da fonte resiliente e altamente disponibile di informazioni affidabili sullo stato degli oggetti nel sistema. Per noi \u00e8 un passo avanti sia in termini di affidabilit\u00e0 che di facilit\u00e0 di supporto.<\/p>\n

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

Perch\u00e9 abbiamo ritenuto che fosse giunto il momento di cambiare il nostro approccio al lavoro con stati condivisi <\/b><\/p>\n

Avevamo la necessit\u00e0 di mantenere lo stato di diversi oggetti, basandoci sulle segnalazioni degli agenti (ad esempio: il sito \u00e8 stato attaccato?). Prima di passare a Kafka Streams, spesso ci affidavamo a un'unica base di dati centrale (+ API del servizio) per gestire lo stato. Questo approccio ha i suoi svantaggi: in situazioni ad alta intensit\u00e0 di dati<\/a><\/noindex> mantenere la coerenza e la sincronizzazione diventa una vera sfida. Il database pu\u00f2 diventare un collo di bottiglia o trovarsi in uno 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 di passare a
\nKafka e Kafka Streams: gli agenti comunicano le loro rappresentazioni tramite l'API, lo stato aggiornato viene calcolato attraverso il database centrale <\/i><\/p>\n

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

Circa un anno fa abbiamo deciso di rivedere attentamente i nostri scenari di lavoro con lo stato condiviso, per affrontare tali problematiche. Abbiamo subito deciso di provare Kafka Streams \u2013 \u00e8 nota la sua scalabilit\u00e0, alta disponibilit\u00e0 e resilienza, oltre all'ampia gamma di funzionalit\u00e0 di streaming (trasformazioni, inclusa la conservazione dello stato). Proprio ci\u00f2 che ci serviva, senza contare quanto fosse matura e affidabile la sistema di messaggistica che si \u00e8 sviluppata in Kafka.<\/p>\n

Ciascuno dei microservizi con stato condiviso che abbiamo creato si basava su un'istanza di Kafka Streams con una topologia piuttosto semplice. Era composta da 1) una sorgente 2) un processore con uno storage persistente di chiavi e valori 3) uno scarico:<\/p>\n

\"Non
\n
\nIllustrazione 2: la topologia predefinita delle nostre istanze di flusso per i microservizi con stato condiviso. Nota: qui c'\u00e8 anche uno storage che contiene i metadati sulla pianificazione. <\/i><\/p>\n

Con questo nuovo approccio, gli agenti compongono i messaggi inviati al topic di origine, mentre i consumatori \u2013 ad esempio, il servizio di notifiche via email \u2013 ricevono lo stato condiviso calcolato tramite lo scarico (topic in uscita).<\/p>\n

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

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

Come accennato in precedenza, la nostra topologia con stato condiviso include uno storage di chiavi e valori. Abbiamo trovato diverse modalit\u00e0 di utilizzo, e due di esse sono descritte di seguito.<\/p>\n

Opzione #1: utilizzo dello storage 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 era possibile tenere tutti gli ultimi rapporti degli agenti sullo stato di un certo oggetto. Poi, ricevuto un nuovo rapporto da un agente, potevamo salvarlo, estrarre dall'archivio i rapporti di tutti gli altri agenti sullo stato dello stesso oggetto e ripetere il calcolo.
\nDi seguito, nell'illustrazione 4, viene mostrato come abbiamo aperto l'accesso all'archivio di chiavi e valori al metodo di elaborazione del processore, in modo da poter elaborare un nuovo messaggio.<\/p>\n

\"Non
\n
\nIllustrazione 4: apriamo l'accesso all'archivio di chiavi e valori per il metodo di elaborazione del processore (dopo di che, in ogni scenario che lavora con stati condivisi, \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 impostato il nostro flusso di lavoro di base, abbiamo provato a scrivere un'API RESTful CRUD per i nostri microservizi con stati condivisi. Volevamo poter estrarre lo stato di alcuni o tutti gli oggetti, oltre a impostare o rimuovere lo stato di un oggetto (ci\u00f2 \u00e8 utile per il supporto del backend).<\/p>\n

Per supportare tutte le API Get State, ogni volta che era necessario ricalcolare lo stato durante l'elaborazione, lo archiviavamo a lungo nel nostro archivio integrato di chiavi e valori. In questo caso, diventa piuttosto semplice implementare tale API con un'unica istanza di Kafka Streams, come mostrato nel listato seguente:<\/p>\n

\"Non
\n
\nIllustrazione 5: utilizzo dell'archivio integrato di chiavi e valori per ottenere lo stato pre-calcolato di un oggetto <\/i><\/p>\n

L'aggiornamento dello stato di un oggetto tramite API \u00e8 anche facile da implementare. In sostanza, per fare ci\u00f2 \u00e8 necessario solo creare un produttore Kafka e utilizzare questo per effettuare una scrittura contenente il nuovo stato. Questo garantisce che tutti i messaggi generati tramite l'API vengano elaborati esattamente come quelli provenienti da altri produttori (ad es. agenti).<\/p>\n

\"Non
\n
\nIllustrazione 6: \u00e8 possibile impostare lo stato di un oggetto utilizzando un produttore Kafka <\/i><\/p>\n

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

Successivamente, volevamo distribuire il carico relativo all'elaborazione e migliorare l'accessibilit\u00e0, fornendo un cluster di microservizi con stato condiviso per ciascun scenario. La configurazione si \u00e8 rivelata molto semplice: dopo aver configurato tutte le istanze affinch\u00e9 funzionassero con lo stesso ID dell'applicazione (e con gli stessi server di avvio), praticamente tutto il resto \u00e8 stato fatto automaticamente. Abbiamo anche specificato che ogni topic sorgente sarebbe consistito in pi\u00f9 partizioni, in modo che a ciascuna istanza potesse essere assegnato un sottoinsieme di queste partizioni.<\/p>\n

Voglio anche menzionare che qui \u00e8 normale eseguire un backup dello stato, in modo che, ad esempio, nel caso di un ripristino dopo un guasto, si possa trasferire questo backup su un'altra istanza. Per ogni stato in Kafka Streams viene creato un topic replicabile con un log delle modifiche (che tiene traccia degli aggiornamenti locali). In questo modo, Kafka offre continuamente una protezione allo stato. Pertanto, in caso di guasto di una particolare istanza, lo stato di Kafka Streams pu\u00f2 essere rapidamente ripristinato su un'altra istanza, a cui andranno le corrispondenti partizioni. I nostri test hanno mostrato che questo avviene in pochi secondi, anche se nello stato ci sono milioni di registrazioni.<\/p>\n

Passando da un microservizio con stato condiviso a un cluster di microservizi, diventa meno banale implementare l'API Get State. Nella nuova situazione, lo stato di ciascun microservizio contiene solo una parte del quadro generale (quegli oggetti i cui chiavi erano assegnati a una specifica partizione). Dobbiamo determinare su quale istanza fosse contenuto lo stato dell'oggetto di nostro interesse, e lo facciamo sulla base dei metadati dei flussi, come mostrato di seguito:<\/p>\n

\"Non
\n
\nIllustrazione 7: utilizzando i metadati dei flussi, definiamo da quale istanza richiedere lo stato dell'oggetto desiderato; questo approccio \u00e8 stato applicato con l'API GET ALL<\/i><\/p>\n

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

Gli stati in Kafka Streams possono di fatto fungere da database distribuito, <\/p>\n