Cloud Ready

Test de santé

Les tests de santé, ou health checks en anglais, permettent de connaître l’état de santé d’une application. Ils font partie de la spécification Microprofile Health et sont fournis par l’extension SmallRye Health.

Ils peuvent être utilisés dans un déploiement cloud ou au sein d’un orchestrateur de conteneurs pour connaître l’état de l’application et décider, par exemple, de la redémarrer ou de l’exclure du trafic HTTP.

Pour ajouter l’extension SmallRye Health à un projet existant, vous pouvez utiliser :

quarkus extension add quarkus-smallrye-health 

mvn quarkus:add-extension \ 
    -Dextension=quarkus-smallrye-health 

Ces commandes ajouteront la dépendance Maven suivante au fichier pom.xml :

<dependency> 
    <groupId>io.quarkus</groupId> 
    <artifactId>quarkus-smallrye-health</artifactId> 
</dependency> 

L’ajout de l’extension suffit pour avoir un état de santé pour une application, mais celui-ci sera vide : il ne contiendra aucun test (check en anglais).

Cet état de santé sera disponible à l’URL http://localhost:8080/q/health qui retournera...

Métrologie

L’extension Micrometer permet la génération de métriques pour une application.

SmallRye Metrics, qui implémente Microprofile Metrics, est aussi supportée mais est dépréciée. Il est possible d’utiliser les annotations fournies par Microprofile Metrics avec Micrometer qui est l’implémentation conseillée de métriques dans Quarkus.

Micrometer supporte plusieurs registres (registry en anglais) de métriques ; nous allons exploiter le registre Prometheus qui est le plus utilisé.

D’autres registres sont disponibles dans le pack d’extension Micrometer registry extensions dont la documentation se trouve ici : https://quarkiverse.github.io/quarkiverse-docs/quarkus-micrometer-registry/dev. Ceux-ci couvrent les principaux fournisseurs cloud et systèmes de métriques open source.

Pour ajouter l’extension Micrometer avec le registre Prometheus à un projet existant, vous pouvez utiliser :

quarkus extension add micrometer-registry-prometheus 

mvn quarkus:add-extension \ 
    -Dextension=micrometer-registry-prometheus 

Ces commandes ajouteront la dépendance Maven suivante au fichier pom.xml :

<dependency> 
    <groupId>io.quarkus</groupId> ...

OpenTracing et OpenTelemetry

OpenTracing est une spécification pour les traces distribuées. Quarkus la supporte via l’extension SmallRye OpenTracing dont la dépendance Maven est io.quarkus:quarkus-smallrye-opentracing.

Les traces distribuées permettent le suivi de bout en bout d’une transaction utilisateur en instrumentant les différents composants qui en font partie. Chaque composant crée un span au sein de cette transaction.

OpenTracing est dépréciée au profit d’OpenTelemetry qui est une spécification englobant les traces distribuées, les métriques et les logs. Quarkus ne supporte à ce jour que les traces distribuées via OpenTelemetry.

L’extension OpenTelemetry supporte plusieurs exportateurs. Nous allons utiliser celui qui permet d’exporter les traces au format OTLP (OpenTelemetry Protocol), protocole standard d’export proposé par la spécification OpenTelemetry. Cet exportateur est compris par défaut dans l’extension OpenTelemetry de Quarkus.

Pour ajouter l’extension OpenTelemetry à un projet existant, vous pouvez utiliser :

quarkus extension add opentelemetry 

mvn quarkus:add-extension \ 
    -Dextension=opentelemetry 

Ces commandes ajouteront la dépendance Maven suivante...

Tolérance à la panne

Lors de la création d’un système distribué, un des plus grands challenges est la communication entre les différents composants de ce système. Par nature, cette communication est peu fiable car elle passe par le réseau et est dépendante de l’état des différents composants.

Nous avons donc besoin de mécanismes de résilience pour éviter qu’une panne d’un service externe ou du réseau mette en danger un autre composant. Pour faciliter le développement d’applications tolérantes à la panne, ou résilientes, Quarkus fournit l’extension SmallRye Fault Tolerance qui est une implémentation de la spécification MicroProfile Fault Tolerance.

Pour ajouter l’extension SmallRye Fault Tolerance à un projet existant, vous pouvez utiliser la ligne de commande de la CLI Quarkus suivante :

quarkus extension add smallrye-fault-tolerance 

ou la ligne de commande Maven suivante :

mvn quarkus:add-extension -Dextension=smallrye-fault-tolerance 

Ces commandes ajouteront la dépendance Maven suivante au fichier pom.xml :

<dependency> 
    <groupId>io.quarkus</groupId> 
    <artifactId>quarkus-smallrye-fault-tolerance</artifactId> 
</dependency> 

Pour tester cette extension, nous allons modifier le endpoint ProductResource pour générer artificiellement des pannes :

@Path("/products") 
public class ProductResource { 
 
    // stockage de la liste des produits 
    Map<String, Product> products = new ConcurrentHashMap<>(); 
 
    private AtomicLong invocationCounter = new AtomicLong(0); 
 
    @GET 
    public Collection<Product> list() { 
        // génère une panne 50% du temps 
        if (new Random().nextBoolean()) { 
            throw new RuntimeException("Panne !"); 
        } 
        return...

Service discovery et load balancing client

Service discovery, ou découverte de service en français, est le mécanisme par lequel un composant A va découvrir à l’exécution la ou les adresses d’un composant B. Ce mécanisme se base le plus souvent sur un annuaire de services qui sera interrogé pour résoudre l’adresse physique d’un service depuis un nom logique.

Load balancing, ou répartition de charge en français, est le mécanisme par lequel plusieurs instances d’un composant vont se répartir la charge, c’est-à-dire le nombre de requêtes ou de messages à traiter.

Il existe de nombreuses solutions de load balancing côté serveur : load balancer du fournisseur cloud, solution dédiée payante, plugin de serveur web...

On parle de load balancing client quand la répartition de la charge, au lieu d’être faite par un composant spécifique, est faite par le client qui appelle le service distant. Ce client devra alors connaître les adresses physiques des différentes instances du service distant et utiliser un algorithme de répartition de charge pour sélectionner celle à appeler. Un exemple d’algorithme de répartition de charge est le round-robin où chaque instance est sélectionnée à tour de rôle.

Pour réaliser une répartition de charge côté client, il est nécessaire de connaître la liste des adresses physiques d’un service distant. La plupart du temps, une solution de service discovery sera utilisée à cette fin.

L’extension SmallRye Stork fournit des fonctionnalités de service discovery et de load balancing client à Quarkus. C’est une dépendance de l’extension REST Client, il n’est donc pas nécessaire de l’ajouter au fichier pom.xml.

Pour référence...