Eines der kritischen Probleme beim Erstellen von Mehrbenutzersystemen ist die Skalierung. Für diese Probleme gibt es verschiedene Lösungen: Sharding, Servicemodell, Entity-Component-System. Heute werden wir alle Optionen prüfen und auch einen praktischen Fall zur Lösung des Problems erörtern. Jetzt mitmachen!
Teil 1.Teil 2.Ich gebe das Wort an die Autoren weiter.Traditionelle Ansätze zum Aufbau von Mehrbenutzersystemen. Servicearchitektur
In der Vergangenheit war die erste Methode zur Lösung des Skalierungsproblems das Sharding - die Aufteilung des gesamten Systems in eine Reihe von Servern nach einem beliebigen Kriterium ohne allgemeinen Zustand der Welt. Das heißt, bis zu einer bestimmten Anzahl von Benutzern können sie sich auf demselben Server befinden, sich sehen und miteinander interagieren. Beim Hinzufügen neuer Dateien wurden jedoch Kopien des virtuellen Speicherplatzes auf einem anderen Server ausgeführt und konnten dementsprechend nicht mit anderen interagieren. Es ist klar, dass dies keine Lösung für das Problem ist, sondern eine Problemumgehung. Und obwohl Sharding auch jetzt noch Sinn macht, sind in vielen Fällen Ansätze erforderlich, die die mögliche Belastung des Servers wirklich erhöhen können.
Die zweite übliche Technik ist das Servicemodell. Der Server verfügt über eine Reihe von Komponenten, die leicht dupliziert werden können. Dies ist beispielsweise eine Datenbank, die mit ihr arbeitet, oder ein Asset-Server, der sie an einen Client oder einen Autorisierungsserver sendet. Alle diese Dienste zeichnen sich dadurch aus, dass Sie sie in mehreren Instanzen haben und Anforderungen für sie parallelisieren können.
Das Hauptproblem ist der gemeinsame Zustand
Das Hauptproblem ist jedoch anders. Was tun mit einem bestimmten Zustand der Welt, dem Zustand des virtuellen Raums? Angenommen, unsere „Welt“ besteht aus einer 3D-Szene, einer Reihe von Objekten und mehreren verbundenen Benutzern. Theoretisch können wir einige Softwarekomponenten duplizieren, die für die Arbeit mit der Szene auf der Serverseite verantwortlich sind. Das Problem ist jedoch, dass der Zustand der Szene allen diesen Komponenten gemeinsam ist. Dementsprechend müssen wir bei der Parallelisierung der Handler das Problem der Synchronisierung der Arbeit mit Daten irgendwie lösen, und gleichzeitig können wir bei der Synchronisierung selbst mehr an Leistung verlieren als an Parallelität gewinnen.
Lösung: Entity-Component-System. Probleme im Fernen Osten
Einer der relativ neuen Ansätze für solche Probleme ist ECS (Entity - Component System). In dieser Version stellen wir das Objekt des Systems als eine bestimmte Entität dar, die einige Eigenschaften hat. Dies kann beispielsweise die Position eines Objekts im Raum und seine Geschwindigkeit sein. Darüber hinaus speichern wir nur einige Daten auf dem Objekt selbst, aber nicht die Logik, mit ihnen zu arbeiten. Das heißt, in unserem Fall werden dem Objekt einfach sechs Zahlen zugewiesen - der Koordinatenvektor und der Geschwindigkeitsvektor.
Der zweite Teil von ECS ist Worker, ein System, das mit einem bestimmten Komponententyp arbeitet. In unserem Fall kann es sich beispielsweise um ein System handeln, das die Koordinaten eines Objekts jede Sekunde ändert und ihnen Geschwindigkeit verleiht. Die Hauptidee ist, dass der Worker nichts über das Objekt als solches weiß - es hat nur eine Warteschlange, eine Pipeline von Komponenten, die er nach bestimmten Regeln verarbeiten muss. Dementsprechend können wir sowohl Arbeitnehmer als auch Dienstleistungen parallelisieren.
Agentensysteme als Methode zum Schreiben von parallelem Code
Der Multi-Agent-Ansatz ist ebenfalls keine besondere Neuheit, aber in letzter Zeit hat das Interesse an Agentensystemen zugenommen. Es gibt eine Reihe ziemlich guter Artikel, die ausführlich darüber berichten. Deshalb listen wir hier nur die allgemeinsten Prinzipien solcher Systeme kurz auf:
- Die Hauptkomponente des Systems ist eine Komponente, die als Agent oder Akteur bezeichnet wird. In gewisser Weise ähnelt es einem Objekt, das jedem vertraut ist, aber der Schauspieler hat keine öffentlichen Methoden. Die einzige Möglichkeit, mit ihm zu kommunizieren, besteht darin, ihm eine Nachricht zu senden.
- Um eine Nachricht an den Agenten zu senden, gibt es das Konzept der "Links". Der Link bietet eine bestimmte Schnittstelle (in verschiedenen Implementierungen kann sie sehr unterschiedlich aussehen), über die Sie Nachrichten senden können. Eine der wichtigen Eigenschaften hierbei ist die Standorttransparenz und das Vorhandensein jedes Agenten mit einer Adresse - eine Zeichenfolge, mit der Sie unabhängig von seinem physischen Standort eine Verknüpfung zum Agenten herstellen können, d. H. Der Agent kann sich auf demselben Computer oder möglicherweise auf einem anderen Computer befinden und im Agentensystem arbeiten. In diesem Fall wird die Verbindung an einer bestimmten Netzwerkadresse hergestellt.
- Der Agent verfügt über eine Nachrichtenwarteschlange, die nacheinander verarbeitet wird. Ein Agent kann eine Zustandsmaschine sein, die Zustände und Nachrichtenhandler in der Reihenfolge ihrer Reaktion ändert.
- Multiagentensysteme sind in der Regel hierarchisch, dh Agenten bilden eine Art Baum. In diesem Fall stoppt ein Fehler in einem der Agenten nicht das gesamte System, sondern nur ein bestimmter Agent wird getrennt und sendet eine Fehlermeldung an seinen Vorfahren. Einer der gängigen Ansätze zur Behandlung solcher Fehler besteht darin, sie abstürzen zu lassen. Wenn ein Agent abstürzt, erstellen wir einfach eine neue Kopie davon.
- Das Erstellen eines neuen Agenten ist kein ressourcenintensiver Vorgang, und das Erstellen des Systems selbst ist sehr kostspielig.
Sehr oft werden Agentensysteme nur bei der Verwendung von ECS verwendet. Da das Agentensystem es sehr einfach macht, die erforderliche Anzahl von Mitarbeitern zu erstellen und ihre Arbeit zu parallelisieren, indem einfach der Nachrichtenfluss zwischen ihnen verteilt wird, scheint dies ein sehr vielversprechender Ansatz zu sein. So funktioniert beispielsweise SpatialOS von Improbable.
Probleme treten hier in einer etwas anderen Ebene auf. Der ECS-Ansatz ist recht einfach, kann aber im Prinzip nicht als intuitiv bezeichnet werden, insbesondere für unerfahrene Programmierer. Daher ist die Erstellung von Benutzercode in einem solchen System eine nicht triviale Aufgabe. Außerdem stellen sich Fragen zur Portabilität verschiedener Objekte zwischen virtuellen Serverinstanzen, da wir zusammen mit dem Objekt alle Worker übertragen müssen, wenn sie (für diesen Komponententyp) nicht auf einem anderen Server vorhanden sind. Im Prinzip können einige Implementierungen von Agentensystemen einige dieser Probleme lösen, aber wir haben einen anderen Ansatz gewählt.
Unser Fall ist die Essenz des Fernen Ostens als Agent
In unserem Fall ist jedes virtuelle Raumobjekt ein Agent bzw. ein Agentensystem. Im Vergleich zum klassischen ECS können wir sagen, dass jede Entität in uns ein System von „Mikroarbeitern“ hat, die an das Objekt selbst gebunden sind. Gleichzeitig bleiben alle Vorteile des Agentensystems erhalten (dh wir können ein solches Objekt in einem separaten Thread, auf einem separaten Computer usw. ausführen, indem wir einfach die Servereinstellungen ändern), aber das Objekt bleibt portabel, und das Schreiben von Skripten erfordert keine ECS-Aufteilung .
In diesem Fall wird der Zustand der Welt in den Zustand einzelner Objekte unterteilt, und jedes von ihnen kann separat verarbeitet werden. Auf dem Client erstellen wir auch ein Agentensystem, das den Status des Servers widerspiegelt, und ordnen jeden Client-Agenten dem Server-Agenten zu. Dies erhöht unter anderem auch die Zuverlässigkeit des Systems, da bei einem Ausfall eines einzelnen Objekts nur dieses Objekt deaktiviert wird und nicht der gesamte virtuelle Raum.
Im Detail sieht es so aus:
Jedes Space-Objekt ist ein kleines Agentensystem, das aus dem Hauptagenten der Entität besteht, die beim Start des Servers erstellt wird. Dies ist kein Komponentencontainer-Agent und eine Reihe von Message-Handler-Komponenten. Zum Verbinden des Clients wird die Eigenschaft Netzwerktransparenz verwendet, dh, jedes bestimmte Objekt auf dem Client verfügt über eine Verknüpfung zum Serveragentenobjekt. Gleichzeitig wird beim Verbinden dynamisch ein neuer Agent erstellt, der ein Nachkomme des Hauptagenten ist.
Ein Agentensystem wird auch auf der Clientseite erstellt, Entitätsagenten darin werden jedoch durch eine Nachricht von der Serverseite gebildet. Nach der Erstellung empfängt der Agent einen Link zum Serveragenten und erstellt eine Nachrichtenverarbeitungskomponente, die Warteschlangen zum Empfangen und Senden von Nachrichten vom Server enthält. Außerdem wird ein Unity-Objekt erstellt, und Client-Teile der Komponenten des Objekts werden von MonoBehaviour geerbt. Gleichzeitig arbeiten der Unity-Teil und der Agent-Teil in verschiedenen Threads. Der Message-Handler ist für die Synchronisation verantwortlich (wenn möglich, wird diese minimiert).
So etwas (ohne besondere Details) sieht aus wie die Implementierung eines dynamischen virtuellen Raums in der JIF-Variante. Im nächsten Artikel werden wir Sie über persönliche Big Data und die Arbeit mit Statistiken sowie über Blockchain informieren.
Die Autoren
Jedium ist ein Microsoft-Partnerunternehmen, das auf dem Gebiet der virtuellen, erweiterten Realität und künstlichen Intelligenz tätig ist. Jedium hat ein Framework entwickelt, um die Entwicklung komplexer Projekte auf Unity zu vereinfachen, von denen ein Teil
auf GitHub öffentlich verfügbar ist. Jedium plant, das Repository mit neuen Framework-Modulen sowie Integrationslösungen mit Microsoft Azure aufzufüllen.
Vitaliy Chashchin - Softwareentwickler mit mehr als 10 Jahren Erfahrung im Design und der Implementierung dreidimensionaler Client-Server-Anwendungen - vom Konzept bis zur vollständigen Implementierung und Integration von Anwendungen und Lösungen im Bereich der virtuellen Realität. Systemarchitekt Jedium LLC, MSc in IT.
Alexey SarafanovMarketing Manager bei Jedium LLC.
Sergey KudryavtsevCEO und Gründer von Jedium LLC.