jeu yivg
Yivgame est une solution de serveur de jeu MicroService écrit dans le langage GO basé sur le kit Go-Kit. En plus du serveur de jeux (Connexion longue), il comprend également un serveur d'interface API pour les opérations frontales et back-end. En plus du serveur lui-même, la configuration détaillée du déploiement Docker sera également impliquée.
caractéristiques
- Architecture de microservice
- Le client et le serveur de jeux réalisent la transmissibilité via le streaming bidirectionnel GRPC
- Communication WebSocket à côté client-serveur
- Implémentez les points de terminaison HTTP et les points de terminaison WebSocket
Pratique de conception
Architecture de microservice
- Grâce à l'architecture de microservice, les serveurs de jeux traditionnels sont divisés en différents microservices
- Différents micro serveurs peuvent communiquer de manière synchrone via GRPC et de manière asynchrone via Kafka
Modèle axé sur le domaine
- Afin d'atteindre le découplage de différents niveaux de logiciels, chaque service est conçu conformément au modèle axé sur le domaine.
- Divisez la structure logicielle des microservices de l'intérieur vers l'extérieur vers la couche commerciale du jeu, la couche de cas d'utilisation, la couche d'interface et la couche de dépendance des installations
- Continuez strictement par une dépendance à sens unique de l'extérieur vers l'intérieur entre les différents niveaux
La couche commerciale implémente principalement la logique de base du jeu ou du serveur, ne se soucie pas des implémentations externes et dépend des systèmes de fichiers, des bases de données, etc. La couche métier utilise l'interface pour définir les interfaces, implémente les méthodes d'interface par la couche de dépendance et passe eux dans la principale injection de dépendance. Par conséquent, à l'exception de citer certaines bibliothèques standard de base, la couche commerciale se réfère à peine aux packages tiers.
Modèle axé sur les événements avec Kafka
- La méthode de communication de base entre l'ensemble du système de microservice est l'appel synchrone GRPC et la communication d'événements asynchrones en utilisant Kafka comme plate-forme de streaming.
- Toutes les activités qui sont suivies dans les microservices seront publiées sur Kafka sous la forme d'événements générés.
Analyse du modèle et des données motivées par événement
- Dans le passé, lors de l'analyse des données de jeu, ils ont été recherchés à travers des tables conjointes.
- Après avoir utilisé le modèle axé sur les événements, tous les comportements des joueurs auxquels nous faisons attention peuvent être enregistrés comme des événements, concevoir différents attributs pour différents événements et obtenir une analyse de données extrêmement évolutive


Structure du répertoire de projet
- Étant donné que l'architecture de microservice implémentée par Go-Kit, essayez de le garder cohérent avec l'exemple officiel de go-kit dans la structure du répertoire autant que possible.
- Étant donné que le modèle axé sur le domaine est en couches, il est naturel d'inclure le répertoire de package intérieur dans la couche extérieure lors de la conception de la structure du répertoire du projet. La structure du répertoire au niveau du domaine, plutôt, le répertoire des packages de différents niveaux est placé sous le répertoire du même niveau.
Pas de variables globales
- Afin de rendre le logiciel plus clair dans la logique du code, évitez strictement les variables globales
Cache de données, stockage de données et kafka
- Par conséquent, les données des joueurs sont directement stockées dans la mémoire de service, ce qui facilite le traitement direct des données
- La modification des données des joueurs est écrite à Kafka via WAL, puis le service de stockage est écrit de manière asynchrone dans la base de données.
- Étant donné que la méthode WAL est utilisée, refaire et annuler les données des joueurs sont faciles à mettre en œuvre
Newsql cockroachdb
- La persistance des données utilise CockroachDB, une base de données relationnelle qui prend en charge les transactions distribuées
- L'utilisation de cockroachdb peut facilement atteindre la mise à l'échelle horizontale, la tolérance aux défauts, la récupération automatique et l'équilibrage de la charge
J'ai commencé à utiliser Cockroachdb de V1.0, de V1.0 à V1.0.6, CockroachDB a toujours eu un problème de crash dans des situations et des pressions spécifiques. n'a pas été grand. Parce que presque toutes les données de Yivgame sont en mémoire et que la base de données doit être écrite lors de l'enregistrement, donc pour l'ensemble du système Yivgame, il n'y a pas de goulot d'étranglement de performances DB.
Modèle
Diagramme de communication

- Méthode de communication
- HTTP: HTTP est une connexion courte, principalement utilisée pour la communication dans le système de fonctionnement de fond.
- WebSocket: Le client est développé à l'aide de Cocos Creator, et la communication à longue durée est en charge WebSocket.
- GRPC: Sur la base du protocole HTTP / 2 GRPC, il peut réaliser une communication multi-flux sur une connexion de socket.
- Format de données
- JSON: En raison de l'auto-interprétation du format JSON, il est principalement utilisé pour l'échange de données entre les connexions courtes et les interfaces du système de fonctionnement du backend dans le jeu.
- Protobuf: principalement utilisé pour l'échange de données entre le client et le serveur WebSocket et le micro-service
Diagramme de composants de service

- Agent: il est principalement utilisé pour l'accès au client. et facile à développer horizontalement
- UserCenter: Toutes les données des joueurs sont gérées dans le centre des utilisateurs, et le centre des utilisateurs est responsable de la lecture, de l'écriture, de la suppression, de la modification et de la vérification des données de jeu. .
- Serveur de jeu: principalement responsable du traitement de la logique commerciale du jeu
Authentification et authentification de l'identité

- Utilisez JWT pour s'authentifier entre les services
- Connexion unique via une passerelle API
- Faire l'authentification à l'échelle mondiale et l'autorisation dans chaque microservice
Dépendance des installations
- Docker: Toutes les installations de dépendance et les instances de jeu sont déployées via la version de la communauté Docker
- RockCoach: En tant que base de données persistante
- Kafka: comme file d'attente de messages et plate-forme de flux
- etcd: pour la découverte de services
- GOGS: Utilisez GOGS pour la gestion de la version
- Bind9: serveur de noms de domaine, commutation transparente des réseaux de développement et de test par la résolution de noms de domaine de commutation
générateur de kit
- YIV / GK: Le générateur de code go-kit est un exercice électrique à la main. Pour écrire une interface de service, chacun doit écrire un ensemble complet de points de terminaison et de transport. Vous sentez que vous faites du travail répétitif et que vous êtes très sujet aux erreurs. n'était pas encore parfait, et il ne m'a pas été complètement applicable, donc je l'ai baissé et je l'ai changé moi-même et je l'ai transmis automatiquement, ce qui peut réduire le code en double de 60% lors de l'écriture d'interfaces de service. probabilité d'erreurs.
Environnement système
se référer à
- Gonet / 2: Yivgame a absorbé beaucoup de conceptions de Gonet, comme l'utilisation du flux pour une transmission transparente, l'introduction de Kafka, etc.
- Go-Kit: Yivgame est développé sur la base de Go-Kit
- goddd: un exemple d'application basée sur le modèle de domaine écrit en Go
- Persistance pratique dans Go: Organisation de l'accès à la base de données
- L'architecture propre
- Appliquer l'architecture propre pour aller applications
- Un article pour comprendre la structure hiérarchique
Quelques réflexions sur le design
- La complexité du système ne fera que disparaître et ne disparaîtra pas. .
- Le kit ne convient pas à la poursuite des objectifs faciles à utiliser, courts et rapides. aide le découplage logique.
- Go-Kit commence par l'interface de service, commence par se concentrer sur les domaines d'activité, HTTP ou GRPC n'est qu'un moyen de le publier dans le monde extérieur, et il est finalement placé.
- Ne poursuivez pas la liberté d'écriture, mais la liberté d'adaptabilité des logiciels ne signifie pas que je peux écrire autant que je le souhaite. n'est pas gratuit car il définit le résultat est que les services écrits à l'aide de tout sont similaires. Il est tellement génial que le code est écrit comme une peinture, et peut être compilé et exécuté.
- Le codec et la communication des appels de microservice introduits sont d'environ 2 millisecondes, et le délai de ping mutuel domestique est généralement de 40 ms.
- Que ce soit un cadre ou une langue, ce sont des outils. Si les outils sont les meilleurs, ils seront mauvais s'ils ne sont pas bien utilisés.