{"id":20985,"date":"2019-07-09T10:52:37","date_gmt":"2019-07-09T08:52:37","guid":{"rendered":"https:\/\/www.teldat.com\/sin-categorizar\/20985\/mensajes-para-aplicaciones-de-microservicios\/"},"modified":"2022-12-19T18:59:39","modified_gmt":"2022-12-19T16:59:39","slug":"mensajes-para-aplicaciones-de-microservicios","status":"publish","type":"post","link":"https:\/\/www.teldat.com\/es\/blog\/mensajes-para-aplicaciones-de-microservicios\/","title":{"rendered":"\u00bfPor qu\u00e9 Apache Kafka?"},"content":{"rendered":"<p><img decoding=\"async\" class=\"alignleft wp-image-5312 size-medium\" src=\"https:\/\/www.teldat.com\/wp-content\/uploads\/2022\/06\/Iago-Fernandez-Julio-2019-300x200.jpg\" alt=\"software\" width=\"300\" height=\"200\" title=\"\">Hoy en d\u00eda un gran n\u00famero de aplicaciones siguen una <strong>arquitectura basada en microservicios<\/strong>. Adem\u00e1s, muchas aplicaciones manejan grandes cantidades de datos (actividad de los usuarios sobre la aplicaci\u00f3n, logs, m\u00e9tricas&#8230;) que viajan constantemente entre microservicios. Esto puede derivar en una serie de problemas a la hora de integrar toda esta informaci\u00f3n, como la sincronizaci\u00f3n, escalado o procesado de los datos.<\/p>\n<p><!--more--><\/p>\n<p>Una posible soluci\u00f3n ser\u00eda aplicar un sistema de mensajer\u00eda tradicional, como las colas o el patr\u00f3n publicar-suscribir. En el caso de las colas cada mensaje es le\u00eddo por un consumidor, permitiendo el escalado, mientras que en publicar-suscribir el mensaje se env\u00eda a todos los consumidores suscritos, por lo que no permite escalado. Ambos sistemas carecen adem\u00e1s de una garant\u00eda en el orden de consumo de los mensajes.<\/p>\n<p>Por lo tanto, es necesario algo que nos garantice mayor fiabilidad y seguridad a la hora de leer mensajes. Es aqu\u00ed donde entra en juego <strong>Apache Kafka,<\/strong> un sistema distribuido y redundante de gesti\u00f3n de eventos desarrollado inicialmente por LinkedIn en 2011. Kafka permite combinar las ventajas de las colas y publicar-suscribir, adem\u00e1s de garantizar el consumo ordenado de los mensajes.<\/p>\n<p>Podemos resumir las<strong> principales ventajas de Kafka<\/strong> en los siguientes puntos:<\/p>\n<p>\u25cf Permite<strong> m\u00faltiples consumidores y productores.<\/strong> Los denominados grupos de consumidores permiten consumir un mismo mensaje por varios consumidores.<\/p>\n<p>\u25cf Garantiza el <strong>orden de los mensajes consumidos<\/strong>.<\/p>\n<p>\u25cf<strong> Retiene temporalmente los datos<\/strong> en disco. Los mensajes no se eliminan tras ser consumidos, sino que se mantienen en el disco hasta que se cumple la pol\u00edtica de retenci\u00f3n definida por el usuario, bien durante un per\u00edodo de tiempo espec\u00edfico o tras alcanzar una determinada capacidad.<\/p>\n<p>\u25cf Es <strong>escalable<\/strong>, tanto vertical como horizontalmente, proporcionando resistencia a fallos.<\/p>\n<p>\u25cf <strong>Proporciona un alto rendimiento<\/strong>, permite gestionar grandes cantidades de datos de manera diaria en aplicaciones en tiempo real.<br \/>\nKafka dispone de varios clientes para gran cantidad de lenguajes, como Java, Python o Node.js, facilitando la comunicaci\u00f3n entre aplicaciones escritas en distintos lenguajes.<\/p>\n<h2>\u00bfC\u00f3mo funciona?<\/h2>\n<p>Apache Kafka basa su funcionamiento en una serie de elementos fundamentales:<\/p>\n<p><strong>Mensajes o records:<\/strong> La unidad m\u00ednima de informaci\u00f3n en Kafka es el mensaje, un array de bytes sin formato espec\u00edfico equivalente a una tupla en base de datos, por lo que puede emplearse para transmitir mensajes entre microservicios escritos en diferentes lenguajes. Cada mensaje almacena un entero (offset) entre sus metadatos que lo identifica de manera inequ\u00edvoca.<\/p>\n<p>Es habitual definir un esquema para estos mensajes de modo que se facilite su lectura y proporcione consistencia, como Json o XML.<\/p>\n<p><strong>Topics y particiones:<\/strong> Los mensajes de Kafka son clasificados en topics, siendo un topic an\u00e1logo a una tabla en base de datos. A su vez un topic se divide en particiones, en donde se almacenan los mensajes en orden de llegada con un offset, garantizando as\u00ed el orden cronol\u00f3gico de los mensajes en una partici\u00f3n, pero no para un mismo topic.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Brokers y clusters:<\/strong> Un broker es un servidor de Kafka, encargado de recibir los mensajes de los productores y commitearlos en logs, la estructura de almacenamiento en disco empleada por Kafka. Tambi\u00e9n se encarga de gestionar las peticiones de los consumidores. Un cluster no es m\u00e1s que un grupo de brokers, en donde uno de ellos funciona como el controlador del cluster, realizando tareas administrativas como la gesti\u00f3n de particiones.<\/p>\n<p>Una partici\u00f3n puede ser asignada a varios brokers, de este modo las r\u00e9plicas permiten la <strong>redundancia<\/strong> de mensajes. Los productores y consumidores actuar\u00e1n sobre una partici\u00f3n denominada l\u00edder, pero si \u00e9sta falla una de las r\u00e9plicas pasar\u00e1 a ser el nuevo l\u00edder. Las particiones tambi\u00e9n son <strong>escalables<\/strong>, pudiendo estar alojada cada partici\u00f3n en un broker distinto, permitiendo as\u00ed el escalado horizontal de topics.<\/p>\n<p><strong>Productores<\/strong>: Producen mensajes que son almacenados en una determinada partici\u00f3n de un topic. En principio la partici\u00f3n es elegida en base a un hash aplicado sobre la clave del mensaje (pues cada mensaje est\u00e1 compuesto por una clave y valor), por lo que el usuario puede establecer una clave espec\u00edfica si quiere escribir en una partici\u00f3n concreta del topic.<\/p>\n<p><strong>Consumidores<\/strong>: Leen mensajes de uno o varios topics en el orden en el que fueron almacenados. El offset de los mensajes es el que ayuda a los consumidores a llevar un control sobre el \u00faltimo mensaje que han le\u00eddo para evitar p\u00e9rdidas tras un reinicio del sistema.<\/p>\n<p>Los consumidores pueden pertenecer a un <strong>grupo de consumidores<\/strong> definido por un id. Los grupos garantizan que cada partici\u00f3n es consumida por un solo miembro, mientras que consumidores de distintos grupos s\u00ed pueden consumir la misma partici\u00f3n. De este modo los consumidores pueden ser escalados horizontalmente para consumir topics con un gran n\u00famero de mensajes, adem\u00e1s de producirse un rebalanceo de particiones entre los consumidores restantes si uno falla.<\/p>\n<h2>Apache ZooKeeper<\/h2>\n<p>Este software, desarrollado por Apache como <strong>servicio de almacenamiento de configuraci\u00f3n centralizado<\/strong>, es un componente fundamental para que Kafka funcione correctamente. Algunas de las funciones clave que desempe\u00f1a ZooKeeper en el ecosistema de Kafka son las siguientes:<\/p>\n<p>\u2022 Elegir un controlador entre los brokers, encargado de mantener la relaci\u00f3n l\u00edder-seguidores de todas las particiones.<\/p>\n<p>\u2022 Mantener informaci\u00f3n relativa a los topics: lista de topics existentes, n\u00famero de particiones, d\u00f3nde se encuentran las r\u00e9plicas\u2026<\/p>\n<p>\u2022 Mantener una lista de todos los brokers activos en cada cluster.<\/p>\n<p>Apache Kafka es empleado por Teldat en el desarrollo de nuestro <a href=\"https:\/\/www.teldat.com\/es\/soluciones\/networking-avanzado\/cnm-sd-wan-redes-hibridas\/\" target=\"_blank\" rel=\"noopener\">SD-WAN<\/a> para comunicar los microservicios y gestionar grandes cantidades de datos relativas a los dispositivos de manera eficiente.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Hoy en d\u00eda un gran n\u00famero de aplicaciones siguen una arquitectura basada en microservicios. Adem\u00e1s, muchas aplicaciones manejan grandes cantidades de datos (actividad de los usuarios sobre la aplicaci\u00f3n, logs, m\u00e9tricas&#8230;) que viajan constantemente entre microservicios. Esto puede derivar en una serie de problemas a la hora de integrar toda esta informaci\u00f3n, como la sincronizaci\u00f3n, [&hellip;]<\/p>\n","protected":false},"author":196,"featured_media":19638,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[1154],"tags":[1102],"class_list":["post-20985","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-seguridad-tic-it","tag-servicios-micro"],"acf":[],"wpml_current_locale":"es_ES","wpml_translations":[{"locale":"en_US","id":19635,"slug":"messages-for-microservices-applications","post_title":"Why Apache Kafka?","href":"https:\/\/www.teldat.com\/messages-for-microservices-applications\/"}],"_links":{"self":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts\/20985","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/users\/196"}],"replies":[{"embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/comments?post=20985"}],"version-history":[{"count":0,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts\/20985\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/media\/19638"}],"wp:attachment":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/media?parent=20985"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/categories?post=20985"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/tags?post=20985"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}