Malheureusement, ce terme n’a pas de bon analogue en russe. Wikipédia donne "multi-location, location multiple." C'est ce qu'on appelle parfois la « propriété multiple ». Ces termes peuvent prêter à confusion, car le sujet n’est pas intrinsèquement associé à la location ou à la propriété. Il s'agit d'une question d'architecture logicielle et d'organisation de son fonctionnement. Et ce dernier n’est pas moins important.
Nous avons commencé à formuler notre compréhension de la multilocation en même temps que nous avons commencé à concevoir une approche du modèle de travail cloud (service) dans 1C:Enterprise. C'était il ya plusieurs années. Et depuis lors, notre compréhension n’a cessé de s’élargir. Nous découvrons sans cesse de nouveaux aspects de ce sujet (avantages, inconvénients, difficultés, fonctionnalités, etc.).
Parfois, les développeurs comprennent la multilocation comme un sujet très simple : « pour que les données de plusieurs organisations soient stockées dans une seule base de données, vous devez ajouter une colonne avec l'identifiant de l'organisation à toutes les tables et définir un filtre dessus ». Bien entendu, nous avons également commencé notre étude de la question à partir de ce moment-là. Mais ils se sont vite rendu compte qu’il ne s’agissait que d’une clairière (ce qui n’est d’ailleurs pas facile). En général, il s'agit d'un « pays entier ».
L'idée de base de la multilocation peut être décrite à peu près comme ceci. Une application typique est un chalet conçu pour accueillir une famille, qui utilise ses infrastructures (murs, toiture, alimentation en eau, chauffage, etc.). Une application multilocation est un immeuble d’appartements. Dans ce document, chaque famille utilise la même infrastructure, mais l'infrastructure elle-même est mise en œuvre pour toute la maison.
L’approche multilocation est-elle bonne ou mauvaise ? Vous pouvez trouver des avis très différents à ce sujet. Il semble qu’il n’y ait pas de « bon ou mauvais » du tout. Vous devez comparer les avantages et les inconvénients dans le contexte des tâches spécifiques à résoudre. Mais c'est un autre sujet...
Dans son sens le plus simple, l’objectif de la multilocation est de réduire le coût de maintenance d’une application en « socialisant » les coûts d’infrastructure. C’est le même mouvement que de réduire le coût d’une application en utilisant une solution de production (éventuellement avec personnalisation et modification), plutôt que de l’écrire « sur commande ». Dans un cas seulement, le développement est socialisé et dans l'autre, l'exploitation.
Par ailleurs, nous le répétons, il n’y a pas de lien direct avec le mode de vente. L'architecture mutualisée peut également être utilisée dans une infrastructure informatique d'entreprise ou départementale pour automatiser un grand nombre de succursales et d'entreprises holding similaires.
On peut dire que la multilocation n’est pas seulement une question d’organisation du stockage des données. Il s'agit d'un modèle de fonctionnement de l'application dans son ensemble (incluant une partie significative de son architecture, de son modèle de déploiement et de son organisation de maintenance).
La chose la plus difficile et la plus intéressante à propos du modèle multi-tenant, nous semble-t-il, est que l’essence de l’application « bifurque ». Une partie de la fonctionnalité fonctionne avec des zones de données spécifiques (appartements) et n'est « pas intéressée » par le fait qu'il y ait des résidents dans d'autres appartements. Et certains perçoivent la maison dans son ensemble et travaillent pour tous les résidents à la fois. Dans le même temps, ces derniers ne peuvent ignorer le fait qu’il s’agit après tout d’appartements séparés et qu’il est nécessaire d’assurer le niveau de granularité et de sécurité nécessaire.
Dans 1C:Enterprise, le modèle multitenancy est implémenté au niveau de plusieurs technologies. Ce sont les mécanismes de la plateforme 1C:Enterprise, les mécanismes de"Et"", mécanismes (bibliothèques de sous-systèmes standards).
Chacun de ces éléments contribue à la construction de l'infrastructure globale d'un immeuble à appartements. Pourquoi cela est-il implémenté dans plusieurs technologies, et pas dans une seule, par exemple dans une plateforme ? Tout d’abord parce que certains mécanismes, à notre avis, sont tout à fait appropriés pour être modifiés pour une option de déploiement spécifique. Mais en général, c'est une question difficile, et nous sommes constamment confrontés à un choix : à quel niveau est-il préférable de mettre en œuvre tel ou tel aspect de la multilocation.
Évidemment, la partie fondamentale des mécanismes devait être implémentée dans la plateforme. Eh bien, par exemple, la séparation des données proprement dite. C’est là que les gens commencent généralement à parler de multilocation. Mais au final, le modèle multi-tenant a « parcouru » une partie importante des mécanismes de la plateforme et a nécessité leur perfectionnement, et dans certains cas, leur refonte.
Au niveau de la plateforme, nous avons implémenté exactement les mécanismes de base. Ils vous permettent de créer des applications qui s'exécutent dans un modèle multi-tenant. Mais pour que les applications « vivent et travaillent » dans un tel modèle, vous devez disposer d'un système de gestion de leurs « activités de vie ». Les technologies 1cFresh et une couche de logique métier unifiée au niveau BSP en sont responsables. Tout comme dans un immeuble d'appartements, l'infrastructure fournit aux résidents tout ce dont ils ont besoin, les technologies 1cFresh fournissent tout ce dont ils ont besoin pour les applications exécutées dans un modèle multi-tenant. Et pour que les applications puissent interagir avec cette infrastructure (sans modifications significatives), les « connecteurs » correspondants y sont placés sous forme de sous-systèmes BSP.
Du point de vue des mécanismes de la plate-forme, il est facile de remarquer qu'à mesure que nous acquérons de l'expérience et développons le cas d'utilisation du cloud « 1C : Enterprise », nous élargissons la composition des mécanismes impliqués dans cette architecture. Donnons un exemple. Dans le modèle mutualisé, les rôles des participants aux services d’application changent considérablement. Le rôle (niveau de responsabilité) des responsables de l'exploitation des applications augmente considérablement. Il leur est devenu nécessaire de disposer d’outils de contrôle des applications plus puissants. Parce que les utilisateurs de l'application (résidents) font avant tout confiance au fournisseur avec lequel ils travaillent. Pour ce faire, nous avons mis en place un nouveau . Ce mécanisme permet aux administrateurs du fournisseur de limiter la liberté des développeurs d'applications au niveau de sécurité requis - en substance, d'isoler le fonctionnement de l'application pour chaque locataire dans un certain bac à sable.
Non moins intéressante est l'architecture de gestion des applications fonctionnant en mode multitenancy (ce qui est implémenté dans les technologies 1cFresh et BSP). Ici, par rapport au modèle de déploiement conventionnel, les exigences en matière d'automatisation des processus de gestion sont considérablement accrues. Il existe des dizaines de processus de ce type : création de nouvelles zones de données (« appartements »), mise à jour des applications, mise à jour des informations réglementaires, sauvegardes, etc. Et, bien sûr, les exigences en matière de niveau de fiabilité et de disponibilité augmentent. Par exemple, pour garantir une interaction fiable entre les applications et les composants du système de contrôle, nous avons mis en œuvre une technologie de système d'appel asynchrone avec une livraison garantie.
Un point très subtil est la manière de socialiser les données et les processus. Cela semble simple (si cela semble à quelqu'un) seulement à première vue. Le plus grand défi réside dans l’équilibre entre la centralisation des données et des processus et la décentralisation. D'une part, la centralisation permet de réduire les coûts (espace disque, ressources processeur, efforts des administrateurs...). En revanche, cela limite la liberté des « locataires ». C'est exactement l'un des moments de « bifurcation » de l'application, où le développeur doit penser simultanément à l'application au sens étroit (au service d'un « appartement ») et au sens large (au service de tous les « locataires » à la fois) .
A titre d'exemple d'un tel « dilemme », on peut citer les informations réglementaires et de référence. Bien sûr, la tentation est grande de la rendre commune à tous les « locataires » de la maison. Cela vous permet de le stocker en une seule copie et de le mettre à jour pour tout le monde en même temps. Mais il arrive que certains résidents aient besoin de changements spécifiques. Curieusement, dans la pratique, cela se produit même pour les informations spécifiées par les régulateurs (organismes gouvernementaux). Cela s’avère être une question difficile : socialiser ou ne pas socialiser ? Il est bien entendu tentant de rendre l’information générale pour tout le monde et privée pour ceux qui le souhaitent. Et cela conduit déjà à une mise en œuvre très difficile. Mais nous y travaillons...
Un autre exemple est la conception de la mise en œuvre de processus réguliers (exécutés selon un planning, initiés par le système de contrôle, etc.). D’une part, ils peuvent être mis en œuvre séparément pour chaque zone de données. C'est plus facile et plus pratique. Mais d’un autre côté, une granularité aussi fine crée une charge importante sur le système. Pour réduire la charge, vous devez mettre en œuvre des processus socialisés. Mais ils nécessitent une étude plus approfondie.
Bien entendu, cela soulève une question très importante. Comment les développeurs d’applications peuvent-ils assurer la multilocation ? Que doivent-ils faire pour cela ? Bien entendu, nous nous efforçons de faire en sorte que le fardeau des problèmes technologiques et d'infrastructure repose autant que possible sur les épaules de la technologie fournie, et que le développeur d'applications ne pense qu'en termes de tâches de logique métier. Mais comme pour d’autres problèmes architecturaux importants, les développeurs d’applications doivent avoir une certaine compréhension du travail dans le modèle multi-tenant et des efforts seront nécessaires lors du développement d’applications. Pourquoi? Car il y a des points que la technologie ne peut pas fournir automatiquement sans prendre en compte la sémantique des données. Par exemple, la même définition des limites de la socialisation de l'information. Mais nous essayons de limiter ces difficultés. Il existe déjà des exemples de mise en œuvre de telles applications.
Un point important dans le contexte de la mise en œuvre de la multilocation dans 1C:Enterprise est que nous créons un modèle hybride dans lequel une application peut fonctionner à la fois en mode multilocation et en mode normal. Il s’agit d’une tâche très difficile et qui fait l’objet d’une discussion distincte.
Source: habr.com