Apprendre à communiquer entre microservices sur Node.js via RabbitMQ

Il s'agit d'une continuation de l'article " Nous écrivons le premier microservice sur Node.js avec communication via RabbitMQ ", qui a été bien accueilli par les utilisateurs du Habr.

Dans cet article, je parlerai de la façon de communiquer correctement entre les microservices afin que les microservices restent isolés.

Comment ne pas le faire

Pourquoi avez-vous besoin de communiquer entre microservices? Utilisez une seule base de données, lisez à partir de là ce que vous voulez - quelque chose d'affaires!

Non, tu ne peux pas faire ça. Le concept des microservices est qu'ils sont isolés les uns des autres, personne ne sait rien de quiconque (pratiquement). Très probablement, à l'avenir, lorsque le système commencera à se développer, vous voudrez étendre les fonctionnalités et vous devrez communiquer entre les microservices: par exemple, un utilisateur a acheté un produit, vous devez donc envoyer une notification de vente au vendeur.

Avantages de l'isolation

Fiabilité

Supposons qu'il existe une application monolithique dans laquelle il existe plusieurs contrôleurs:

1. Les produits
2. Remises
3. Le blog
4. Les utilisateurs

Un beau jour, notre base de données tombe en panne: nous ne pouvons plus obtenir de produits, pas de remises, pas de billets de blog, pas d'utilisateurs. Le site est complètement indisponible, les clients ne peuvent pas se connecter, l'entreprise perd des bénéfices.

Que se passera-t-il dans l'architecture de microservices?

Dans un autre univers, le même jour que la base de données des microservices des utilisateurs tombe, elle devient inaccessible: les utilisateurs ne peuvent pas se déconnecter, s'inscrire et se connecter. Il semblerait que tout va mal et que l’entreprise perd également des bénéfices, mais non: les acheteurs potentiels peuvent consulter les produits disponibles, lire le blog de l’entreprise et trouver des remises.

Étant donné que chaque microservice possède sa propre base de données, les effets secondaires deviennent beaucoup moins importants.

C'est ce qu'on appelle la dégradation progressive .

Abstraction

Dans une grande application, il est très difficile de se concentrer sur une seule tâche, car la modification d'un petit middleware peut casser une sorte de contrôleur. Vous voulez utiliser le nouveau client pour redis - non, vous ne pouvez pas, ce contrôleur que nous avons écrit il y a trois ans utilise la version 0.1.0. Vous voulez enfin profiter des nouvelles fonctionnalités de Node.js 10? Ou peut-être 12? Désolé, mais le monolithe utilise la version 6.

Comment communiquer

Depuis que nous avons commencé à parler de l'exemple "un utilisateur a acheté un produit, nous envoyons un avis de vente au vendeur", puis nous allons le mettre en œuvre.

Le schéma est le suivant:

1. L'utilisateur envoie une demande au marché des microservices pour acheter des choses sur le lien / marché / acheter /: id
2. Le drapeau est écrit dans la base de données que le produit est vendu
3. Depuis le marché des microservices, une demande est envoyée aux notifications de microservices, auxquelles les clients sont connectés via WebSocket
4. Les notifications de microservices envoient un message au vendeur sur la vente de choses

Installer MicroMQ

$ npm i micromq@1 -S 

Écrire une passerelle

 const Gateway = require('micromq/gateway'); //   const gateway = new Gateway({ microservices: ['market'], rabbit: { url: process.env.RABBIT_URL, }, }); //        market gateway.post('/market/buy/:id', (req, res) => res.delegate('market')); //      gateway.listen(process.env.PORT); 

Notre passerelle se compose d'un seul point de terminaison, mais cela suffit par exemple pour la formation.

Rédaction d'une notification de microservice

 const MicroMQ = require('micromq'); const WebSocket = require('ws'); //   const app = new MicroMQ({ name: 'notifications', rabbit: { url: process.env.RABBIT_URL, }, }); //        const ws = new WebSocket.Server({ port: process.env.PORT, }); //     const clients = new Map(); //    ws.on('connection', (connection) => { //     connection.on('message', (message) => { //  ,       . //      try/catch,    json! const { event, data } = JSON.parse(message); //   'authorize'         if (event === 'authorize' && data.userId) { //         clients.set(data.userId, connection); } }); }); //       , //    ! ws.on('close', ...); //   notify,      app.action('notify', (meta) => { //      ,    400 if (!meta.userId || !meta.text) { return [400, { error: 'Bad data' }]; } //     const connection = clients.get(meta.userId); //     ,    404 if (!connection) { return [404, { error: 'User not found' }]; } //    connection.send(meta.text); //  200   return { ok: true }; }); //   app.start(); 

Ici, nous élevons le serveur de socket Web et le microservice en même temps pour recevoir des demandes pour les sockets Web et RabbitMQ.

Le schéma est le suivant:

1. Un utilisateur se connecte à notre serveur de socket Web
2. L'utilisateur est autorisé en envoyant un événement d' authorize avec son userId à l'intérieur
3. Nous gardons la connexion de l'utilisateur afin que vous puissiez lui envoyer des notifications à l'avenir
4. Un événement arrive sur RabbitMQ dont vous devez envoyer une notification à l'utilisateur
5. Vérification de la validité des données entrantes
6. Obtenir une connexion utilisateur
7. Envoyer une notification

Écrire un marché de microservices

 const MicroMQ = require('micromq'); const { Items } = require('./api/mongodb'); //   const app = new MicroMQ({ name: 'market', rabbit: { url: process.env.RABBIT_URL, }, }); //      app.post('/market/buy/:id', async (req, res) => { const { id } = req.params; //      const item = await Items.findOne({ id, isSold: false }); //   ,  404 if (!item) { res.status(404).json({ error: 'Item not found', }); return; } //  ,    ,    await Items.updateOne({ id, }, { $set: { isSold: true, }, }); //     ,    req.app.ask('notifications', { server: { action: 'notify', meta: { userId: item.sellerId, text: JSON.stringify({ event: 'notification', data: { text: `Item #${id} was sold!`, }, }), }, }, }) //  ,      .catch(err => console.log('Cannot send message via notifications microservice', err)); //    ,     res.json({ ok: true, }); }); //   app.start(); 

Le schéma est le suivant:

1. Nous recevons une demande de l'utilisateur pour l'achat d'un article
2. Nous recherchons l'article avec le bon identifiant et nous assurons qu'il n'est pas encore vendu
3. Marquer l'article comme vendu
4. Nous envoyons une notification au vendeur sur la vente en arrière-plan
5. Nous répondons au client

Vérifier

1. Nous démarrons 3 processus
2. Nous enverrons POST / market / buy / 1
3. Nous obtenons la réponse { ok: true }
4. Le vendeur reçoit une notification

 $ PORT=9000 node ./src/gateway.js $ PORT=9001 node ./src/notifications.js $ MONGODB_URL=mongodb://localhost:27017/my-super-microservice node ./src/market.js 

• Lien vers le code source de la bibliothèque
• Lien vers le package dans le registre NPM