Enregistrer des utilisateurs pour des événements, rechercher automatiquement des réponses dans la base de données, communiquer avec le support technique, échanger des contacts - tout cela fait partie des fonctions de notre robot Leader-ID. Il "vit" sur trois plateformes: VK, Facebook Messenger et Telegram, tandis que la logique de son travail est écrite une fois pour toutes en utilisant des abstractions indépendantes de la plateforme. Cette approche vous permet d'ajouter rapidement de nouvelles fonctionnalités et de rectifier les anciennes.
La structure du système rend le développement des fonctions pour différentes plates-formes unifié et simplifie les processus d'un ordre de grandeur par rapport à l'option de les réécrire manuellement dans chaque API dépendante de la plate-forme. Dans le même temps, pour démarrer un bot sur une nouvelle plateforme, il vous suffit d'écrire l'adaptateur (
connecteur ) approprié.
Je voulais parler brièvement de cette structure. Peut-être que cela sera utile à ceux qui veulent écrire leur bot multiplateforme, mais qui n'ont pas encore plongé profondément dans le sujet et tout en étudiant l'expérience de quelqu'un d'autre.
Faisons connaissance avec notre bot. Il peut être trouvé dans
Telegram ,
VK ,
FB , où il sert jusqu'à plusieurs milliers de personnes en même temps (comme cela se produit lors de grands événements). Soit dit en passant, nous pouvons apprendre qui nous sommes et ce que nous faisons à partir de notre
premier article . En bref, nous exploitons un vaste réseau d'espaces de coworking et de présentation gratuits dans toute la Russie et soutenons en même temps la plate-forme de communication
Leader-ID , qui est au cœur de tout le système. Et le bot joue un rôle important dans toute l'histoire.
Double pistolet - double plaisir
En fait, nous avons deux robots. Le premier est le principal, chargé d'interagir avec les utilisateurs. Il s'agit d'un moyen pratique d'enregistrement mobile des utilisateurs pour des événements, d'interaction avec le support et d'obtention d'informations supplémentaires à partir de conférences et de séminaires, ainsi que d'échange de contacts au sein du même écosystème.
Le deuxième bot est essentiellement une interface pour les opérateurs de support. Les bots fonctionnent conjointement, mais leurs bases et interfaces sont séparées.
À l'aide de leur exemple, nous montrerons à quoi pourrait ressembler la structure d'un tel système. Cependant, nous allons commencer à détordre cette balle progressivement, avec des cas simples.
La structure du bot le plus simple
Dans la version de base, le bot consistera en un seul service qui envoie et reçoit des messages via l'API du messager (plateforme) dont nous avons besoin, par exemple Telegram.
Si nous avons plusieurs messagers par lesquels nous voulons communiquer avec les utilisateurs, il serait raisonnable d'écrire une logique dans un style indépendant de la plate-forme avec l'ajout de connecteurs à la structure qui traduisent les commandes et les données du format interne au format de la plate-forme correspondante (messager).
Cela permettra d'ajouter de nouvelles fonctionnalités en un seul endroit et de ne pas les dupliquer séparément pour chaque plate-forme.
Les connecteurs sont des services qui reçoivent des messages de la plate-forme pour les transmettre au noyau et vice versa. En général, ce sont des composants relativement indépendants du système qui, si nécessaire, peuvent être situés sur un serveur distinct, avoir plusieurs répliques, etc.
Nous organisons la communication des connecteurs et du noyau (interrogation de la base de données, ou comment ne pas le faire)
Nous sommes donc confrontés à la tâche d'organiser l'échange de données entre les connecteurs et le cœur. La première option consiste à envoyer de nouveaux messages via la base de données. Nous sommes partis de là. En conséquence, la base de données elle-même apparaît dans notre schéma, et la structure devient comme ceci: un noyau écrit en Python, plus une base sur MongoDB (les raisons de ce choix sont exclusivement historiques), plus des connecteurs.
Ce schéma n'a pas fonctionné pour nous relativement longtemps. Lorsque le nombre de messages a dépassé 700 000 et que la fréquence des pics a atteint 120 visites par seconde, les indices se sont alourdis et les sondages dans la base de données sont devenus beaucoup plus chers. J'ai dû connecter le courtier RabbitMQ ici. Son rôle principal est de générer des notifications qu'un composant (core / connecteur) doit traiter un message avec un identifiant spécifique. Ces identifiants sont transmis par son intermédiaire. RabbitMQ nous a déchargé la base et les composants, qui n'ont plus besoin de vérifier constamment la base de données pour de nouvelles informations à traiter.
En conséquence, notre structure de base a commencé à ressembler à ceci:
Le travail des connecteurs via la base de données a un inconvénient - cela réduit leur indépendance et augmente la connectivité du système. Cependant, si les données sont transférées directement à l'aide du gestionnaire de files d'attente, alors toute la responsabilité de leur sécurité et de leur disponibilité incombe à ce courtier. Comment cela répond aux exigences de fiabilité et de transparence est une question ouverte. Pour nous-mêmes, nous avons décidé de l'expérimenter dans le processus de développement ultérieur du système.
Ajouter des administrateurs
Pour gérer toute la cuisine, vous avez besoin d'une interface administrateur. Avec son aide, nous trouvons les informations nécessaires dans la correspondance, modifions les données, réalisons des enquêtes et des newsletters. Par conséquent, le composant Web apparaît dans notre diagramme. En plus de ce qui précède, il fournit une interface Web pour authentifier les utilisateurs et les API de bot.
Le Web communique avec la base de données et le noyau via des messages système spéciaux. Ils sont acheminés sous forme de texte, ils ne contiennent que des informations non pas sur un nouveau message de l'utilisateur, mais sur un autre événement du système dans son ensemble, auquel le noyau doit répondre. Par exemple, obtenir des codes d'autorisation.
L'interface elle-même pour les administrateurs ressemble à ceci:
Nous connectons les opérateurs via le second bot
Pour implémenter la prise en charge complète des utilisateurs, nous avons connecté les opérateurs au système. Pour maintenir la vitesse de communication avec eux, en l'absence d'alternatives appropriées, Telegram a été choisi comme interface de dialogue principale. Les opérateurs reçoivent des questions des utilisateurs à travers elle et envoient immédiatement des réponses.
Voici à quoi ressemble la boîte de dialogue utilisateur avec le bot principal lors de l'envoi d'une question d'assistance:
La phrase «Question test» dans la capture d'écran est le texte de la question pour le support techniqueEn conséquence, un deuxième bot (Support Bot) apparaît sur notre circuit avec son noyau et son connecteur Telegram. Il communique avec le noyau principal et organise le transfert des questions et réponses entre les chats avec les utilisateurs et les chats dans lesquels les agents de support sont assis.
Il possède également sa propre base de données. Mais la communication avec l'utilisateur final passe par le cœur du bot principal, qui contrôle le flux global des messages.
Voici à quoi ressemble le dialogue de l'opérateur avec un bot d'assistance qui redirige les messages des utilisateurs:
Dans notre cas, les opérateurs sont divisés en deux catégories: ceux qui s'occupent de l'assistance générale aux utilisateurs et ceux qui sont responsables de la prise en charge des points d'ébullition ou des événements individuels. Cependant, cela n'a aucun effet sur la structure.
Que peut faire d'autre notre robot?
Ces informations ne concernent que notre pratique, mais elles seront peut-être intéressantes en tant que sélection d'idées simples dont vous pourrez prendre note.
Échange de contactsIl est effectué par la numérisation et la reconnaissance des codes QR personnels du bot. Pour ce faire, le processeur d'images par défaut est ajouté au noyau. Les images sont envoyées par des connecteurs, qui les enregistrent dans la base de données avec le message.
La reconnaissance du code QR est également utilisée pour fournir à l'utilisateur des informations supplémentaires ou des fichiers de séminaires. Cela ressemble à ceci:
Envoi de notification
Grâce au panneau de configuration du module Web, nous pouvons envoyer des notifications aux participants de divers événements.
Réalisation d'enquêtesDe même, des enquêtes sont menées lors des cours. Mais pour eux, nous générons toujours manuellement un fichier JSON avec logique, que nous téléchargeons sur le Web.
Les questions peuvent être à la fois avec des réponses et ouvertes. Et la structure de l'enquête peut varier en fonction des réponses.
Réponses automatiquesLe bot peut sélectionner indépendamment les réponses aux questions fréquemment posées.
Pour ce faire, nous avons une base spéciale, réapprovisionnée manuellement. Si rien ne s'y trouve trouvé ou que l'utilisateur n'est pas satisfait de la réponse choisie, son appel via le bot de support est redirigé vers les opérateurs.
En général, alors que c'est toute notre histoire. En ce moment, nous travaillons à étendre les fonctions de mise en réseau et nous espérons que dans un proche avenir notre bot deviendra un peu plus «gras», tandis que sa structure restera la même.