yivgame
O YIVGAME é uma solução de servidor de arquitetura de microsserviços, gravada no idioma Go com base no Go-Kit. Além do servidor de jogos (conexão longa), ele também inclui um servidor de interface da API para operações front-end e back-end. Além do próprio servidor, a configuração detalhada da implantação do Docker também estará envolvida.
característica
- Arquitetura de microsserviço
- O cliente e o servidor de jogo percebem a transmissibilidade através do streaming bidirecional de GRPC
- Comunicação do WebSocket do Websocket, do lado do servidor
- Implementar pontos de extremidade HTTP e WebSocket Endpoints Westes and Trogs
Prática de design
Arquitetura de microsserviço
- Através da arquitetura de microsserviços, os servidores de jogos tradicionais são divididos em diferentes microsserviços
- Diferentes micro -servidores podem se comunicar de maneira síncrona através da GRPC e assíncrona através de Kafka
Modelo acionado por domínio
- Para alcançar a dissociação de diferentes níveis de software, cada serviço é projetado de acordo com o modelo orientado ao domínio.
- Divida a estrutura de software dos microsserviços de dentro para fora para a camada de negócios do jogo, use camada de caixa, camada de interface e camada de dependência da instalação
- Respeitar estritamente a dependência unidirecional de fora para o interior entre os vários níveis
A camada de negócios implementa principalmente a lógica principal do jogo ou servidor, não se importa com implementações externas e depende de sistemas de arquivos, bancos de dados etc. A camada de negócios usa interface para definir interfaces, implementa métodos de interface pela camada de dependência e passa eles em principal por meio de injeção de dependência. Portanto, exceto por citar algumas bibliotecas padrão básicas, a camada de negócios dificilmente se refere a pacotes de terceiros.
Modelo orientado a eventos com kafka
- O método de comunicação principal entre todo o sistema de microsserviço é a chamada síncrona de GRPC e a comunicação de eventos assíncronos usando Kafka como plataforma de streaming.
- Todas as atividades que estão sendo seguidas nos microsserviços serão publicadas na Kafka na forma de eventos gerados
Modelo orientado a eventos e análise de dados
- No passado, ao fazer a análise dos dados do jogo, eles eram pesquisados através de tabelas conjuntas.
- Depois de usar o modelo orientado a eventos, todos os comportamentos dos jogadores com os quais prestamos atenção podem ser registrados como eventos, projetar diferentes atributos para diferentes eventos e obter análise de dados extremamente escalável
Estrutura do diretório do projeto
- Como a arquitetura de microsserviços implementada pelo Go-Kit, tente mantê-la consistente com o exemplo oficial de kit Go-Kit na estrutura do diretório o máximo possível.
- Como o modelo acionado por domínio está em camadas, é natural incluir o diretório de pacotes interno na camada externa ao projetar a estrutura do diretório do projeto A estrutura do diretório no nível do domínio, em vez disso, o diretório de pacotes de diferentes níveis é colocado no diretório do mesmo nível.
Sem variáveis globais
- Para tornar o software mais claro na lógica do código, evite estritamente variáveis globais
Cache de dados, armazenamento de dados e kafka
- Portanto, os dados do jogador são diretamente armazenados na memória de serviço, o que facilita o processamento direto de dados
- A modificação dos dados do player é gravada em Kafka através do WAL e, em seguida, o serviço de armazenamento é gravado de forma assíncrona no banco de dados.
- Como o método WAL é usado, refazer e desfazer os dados do jogador são fáceis de implementar
Newsql barraca de barro
- A persistência dos dados usa o CockRaChDB, um banco de dados relacional que suporta transações distribuídas
- O uso de baratas pode facilmente obter escala horizontal, tolerância a falhas, recuperação automática e balanceamento de carga
Comecei a usar o Cockroachdb da v1.0, da v1.0 a v1.0.6, a barata sempre teve um problema de colisão em situações e pressões específicas. não foi grande. Como quase todos os dados do Yivgame estão na memória, e apenas o banco de dados precisa ser escrito ao salvar; portanto, para todo o sistema Yivgame, não há gargalos de desempenho de banco de dados.
Modelo
Diagrama de comunicação
- Método de comunicação
- HTTP: HTTP é uma conexão curta, usada principalmente para comunicação no sistema de operação em segundo plano.
- WebSocket: o cliente é desenvolvido usando o Cocos Creator e a comunicação de conexão longa suporta o WebSocket.
- GRPC: Com base no protocolo HTTP/2 GRPC, ele pode realizar a comunicação multi-stream em uma conexão de soquete.
- Formato de dados
- JSON: Devido à auto-interpretação do formato JSON, ele é usado principalmente para troca de dados entre conexões curtas e interfaces de sistema de operação de back-end no jogo.
- Protobuf: usada principalmente para troca de dados entre o cliente e o servidor WebSocket e o micro-serviço
Diagrama de componentes de serviço
- Agente: ele é usado principalmente para acesso ao cliente. e fácil de expandir horizontalmente
- UserCenter: Todos os dados do player são gerenciados no centro de usuários e o centro de usuários é responsável por ler, escrever, excluir, modificar e verificar dados do jogo. .
- Servidor de jogo: principalmente responsável pelo processamento da lógica de negócios de jogos
Autenticação e autenticação de identidade
- Use JWT para autenticar entre serviços
- Indicidade única através do gateway da API
- Faça autenticação globalmente e autorização em todos os microsserviços
Dependência das instalações
- Docker: Todas as instalações de dependência e instâncias de jogo são implantadas através da versão da comunidade Docker
- RockCoach: como um banco de dados persistente
- Kafka: como fila de mensagens e plataforma de fluxo
- etcd: para descoberta de serviços
- Gogs: Use Gogs para gerenciamento de versão
- Bind9: servidor de nomes de domínio, comutação contínua das redes de desenvolvimento e teste através da resolução de nomes de domínio da comutação
Gerador Go-Kit
- YIV/GK: Gerador de código GO-KIT é uma broca elétrica à mão. Para gravar uma interface de serviço, todos precisam escrever um conjunto completo de endpoint, definição e transporte. Você sente que está fazendo um trabalho repetitivo e é muito propenso a erros. Ainda não foi perfeito, e não foi completamente aplicável a mim, então eu o gasto e mudei e passei por ele gerar automaticamente código, o que pode reduzir o código duplicado em 60% ao escrever interfaces de serviço. probabilidade de erros.
Ambiente do sistema
consulte
- Gonet/2: Yivgame absorveu muitos designs da Gonet, como o uso de fluxo para transmissão transparente, introdução de kafka, etc.
- GO-KIT: Yivgame é desenvolvido com base no Go-Kit
- Goddd: um aplicativo de amostra baseado no modelo de domínio escrito em go
- Persistência prática em Go: Organizando o acesso ao banco de dados
- A arquitetura limpa
- Aplicando a arquitetura limpa para ir aplicativos
- Um post para entender a estrutura hierárquica
Alguns pensamentos sobre design
- A complexidade do sistema só muda e não desaparece. .
- O GO-KIT não é adequado para buscar objetivos fáceis de usar, curtos e rápidos. Ajuda a dissociação lógica.
- O GO-KIT começa com a interface de serviço, começa com foco nas áreas de negócios, HTTP ou GRPC é apenas uma maneira de publicá-lo no mundo exterior e é colocado no final.
- Não busque a liberdade de escrita, mas busque a adaptabilidade da liberdade de software não é gratuito porque define o resultado é que os serviços gravados usando tudo parecem semelhantes. É tão incrível que o código é escrito como uma pintura e pode ser compilado e executado.
- O codec e a comunicação de chamadas de microsserviço introduzidas são cerca de 2 milissegundos, e o atraso doméstico de ping mútuo é geralmente 40ms.
- Seja uma estrutura ou um idioma, eles são apenas ferramentas Se as ferramentas são as melhores, elas serão ruins se não forem bem usadas.
