Architectures micronoyau et à plug-ins

Définition et origine

Une architecture micronoyau, aussi appelée architecture à plug-ins, divise une application en deux sortes de parties : un système central qui contient les fonctionnalités minimales et générales nécessaires pour fonctionner, et des plug-ins qui ajoutent ou modifient des comportements sans que le noyau soit modifié. Les plug-ins ne se connectent au noyau que par des contrats publiés, et le noyau les trouve au moyen d’un registre. Mark Richards et Neal Ford le cataloguent parmi les styles d’architecture classiques dans Fundamentals of Software Architecture, et il correspond à la description d’un style architectural donnée à la section 5.1 : un ensemble nommé de contraintes portant sur les éléments (noyau, plug-ins) et les connecteurs (contrats) d’un système.

L’idée est née dans les logiciels produits : des outils installés par de nombreux clients, chacun voulant quelque chose de légèrement différent. Plutôt que de maintenir une version distincte pour chaque client, l’éditeur livre un seul noyau et laisse les clients, les partenaires ou ses propres équipes ajouter des plug-ins. Les environnements de développement intégrés, les navigateurs web, les éditeurs graphiques et les logiciels de comptabilité fonctionnent tous ainsi. Le nom est emprunté aux systèmes d’exploitation, où un micronoyau est un très petit noyau autour duquel tout le reste s’exécute à l’extérieur ; les deux idées sont liées mais ne doivent pas être confondues, comme expliqué plus loin.

Une application micronoyau forme normalement une seule unité de déploiement ; elle appartient donc aux styles monolithiques de ce chapitre : une seule unité de déploiement, un seul processus, un seul ensemble de préoccupations d’exploitation. Les plug-ins peuvent être installés séparément, mais à l’exécution ils vivent à l’intérieur du noyau, ou juste à côté.

Fonctionnement : noyau, plug-ins, registre et contrats

Le système central contient ce dont chaque installation a besoin : le flux de travail principal, des services partagés comme la journalisation ou la configuration, et les points d’extension où se branchent les plug-ins. Richards et Ford le décrivent comme le chemin nominal à travers l’application, avec peu ou pas de traitement personnalisé ; dans l’étape de paiement d’une plateforme de livraison de repas, cela consiste à calculer le prix d’un panier, encaisser le paiement et confirmer la commande. Un bon noyau est volontairement ennuyeux. Chaque cas particulier qui varie selon le client, le pays ou la gamme de produits est un candidat à en sortir.

Les plug-ins sont des modules indépendants et autonomes qui contiennent un traitement spécialisé. Ils ne doivent dépendre que du contrat, ni les uns des autres ni des classes internes du noyau. Quand un plug-in a besoin de quelque chose qu’un autre fournit, ce besoin doit être satisfait par le noyau (sous la forme d’un service qu’il expose par le contrat), ou bien les deux plug-ins doivent être fusionnés ; les dépendances de plug-in à plug-in transforment discrètement une étoile bien nette en enchevêtrement.

Le registre enregistre quels plug-ins sont disponibles, comment chacun s’appelle, quelle est sa version, quel contrat il implémente et comment l’atteindre. Il peut être aussi simple qu’un dictionnaire rempli au démarrage, un répertoire que le noyau parcourt à la recherche de manifestes, des entrées dans les métadonnées d’un paquet (comme avec les points d’entrée Python), une table de base de données ou un service distant qui liste des plug-ins déployés ailleurs. C’est le registre qui permet au noyau de dire « donne-moi les règles fiscales de l’Allemagne » sans savoir qu’une classe appelée GermanTax existe.

Les contrats définissent ce qu’un plug-in doit fournir et ce sur quoi il peut compter : une interface avec des signatures de méthodes, les structures de données qui la traversent, le comportement en cas d’erreur et une version. Dans Eclipse, un contrat est un point d’extension déclaré dans le manifeste d’un plug-in avec un schéma ; dans Visual Studio Code, c’est l’API d’extension plus les points de contribution listés dans le package.json d’une extension ; dans votre propre code, c’est généralement une interface (ou un Protocol Python) placée dans un petit paquet à part. Lorsque le plug-in vient d’une autre organisation et ne peut pas suivre votre contrat, un adaptateur fait la traduction entre les deux, exactement comme dans l’architecture hexagonale.

Les plug-ins peuvent être connectés de trois façons. Les appels point à point, dans le processus sont la norme : le noyau appelle une méthode sur l’objet plug-in. Les plug-ins en processus séparé s’exécutent dans leur propre processus et communiquent avec le noyau par des messages interprocessus, ce qui protège le noyau des plantages. Les plug-ins distants se trouvent derrière une interface HTTP ou de messagerie ; cela permet des plug-ins écrits dans d’autres langages ou détenus par d’autres équipes, mais ajoute de la latence réseau et des modes de défaillance, et le système commence à ressembler aux styles distribués du chapitre 6.

Exemples réels

Eclipse. L’IDE Eclipse est le cas d’école. Son noyau n’est guère plus qu’un plan de travail et un runtime de plug-ins (bâti sur Equinox, une implémentation de la spécification du framework OSGi). Presque tout ce que voit un développeur, des outils Java à l’intégration de la gestion de versions, est un plug-in. Chaque plug-in possède un manifeste qui déclare ce dont il a besoin, quels points d’extension il offre aux autres et à quelles extensions il se branche. Les plug-ins sont activés de façon paresseuse, seulement quand quelque chose en a réellement besoin, afin que des centaines de plug-ins installés ne ralentissent pas le démarrage.

Visual Studio Code. Les extensions déclarent des événements d’activation (ouvrir un fichier Markdown, exécuter une commande) afin de ne se charger qu’en cas de besoin, et apportent des commandes, des langages, des thèmes et des vues par leur manifeste. Les extensions s’exécutent dans un processus hôte d’extensions séparé, si bien qu’une extension défaillante ne peut pas figer l’interface utilisateur de l’éditeur. C’est un bon exemple de choix de l’isolation par processus pour un écosystème de plug-ins qui compte des milliers d’auteurs tiers.

Navigateurs web. Les extensions de navigateur utilisent un ensemble standard d’API d’extension et doivent déclarer dans un manifeste les permissions dont elles ont besoin (quels sites elles peuvent lire, si elles peuvent voir les onglets ou les téléchargements). Le navigateur fait respecter ces permissions, car on ne peut pas, par défaut, faire confiance aux auteurs d’extensions.

Moteurs de règles métier. Le système de gestion des sinistres d’un assureur peut garder le flux de traitement des sinistres dans le noyau et placer les règles de chaque juridiction (ce qui est couvert, quels documents sont nécessaires, délais légaux) dans des plug-ins. Les moteurs fiscaux, les systèmes de paie et les plateformes de commerce en ligne dotées de plug-ins de moyens de paiement suivent le même modèle : un processus stable, avec des règles ou des prestataires qui varient selon le pays, le produit ou le client.

Outils de développement. Le framework de test pytest est construit autour de la bibliothèque de plug-ins pluggy ; nombre de ses propres fonctionnalités sont implémentées sous forme de plug-ins utilisant les mêmes hooks que ceux qu’utilisent les tiers. Les outils de build, les linters et les générateurs de sites statiques font couramment de même.

Isolation, versionnage et compatibilité des plug-ins

Trois questions décident si une architecture à plug-ins reste saine au fil des années : à quel point les plug-ins sont isolés, comment le contrat évolue, et comment l’incompatibilité est détectée.

Isolation. Les plug-ins internes au processus partagent la mémoire, les threads et les permissions du noyau. C’est rapide et simple, mais un seul plug-in avec une boucle infinie, une fuite mémoire ou une faille de sécurité affecte tout. Les options, par ordre croissant d’isolation et de coût, sont : dans le processus avec des appels défensifs (délais d’expiration, capture des exceptions plug-in par plug-in, limites de ressources) ; un processus ou un worker séparé par plug-in ou par groupe de plug-ins ; une sandbox (bac à sable), comme un runtime WebAssembly ou un interpréteur restreint, qui limite ce que le code du plug-in peut toucher ; et un service distant. Choisissez en vous demandant qui écrit les plug-ins. Les règles fiscales de votre propre équipe peuvent s’exécuter dans le processus ; du code arbitraire provenant d’une place de marché publique ne le devrait pas.

Versionnage. Le contrat est une API, et les règles de la section 0.6 sur les changements cassants s’appliquent. Versionnez le contrat séparément du noyau, généralement avec le versionnage sémantique : une nouvelle version majeure pour les changements cassants, une version mineure pour les ajouts rétrocompatibles. Laissez chaque plug-in déclarer pour quelle version du contrat il a été construit, et laissez le noyau déclarer quelles versions il prend en charge. Les changements additifs (nouveaux champs facultatifs, nouveaux hooks facultatifs) permettent aux anciens plug-ins de continuer à fonctionner ; quand un changement cassant est inévitable, prenez en charge l’ancienne et la nouvelle version majeure côte à côte pendant une période de dépréciation annoncée.

Vérifications de compatibilité. Vérifiez la compatibilité au chargement des plug-ins, pas au moment où un client les déclenche pour la première fois. Un registre qui refuse un plug-in incompatible au démarrage, avec un message de journal clair, transforme un bogue à l’exécution en échec de déploiement. L’observation de Hyrum Wright, connue sous le nom de loi de Hyrum, mérite d’être retenue ici : avec suffisamment d’utilisateurs, chaque comportement observable d’une interface finira par être utilisé par quelqu’un, quoi que dise la documentation. Gardez le contrat petit, gardez les éléments internes du noyau hors d’atteinte (Eclipse marque pour cette raison les paquets hors API comme internal), et traitez tout ce qui est visible par les plug-ins comme faisant partie du contrat.

Quand l’utiliser, et quand l’éviter

Bons cas d’usage. Les logiciels produits que de nombreux clients installent et personnalisent. Les systèmes au flux de travail stable mais avec de nombreuses variantes d’une étape : fiscalité et paie par pays, règles d’assurance par juridiction, moyens de paiement, importateurs de formats de fichiers, transporteurs. Les plateformes qui veulent un écosystème de tiers. Les systèmes où un régulateur ou un client modifie souvent les règles et où vous voulez que ces modifications soient de petites mises en production testées séparément. Le style fonctionne aussi au sein d’un système plus vaste : un service d’une architecture distribuée peut lui-même être un micronoyau.

Mauvais cas d’usage. Les systèmes dont vous ne savez pas encore ce qui varie. Des points d’extension conçus à l’avance pour des besoins imaginés relèvent de la généralité spéculative : ils ajoutent de la mécanique, ralentissent l’équipe et se trouvent généralement au mauvais endroit quand le vrai besoin arrive (voir la discussion sur la réversibilité à la section 1.6). Les systèmes qui exigent une très grande scalabilité ou une isolation des pannes, puisque l’ensemble passe à l’échelle et tombe en panne comme une seule unité. Les systèmes où les plug-ins devraient se coordonner étroitement entre eux, ce qui annule le principal avantage du style.

Une règle pratique : attendez d’avoir construit deux ou trois fois le même type de variation, puis extrayez le contrat à partir des cas réels. Un contrat dérivé de trois implémentations fiscales qui fonctionnent sera bien meilleur qu’un contrat deviné avant la première.

# package: tax_contract  (version 2.1.0)
from dataclasses import dataclass
from decimal import Decimal
from typing import Protocol

CONTRACT_VERSION = (2, 1)

@dataclass(frozen=True)
class TaxLine:
    sku: str
    category: str      # "hot-food", "cold-food", "alcohol", "delivery-fee"
    net: Decimal       # never float for money

@dataclass(frozen=True)
class TaxResult:
    total_tax: Decimal
    breakdown: dict[str, Decimal]   # label shown on the receipt

class TaxRules(Protocol):
    country: str                    # ISO 3166-1 alpha-2, e.g. "DE"
    requires_contract: tuple[int, int]
    def calculate(self, lines: list[TaxLine], region: str | None) -> TaxResult: ...

from importlib.metadata import entry_points
from tax_contract import CONTRACT_VERSION

class UnsupportedCountry(Exception): pass

class TaxRegistry:
    def __init__(self, log):
        self._by_country = {}
        for ep in entry_points(group="fooddelivery.tax_rules"):
            plugin = ep.load()()
            major, minor = plugin.requires_contract
            if major != CONTRACT_VERSION[0] or minor > CONTRACT_VERSION[1]:
                log.warning("skipping %s: needs contract %s", ep.name, plugin.requires_contract)
                continue
            self._by_country[plugin.country] = plugin

    def for_country(self, country):
        if country not in self._by_country:
            raise UnsupportedCountry(country)   # fail loudly, never guess a rate
        return self._by_country[country]

Faire respecter le style dans le code

Une architecture à plug-ins ne le reste que si ses règles sont vérifiées automatiquement. La structure qui fonctionne dans la plupart des langages comporte trois sortes de paquets : un petit paquet de contrat ne contenant que des interfaces et des types de données ; le noyau, qui dépend du contrat ; et un paquet par plug-in, chacun dépendant du contrat et de rien d’autre parmi votre code.

Faites ensuite respecter les règles de dépendance avec des outils du type présenté à la section 3.4 : en Python, import-linter peut interdire au noyau d’importer un paquet de plug-in et interdire aux plug-ins de s’importer entre eux ou d’importer le noyau ; en Java, des tests ArchUnit ou des systèmes de modules (JPMS, OSGi) peuvent faire de même. Faites échouer le build quand une règle est enfreinte.

Ajoutez une suite de tests de contrat : un ensemble de tests écrits une fois pour toutes par rapport au contrat et exécutés contre chaque plug-in dans le pipeline propre à ce plug-in. Elle vérifie le comportement que promet le contrat (arrondis, entrée vide, types d’erreur), et non le droit fiscal de chaque pays, que couvrent les tests propres au plug-in. Enfin, ajoutez une vérification au démarrage ou un test de fumée (smoke test) de déploiement qui charge chaque plug-in installé et vérifie sa version de contrat, afin que les incompatibilités soient détectées avant que les utilisateurs ne les découvrent.