L'un des problèmes critiques qui se posent lors de la construction de systèmes multi-utilisateurs est la mise à l'échelle. Il existe différentes solutions à ces problèmes: partitionnement, modèle de service, système Entity-Component. Aujourd'hui, nous examinerons toutes les options et discuterons également d'un cas pratique pour résoudre le problème. Rejoignez-nous maintenant!
Partie 12e partieJe passe le mot aux auteurs.Approches traditionnelles de la construction de systèmes multi-utilisateurs. Architecture de service
Historiquement, la première méthode pour résoudre le problème de la mise à l'échelle était le sharding - divisant l'ensemble du système en un certain nombre de serveurs par n'importe quel critère sans état général du monde. Autrement dit, jusqu'à un certain nombre d'utilisateurs, ils pourraient être sur le même serveur, se voir et interagir les uns avec les autres; mais en en ajoutant de nouveaux, ils se sont retrouvés dans des copies d'espace virtuel fonctionnant sur un autre serveur et, par conséquent, ne pouvaient pas interagir avec les autres. Il est clair que ce n'est pas une solution au problème, c'est une solution de contournement. Et bien que le partage soit logique même maintenant, dans de nombreux cas, des approches sont nécessaires qui peuvent vraiment augmenter la charge possible sur le serveur.
La deuxième technique courante est le modèle de service. Le serveur possède un certain nombre de composants qui peuvent facilement être dupliqués. Par exemple, il s'agit d'une base de données et de son utilisation, ou d'un serveur de ressources qui les envoie à un client ou à un serveur d'autorisation. Tous ces services se distinguent par le fait que vous pouvez les avoir dans plusieurs instances et paralléliser leurs demandes.
Le principal problème est l'état partagé
Mais le problème principal est différent. Que faire d'un état spécifique du monde, l'état de l'espace virtuel? Supposons que notre «monde» se compose d'une scène 3D, d'un ensemble d'objets dessus et de plusieurs utilisateurs connectés. Théoriquement, nous pouvons dupliquer certains composants logiciels chargés de travailler avec la scène côté serveur. Mais le problème est que l'état de la scène est une chose commune à tous ces composants. Par conséquent, lors de la parallélisation des gestionnaires, nous devons d'une manière ou d'une autre résoudre le problème de la synchronisation du travail avec les données, et en même temps sur la synchronisation elle-même, nous pouvons perdre plus en performances que gagner en parallélisme.
Solution: Système Entity-Component. Problèmes dans le cas de l'Extrême-Orient
ECS (Entity - Component System) est l'une des approches relativement récentes de ces problèmes. Dans cette version, nous représentons l'objet du système comme une certaine entité qui a des propriétés. Par exemple, cela peut être la position d'un objet dans l'espace et sa vitesse. De plus, tout ce que nous stockons sur l'objet lui-même n'est que quelques données, mais pas la logique de travailler avec eux. Autrement dit, dans notre cas, six nombres seront simplement attribués à l'objet - le vecteur de coordonnées et le vecteur de vitesse.
La deuxième partie d'ECS est travailleur, un système qui fonctionne avec un type spécifique de composant. Par exemple, dans notre cas, il peut s'agir d'un système qui modifie les coordonnées d'un objet toutes les secondes, en leur ajoutant de la vitesse. L'idée principale est que le travailleur ne sait rien de l'objet en tant que tel - il a juste une file d'attente, un pipeline de composants qu'il doit traiter selon certaines règles. En conséquence, nous pouvons paralléliser les travailleurs, ainsi que les services parallélisés.
Systèmes d'agents comme méthode d'écriture de code parallèle
L'approche multi-agents n'est pas non plus une nouveauté particulière, mais récemment, l'intérêt pour les systèmes d'agents s'est accru. Il y a un certain nombre d'articles assez bons qui en parlent en détail, donc ici nous ne listons brièvement que les principes les plus généraux de tels systèmes:
- Le composant principal du système est un composant appelé agent ou acteur. À certains égards, il ressemble à un objet familier à tout le monde, mais l'acteur n'a pas de méthodes publiques, la seule façon de communiquer avec lui est de lui envoyer un message;
- Pour envoyer un message à l'agent, il y a le concept de «liens». Le lien fournit une certaine interface (dans diverses implémentations, il peut être très différent), ce qui vous permet d'envoyer des messages. L'une des propriétés importantes ici est la transparence de l'emplacement et la présence de chaque agent avec une adresse - une chaîne qui vous permet d'obtenir un lien vers l'agent indépendamment de son emplacement physique, c'est-à-dire l'agent peut être localisé et fonctionner dans le système d'agent sur le même ordinateur, ou peut-être sur un autre - dans ce cas, le lien est obtenu à une adresse réseau;
- L'agent dispose d'une file d'attente de messages et ils sont traités séquentiellement. Un agent peut être une machine à états qui modifie les états et les gestionnaires de messages dans l'ordre de réaction à ceux-ci;
- En règle générale, les systèmes multi-agents sont hiérarchiques, c'est-à-dire que les agents forment une sorte d'arbre. Dans ce cas, une erreur dans l'un des agents n'arrête pas tout le système, seul un agent spécifique est déconnecté, envoyant un message d'erreur à son ancêtre. L'une des approches les plus utilisées pour gérer de telles erreurs est de les laisser planter - lorsqu'un agent se bloque, nous en créons simplement une nouvelle copie;
- La création d'un nouvel agent n'est pas une opération gourmande en ressources et la création du système lui-même est très coûteuse.
Très souvent, les systèmes d'agents sont utilisés uniquement dans l'approche utilisant ECS. Étant donné que le système d'agents permet de créer très facilement le nombre requis de travailleurs et de paralléliser leur travail, en répartissant simplement le flux de messages entre eux, cela semble être une approche très prometteuse. Par exemple, voici comment fonctionne SpatialOS d'Improbable.
Les problèmes se posent ici dans un plan légèrement différent. L'approche ECS est assez simple, mais en principe, elle ne peut pas être qualifiée d'intuitive, en particulier pour les programmeurs inexpérimentés. Par conséquent, la création de code utilisateur dans un tel système est une tâche plutôt simple. En outre, des questions se posent concernant la portabilité de divers objets entre des instances de serveur virtuel, car avec l'objet, nous devons transférer tous les travailleurs s'ils (pour ce type de composant) ne sont pas présents sur un autre serveur. En principe, certaines implémentations de systèmes d'agents peuvent résoudre certains de ces problèmes, mais nous avons choisi une approche différente.
Notre cas est l'essence de l'Extrême-Orient en tant qu'agent
Dans notre cas, chaque objet spatial virtuel est un agent, ou plutôt un système d'agents. Par rapport à l'ECS classique, nous pouvons dire que chaque entité en nous porte un système de «micro-travailleurs», lié à l'objet lui-même. Dans le même temps, tous les avantages du système d'agents sont préservés (c'est-à-dire que nous pouvons exécuter un tel objet dans un thread séparé, sur une machine distincte, etc., simplement en modifiant les paramètres du serveur), mais l'objet reste portable et l'écriture de scripts pour celui-ci ne nécessite pas de division ECS .
Dans ce cas, l'état du monde est divisé en l'état des objets individuels, et chacun d'eux peut être traité séparément. Sur le client, nous construisons également un système d'agent, qui est une sorte de reflet de l'état du serveur, et nous associons chaque agent client à l'agent serveur. Entre autres choses, cela augmente également la fiabilité du système, car si un objet individuel tombe en panne, seul cet objet est désactivé, et non tout l'espace virtuel.
Plus en détail, cela ressemble à ceci:
Tout objet spatial est un petit système d'agent composé de l'agent principal de l'entité créée au démarrage du serveur, qui n'est pas un agent de conteneur de composants et un ensemble de composants de gestionnaire de messages. Pour connecter le client, la propriété de transparence du réseau est utilisée, c'est-à-dire que chaque objet spécifique sur le client a un lien vers l'objet agent serveur. Dans le même temps, lors de la connexion, un nouvel agent est créé dynamiquement, qui est un descendant de l'agent principal.
Un système d'agent est également créé côté client, mais les agents d'entité qu'il contient sont formés par un message du côté serveur. Après la création, l'agent reçoit un lien vers l'agent serveur et crée un composant de traitement des messages qui comprend des files d'attente pour recevoir et envoyer des messages depuis le serveur. Un objet Unity est également créé et les parties clientes des composants de l'objet hérités de MonoBehaviour. Dans le même temps, la partie Unity et la partie agent fonctionnent dans des threads différents, le gestionnaire de messages est responsable de la synchronisation (si possible, elle est minimisée).
Quelque chose comme ça (sans détails particuliers) ressemble à l'implémentation d'un espace virtuel dynamique dans la variante JIF. Dans le prochain article, nous vous parlerons des mégadonnées personnelles et travaillerons sur les statistiques, ainsi que sur la blockchain.
Les auteurs
Jedium est une société partenaire de Microsoft travaillant dans le domaine de la réalité virtuelle, augmentée et de l'intelligence artificielle. Jedium a développé un cadre pour simplifier le développement de projets complexes sur Unity, dont une partie est accessible au public
sur GitHub . Jedium prévoit de reconstituer le référentiel avec de nouveaux modules de framework, ainsi que des solutions d'intégration avec Microsoft Azure.
Vitaliy Chashchin -
Développeur de logiciels avec plus de 10 ans d'expérience dans la conception et la mise en œuvre d'applications client-serveur tridimensionnelles - du concept à la mise en œuvre complète et à l'intégration des applications et des solutions dans le domaine de la réalité virtuelle. Architecte système Jedium LLC, MSc en informatique.
Alexey SarafanovResponsable marketing chez Jedium LLC.
Sergey KudryavtsevPDG et fondateur de Jedium LLC.