Hola Habr!
Us recordem que seguint el llibre sobre hem publicat un treball igualment interessant sobre la biblioteca .
De moment, la comunitat només està aprenent els límits d'aquesta potent eina. Així doncs, recentment s'ha publicat un article, la traducció del qual us volem presentar. Des de la seva pròpia experiència, l'autor explica com convertir Kafka Streams en un emmagatzematge de dades distribuït. Gaudeix de la lectura!
Biblioteca Apache utilitzat a tot el món a les empreses per al processament de fluxos distribuïts a sobre d'Apache Kafka. Un dels aspectes poc apreciats d'aquest marc és que us permet emmagatzemar l'estat local produït a partir del processament de fils.
En aquest article, us explicaré com la nostra empresa va aconseguir aprofitar aquesta oportunitat de manera rendible per desenvolupar un producte per a la seguretat d'aplicacions al núvol. Amb Kafka Streams, vam crear microserveis d'estat compartits, cadascun dels quals serveix com a font d'informació fiable i d'alta disponibilitat sobre l'estat dels objectes del sistema. Per a nosaltres, aquest és un pas endavant tant pel que fa a la fiabilitat com a la facilitat de suport.
Si esteu interessats en un enfocament alternatiu que us permeti utilitzar una única base de dades central per donar suport a l'estat formal dels vostres objectes, llegiu-lo, serà interessant...
Per què vam pensar que era hora de canviar la nostra manera de treballar amb l'estat compartit
Necessitàvem mantenir l'estat de diversos objectes en funció dels informes de l'agent (per exemple: el lloc estava sota atac)? Abans de migrar a Kafka Streams, sovint confiàvem en una única base de dades central (+ API de servei) per a la gestió de l'estat. Aquest enfocament té els seus inconvenients: mantenir la coherència i la sincronització es converteix en un autèntic repte. La base de dades pot convertir-se en un coll d'ampolla o acabar-hi i pateix la imprevisibilitat.
Figura 1: un escenari típic d'estat dividit vist abans de la transició a
Kafka i Kafka Streams: els agents comuniquen les seves opinions mitjançant API, l'estat actualitzat es calcula mitjançant una base de dades central
Coneix Kafka Streams, que facilita la creació de microserveis d'estat compartits
Fa aproximadament un any, vam decidir fer una ullada detinguda als nostres escenaris d'estat compartits per abordar aquests problemes. Immediatament vam decidir provar Kafka Streams: sabem com d'escalable, altament disponible i tolerant a errors és, quina funcionalitat de transmissió rica té (transformacions, incloses les amb estat). Just el que necessitàvem, per no parlar de com de madur i fiable s'ha tornat el sistema de missatgeria a Kafka.
Cadascun dels microserveis amb estat que hem creat es va crear a sobre d'una instància de Kafka Streams amb una topologia bastant simple. Constava de 1) una font 2) un processador amb un magatzem de valor-clau persistent 3) un lavabo:
Figura 2: la topologia predeterminada de les nostres instàncies de transmissió per a microserveis amb estat. Tingueu en compte que també hi ha un repositori aquí que conté metadades de planificació.
En aquest nou enfocament, els agents redacten missatges que s'introdueixen al tema d'origen i els consumidors, per exemple, un servei de notificació de correu, reben l'estat compartit computat a través del lavabo (tema de sortida).
Figura 3: Nou exemple de flux de tasques per a un escenari amb microserveis compartits: 1) l'agent genera un missatge que arriba al tema font de Kafka; 2) un microservei amb estat compartit (utilitzant Kafka Streams) el processa i escriu l'estat calculat al tema final de Kafka; després del qual 3) els consumidors accepten el nou estat
Ei, aquesta botiga de valor-clau integrada és realment molt útil!
Com s'ha esmentat anteriorment, la nostra topologia d'estat compartit conté un magatzem de valor-clau. Hem trobat diverses opcions per utilitzar-lo, i dues d'elles es descriuen a continuació.
Opció 1: utilitzeu un magatzem de valor-clau per als càlculs
El nostre primer magatzem de valor-clau contenia les dades auxiliars que necessitàvem per als càlculs. Per exemple, en alguns casos l'estat compartit estava determinat pel principi de "vots majoritaris". El repositori podria contenir tots els informes més recents de l'agent sobre l'estat d'algun objecte. Aleshores, quan rebíem un informe nou d'un agent o un altre, podríem desar-lo, recuperar informes de tots els altres agents sobre l'estat del mateix objecte des de l'emmagatzematge i repetir el càlcul.
La figura 4 a continuació mostra com vam exposar el magatzem de claus/valors al mètode de processament del processador perquè es pogués processar el nou missatge.
Il·lustració 4: Obrim l'accés al magatzem de valor-clau per al mètode de processament del processador (després d'això, cada script que funcioni amb estat compartit ha d'implementar el mètode doProcess)
Opció 2: crear una API CRUD a la part superior de Kafka Streams
Un cop establert el nostre flux de tasques bàsic, vam començar a intentar escriure una API CRUD RESTful per als nostres microserveis d'estat compartits. Volíem poder recuperar l'estat d'alguns o tots els objectes, així com establir o eliminar l'estat d'un objecte (útil per al suport del backend).
Per donar suport a totes les API de Get State, sempre que havíem de recalcular l'estat durant el processament, l'hem emmagatzemat en una botiga de valor-clau integrada durant molt de temps. En aquest cas, és bastant senzill implementar aquesta API mitjançant una única instància de Kafka Streams, tal com es mostra a la llista següent:
Figura 5: Ús del magatzem de valor-clau integrat per obtenir l'estat precalculat d'un objecte
Actualitzar l'estat d'un objecte mitjançant l'API també és fàcil d'implementar. Bàsicament, tot el que heu de fer és crear un productor de Kafka i utilitzar-lo per fer un disc que contingui el nou estat. Això garanteix que tots els missatges generats a través de l'API es processaran de la mateixa manera que els rebuts d'altres productors (per exemple, agents).
Figura 6: Podeu establir l'estat d'un objecte mitjançant el productor Kafka
Petita complicació: Kafka té moltes particions
A continuació, volíem distribuir la càrrega de processament i millorar la disponibilitat proporcionant un clúster de microserveis d'estat compartit per escenari. La configuració va ser molt fàcil: un cop vam configurar totes les instàncies per executar-se amb el mateix identificador d'aplicació (i els mateixos servidors d'arrencada), gairebé tota la resta es va fer automàticament. També vam especificar que cada tema d'origen constaria de diverses particions, de manera que a cada instància se li podria assignar un subconjunt d'aquestes particions.
També esmentaré que és una pràctica habitual fer una còpia de seguretat de la botiga estatal de manera que, per exemple, en cas de recuperació després d'un error, transferir aquesta còpia a una altra instància. Per a cada botiga estatal a Kafka Streams, es crea un tema replicat amb un registre de canvis (que fa un seguiment de les actualitzacions locals). Així, Kafka dóna suport constantment a la botiga estatal. Per tant, en cas de fallada d'una o altra instància de Kafka Streams, la botiga d'estat es pot restaurar ràpidament en una altra instància, on aniran les particions corresponents. Les nostres proves han demostrat que això es fa en qüestió de segons, encara que hi hagi milions de discos a la botiga.
Passant d'un únic microservei amb estat compartit a un clúster de microserveis, es fa menys trivial implementar l'API Get State. En la nova situació, el magatzem d'estat de cada microservei conté només una part de la imatge general (aquells objectes les claus dels quals s'han assignat a una partició específica). Vam haver de determinar quina instància contenia l'estat de l'objecte que necessitàvem, i ho vam fer en funció de les metadades del fil, com es mostra a continuació:
Figura 7: Utilitzant metadades de flux, determinem des de quina instància consultar l'estat de l'objecte desitjat; es va utilitzar un enfocament similar amb l'API GET ALL
Principals conclusions
Les botigues estatals a Kafka Streams poden servir com a base de dades distribuïda de facto,
- repetida constantment a Kafka
- Una API CRUD es pot construir fàcilment a sobre d'aquest sistema
- La gestió de diverses particions és una mica més complicat
- També és possible afegir un o més magatzems d'estat a la topologia de streaming per emmagatzemar dades auxiliars. Aquesta opció es pot utilitzar per a:
- Emmagatzematge a llarg termini de les dades necessàries per als càlculs durant el processament del flux
- Emmagatzematge a llarg termini de dades que poden ser útils la propera vegada que es subministra la instància de transmissió
- molt més...
Aquests i altres avantatges fan que Kafka Streams sigui molt adequat per mantenir l'estat global en un sistema distribuït com el nostre. Kafka Streams ha demostrat ser molt fiable a la producció (pràcticament no hem tingut cap pèrdua de missatges des del desplegament) i estem segurs que les seves capacitats no s'aturaran aquí!
Font: www.habr.com