{"id":37849,"date":"2019-10-31T22:20:09","date_gmt":"2019-10-31T19:20:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kafka-i-mikroservisy-obzor\/"},"modified":"2019-10-31T22:20:09","modified_gmt":"2019-10-31T19:20:09","slug":"kafka-i-mikroservisy-obzor","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","title":{"rendered":"Kafka et microservices : un aper\u00e7u","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Kafka et microservices : un aper\u00e7u\" src=\"\/wp-content\/uploads\/2019\/09\/ab0534ad5d28b3c3aa03e4e0b2d3101b.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Bonjour \u00e0 tous. Dans cet article, je vais vous expliquer pourquoi nous avons choisi Kafka chez Avito il y a neuf mois, et ce qu'elle repr\u00e9sente. Je partagerai l'un des cas d'utilisation - le broker de messages. Enfin, nous aborderons les avantages que nous avons tir\u00e9s de l'approche Kafka as a Service.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1 id=\"problema\">Le probl\u00e8me<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka et microservices : un aper\u00e7u\" src=\"\/wp-content\/uploads\/2019\/09\/dfa5e231847cee67259da17867a11812.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Pour commencer, un peu de contexte. Il y a quelque temps, nous avons commenc\u00e9 \u00e0 nous \u00e9loigner de l'architecture monolithique, et maintenant, chez Avito, il y a plusieurs centaines de services diff\u00e9rents. Chacun d'eux a ses propres bases de donn\u00e9es, sa propre pile technologique et est responsable de sa partie de la logique m\u00e9tier. <\/p>\n<p><\/p>\n<p>L'un des probl\u00e8mes li\u00e9s \u00e0 un grand nombre de services est la communication. Le service A souhaite souvent conna\u00eetre des informations d\u00e9tenues par le service B. Dans ce cas, le service A se tourne vers le service B via une API synchronis\u00e9e. Le service C veut savoir ce qui se passe avec les services G et D, tandis que ceux-ci, \u00e0 leur tour, s'int\u00e9ressent aux services A et B. Lorsque ce genre de services 'curieux' devient nombreux, les connexions entre eux se transforment en un enchev\u00eatrement complexe.<\/p>\n<p><\/p>\n<p>\u00c0 tout moment, le service A peut devenir indisponible. Que doit alors faire le service B et tous les autres services qui en d\u00e9pendent ? Et si, pour ex\u00e9cuter une op\u00e9ration commerciale, il faut effectuer une cha\u00eene d'appels synchrones successifs, la probabilit\u00e9 que l'ensemble de l'op\u00e9ration \u00e9choue devient encore plus grande (et elle augmente avec la longueur de cette cha\u00eene). <\/p>\n<p><\/p>\n<h1 id=\"vybor-tehnologii\">Choix de la technologie<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka et microservices : un aper\u00e7u\" src=\"\/wp-content\/uploads\/2019\/09\/3acd7bcf3dded8093bdef6d627eb4071.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ok, les probl\u00e8mes sont clairs. Nous pouvons les r\u00e9soudre en cr\u00e9ant un syst\u00e8me centralis\u00e9 d'\u00e9change de messages entre les services. Maintenant, chaque service n'a besoin de conna\u00eetre que ce syst\u00e8me d'\u00e9change de messages. De plus, le syst\u00e8me doit \u00eatre r\u00e9sistant aux pannes et pouvoir \u00e9voluer horizontalement, tout en accumulant un tampon des appels en cas de d\u00e9faillance pour un traitement ult\u00e9rieur. <\/p>\n<p><\/p>\n<p>Choisissons maintenant la technologie sur laquelle la livraison des messages sera r\u00e9alis\u00e9e. Pour cela, comprenons d'abord ce que nous en attendons :<\/p>\n<p><\/p>\n<ul>\n<li>les messages entre les services ne doivent pas \u00eatre perdus ;<\/li>\n<li>les messages peuvent \u00eatre dupliqu\u00e9s ;<\/li>\n<li>les messages peuvent \u00eatre stock\u00e9s et lus sur plusieurs jours (tampon persistant) ;<\/li>\n<li>les services peuvent s'abonner aux donn\u00e9es qui les int\u00e9ressent ;<\/li>\n<li>plusieurs services peuvent lire les m\u00eames donn\u00e9es ;<\/li>\n<li>les messages peuvent contenir une charge utile d\u00e9taill\u00e9e et volumineuse (event-carried state transfer) ;<\/li>\n<li>parfois, une garantie de l'ordre des messages est n\u00e9cessaire.<\/li>\n<\/ul>\n<p><\/p>\n<p>Il \u00e9tait \u00e9galement crucial pour nous de choisir un syst\u00e8me hautement \u00e9volutif et fiable avec une grande capacit\u00e9 de traitement (au moins 100k messages de plusieurs kilobytes par seconde).<\/p>\n<p><\/p>\n<p>\u00c0 ce stade, nous avons dit adieu \u00e0 RabbitMQ (difficile \u00e0 maintenir stable \u00e0 des RPS \u00e9lev\u00e9s), PGQ de SkyTools (pas assez rapide et mal \u00e9volutif) et NSQ (non persistant). Toutes ces technologies sont utilis\u00e9es dans notre entreprise, mais elles n'\u00e9taient pas adapt\u00e9es \u00e0 la t\u00e2che \u00e0 accomplir. <\/p>\n<p><\/p>\n<p>Nous avons ensuite commenc\u00e9 \u00e0 explorer de nouvelles technologies pour nous : Apache Kafka, Apache Pulsar et NATS Streaming.<\/p>\n<p><\/p>\n<p>Nous avons d'abord \u00e9cart\u00e9 Pulsar. Nous avons d\u00e9cid\u00e9 que Kafka et Pulsar sont des solutions assez semblables. Et m\u00eame si Pulsar est \u00e9prouv\u00e9 par de grandes entreprises, plus r\u00e9cent et offre une latence plus faible (en th\u00e9orie), nous avons d\u00e9cid\u00e9 de conserver Kafka parmi ces deux options, comme la norme de facto pour de telles t\u00e2ches. Nous reviendrons probablement \u00e0 Apache Pulsar \u00e0 l'avenir. <\/p>\n<p><\/p>\n<p>Il nous restait donc deux candidats : NATS Streaming et Apache Kafka. Nous avons \u00e9tudi\u00e9 les deux solutions en d\u00e9tail, et toutes deux r\u00e9pondaient \u00e0 nos besoins. Mais au final, nous avons craint la relative jeunesse de NATS Streaming (et le fait que l'un des principaux d\u00e9veloppeurs, Tyler Treat, a d\u00e9cid\u00e9 de quitter le projet pour commencer le sien \u2014 Liftbridge). De plus, le mode de clustering de NATS Streaming ne permettait pas un fort \u00e9volutivit\u00e9 horizontale (ce n'est probablement plus un probl\u00e8me depuis l'ajout du mode de partitionnement en 2017).<\/p>\n<p><\/p>\n<p>Cela dit, NATS Streaming est une technologie impressionnante, \u00e9crite en Go et soutenue par la Cloud Native Computing Foundation. Contrairement \u00e0 Apache Kafka, elle n'a pas besoin de Zookeeper pour fonctionner (peut-\u00eatre que <noindex><a rel=\"nofollow\" href=\"https:\/\/cwiki.apache.org\/confluence\/display\/KAFKA\/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum\">on pourra bient\u00f4t en dire autant pour Kafka<\/a><\/noindex>), car elle impl\u00e9mente le RAFT en interne. De plus, NATS Streaming est plus simple \u00e0 administrer. Nous ne rejetons pas la possibilit\u00e9 de revenir \u00e0 cette technologie \u00e0 l'avenir. <\/p>\n<p><\/p>\n<p>Et pourtant, aujourd'hui, notre gagnant est Apache Kafka. Dans nos tests, elle s'est montr\u00e9e suffisamment rapide (plus d'un million de messages par seconde pour la lecture et l'\u00e9criture avec un volume de messages de 1 kilobyte), assez fiable, bien \u00e9volutive et \u00e9prouv\u00e9e en production par de grandes entreprises. De plus, Kafka est soutenue par au moins plusieurs grandes entreprises commerciales (nous utilisons par exemple la version de Confluent), et poss\u00e8de un \u00e9cosyst\u00e8me bien d\u00e9velopp\u00e9.<br \/>\n<br clear=\"left\">\n <\/p>\n<p><\/p>\n<h1 id=\"obzor-kafka\">Aper\u00e7u de Kafka<\/h1>\n<p><\/p>\n<p>Avant de commencer, je recommande imm\u00e9diatement un excellent livre \u2014 <em>\u00ab Kafka: The Definitive Guide \u00bb<\/em> (il existe aussi une traduction en russe, mais les termes peuvent \u00eatre un peu d\u00e9routants). On y trouve des informations n\u00e9cessaires pour une compr\u00e9hension de base de Kafka et m\u00eame un peu plus. La documentation d'Apache et le blog de Confluent sont \u00e9galement bien r\u00e9dig\u00e9s et faciles \u00e0 lire. <\/p>\n<p><\/p>\n<p>Alors, examinons comment Kafka est structur\u00e9 dans les grandes lignes. La topologie de base de Kafka se compose de producteurs, consommateurs, courtiers et zookeeper.<\/p>\n<p><\/p>\n<h3 id=\"broker\">Courtier<\/h3>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka et microservices : un aper\u00e7u\" src=\"\/wp-content\/uploads\/2019\/09\/82f34b5a1aadcdc07eef58eb5414b553.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Le courtier (broker) est responsable de la conservation de vos donn\u00e9es. Toutes les donn\u00e9es sont stock\u00e9es sous forme binaire, et le courtier sait peu de choses sur leur contenu et leur structure. <\/p>\n<p><\/p>\n<p>Chaque type logique d'\u00e9v\u00e9nement se trouve g\u00e9n\u00e9ralement dans son propre topic. Par exemple, un \u00e9v\u00e9nement de cr\u00e9ation d'annonce peut \u00eatre envoy\u00e9 au topic item.created, tandis qu'un \u00e9v\u00e9nement de modification ira dans item.changed. Les topics peuvent \u00eatre consid\u00e9r\u00e9s comme des classificateurs d'\u00e9v\u00e9nements. Au niveau du topic, vous pouvez d\u00e9finir des param\u00e8tres de configuration tels que : <\/p>\n<p><\/p>\n<ul>\n<li>la taille des donn\u00e9es stock\u00e9es et\/ou leur anciennet\u00e9 (retention.bytes, retention.ms); <\/li>\n<li>le facteur de redondance des donn\u00e9es (replication factor);<\/li>\n<li>la taille maximale d'un message (max.message.bytes);<\/li>\n<li>le nombre minimum de r\u00e9pliques synchronis\u00e9es n\u00e9cessaires pour \u00e9crire des donn\u00e9es dans le topic (min.insync.replicas);<\/li>\n<li>la possibilit\u00e9 d'effectuer un basculement vers une r\u00e9plique en retard non synchronis\u00e9e avec une possible perte de donn\u00e9es (unclean.leader.election.enable);<\/li>\n<li>et bien d'autres (<noindex><a rel=\"nofollow\" href=\"https:\/\/kafka.apache.org\/documentation\/#topicconfigs\">https:\/\/kafka.apache.org\/documentation\/#topicconfigs<\/a><\/noindex>).<\/li>\n<\/ul>\n<p><\/p>\n<p>Chaque topic est \u00e0 son tour divis\u00e9 en une ou plusieurs partitions. Ce sont dans ces partitions que les \u00e9v\u00e9nements finissent par \u00eatre stock\u00e9s. S'il y a plus d'un courtier dans le cluster, les partitions seront r\u00e9parties \u00e9quitablement entre tous les courtiers (autant que possible), permettant ainsi de r\u00e9partir la charge d'\u00e9criture et de lecture d'un topic sur plusieurs courtiers \u00e0 la fois.<\/p>\n<p><\/p>\n<p>Sur le disque, les donn\u00e9es de chaque partition sont stock\u00e9es sous forme de fichiers segments, par d\u00e9faut d'un gigaoctet chacun (contr\u00f4l\u00e9 via log.segment.bytes). Une caract\u00e9ristique importante est que la suppression de donn\u00e9es des partitions (lorsque la r\u00e9tention s'active) se fait par segments (un \u00e9v\u00e9nement ne peut pas \u00eatre supprim\u00e9 d'une partition, seul un segment entier peut l'\u00eatre, et uniquement s'il est inactif).<\/p>\n<p><\/p>\n<h3 id=\"zookeeper\">Zookeeper<\/h3>\n<p><\/p>\n<p>Zookeeper joue le r\u00f4le de stockage des m\u00e9tadonn\u00e9es et de coordinateur. C'est lui qui peut dire si les courtiers sont vivants (vous pouvez le voir avec zookeeper via la commande zookeeper-shell <code>ls \/brokers\/ids<\/code>), lequel des courtiers est le contr\u00f4leur (<code>get \/controller<\/code>), les partitions sont-elles en \u00e9tat de synchronisation avec leurs r\u00e9pliques (<code>get \/brokers\/topics\/topic_name\/partitions\/partition_number\/state<\/code>). De plus, c'est d'abord vers zookeeper que le producer et le consumer se dirigeront pour savoir sur quel broker quels topics et partitions sont stock\u00e9s. Dans les cas o\u00f9 un facteur de r\u00e9plication sup\u00e9rieur \u00e0 1 est d\u00e9fini pour le topic, zookeeper indiquera quelles partitions sont les leaders (o\u00f9 l'\u00e9criture aura lieu et d'o\u00f9 la lecture sera \u00e9galement effectu\u00e9e). En cas de d\u00e9faillance d'un broker, c'est bien dans zookeeper que l'information sur les nouvelles partitions leaders sera enregistr\u00e9e (depuis la version 1.1.0 de mani\u00e8re asynchrone, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.confluent.io\/blog\/apache-kafka-supports-200k-partitions-per-cluster\">et c'est important<\/a><\/noindex>).<\/p>\n<p><\/p>\n<p>Dans les versions plus anciennes de Kafka, zookeeper \u00e9tait \u00e9galement responsable du stockage des offsets, mais maintenant ils sont conserv\u00e9s dans un topic sp\u00e9cial <code>__consumer_offsets<\/code> sur le broker (bien que vous puissiez toujours utiliser zookeeper \u00e0 ces fins). <\/p>\n<p><\/p>\n<p>Le moyen le plus simple de transformer vos donn\u00e9es en citrouille est justement de perdre des informations avec zookeeper. Dans ce sc\u00e9nario, il sera tr\u00e8s difficile de comprendre ce qu'il faut lire et d'o\u00f9. <\/p>\n<p><\/p>\n<h3 id=\"producer\">Producteur<\/h3>\n<p><\/p>\n<p>Un Producteur est souvent un service qui enregistre directement des donn\u00e9es dans Apache Kafka. Le Producteur choisit le topic dans lequel ses messages th\u00e9matiques seront stock\u00e9s et commence \u00e0 y \u00e9crire des informations. Par exemple, un service de petites annonces pourrait \u00eatre un producteur. Dans ce cas, il enverrait dans des topics th\u00e9matiques des \u00e9v\u00e9nements tels que \"annonce cr\u00e9\u00e9e\", \"annonce mise \u00e0 jour\", \"annonce supprim\u00e9e\", etc. Chaque \u00e9v\u00e9nement repr\u00e9sente alors une paire cl\u00e9-valeur.<\/p>\n<p><\/p>\n<p>Par d\u00e9faut, tous les \u00e9v\u00e9nements sont r\u00e9partis dans les partitions du topic par round-robin si aucune cl\u00e9 n'est sp\u00e9cifi\u00e9e (perdant l'ordre), et via MurmurHash (cl\u00e9), si une cl\u00e9 est pr\u00e9sente (maintenant l'ordre au sein d'une seule partition).<\/p>\n<p><\/p>\n<p>Il convient de noter ici que Kafka garantit l'ordre des \u00e9v\u00e9nements uniquement au sein d'une seule partition. Mais en r\u00e9alit\u00e9, cela n'est souvent pas un probl\u00e8me. Par exemple, il est possible d'ajouter de mani\u00e8re garantie tous les changements d'une m\u00eame annonce dans une seule partition (maintenant ainsi l'ordre de ces changements au sein de l'annonce). Il est \u00e9galement possible de transmettre un num\u00e9ro de s\u00e9quence dans l'un des champs de l'\u00e9v\u00e9nement.<\/p>\n<p><\/p>\n<h3 id=\"consumer\">Consumer<\/h3>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka et microservices : un aper\u00e7u\" src=\"\/wp-content\/uploads\/2019\/09\/1f69a53dc19bb6c587883b8754cde29f.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Le consumer est responsable de l'obtention des donn\u00e9es depuis Apache Kafka. Pour revenir \u00e0 l'exemple pr\u00e9c\u00e9dent, le consumer pourrait \u00eatre un service de mod\u00e9ration. Ce service sera abonn\u00e9 au topic du service d'annonces, et lorsqu'une nouvelle annonce appara\u00eetra, il la recevra et l'analysera en fonction de certaines politiques d\u00e9finies.<\/p>\n<p><\/p>\n<p>Apache Kafka m\u00e9morise quels sont les derniers \u00e9v\u00e9nements re\u00e7us par le consumer (pour cela, un topic de service est utilis\u00e9 <code>__consumer__offsets<\/code>), garantissant ainsi que lors d'une lecture r\u00e9ussie, le consumer ne recevra pas le m\u00eame message deux fois. Cependant, si l'option enable.auto.commit = true est utilis\u00e9e et que l'on confie enti\u00e8rement le suivi de la position du consumer dans le topic \u00e0 Kafka, il est possible de <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.newrelic.com\/engineering\/kafka-consumer-config-auto-commit-data-loss\/\">perdre des donn\u00e9es<\/a><\/noindex>. Dans le code de production, la position du consumer est le plus souvent contr\u00f4l\u00e9e manuellement (le d\u00e9veloppeur g\u00e8re le moment o\u00f9 le commit de l'\u00e9v\u00e9nement lu doit obligatoirement se produire).<\/p>\n<p><\/p>\n<p>Dans les cas o\u00f9 un seul consumer n'est pas suffisant (par exemple, si le flux de nouveaux \u00e9v\u00e9nements est tr\u00e8s important), il est possible d'ajouter plusieurs consumers, en les liant ensemble dans un groupe de consumers. Le groupe de consumers repr\u00e9sente logiquement un consumer exactement de la m\u00eame mani\u00e8re, mais avec la r\u00e9partition des donn\u00e9es entre les membres du groupe. Cela permet \u00e0 chacun des participants de prendre sa part de messages, augmentant ainsi la vitesse de lecture. <\/p>\n<p><\/p>\n<h1 id=\"rezultaty-testirovaniya\">R\u00e9sultats des tests<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka et microservices : un aper\u00e7u\" src=\"\/wp-content\/uploads\/2019\/09\/f7abe4bcf34fdb0d762c8a928bd873ee.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Je ne vais pas \u00e9crire beaucoup de texte explicatif ici, je vais simplement partager les r\u00e9sultats obtenus. Les tests ont \u00e9t\u00e9 r\u00e9alis\u00e9s sur 3 machines physiques (12 CPU, 384 Go de RAM, DISK SAS 15k, 10Gbit\/s Net), les brokers et zookeeper ont \u00e9t\u00e9 d\u00e9ploy\u00e9s dans lxc. <\/p>\n<p><\/p>\n<p><strong>Tests de performance<\/strong><\/p>\n<p><\/p>\n<p>Au cours des tests, les r\u00e9sultats suivants ont \u00e9t\u00e9 obtenus.<\/p>\n<p><\/p>\n<ul>\n<li>La vitesse d'\u00e9criture des messages de 1 Ko avec 9 producers simultan\u00e9s \u2014 1 300 000 \u00e9v\u00e9nements par seconde.<\/li>\n<li>La vitesse de lecture des messages de 1 Ko avec 9 consumers simultan\u00e9s \u2014 1 500 000 \u00e9v\u00e9nements par seconde.<\/li>\n<\/ul>\n<p><\/p>\n<p><strong>Tests de r\u00e9silience<\/strong><\/p>\n<p><\/p>\n<p>Au cours des tests, les r\u00e9sultats suivants ont \u00e9t\u00e9 obtenus (3 brokers, 3 zookeepers).<\/p>\n<p><\/p>\n<ul>\n<li>L'arr\u00eat inattendu de l'un des brokers n'entra\u00eene pas l'arr\u00eat ou l'indisponibilit\u00e9 du cluster. Le fonctionnement se poursuit normalement, mais la charge sur les brokers restants augmente.<\/li>\n<li>La terminaison anormale de deux courtiers dans un cluster de trois courtiers avec min.isr = 2 rend le cluster inaccessible pour l'\u00e9criture, mais accessible pour la lecture. Si min.isr = 1, le cluster reste accessible aussi bien pour la lecture que pour l'\u00e9criture. Cependant, ce mode contredit l'exigence de haute durabilit\u00e9 des donn\u00e9es.<\/li>\n<li>La terminaison anormale d'un des serveurs Zookeeper ne conduit pas \u00e0 l'arr\u00eat ou \u00e0 l'inaccessibilit\u00e9 du cluster. Le fonctionnement continue normalement.<\/li>\n<li>La terminaison anormale de deux serveurs Zookeeper rend le cluster inaccessible jusqu'\u00e0 ce qu'au moins un des serveurs Zookeeper soit restaur\u00e9. Cette affirmation est valable pour un cluster Zookeeper compos\u00e9 de 3 serveurs. En cons\u00e9quence, apr\u00e8s des recherches, il a \u00e9t\u00e9 d\u00e9cid\u00e9 d'augmenter le cluster Zookeeper \u00e0 5 serveurs pour am\u00e9liorer la tol\u00e9rance aux pannes. <br clear=\"left\">\n <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"kafka-as-a-service\">Kafka en tant que service<\/h1>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Kafka et microservices : un aper\u00e7u\" src=\"\/wp-content\/uploads\/2019\/09\/19b2356131203cefbadfd90a25ae9674.png\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p><\/p>\n<p>Nous avons constat\u00e9 que Kafka est une excellente technologie qui permet de r\u00e9soudre le probl\u00e8me qui nous \u00e9tait pos\u00e9 (la mise en \u0153uvre d'un courtier de messages). N\u00e9anmoins, nous avons d\u00e9cid\u00e9 d'interdire aux services d'acc\u00e9der directement \u00e0 Kafka et l'avons ferm\u00e9 par-dessus avec le service data-bus. Pourquoi avons-nous fait cela ? En fait, il y a plusieurs raisons.<\/p>\n<p><\/p>\n<ul>\n<li>\n<p>Le data-bus a pris en charge toutes les t\u00e2ches li\u00e9es \u00e0 l'int\u00e9gration avec Kafka (mise en \u0153uvre et configuration des consommateurs et producteurs, surveillance, alertes, journalisation, scalabilit\u00e9, etc.). Ainsi, l'int\u00e9gration avec le courtier de messages se fait de mani\u00e8re extr\u00eamement simple. <\/p>\n<p>\n<\/li>\n<li>\n<p>Le data-bus a permis de s'abstraire de la langue ou de la biblioth\u00e8que sp\u00e9cifique pour travailler avec Kafka. <\/p>\n<p>\n<\/li>\n<li>\n<p>Le data-bus a permis aux autres services de s'abstraire de la couche de stockage. Peut-\u00eatre qu'\u00e0 un moment donn\u00e9, nous remplacerons Kafka par Pulsar, et \u00e0 ce moment-l\u00e0, personne ne s'en rendra compte (tous les services connaissent uniquement l'API du data-bus).<\/p>\n<p>\n<\/li>\n<li>\n<p>Le data-bus a pris en charge la validation des sch\u00e9mas d'\u00e9v\u00e9nements.<\/p>\n<p>\n<\/li>\n<li>\n<p>Avec le data-bus, l'authentification a \u00e9t\u00e9 mise en \u0153uvre.<\/p>\n<p>\n<\/li>\n<li>\n<p>Sous la couverture du data-bus, nous pouvons mettre \u00e0 jour les versions de Kafka sans temps d'arr\u00eat, discr\u00e8tement, g\u00e9rer la configuration des producteurs, consommateurs, courtiers, etc.<\/p>\n<p>\n<\/li>\n<li>\n<p>Le data-bus a permis d'ajouter les fonctionnalit\u00e9s n\u00e9cessaires qui ne sont pas pr\u00e9sentes dans Kafka (telles que l'audit des sujets, le contr\u00f4le des anomalies dans le cluster, la cr\u00e9ation de DLQ, etc.).<\/p>\n<p>\n<\/li>\n<li>\n<p>Le data-bus permet de r\u00e9aliser un basculement de mani\u00e8re centralis\u00e9e pour tous les services.<\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Actuellement, pour commencer \u00e0 envoyer des \u00e9v\u00e9nements \u00e0 un courtier de messages, il vous suffit de connecter une petite biblioth\u00e8que dans le code de votre service. C'est tout. Vous avez d\u00e9sormais la possibilit\u00e9 d'\u00e9crire, de lire et de vous d\u00e9velopper avec une seule ligne de code. Toute l'impl\u00e9mentation est cach\u00e9e de vous, seules quelques poign\u00e9es, comme la taille du lot, sont visibles. Sous le capot, le service data-bus d\u00e9ploie dans Kubernetes le nombre n\u00e9cessaire d'instances de producteurs et de consommateurs et leur fournit la configuration requise, mais tout cela reste transparent pour votre service. <\/p>\n<p><\/p>\n<p>Bien s\u00fbr, il n'existe pas de solution miracle, et cette approche pr\u00e9sente ses propres limitations.<\/p>\n<p><\/p>\n<ul>\n<li>Le data-bus doit \u00eatre maintenu par vos propres moyens, contrairement aux biblioth\u00e8ques tierces.<\/li>\n<li>Le data-bus augmente le nombre d'interactions entre les services et le courtier de messages, ce qui entra\u00eene une diminution des performances par rapport \u00e0 une utilisation directe de Kafka.<\/li>\n<li>Tout ne peut pas \u00eatre cach\u00e9 si facilement aux services, nous ne souhaitons pas dupliquer les fonctionnalit\u00e9s de KSQL ou de Kafka Streams dans le data-bus, donc parfois, il est n\u00e9cessaire de permettre aux services d'acc\u00e9der directement. <\/li>\n<\/ul>\n<p><\/p>\n<p>Dans notre cas, les avantages ont pr\u00e9valu sur les inconv\u00e9nients, et la d\u00e9cision de masquer le courtier de messages derri\u00e8re un service distinct s'est av\u00e9r\u00e9e judicieuse. En un an d'exploitation, nous n'avons rencontr\u00e9 aucun incident grave ni probl\u00e8me.<\/p>\n<p><\/p>\n<p>P.S. Merci \u00e0 ma copine, Ekaterina Obalayeva, pour les superbes illustrations de cet article. Si elles vous ont plu, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.instagram.com\/o.k_o.k_\/\">ici<\/a><\/noindex> vous trouverez encore plus d'illustrations.<\/p>\n<p>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/465315\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043f\u043e\u0447\u0435\u043c\u0443 \u043c\u044b \u0432 \u0410\u0432\u0438\u0442\u043e \u0434\u0435\u0432\u044f\u0442\u044c \u043c\u0435\u0441\u044f\u0446\u0435\u0432 \u043d\u0430\u0437\u0430\u0434 \u0432\u044b\u0431\u0440\u0430\u043b\u0438 Kafka, \u0438 \u0447\u0442\u043e \u043e\u043d\u0430 \u0438\u0437 \u0441\u0435\u0431\u044f \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442. \u041f\u043e\u0434\u0435\u043b\u044e\u0441\u044c \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u043a\u0435\u0439\u0441\u043e\u0432 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f \u2014 \u0431\u0440\u043e\u043a\u0435\u0440 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418 \u043d\u0430\u043f\u043e\u0441\u043b\u0435\u0434\u043e\u043a \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a\u0438\u0435 \u043f\u043b\u044e\u0441\u044b \u043c\u044b \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u0438 \u043e\u0442 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u043f\u043e\u0434\u0445\u043e\u0434\u0430 Kafka as a Service. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0414\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0435\u043a\u0441\u0442\u0430. \u041d\u0435\u043a\u043e\u0442\u043e\u0440\u043e\u0435 \u0432\u0440\u0435\u043c\u044f \u043d\u0430\u0437\u0430\u0434 \u043c\u044b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28406,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37849","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Kafka \u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u044b: \u043e\u0431\u0437\u043e\u0440 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:20:09+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:20:09+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Kafka et microservices : aper\u00e7u | ProHoster","description":"Bonjour \u00e0 tous.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Kafka \u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u044b: \u043e\u0431\u0437\u043e\u0440 | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kafka-i-mikroservisy-obzor","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:20:09+00:00","article:modified_time":"2019-10-31T19:20:09+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37849","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 19:31:03","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:19:23","updated":"2026-01-23 19:31:03","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/37849","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=37849"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/37849\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/28406"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=37849"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=37849"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=37849"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}