Tous nos microservices, quelle que soit la façon dont ils communiquent les uns avec les autres, fournissent une sorte d'interface de battement de cœur afin que le système de surveillance puisse à tout moment découvrir comment c'est; comme l'état de santé général et certaines particularités, par exemple, les sommes de contrôle pour les données internes avec lesquelles ils traitent. Il ne s'agit pas du transport principal: ici RabbitMQ et Redis font très bien.
Et parfois, il est logique de fournir l'interface la plus simple ( HTTP ) pour exporter les données pertinentes. En pensant dans cette direction aussi, à long terme, je veux me débarrasser complètement de Redis au profit d'une solution interne pour stocker les paires clé-valeur, comme nous l'avons fait avec succès il y a exactement deux ans avec PubSub .
Par conséquent, au lieu de réinventer les vélos avec chaque nouveau microservice, j'ai décidé de créer une bibliothèque de plug-ins qui pourrait résoudre ce problème peu sophistiqué de fournir des données arbitraires à partir de n'importe quelle application avec zéro code (à l'exception de trois lignes dans config.exs ). Que ce soit un simple battement de cœur ( HTTP 200 OK ), ou une longue liste de taux de change actuels.
La solution est basée sur ce tweet de Dave Thomas .
Serveur API JSON en poids de plume
Camarero est une solution prête à l'emploi pour ajouter certaines fonctions de l'API JSON à une application existante ou même pour implémenter une API JSON pas si compliquée à partir de zéro lorsque des solutions plus complexes (lire: lourdes) ne sont pas souhaitables. L'image ci-dessous montre comment, dans un cas typique, nous pouvons nous connecter et l'utiliser.
La bibliothèque n'a nullement été conçue pour se substituer à des solutions à part entière comme le Phoenix. Pas du tout, non. Il s'agit simplement d'un tel ajout, lorsque le microservice a juste besoin d'exposer quelques API API HTTP. Camarero , dans certains cas, peut être un bon candidat pour remplacer Redis , ou tout autre magasin de valeurs clés (également dans son groupe de poids). La principale différence avec ce type de solution Web est que cette bibliothèque est très rapide.
Voici les temps de réponse HTTP pour renvoyer une valeur de clé à partir d'une table de hachage avec un million de clés.
Oui, il n'y a pas de prise. Le temps de réponse HTTP pour une requête via kv-stockage avec un million de valeurs est de plusieurs dizaines de microsecondes dans le pire des cas.
Détails d'implémentation
On suppose que Camarero se connecte à une application en cours d'exécution simplement en activant la bibliothèque et trois lignes dans le fichier de configuration. Il traite les routes configurées, déléguant l'exécution aux modules de gestion désignés. La configuration la plus simple pourrait ressembler à ceci:
config :camarero, carta: [Camarero.Carta.Heartbeat], root: "api/v1"
C'est tout, et donc, probablement, c'est clair: /api/v1 - la racine du serveur Web, une route de heartbeat (configurée par défaut à l'intérieur du module - le nom sans préfixe) - avec le gestionnaire Camarero.Carta.Heartbeat . Les gestionnaires peuvent également être ajoutés dynamiquement lors de l'exécution à l'aide d'appels à Camarero.Catering.route! .
Gestionnaires
Un gestionnaire est un module qui implémente le comportement Camarero.Plato . Il se compose de méthodes de manipulation de référentiel CRUD standard. Pour une utilisation en tant que gestionnaire pour les requêtes HTTP entrantes, tout module qui implémente ce comportement convient.
Il existe un ajustement encore plus fin: le comportement Camarero.Tapas , qui gère le CRUD à l'intérieur de chaque conteneur Camarero.Plato , pour une paire clé / valeur. Habituellement, vous n'avez pas besoin de creuser aussi profondément lorsque vous utilisez la bibliothèque.
L'implémentation par défaut utilise la carte %{} comme conteneur et semble assez compacte:
defmodule Camarero.Carta.Heartbeat do use Camarero.Plato end
Il s'agit d'un module Heartbeat pur et non Heartbeat , inclus par défaut dans la bibliothèque. Des utilisations moins triviales sont décrites dans la documentation .
Réglage fin
Sans exception, toutes les méthodes des deux implémentations par défaut ( Camarero.Tapas et Camarero.Plato ) sont facilement redéfinies. Par exemple, pour utiliser un itinéraire personnalisé pour un module, ainsi qu'un conteneur personnalisé, vous pouvez effectuer les opérations suivantes:
defmodule Camarero.Carta.Heartbeat do use Camarero.Plato, container: %MyStructWithAccessBehaviour{} @impl true def plato_route(), do: "internal/heartbeat" end
Configuration du serveur Web
Camarero a besoin d'un serveur Cowboy2 et de CowboyPlug pour fonctionner . Voici une configuration typique de Cowboy2 dans config.exs :
config :camarero, cowboy: [port: 4043, scheme: :https, options: []]
Ce que Camarero ne prétend pas
Cette bibliothèque ne prétend nullement rivaliser avec des solutions complexes. Il n'y figure pas et, presque certainement, il n'y aura jamais d'autorisation ou d'authentification, c'est-à-dire que nous ne l'utilisons que pour des services à l'intérieur d'un cloud privé.
Tous les modules de traitement sont générés, donc, à l'exception de la surcharge d'interface, aucun réglage supplémentaire n'est possible. Cela se fait aussi délibérément.
Mais il est plus rapide que tous les analogues dans tous les benchmarks .
Bonne réponse rapide!