En processus et distant
Clustron Zaris s'exécute de deux manières : en processus (embarqué dans votre application) et distant (connecté à un cluster). Cet article explique en quoi les deux diffèrent, quand utiliser chacun, et comment passer de l'un à l'autre.
Les deux utilisent exactement la même API client et le même modèle de programmation. Vous écrivez votre code une seule fois, et le choix entre en processus et distant s'exprime entièrement par la chaîne de connexion que vous utilisez — zaris://inproc/store pour l'embarqué, zaris://host:port/store (ou zariss:// pour le TLS) pour un cluster. Comme seule la chaîne change, vous pouvez commencer en processus pendant le développement et passer à un cluster en production sans toucher au code applicatif.
En processus
Un store en processus s'exécute à l'intérieur du propre processus de votre application. Aucun serveur distinct ni aucune connexion réseau n'est impliqué, et les données sont conservées en mémoire. Vous le sélectionnez avec l'hôte réservé inproc :
zaris://inproc/orders
Utilisez le mode en processus lorsque vous voulez exécuter sans infrastructure :
- Développement local, où le store démarre et s'arrête avec votre application.
- Tests unitaires et d'intégration, où vous avez besoin d'un store mais pas d'un cluster.
- Applications mono-instance qui ne partagent pas de données entre les processus.
Comme il n'y a pas de saut réseau, le mode en processus est la manière la plus rapide d'exécuter le store. Un store en processus ne peut pas utiliser le TLS — il n'y a aucune connexion réseau à sécuriser.
Distant
Une connexion distante atteint un store s'exécutant à travers un cluster de nœuds. Un nœud est une unique instance en cours d'exécution du store, généralement une par machine. Les nœuds communiquent sur le réseau pour répliquer les données et coordonner le travail entre les instances applicatives. Vous le sélectionnez en listant un ou plusieurs hôtes d'amorçage (seed) :
zaris://node-a:7861,node-b:7861/orders
zariss://node-a:7863/orders?ca=/etc/zaris/ca.pem
Les hôtes séparés par des virgules forment une liste d'amorçage que le client utilise pour découvrir le reste du cluster et pour basculer. Utilisez le mode distant lorsqu'un seul processus ne suffit pas :
- Systèmes de production qui nécessitent une haute disponibilité.
- Applications qui s'exécutent sous forme de multiples instances et doivent partager l'état.
- Charges de travail qui doivent monter en charge sur plus d'une machine.
Choisir une forme
Le tableau suivant compare les deux afin que vous puissiez décider laquelle convient à un environnement donné.
| Aspect | En processus | Distant |
|---|---|---|
| Chaîne de connexion | zaris://inproc/store | zaris(s)://host:port/store |
| Exécution | À l'intérieur du processus de votre application | À travers plusieurs nœuds |
| Réseau | Aucun | Requis |
| TLS | Non disponible | Disponible via zariss:// |
| Mise en place | Aucune | Installation requise |
| Échelle | Instance unique | Multiples instances |
| Coordination | Locale au processus | Partagée entre les instances |
Le modèle mental à retenir est « en processus aujourd'hui, distant demain ». Construisez et testez avec zaris://inproc/..., puis passez à une chaîne zaris://host.../... lorsque vous avez besoin de disponibilité ou de montée en charge. Le même chemin de code sert les deux.
Passer de l'un à l'autre
Vous sélectionnez le mode en processus ou distant par la chaîne de connexion, pas par le code. Conservez la chaîne dans la section ConnectionStrings et faites varier sa valeur par environnement (voir Obtenir un client).
Un store en processus :
{
"ConnectionStrings": {
"orders": "zaris://inproc/orders"
}
}
Un cluster distant — même clé, valeur différente :
{
"ConnectionStrings": {
"orders": "zaris://node-a:7861,node-b:7861/orders"
}
}
Le code applicatif qui enregistre et appelle le store est identique dans les deux cas :
services.AddClustronZaris(configuration, "orders");
var client = await provider.GetAsync("orders");
await client.PutAsync("key", "value");