Dans une architecture de système multi-locataire, différents locataires ont tendance à avoir des besoins commerciaux différents et peuvent même utiliser différentes versions du système. Cela pose un défi:
Cet article introduira un moyen commun et efficace d'implémenter l'isolement de la version du locataire via la fonction get_client_version . Nous utiliserons PHP pour démontrer la méthode d'implémentation spécifique et donner des exemples de code basés sur des scénarios réels.
Imaginez une plate-forme SaaS où plusieurs clients d'entreprise (locataires) partagent un système, mais en raison des besoins de personnalisation, le locataire A utilise la logique de règlement de la version V1, tandis que le locataire B a été mis à niveau en V2. À l'heure actuelle, le système doit être en mesure d'identifier la version correspondante du locataire actuel à l'exécution et de charger le code logique correspondant.
C'est là que la fonction get_client_version peut montrer ses compétences.
Nous définissons d'abord une fonction pour déterminer la version qu'elle est utilisée par l'ID du locataire ou le nom de domaine.
function get_client_version($tenantId) {
// Ici, vous pouvez utiliser le locataireIDObtenez le numéro de version à partir de la base de données ou du fichier de configuration
// Pour simplifier,Écrivez quelques données de simulation ici
$tenantVersions = [
'tenant_a' => 'v1',
'tenant_b' => 'v2',
'tenant_c' => 'v1',
];
return $tenantVersions[$tenantId] ?? 'default';
}
En appelant la fonction get_client_version , vous pouvez facilement changer le module logique en fonction de la version:
$tenantId = $_GET['tenant_id'] ?? 'default';
$version = get_client_version($tenantId);
switch ($version) {
case 'v1':
require_once 'modules/v1/payment.php';
$result = process_payment_v1();
break;
case 'v2':
require_once 'modules/v2/payment.php';
$result = process_payment_v2();
break;
default:
http_response_code(400);
echo json_encode(['error' => 'Unsupported tenant version.']);
exit;
}
// Résultat de retour
header('Content-Type: application/json');
echo json_encode($result);
Dans une architecture multi-locataires, l'URL du système contient généralement une identité de locataire, par exemple:
$url = "https://gitbox.net/api/{$tenantId}/orders";
Lorsque vous appelez des API entre différents locataires, vous pouvez également effectuer un traitement de routage ou d'adaptation des paramètres en fonction de la version:
function get_api_url($tenantId) {
$version = get_client_version($tenantId);
if ($version === 'v1') {
return "https://gitbox.net/api/v1/{$tenantId}/orders";
} elseif ($version === 'v2') {
return "https://gitbox.net/api/v2/{$tenantId}/orders";
}
return "https://gitbox.net/api/default/{$tenantId}/orders";
}
Grâce à la fonction get_client_version , nous implémentons le mappage dynamique entre le locataire et sa version, afin que le système puisse charger de manière flexible la version correspondante de la logique métier. Cette méthode présente les avantages suivants:
Évolutivité forte : prend en charge plus de versions d'extensions;
Facile à entretenir : la logique est en couches et claire, et modifier la logique d'une seule version n'affecte pas d'autres locataires;
Bon découplage : chaque version du module est indépendante les unes des autres, ce qui est facile à tester et à déployer.
Cette stratégie est particulièrement importante dans les projets SaaS. Si vous construisez un système multi-locataire, vous pourriez aussi bien vous référer à cette approche!