La moitié des bugs de connexion « fonctionne en développement, casse en production » se résument à la même chose : les détails de connexion ont été orthographiés de trois façons différentes à trois endroits différents. Le appsettings.json avait une liste d'hôtes, le runbook d'exploitation en a collé une autre dans une session PowerShell, et la chaîne copiée d'un wiki avait un token périmé incrusté en dur.

Zaris élimine toute cette catégorie de problèmes avec un format de chaîne de connexion unique et indépendant de la plateforme. La même chaîne exacte fonctionne quand votre application .NET la lit depuis la configuration, quand un opérateur la passe à une cmdlet PowerShell, et quand quelqu'un la copie directement depuis la console web. Une orthographe canonique, partout.

Cet article décompose la chaîne partie par partie, montre les trois façons de l'utiliser, et plaide pour la seule règle qui compte le plus en production : ne jamais mettre un token brut dans la chaîne.

Le moyen le plus sûr de garantir que TLS sera contourné est d'imposer un unique modèle de confiance à tout le monde. Un développeur qui exécute un store sur un ordinateur portable ne veut pas monter une CA. Une banque dont la racine hors ligne est dans un HSM ne veut pas du tout que votre outil frappe des certificats. Livrez un store qui ne connaît qu'un seul de ces cas, et la moitié de vos utilisateurs désactiveront la sécurité pour faire leur travail.

Zaris ne choisit donc pas à votre place. Sa confiance TLS est enfichable selon quatre modes d'autorité de certification, du self-signed zéro-configuration jusqu'aux certificats que vous provisionnez entièrement hors bande. Vous choisissez le mode qui correspond à la PKI que vous exploitez déjà, et Zaris s'y insère au lieu de vous demander de tout reconstruire autour de lui. TLS n'est pas une solution universelle, et le traiter ainsi est précisément la raison pour laquelle la sécurité est repoussée.

Mettre un store distribué sur Kubernetes est facile. L'y mettre avec TLS activé, atteignable depuis l'extérieur du cluster, et un client qui se connecte réellement est là où la plupart des tutoriels s'arrêtent discrètement. Zaris fournit un chart Helm, et nous avons validé tout le chemin — y compris la configuration sécurisée et atteignable de l'extérieur — de bout en bout sur un cluster local.

Cet article est ce tutoriel. Nous l'exécutons sur kind (Kubernetes-in-Docker) afin que vous puissiez reproduire chaque étape sur un ordinateur portable, et nous prenons la route la plus difficile à dessein : TLS activé, certificats avec les bons subject alternative names, accès externe activé, et un client se connectant via le point d'accès sécurisé. Nous appelons cela la configuration Model B — atteignable de l'extérieur et sécurisée, par opposition à un cluster interne uniquement.

Une règle d'exactitude accroche presque chaque premier déploiement, et elle n'a rien à voir avec les certificats : le nom du store dans votre chaîne de connexion doit être égal au clusterId du déploiement. Nous signalerons exactement où cela mord. Tout le reste est identique sur un cluster de production — kind nous offre simplement un endroit propre et jetable pour le prouver.

Exécutez Zaris dans Kubernetes et le chemin heureux est simple : les clients internes au cluster atteignent les pods par leurs adresses internes — IP de pod et noms DNS du cluster comme zaris-0.zaris.svc — et tout route proprement. Dès qu'un client se trouve à l'extérieur du cluster, cela casse. Une application externe ne peut pas appeler zaris-0.zaris.svc ni une IP de pod ; ces noms et adresses ne se résolvent et ne routent qu'à l'intérieur du réseau du cluster.

Ce n'est pas une bizarrerie de Zaris — c'est la séparation fondamentale entre le réseau interne du cluster et le monde extérieur. Elle mord le plus fort avec les clients conscients de la topologie. Un client Redis en mode cluster, ou tout client qui découvre les nœuds et route par clé, récupère une carte de topologie depuis le serveur et se connecte aux adresses qu'elle contient. Si ces adresses sont internes, un client externe obtient une carte remplie de points d'accès qu'il ne pourra jamais atteindre.

Zaris résout cela avec des adresses annoncées, gérées comme une « vue de frontière » par listener.

Zaris expose un front-end protocole Redis (RESP) afin que n'importe quel client Redis, dans n'importe quel langage, puisse pointer vers un cluster Zaris et l'utiliser comme store interchangeable. Mais « n'importe quel client Redis » masque un vrai problème : les écosystèmes de clients Redis ne s'accordent pas sur la façon de découvrir la topologie ni de récupérer lorsqu'un nœud disparaît. Un client simple attend un unique point d'accès stable. Un client fondé sur Sentinel attend de pouvoir demander à un service de découverte « qui est le maître ? » Un client en mode cluster attend des slots de hachage et des redirections MOVED/ASK.

Si un store ne parlait qu'un seul de ces dialectes, toute une catégorie de clients serait exclue. C'est pourquoi le front-end RESP de Zaris prend en charge trois modèles de basculement, chacun correspondant à la façon dont une famille particulière de clients Redis s'attend déjà à fonctionner. Vous choisissez le modèle par déploiement ; le client se comporte exactement comme il le ferait face à un vrai Redis.

Une remarque honnête d'emblée, car elle conditionne tout ce qui suit : les trois modèles se placent devant le même store Zaris, répliqué et partitionné. Le modèle que vous choisissez change la sémantique de découverte et de redirection — comment un client trouve un nœud et ce qu'il fait lorsqu'un nœud tombe en panne — et non l'endroit où vos données résident réellement.

Zaris s'exprime déjà en collections — hashes, listes, sets et sorted sets qui résident sur le serveur et se répliquent comme toute autre clé. Les Streams sont le cinquième type, et c'est celui qui fait passer Zaris du statut de store à celui d'élément d'infrastructure de messagerie.

Un stream Zaris est un véritable journal en ajout seul : les entrées reçoivent des ID monotones, vous pouvez lire des plages, et vous pouvez attacher des groupes de consommateurs pour qu'un pool de workers se partage le journal, suive les entrées en attente par consommateur et acquitte ce qu'il a traité. Vous pouvez aussi effectuer une lecture bloquante — un consommateur se met en pause et attend l'arrivée de nouvelles entrées au lieu de boucler à vide.

Et parce qu'il s'agit d'une collection Zaris native, le journal est partitionné et répliqué exactement comme tout le reste. Un stream survit au basculement d'un nœud, ce qui est précisément la raison pour laquelle on recourt à une messagerie durable en premier lieu.

Zaris 1.x stockait des valeurs. Zaris 2.0.0 stocke des collections. Les hashes, listes, sets et sorted sets sont désormais des types de premier ordre, côté serveur, assortis de véritables API .NET typées — et, tout aussi important, ils se comportent comme tout le reste dans le store.

C'est cette dernière partie que l'on se représente généralement de travers. Dans beaucoup de systèmes, les « structures de données » sont une illusion côté client : une bibliothèque sérialise un dictionnaire en un blob, le Put, et appelle cela un hash. Cela fonctionne jusqu'à ce que deux clients touchent la même collection en même temps, ou jusqu'à ce que vous demandiez ce qui se passe lors d'un basculement. Dans Zaris, un hash est un hash sur le serveur. Il réside sur la partition propriétaire de sa clé, il se réplique vers le réplica de cette partition, et il survit à la perte d'un nœud exactement comme le fait une simple clé.

Aujourd'hui, nous publions Zaris 2.0.0 — la plus importante version depuis que Zaris a atteint la disponibilité générale, et la première avec un changement de version majeure. Elle transforme Zaris, qui était un store clé-valeur rapide et répliqué, en un serveur de structures de données complet : hashes, listes, sets, sorted sets, pub/sub et Redis Streams natifs, tous partitionnés et répliqués de la même façon que le sont déjà vos clés.

Et elle ouvre la porte à tous les autres. Chaque nœud peut désormais exposer un front-end protocole-Redis (RESP), de sorte qu'une application en Python, Ruby, Java, Go — n'importe quel langage disposant d'un client Redis — peut pointer vers Zaris et l'utiliser en remplacement direct, sans SDK natif et sans réécrire une ligne.

Le numéro de version est un 2, et non un 1.x, pour une raison : la 2.0.0 modifie le protocole filaire. Lisez la note de mise à niveau ci-dessous avant de la déployer.

Zaris est un store clé-valeur distribué conçu nativement pour .NET. Ses clients de premier ordre parlent un protocole binaire efficace, et si votre pile est en .NET, c'est le chemin que vous voulez — de véritables API asynchrones, des types .NET, des primitives de coordination, des remplacements directs IDistributedCache et HybridCache.

Mais la plupart des systèmes ne sont pas uniquement en .NET. Il y a un service Python qui fait du traitement de données, un sidecar Go, un exécuteur de tâches Ruby, une passerelle Node. Les réécrire tous vers un nouveau client pour essayer un nouveau store est inenvisageable. Aussi, dans la 2.0.0, chaque nœud Zaris peut également exposer un listener protocole-Redis (RESP2) : pointez un client Redis existant vers lui et utilisez Zaris comme store clé-valeur en remplacement direct, dans n'importe quel langage, sans changer une ligne de code client.

Cet article explique comment ce front-end fonctionne réellement — le modèle de routage, le modèle de données, les modèles de basculement, et exactement quelles commandes sont prises en charge ou non.

Redis est rapide. Il est aussi, par conception, mono-thread sur le chemin de données : une boucle d'événements, un cœur, une commande à la fois. C'est une conception réellement bonne — elle rend Redis simple à appréhender et élimine toute une catégorie de bugs de concurrence. Mais elle comporte un plafond qu'aucune somme d'argent ne peut lever. Donnez à un moteur mono-boucle d'événements une machine à 4 cœurs, à 8 cœurs, à 32 cœurs, et le débit en lecture retombe au même endroit. Les cœurs supplémentaires restent inactifs.

Zaris emprunte l'autre voie. Les clés sont partitionnées et chaque partition a un propriétaire, de sorte que les lectures de clés différentes atterrissent sur des cœurs différents et s'exécutent en même temps. Résultat : un débit qui bouge lorsque vous ajoutez des cœurs — une pente plutôt qu'une ligne plate.