Apache RocketMQ EventBridge : création d'un moteur événementiel de nouvelle génération

Auteur : Shen Lin

avant-propos

Event-driven, le terme est dans l'esprit de certaines personnes, c'est une technologie dépassée, rien de nouveau. Du point de vue du temps, c'est effectivement le cas.Dans les années 1960, l'événementiel a été formellement proposé, et il est souvent utilisé dans la programmation graphique. Mais dans l'esprit de certaines personnes, l'événementiel est une technologie très étrange et très nouvelle.

Dans tous les cas, la réalité est que de plus en plus d'entreprises ont commencé ou appliqué l'architecture événementielle au cœur de métier de l'entreprise, notamment : Alibaba, Heineken, Unilever, la Federal Aviation Administration, le marché des capitaux des banques, etc. Sur le marché, de nombreuses entreprises ont également lancé leurs propres produits ou solutions, telles que Alibaba Cloud, AWS, Google et Solace. Les normes événementielles ont également été développées dans l'industrie : CloudEventsGartener définit l'événementiel comme l'une des dix principales tendances à venir ;

À l'heure actuelle, nous devons nous demander, qu'est-ce qu'une architecture événementielle ? Pourquoi maintenant, de plus en plus de gens prêtent attention à l'architecture événementielle ?

Le 28 mai, lors du sommet mondial des technologies open source GOTC 2023, Shen Lin, expert en technologies intelligentes du cloud d'Alibaba, a prononcé un discours d'ouverture : Apache RocketMQ Event-Driven Engine.

Apache RocketMQ PMC & Expert en technologie intelligente du cloud Alibaba : Shen Lin

Qu'est-ce qu'un événement ?

En ce qui concerne l'architecture événementielle, les premières impressions des gens ont tendance à se concentrer sur le mot "architecture", mais le grand charme de l'architecture événementielle vient en fait du mot "événementiel" devant, donc aujourd'hui, nous allons d'abord prendre un aperçu de ce qu'est un événement. RocketMQ a toujours donné l'impression d'être un moteur de messages, alors pourquoi avons-nous introduit des événements dans la version 5.0 sortie il y a quelque temps ? Quelle est la différence entre les nouvelles et les événements?

Événement, si nous cherchons dans le dictionnaire, il vous donnera une telle explication : un événement fait référence à quelque chose qui s'est passé dans le passé, surtout quelque chose de plus important.

C'est facile à comprendre. Par exemple, la conférence GOTC s'est officiellement ouverte à Shanghai aujourd'hui ; mon téléphone portable a sonné tout à l'heure ; ce sont tous des événements qui se sont produits dans le passé.

Cependant, si nous reprenons la question de tout à l'heure : Quelle est la différence entre un événement et un message ? À l'heure actuelle, pensez-vous que la définition d'événement n'est pas aussi claire ? Les événements que nous venons d'évoquer peuvent-ils être compris comme des actualités ? Si Lao Zhang m'envoyait un SMS à ce moment-là, ce SMS serait-il considéré comme un événement ou une nouvelle ?

Nous pouvons utiliser cette image pour comprendre simplement la relation entre les messages et les événements. Il existe deux types de messages, l'un est les messages de commande et l'autre est les messages d'événement.

1. Qu'est-ce que le message de commande ? Regardons l'image ci-dessous à gauche, une commande d'opération envoyée par le système externe au système est le message de commande ;

2. Qu'est-ce qu'un message d'événement ? Regardez à nouveau l'image ci-dessous à droite, le système reçoit une demande d'opération de commande externe, et après que le système a changé en interne, un événement est généré ;

Ainsi, les événements et les messages sont légèrement différents. Un événement peut être compris comme un type particulier de nouvelles, alors qu'y a-t-il de si spécial dans un événement ? Il comprend principalement 4 aspects :

Propriété 1 des événements : arrivés et immuables

L'événement doit être "envoyé". Que signifie "s'est-il passé" ? immuable. Nous ne pouvons pas changer le passé à moins que vous n'ayez des super pouvoirs. Cette fonctionnalité est très importante. Lorsque nous traitons et analysons des événements, cela signifie que nous pouvons absolument croire en ces événements. Tant que les événements sont reçus, ils doivent être le comportement réel du système, et ils sont immuables et ne peuvent pas être modifiés .

Par rapport au message de commandement, qu'est-ce que le chinois du commandement ? Commande! De toute évidence, cela ne s'est toujours pas produit, mais a exprimé une attente. Nous savons que ce qui est «désiré» ne se produit pas nécessairement avec succès. Par exemple:

allumez la lumière de la cuisine ;
sonner à la porte;
Virement sur le compte A 10w ;

Ce sont des comportements courants et attendus. Mais est-ce arrivé finalement ? ne sais pas.

L'événement est de clarifier ce qui s'est passé. Par exemple:

La lumière de la cuisine était allumée ;
Quelqu'un a sonné à la porte;
Le compte A a reçu 10w

Propriété 2 des événements : inattendus

La deuxième propriété des événements est qu'ils ne sont pas désirés. Un événement est une description objective d'un changement dans l'état ou la valeur d'attribut d'une chose, mais il ne fait aucune attente sur la façon de gérer l'événement lui-même. En revanche, Commond a des attentes et espère que le système apportera des changements ; mais Event, il décrit objectivement un changement dans le système. Prenons un exemple : lorsqu'un feu passe du vert au rouge, c'est un événement. L'événement lui-même n'a aucune attente, disons qu'il est interdit aux piétons ou aux voitures de passer, mais le code de la route impose des feux de circulation et leur donne des règles.

Par conséquent, le système n'envoie généralement pas d'événements à un système désigné de manière ciblée, mais informe le "centre d'événements" de manière uniforme. Dans le "Event Center", il y a divers événements signalés par divers systèmes. Le système expliquera au centre d'événements : quels événements seront générés par son propre système, et quel est le format de ces événements ; si d'autres systèmes sont intéressés, ils peuvent s'abonner activement à ces événements ; c'est le consommateur d'événements qui donne vraiment la valeur de l'événement. Les consommateurs d'événements veulent voir, qu'est-ce qui a changé dans un certain système ? OK, alors il s'abonnera à ces événements, donc les événements sont axés sur le consommateur.

En quoi est-ce différent des nouvelles ? L'envoi et l'abonnement aux messages Commond sont convenus par les deux parties, et les tiers ne le savent pas. Il se présente souvent sous la forme de documents ou de codes. Tout le monde envoie, s'abonne et consomme conformément à l'accord convenu. Ce processus est souvent piloté par les producteurs.

Pour utiliser une métaphore, un événement est comme une économie de marché : quand un produit est fabriqué, sa valeur et sa valeur dépendent largement de ses consommateurs. Nous pouvons voir toutes sortes d'événements dans le système, tout comme une variété de marchandises dans une vitrine ; tandis que les nouvelles communes, un peu comme une économie planifiée, naissent avec un objectif fort, "je" C'est d'être "distribué" à qui consommer.

Caractéristique 3 des événements : ordre naturel et unicité

La troisième caractéristique des événements est : « L'ordre naturel et l'unicité ». Pour une même entité, A et B ne peuvent pas se produire en même temps, il doit y avoir une relation de séquence ; si c'est le cas, les deux événements doivent appartenir à des types d'événements différents. Les étudiants attentifs doivent avoir découvert une chose. En fait, un attribut supplémentaire de l'événement est caché ici : parce qu'il est naturellement ordonné, il est fortement lié à un certain moment sur la ligne de temps, et ne peut pas se produire en même temps, il doit donc être unique.

Si nous voyons deux événements avec le même contenu, cela doit s'être produit deux fois, un avant et un après. Ceci est très précieux pour nous pour traiter de la cohérence finale des données et de l'analyse du comportement du système : ce que nous voyons n'est pas seulement un résultat final du système, mais une série de processus intermédiaires avant qu'il ne devienne ce résultat.

Caractéristique 4 des événements : Concrétisation

La quatrième caractéristique des événements est : la "concrétisation". L'événement essaiera d'enregistrer la "scène du crime" aussi complètement que possible, car il ne sait pas comment les consommateurs l'utiliseront, il essaiera donc d'être aussi détaillé que possible, y compris : Quand est-ce arrivé ? Qui a généré l'événement ? Quel type d'événement ? Qui a envoyé l'événement ? Quel est le signe unique de l'événement ? Quel est le contenu de l'événement ? etc.

Par rapport à notre actualité commune, parce que l'amont et l'aval sont généralement déterminés, souvent dans un souci de performance et d'efficacité de transmission, il sera le plus rationalisé possible, pour autant qu'il réponde aux besoins des consommateurs désignés par « l'économie planifiée ».

Qu'est-ce que l'architecture événementielle ?

Après avoir parlé des événements, revenons en arrière et regardons ce qu'est une architecture événementielle. Pour faciliter la compréhension, prenons un exemple simple : nous savons tous qu'une fois que le système de transaction a terminé la transaction de commande, de nombreux systèmes "ont besoin" de connaître les informations de la commande, telles que :

Le système logistique doit connaître les informations de la commande pour organiser la livraison ;
Le système de points a besoin de connaître les informations de la commande pour recalculer les points de l'utilisateur ;
Le système marketing a besoin de connaître ces informations de commande pour calculer le montant de la transaction en temps réel de la journée.

Ici, nous avons trois façons de réaliser l'intégration du système de transaction en amont et des systèmes de logistique, de points et de commercialisation en aval.

Intégration en amont et en aval

Méthode 1 : appel actif

L'une des méthodes de mise en œuvre les plus simples est la suivante : le système de négociation appelle tour à tour chaque système pour envoyer les informations de commande. Par exemple, comme indiqué ci-dessous :

Mais nous savons tous que cette conception est très mauvaise. Surtout lorsque de plus en plus de systèmes sont ajoutés, non seulement le coût de développement est élevé, mais aussi s'il y a un problème dans l'un des systèmes, s'il n'est pas géré correctement, cela affectera facilement la livraison des autres systèmes.

Méthode 2 : Découplage asynchrone des messages

Une solution très naturelle est la suivante : nous envoyons les informations de commande à un service de messagerie intermédiaire. Ensuite, le système logistique, le système de points et le système de commercialisation n'ont qu'à s'abonner à ces messages d'ordre de transaction du courtier, ce qui est très simple et clair.

Approche 3 : architecture pilotée par les événements

Alors, que devez-vous faire si c'est dans une architecture événementielle ? Le système de négociation enverra toujours l'ordre de négociation à notre service de courtier intermédiaire, mais le service en aval n'a plus besoin de souscrire activement à l'ordre de négociation dans le courtier, mais le courtier le pousse souvent vers le système en aval. À ce stade, vous pouvez avoir des doutes. Cela semble être découplé de manière asynchrone du message de la méthode 2. Il n'y a pas beaucoup de différence, n'est-ce pas ? L'architecture événementielle change-t-elle simplement le mode Pull en mode Push ?

Ici, nous nous concentrons sur l'amont et l'aval pour voir les changements apportés par l'architecture événementielle.

En aval

1. Extension de couplage

Jetons un coup d'œil ici. Dans de nombreux cas, le système de marketing en aval ne repose pas uniquement sur les données de commande générées par un système commercial. Par exemple, il peut également avoir besoin des ordres de transaction de Taobao, des ordres de transaction de JD.com et des ordres de transaction de Pinduoduo pour calculer une transaction en temps réel Valeur agrégée à l'instant présent. À l'heure actuelle, dans l'architecture de « découplage asynchrone des messages », le système marketing du client doit faire deux choses :

Tout d'abord, abonnez-vous à trois services de courtier pour obtenir les données de commande de transaction de Taobao, JD.com et Pinduoduo ;

Deuxièmement, étant donné que Taobao, JD.com et Pinduoduo ont des formats de données de commande de transaction différents, le système marketing du client doit s'adapter aux trois formats de données, les convertir d'abord au format de données souhaité dans le système marketing, puis les traiter.

De plus, si le client ouvre ultérieurement un magasin sur Douyin, le système marketing du client doit être à nouveau adapté ; si le format des données de commande d'un certain magasin change, le système marketing du client doit également être mis à jour en même temps.

S'il s'agit d'une architecture basée sur les événements, que doit faire le système marketing du client ? Il n'a besoin de rien, il n'a qu'à crier : "De quel type de format d'événement de commande ai-je besoin, je fournis une API, et d'autres systèmes peuvent me l'envoyer selon ce format d'événement de commande." EventBroker convertira les événements en amont dans le format de données requis par le système de marketing client et l'enverra à son API. Peu importe le nombre d'ordres de trading du système que je reçois, peu importe la façon dont le système externe change, je resterai le même de toute façon.

2. Sens d'accouplement

Nous analysons ici la relation de couplage de ces trois méthodes : Il faut savoir que le couplage est directionnel.

Méthode 1 - appel direct : l'amont A dépend de l'aval B ; (une fois que l'aval B change, A doit être changé de manière synchrone)
Méthode 2 - Découplage asynchrone des messages : B dépend de A ; (Une fois que le format de données de A en amont change, B doit être modifié de manière synchrone)
Mode 3 événementiel : A ne dépend pas de B et B ne dépend pas de A ; (tous les couplages sont traités et maintenus de manière uniforme par le courtier d'événements intermédiaire)

3. Quels sont les facteurs qui affectent la stabilité du système ?

En plus de réduire les dépendances, quelle est la chose la plus importante à laquelle prêter attention lors du développement de systèmes en aval ? Pour la plupart des scénarios d'entreprise, le plus important est : de faibles coûts de développement et de maintenance, stables et fiables. Cependant, dans l'architecture de découplage asynchrone des messages, avez-vous trouvé qu'il y a deux entrées qui affectent les changements dans le système en aval actuel ? (C'est la partie marron ci-dessous) L'une est l'API, l'autre est l'abonnement aux messages.

C'est une chose très gênante pour un système d'avoir deux entrées qui entraîneront des changements. Cela signifie que lorsque nous développons et maintenons la stabilité de ce système, nous devons garder deux points : qu'il s'agisse d'authentification d'identité, d'audit, de sécurité, de contrôle de flux, de test, de maintenance, etc., nous devons considérer les deux côtés. Non seulement le coût est élevé, mais il est également sujet à des problèmes.

4. Testabilité et maintenabilité

Dans le modèle d'architecture pilotée par les événements, le système en aval doit uniquement fournir une entrée d'API.

Externe : cette API est utilisée non seulement pour recevoir des événements en amont, mais également pour communiquer avec d'autres systèmes ;
En interne : la conception de cette API est conçue autour du modèle de domaine actuel du système en aval, et il n'est pas nécessaire de s'adapter à d'autres systèmes.

Ainsi, tout le système sera très simple. L'avantage de la simplicité est que lorsque nous devons changer le système, nous devons seulement nous assurer que l'API que nous fournissons est fiable, et que la testabilité et la maintenabilité sont grandement améliorées.

5, sans serveur

Un autre grand avantage de l'événementiel est qu'il peut piloter Serverless en volume via des événements à consommer. Toujours dans le scénario de notre ordre de transaction :

Certains petits commerçants n'ont en fait pas autant de commandes, c'est donc un comportement inutile de déployer un service de système de points distinct et de l'exécuter 7*24 heures par jour. À ce stade, si nous utilisons le mode événementiel : uniquement lorsque l'événement de commande de transaction se produit, le service sans serveur en aval est déclenché et le paiement est calculé en fonction du volume, ce qui peut réduire considérablement nos coûts ;
Pour certains commerçants, le volume de commandes de transactions est très important, en particulier lors de festivals et de promotions, le pic de trafic sera très élevé. À ce stade, si le mode événementiel est utilisé pour déclencher des calculs sans serveur en fonction du montant, le les performances du système peuvent être améliorées puissance de traitement maximale.
De plus, si le système en aval affectera la stabilité du système en raison de certains événements anormaux. Le déclenchement événementiel de Serverless peut naturellement fournir une bonne isolation et permettre une récupération rapide.

Le sans serveur est progressivement devenu une tendance imparable à l'ère du cloud natif, et l'événementiel et le sans serveur sont les meilleurs frères.

En amont

Intégration SaaS

Tout ce qui précède concerne l'aval, alors quelle est l'importance de l'événementiel pour le système en amont ? Réfléchissons-y, pour le système en amont, qu'est-ce qui le préoccupe le plus ? Ce qui l'intéresse, ce n'est certainement pas la stabilité du système et le découplage de ces choses, pour ne pas dire que ces choses ne sont pas importantes, mais pour le système en amont, l'envoi au courtier de messages n'est pas différent du courtier d'événements. Alors, qu'est-ce qui est le plus important pour le système en amont ? L'essentiel ici est que le système en amont espère s'intégrer à d'autres systèmes pour créer sa propre niche écologique.

Comment comprendre cela ? Prenons un exemple : système de carte perforée de contrôle d'accès.

Le système de pointage de contrôle d'accès est vendu à différentes entreprises et il est nécessaire de prendre en charge la synchronisation des informations d'enregistrement de pointage des employés avec les systèmes ERP de différentes entreprises. À ce stade, si le système de pointage de contrôle d'accès lui-même est intégré et adapté aux systèmes ERP de chaque entreprise, le coût sera très élevé, presque irréaliste, si vous n'intégrez pas, de nombreuses entreprises risquent de ne pas acheter le vôtre.

Par conséquent, pour le système en amont, il est primordial de pouvoir s'intégrer facilement aux produits de l'écosystème sans souci ni effort. Dans le modèle d'architecture piloté par les événements, le système de pointage de contrôle d'accès n'a besoin que d'enregistrer l'événement de pointage des employés sous la forme d'un événement et de le transmettre au centre d'événements, vous n'avez donc pas à vous soucier de la repos. Le centre événementiel sera responsable de l'arrimage intégré de l'écologie en aval.

De plus, pour le système de pointage de contrôle d'accès lui-même, il doit également connaître l'événement d'entrée du nouvel employé, car ce n'est qu'ainsi que le nouvel employé pourra être reconnu à temps lorsqu'il pointera. Si le mode événementiel est utilisé, le système de contrôle d'accès et de pointage peut facilement créer sa propre niche écologique à partir de zéro dans l'écosystème SaaS.

Comment créer un excellent moteur événementiel

Tant de choses ont été dites auparavant, qu'est-ce qu'un événement et qu'est-ce qu'une architecture événementielle. J'ai également appris certains des charmes uniques de l'architecture événementielle : pourquoi l'architecture événementielle est privilégiée par de plus en plus d'entreprises.

Enfin, parlons des capacités nécessaires pour être un excellent moteur événementiel ? Comment faisons-nous RocketMQ EventBridge ?

Quel genre de capacité est nécessaire?

Tout d'abord, nous devons avoir une norme d'événement. Parce que l'événement n'est pas pour vous, ni pour lui, mais pour tout le monde. Il n'y a pas de consommateurs clairs pour les événements, et tous sont des consommateurs potentiels, il faut uniformiser la définition des événements pour que chacun puisse les comprendre d'un coup d'œil ;

Deuxièmement, nous devons avoir un centre d'événements dans lequel se trouvent divers événements enregistrés par tous les systèmes. C'est un peu comme un hypermarché en économie de marché. C'est plein de belles choses. Il y a de nombreux événements dedans. Même si vous ne l'achetez pas, vous pouvez entrer et y jeter un coup d'œil. Jetez un coup d'œil. c'est peut-être ce dont j'ai besoin Oui, alors vous pouvez le racheter;

Troisièmement, nous devons avoir un format d'événement pour décrire le contenu spécifique de l'événement. Cela équivaut à un contrat de vente dans une économie de marché. Le format de l'événement envoyé par le producteur doit être déterminé et ne peut pas toujours être modifié ; le format de l'événement reçu par le consommateur doit également être déterminé, sinon tout le marché sera chamboulé ;

Quatrièmement, nous devons donner aux consommateurs la possibilité de livrer des événements à la cible, et avant la livraison, les événements peuvent être filtrés et convertis afin qu'ils puissent s'adapter au format des paramètres reçus par l'API cible. Nous appelons ce processus une règle d'abonnement. .

Cinquièmement, nous devons avoir un endroit pour stocker les événements, qui est le bus d'événements du milieu.

comment décrire l'événement

En ce qui concerne le premier point des critères d'événement que nous venons de mentionner, c'est très important. La norme d'événement est équivalente à la langue de communication entre différents systèmes. Si la langue n'est pas claire, il y aura certainement de nombreux problèmes de communication mutuelle. Nous recommandons d'utiliser le protocole open source CloudEvents sous CNCF, qui a été largement intégré par de nombreuses entreprises et est considéré comme un standard de facto. Le protocole CloudEvent est également très simple. Nous avons un exemple simple. Pour plus de détails, veuillez vous référer au site officiel [ 1] :

{
  "specversion":"1.0",
  "type":"com.github.pull_request.opened",
  "source":"https://github.com/cloudevents",
  "subject":"123",
  "id":"A234-1234-1234",
  "time":"2018-04-05T17:31:00Z",
  "comexampleextension1":"value",
  "comexampleothervalue":5,
  "datacontenttype":"text/xml",
  "data":"<much wow=\"xml\"/>"
}

centre d'événements

De plus, nous devons avoir un centre d'événements. Le centre événementiel joue un rôle très important dans l'architecture événementielle. C'est comme l'hypermarché de l'économie de marché que nous venons d'évoquer. Toutes les animations, dans cet hypermarché, ont un mode d'emploi détaillé. Chacun peut venir y jeter un coup d'œil. Si vous pensez que cela convient, vous pouvez vous abonner et l'acheter.

En ce qui concerne la gestion du centre d'événements, nous pouvons apprendre beaucoup de la gestion de l'API : nous savons que l'API comprend l'enregistrement, la description du schéma, l'échantillon, la documentation, le SDK, les tests et la surveillance. L'événement, en fait, est le même. Il doit être enregistré dans le centre d'événements pour définir la description du schéma, l'échantillon, le document, le CodeBinding, le test et la surveillance.

De cette façon, lorsque les consommateurs recevront cet événement, ils sauront de quoi il s'agit et comment l'utiliser, afin qu'ils puissent l'utiliser en toute confiance.

Schéma

Le schéma de l'événement est utilisé pour décrire les attributs, les significations et d'autres informations de l'événement. Pourquoi introduisons-nous Schema ? D'une part, afin de permettre à l'aval de comprendre le format de l'événement et de faciliter l'utilisation des événements ; d'autre part, c'est aussi de limiter le format de l'événement envoyé en amont, et tant l'envoi que la modification doivent être Une fois le contrat signé, il ne peut pas être facilement modifié. Nous vous recommandons d'utiliser Json Schema et OpenAPI 3.0.

Filtrage et transformation des événements

En ce qui concerne le filtrage et la conversion des événements, le moteur basé sur les événements RocketMQ fournit une multitude de méthodes de filtrage et de conversion des événements. Je n'entrerai pas dans les détails un par un, vous pouvez les décrire en détail dans l'image ci-dessus.

Architecture technique RocketMQEventBridge

Enfin, le produit événementiel lancé par notre RocketMQ s'appelle EventBridge.Toute son architecture peut être divisée en deux parties : la partie supérieure est notre plan de contrôle, et la partie inférieure est notre plan de données.

Surface de contrôle : Face à l'amont, faites un bon travail dans la gestion des événements. Grâce à EventSource, gérez les événements générés en amont, afin que chacun puisse trouver les événements dont il a besoin et sache comment les utiliser après avoir trouvé les événements ; face à l'aval, les consommateurs peuvent facilement convertir les événements au format requis via EventRule, et le pousser vers vous-même . L'EventBus au milieu est l'endroit où nous stockons les événements. La partie inférieure est notre propre courtier de RocketMQ ; le plan de données : c'est le canal des événements. En plus d'envoyer des événements à EventBus via l'API, nous pouvons également extraire activement des événements vers EventBus . Une fois que le consommateur a créé l'EventRule, l'événement peut être transmis à la cible via le connecteur Sink ; en outre, nous aurons également : le suivi des événements, la lecture des événements, l'analyse des événements, l'archivage des événements, etc.

Bienvenue à vous joindre à nous

Si vous voulez en savoir plus sur EventBridge, vous pouvez cliquer sur le lien ci-dessous, et vous pouvez aussi participer ensemble à la construction de la communauté.

RocketMQ EventBridge：

https://github.com/apache/rocketmq-eventbridge

Adresse de l'expérience de la communauté d'apprentissage RocketMQ

La communauté d'apprentissage RocketMQ est en ligne ! Interaction IA, une seconde pour comprendre le code source des fonctions RocketMQ. La communauté d'apprentissage RocketMQ est la première communauté de services de connaissances basée sur AIGC en Chine, visant à devenir une "seconde personnelle" sur la voie de l'apprentissage RocketMQ.

PS : La communauté RocketMQ utilise les données RocketMQ 5.0 comme principal contenu de formation. Lors des itérations d'optimisation continue, les réponses sont toutes générées par des modèles d'intelligence artificielle. L'exactitude et l'exhaustivité des réponses ne peuvent être garanties, et elles ne représentent pas l'attitude ou l'opinion de la communauté d'apprentissage RocketMQ.

Liens connexes:

[1] Site officiel https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md

Cliquez ici pour découvrir immédiatement la communauté d'apprentissage RocketMQ (un PC est recommandé pour découvrir toutes les fonctionnalités)