{"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\/es\/blog\/administrirovanie\/ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo","title":{"rendered":"No solo procesamiento: C\u00f3mo convertimos Kafka Streams en una base de datos distribuida y qu\u00e9 result\u00f3 de ello","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00a1Hola, Habr!<\/p>\n

Recordamos que, despu\u00e9s del libro sobre Kafka<\/a><\/noindex> hemos publicado una obra igualmente interesante sobre la biblioteca Kafka Streams API<\/a><\/noindex>. <\/p>\n

\"No
\n
\nMientras la comunidad a\u00fan explora los l\u00edmites de las capacidades de esta poderosa herramienta. Recientemente se public\u00f3 un art\u00edculo con el que queremos familiarizarles. En su propia experiencia, el autor narra c\u00f3mo convertir Kafka Streams en un almac\u00e9n de datos distribuido. \u00a1Disfruten la lectura!
\n<\/a><\/noindex>
\nLa biblioteca Apache Kafka Streams<\/a><\/noindex> se utiliza en todo el mundo en empresas para el procesamiento de flujos distribuidos sobre Apache Kafka. Uno de los aspectos infravalorados de este marco es que permite almacenar un estado local, generado a partir del procesamiento de flujos.<\/p>\n

En este art\u00edculo, contar\u00e9 c\u00f3mo nuestra empresa logr\u00f3 aprovechar esta posibilidad de manera rentable en el desarrollo de un producto de seguridad para aplicaciones en la nube. Con la ayuda de Kafka Streams, creamos microservicios con estado compartido, cada uno de los cuales sirve como una fuente confiable y altamente disponible de informaci\u00f3n sobre el estado de los objetos en el sistema. Para nosotros, esto representa un avance tanto en t\u00e9rminos de confiabilidad como en la facilidad de mantenimiento.<\/p>\n

Si te interesa un enfoque alternativo que permita utilizar una \u00fanica base de datos central para mantener el estado formal de tus objetos, sigue leyendo, ser\u00e1 interesante... <\/p>\n

Por qu\u00e9 consideramos que lleg\u00f3 el momento de cambiar nuestros enfoques sobre la gesti\u00f3n del estado compartido <\/b><\/p>\n

Necesit\u00e1bamos mantener el estado de varios objetos, bas\u00e1ndonos en informes de agentes (por ejemplo: \u00bfel sitio fue atacado?). Antes de cambiar a Kafka Streams, a menudo depend\u00edamos de una \u00fanica base de datos central (+ API de servicio) para gestionar el estado. Este enfoque tiene sus desventajas: en situaciones intensivas en datos<\/a><\/noindex> el mantenimiento de la consistencia y sincronizaci\u00f3n se convierte en un verdadero desaf\u00edo. La base de datos puede convertirse en un cuello de botella, o verse en una condici\u00f3n de carrera<\/a><\/noindex> y sufrir impredecibilidad.<\/p>\n

\"No
\n
\nIlustraci\u00f3n 1: un escenario t\u00edpico de separaci\u00f3n de estado que se experiment\u00f3 antes de la transici\u00f3n a
\nKafka y Kafka Streams: los agentes informan sus perspectivas a trav\u00e9s de una API, el estado actualizado se calcula a trav\u00e9s de una base de datos central <\/i><\/p>\n

Conozcan Kafka Streams: ahora es f\u00e1cil crear microservicios con estado compartido <\/b><\/p>\n

Hace aproximadamente un a\u00f1o, decidimos revisar a fondo nuestros escenarios de trabajo con estado compartido para abordar ciertos problemas. Inmediatamente decidimos probar Kafka Streams, dado lo escalable, altamente disponible y tolerante a fallos que es, y su rico conjunto de funcionalidades de flujo (transformaciones, incluidas, con estado). Justo lo que necesit\u00e1bamos, sin mencionar cu\u00e1n madura y confiable se ha vuelto la sistema de mensajer\u00eda en Kafka.<\/p>\n

Cada uno de los microservicios con estado que creamos se construy\u00f3 sobre una instancia de Kafka Streams con una topolog\u00eda bastante simple. Consist\u00eda en 1) una fuente, 2) un procesador con almacenamiento persistente de claves y valores, 3) un sumidero:<\/p>\n

\"No
\n
\nIlustraci\u00f3n 2: la topolog\u00eda por defecto de nuestras instancias de flujo para microservicios con estado. Tenga en cuenta: aqu\u00ed tambi\u00e9n hay un almacenamiento que contiene metadatos sobre la planificaci\u00f3n. <\/i><\/p>\n

Con este nuevo enfoque, los agentes generan mensajes que se env\u00edan al t\u00f3pico de origen, y los consumidores \u2014 digamos, el servicio de notificaciones por correo \u2014 reciben el estado compartido calculado a trav\u00e9s del sumidero (t\u00f3pico de salida).<\/p>\n

\"No
\n
\nIlustraci\u00f3n 3: un nuevo ejemplo de flujo de tareas para un escenario con microservicios compartidos: 1) el agente genera un mensaje que llega al t\u00f3pico de origen de Kafka; 2) el microservicio con estado compartido (que utiliza Kafka Streams) lo procesa y escribe el estado calculado en el t\u00f3pico final de Kafka; despu\u00e9s, 3) los consumidores reciben el nuevo estado.<\/i><\/p>\n

\u00a1Hey, y este almacenamiento integrado de claves y valores es realmente muy \u00fatil!<\/b><\/p>\n

Como se mencion\u00f3 anteriormente, nuestra topolog\u00eda con estado compartido incluye un almacenamiento de claves y valores. Encontramos varias formas de utilizarlo, y dos de ellas se describen a continuaci\u00f3n.<\/p>\n

Opci\u00f3n #1: uso del almacenamiento de claves y valores durante los c\u00e1lculos.<\/b><\/i><\/p>\n

Nuestro primer almac\u00e9n de claves y valores conten\u00eda datos auxiliares que necesit\u00e1bamos para los c\u00e1lculos. Por ejemplo, en algunos casos, el estado compartido se determin\u00f3 por el principio de \"mayor\u00eda de votos\". En el almac\u00e9n pod\u00edamos mantener todos los \u00faltimos informes de los agentes sobre el estado de un determinado objeto. Luego, al recibir un nuevo informe de uno u otro agente, pod\u00edamos guardarlo, extraer del almac\u00e9n los informes de todos los dem\u00e1s agentes sobre el mismo objeto y repetir el c\u00e1lculo.
\nA continuaci\u00f3n, en la ilustraci\u00f3n 4 se muestra c\u00f3mo abrimos el acceso al almac\u00e9n de claves y valores al m\u00e9todo procesador, de modo que luego se pudiera procesar un nuevo mensaje.<\/p>\n

\"No
\n
\nIlustraci\u00f3n 4: abrimos el acceso al almac\u00e9n de claves y valores para el m\u00e9todo procesador (despu\u00e9s de esto, en cada escenario que trabaje con estado compartido, es necesario implementar el m\u00e9todo doProcess<\/code>)<\/i><\/p>\n

Opci\u00f3n #2: crear una API CRUD sobre Kafka Streams<\/b><\/i><\/p>\n

Al establecer nuestro flujo b\u00e1sico de tareas, comenzamos a intentar escribir una API RESTful CRUD para nuestros microservicios con estado compartido. Quer\u00edamos poder extraer el estado de algunos o todos los objetos, as\u00ed como establecer o eliminar el estado de un objeto (lo cual es \u00fatil para mantener la parte del servidor).<\/p>\n

Para admitir todas las API Get State, cada vez que necesit\u00e1bamos recalcular el estado durante el procesamiento, lo almacen\u00e1bamos temporalmente en un almac\u00e9n de claves y valores incorporado. En tal caso, es bastante sencillo implementar dicha API utilizando una \u00fanica instancia de Kafka Streams, como se muestra en el listado siguiente:<\/p>\n

\"No
\n
\nIlustraci\u00f3n 5: utilizaci\u00f3n del almac\u00e9n de claves y valores incorporado para obtener el estado precalculado de un objeto <\/i><\/p>\n

Actualizar el estado de un objeto a trav\u00e9s de la API tambi\u00e9n es f\u00e1cil de implementar. En principio, solo es necesario crear un productor de Kafka y, con \u00e9l, hacer una escritura que contenga el nuevo estado. Esto garantiza que todos los mensajes generados a trav\u00e9s de la API se procesen exactamente de la misma manera que los que provienen de otros productores (por ejemplo, agentes).<\/p>\n

\"No
\n
\nIlustraci\u00f3n 6: se puede establecer el estado de un objeto mediante un productor de Kafka <\/i><\/p>\n

Un peque\u00f1o inconveniente: Kafka tiene muchas particiones<\/b><\/p>\n

A continuaci\u00f3n, quer\u00edamos distribuir la carga relacionada con el procesamiento y mejorar la disponibilidad, proporcionando un cl\u00faster de microservicios con un estado compartido para cada escenario. La configuraci\u00f3n fue muy sencilla: despu\u00e9s de configurar todas las instancias para que trabajaran con el mismo ID de aplicaci\u00f3n (y los mismos servidores de arranque inicial), pr\u00e1cticamente todo lo dem\u00e1s se hac\u00eda de forma autom\u00e1tica. Tambi\u00e9n determinamos que cada t\u00f3pico de origen constar\u00eda de varias particiones, para que a cada instancia se le pudiera asignar un subconjunto de estas particiones.<\/p>\n

Tambi\u00e9n cabe mencionar que aqu\u00ed es habitual hacer una copia de seguridad del almacenamiento de estados, para que, en caso de recuperaci\u00f3n de fallos, esta copia se pueda mover a otra instancia. Para cada almacenamiento de estados en Kafka Streams se crea un t\u00f3pico replicable con un registro de cambios (donde se rastrean las actualizaciones locales). As\u00ed, Kafka siempre respalda el almacenamiento de estados. Por lo tanto, si una instancia de Kafka Streams falla, el almacenamiento de estados puede ser restaurado r\u00e1pidamente en otra instancia, a la que se trasladar\u00e1n las particiones correspondientes. Nuestros tests mostraron que esto se realiza en cuesti\u00f3n de segundos, incluso si el almacenamiento contiene millones de registros.<\/p>\n

Al pasar de un microservicio con estado compartido a un cl\u00faster de microservicios, la implementaci\u00f3n del Get State API se vuelve menos trivial. En la nueva situaci\u00f3n, el almacenamiento de estados de cada microservicio contiene solo una parte del panorama general (los objetos cuyos claves se asignan a una partici\u00f3n espec\u00edfica). Era necesario determinar en qu\u00e9 instancia se encontraba el estado del objeto que necesit\u00e1bamos, y lo hac\u00edamos bas\u00e1ndonos en los metadatos de los flujos, como se muestra a continuaci\u00f3n:<\/p>\n

\"No
\n
\nIlustraci\u00f3n 7: mediante metadatos de flujos, determinamos de qu\u00e9 instancia solicitar el estado del objeto requerido; este enfoque se aplic\u00f3 con el GET ALL API.<\/i><\/p>\n

Conclusiones Principales<\/b><\/p>\n

Los almacenes de estados en Kafka Streams pueden servir de facto como una base de datos distribuida, <\/p>\n