Haga clic en la fuente azul de arriba y seleccione "Cuenta oficial de Star"
Artículos de alta calidad, entregados de inmediato
99 conjuntos de proyectos de combate reales de nivel empresarial de Java
Información del arquitecto 4000G
Fuente del contenido: Conozca a todos los internautas, organícelos desde: Proyecto web Java Edition
zhihu.com/question/359630395/answer/954452799
Hoy vi una pregunta de este tipo en Zhihu: "¿Por qué los servidores de las empresas de juegos no están dispuestos a ser microservicios?"
Introducción de antecedentes:
El autor fue recientemente a entrevistar a una empresa de juegos.
Entrevisté recientemente a una empresa de juegos (mandarín, se enumeran)
Le pregunté, ¿la empresa tiene planes y consideraciones para la arquitectura de microservicios?
Se sorprendió y dijo: nunca he oído hablar de microservicios, ¿puedes explicarlo?
Probablemente dije que es conveniente para las pruebas, conveniente para el mantenimiento, conveniente para las actualizaciones, acoplamiento flexible entre servicios, desarrollo en varios idiomas, expansión automática ... etc.
Luego dijo que el servidor de juegos no necesita microservicios, porque se requiere tiempo real y el rendimiento de los microservicios se verá afectado, es bueno desarrollarlos en módulos.
No estoy seguro, pero ¿los microservicios no son una tendencia? Especialmente para las grandes empresas, el servicio de servidor de juegos debería ser fácil de dividir, ¿verdad?
hongjic93 respondió así:
Por ejemplo, juegos de moba / Honor of Kings / LOL, solo mira al cliente de Honor of Kings, e imagina.
El sistema de cuentas, el sistema de runas, el sistema de héroe, el sistema de máscara, el sistema de amigos y la mensajería entre amigos son operaciones de rutina. Si el tráfico es lo suficientemente grande, por supuesto, puede usar la arquitectura de microservicio para hacerlo.
Pero este no es el núcleo de este juego, el núcleo es MOBA: campo de batalla en línea multijugador. Cuales son las caracteristicas?
Comunicación multidireccional de alta velocidad de varios eventos del juego entre 10 personas,
transmisión / transmisión / multidifusión / pubsub varios modos de comunicación
Entonces, el núcleo del juego radica en la comunicación de red de alta velocidad entre grupos a pequeña escala. Es el tiempo real que dijo la otra parte. Los jugadores tendrán que regañar a su madre si hay un retraso de 10 ms.
1. Para desarmar perfectamente el negocio, los microservicios dividen los módulos originales en el mismo proceso en diferentes servicios, lo que aumenta significativamente la sobrecarga adicional de la red. Sin mencionar la malla de servicios, varias puertas de enlace, proxies y sidecars. Es solo una preocupación que la demora sea demasiado baja.
2. Los microservicios básicamente solo tienen un modelo de solicitud / respuesta. ¿No puedes hacer streaming? Los microservicios generalmente requieren que las aplicaciones no tengan estado para escalar horizontalmente. Streaming se une al estado
3. Puedo imaginar que para mejorar el rendimiento de la comunicación, es probable que un juego de League of Legends utilice el mismo servidor para ser responsable de la comunicación entre estos 10 jugadores, de modo que los datos se puedan intercambiar localmente y se maximice el rendimiento. . Esto requiere que la puerta de enlace unificada del cliente o servidor admita el enrutamiento fijo. Suponiendo que la conexión del cliente se interrumpa, el siguiente debe volver a conectarse al mismo servidor anterior. Los requisitos de extensión sin estado y de botella de agua de los propios microservicios son el enrutamiento antiadherente, porque el enrutamiento adhesivo en sí es el estado.
4. Para el clúster de servidores, hay innumerables competiciones de Glory of Kings en curso al mismo tiempo, cada una puede considerarse como una caja de arena, cada caja de arena está en un estado diferente: cuántas torres se han empujado, a ti te han matado varias veces, y unos superdioses en el lado opuesto, han pasado 20 minutos. Estos son estados de larga duración y el servidor puede limpiar el estado de un juego hasta que el juego termine. Entonces, aunque estos estados no necesitan escribirse en un almacenamiento persistente, inevitablemente existirán en la memoria durante mucho tiempo. Todo es estado. Si hay estado de todos modos, ni siquiera pienses en usar microservicios. A menos que diga que mueva todos estos estados a redis, se realizará una solicitud remota cuando el servidor esté a la mitad del flujo de información y el retraso aumentará una y otra vez. De todos modos, no es bueno. (Por ejemplo, imagina que la otra parte está en A y tu cristal. Cada operación de A es un evento, que se transmite a la zona de pruebas del lado del servidor. Hay un procesador de transmisión en la zona de pruebas. Cada vez que recibe un evento de su cristal y A Calcule si su cristal ha explotado. Este cálculo debe ser extremadamente rápido, es imposible para usted almacenar los datos de la salud de su cristal en el control remoto)
Estos juegos tienen altos requisitos para la optimización de la red, la memoria y la CPU. Durante todo el juego, casi no hay llamadas RPC. Los datos remotos son realmente necesarios y deben ser precargados, que es cuando el juego acaba de comenzar. Cargado
Los microservicios no son una solución milagrosa, es decir, solo es conveniente desmontar la aplicación CRUD original. No toca el método de interacción avanzada, y no toca la dificultad real del sistema distribuido: el estado, de hecho, no es tan útil como todo el mundo piensa. Parece que los microservicios han cambiado Internet, pero el 90% de las aplicaciones de Internet son CRUD simples y de pequeña escala.
La otra parte nunca ha oído hablar de microservicios y no hay ningún problema, porque este no es un concepto sofisticado en sí mismo. Por el contrario, la otra parte sabrá que los microservicios no son adecuados para juegos cuando usted lo diga, lo que indica que el la otra parte tiene una sólida comprensión del diseño del sistema de juego.
Brice respondió de esta manera:
Ha jugado un juego de mesa (el tipo de juego más fácil), puede intentar decir algunos puntos:
1. El microservicio en sí mismo debe hacer frente a la complejidad de la lógica empresarial y se necesita una nueva forma de organizar las interfaces. La lógica del juego en sí no es tan complicada. Por ejemplo, el lobby tiene algunas funciones básicas, como cambiar de cuenta e iniciar sesión. El juego en sí es la lógica del juego en sí.
2. El servidor de lógica del juego en sí (como el ajedrez y las cartas como Doudizhu) se debe a los requisitos de rendimiento de respuesta de la red (el tiempo de respuesta del jugador para cada operación es mucho más sensible que el sistema empresarial), por lo que el servidor del juego tiene estado. y el estado existe en la memoria, ocasionalmente aceptar redis, mysql, etc. es absolutamente inaceptable La base de datos de filas relacionales solo se usa para persistir datos de manera periódica y asincrónica, y solo el servidor del juego puede persistir en redis.
3. Los servidores de juegos generalmente necesitan ser impulsados activamente, por lo que la primera generación de puertas de enlace de microservicio no puede satisfacer la demanda. No hay una puerta de enlace para tcp, y se pueden usar sockets web para la puerta de enlace de Spring Cloud (pero desde la perspectiva del anti-ataque, Definitivamente, TCP se usa para juegos finales (razonable que el conector web).
4. Comunicación interservicios rpc First ribbon, fingir, etc. no son adecuados, porque todos se basan en http, hay un problema de desorden de mensajes con Http, por ejemplo, si el jugador juega la carta dos veces, el orden puede ser inconsistente en http. Los clústeres de servidores de juegos generalmente usan conexiones largas para interconectarse. ¿Es posible que necesite usar dubbo? (Escuché que es una conexión larga)
5. El servidor de lógica de juego (como el servidor Doudizhu), generalmente no se puede hacer con Spring MVC, porque el modelo de subprocesamiento es completamente diferente. El modelo de subprocesos múltiples tiene un rendimiento de juego deficiente y es muy complicado. Por lo general, se utiliza un solo proceso / subproceso para controlar un número fijo de salas (esta es la razón por la que el servidor debe tener un estado y no debe leer o escribir directamente en mysql) . Por lo general, netty directamente
6. La expansión automática se llama servidor abierto en el lado del juego, y ha habido procesos y herramientas fijos y métodos de limitación actuales durante mucho tiempo.
7. No hay fusibles de degradación del servicio en muchas operaciones del juego. Si no funciona, debes informar el error directamente al usuario.
8. De hecho, el inicio de sesión y el registro del servidor de lobby, etc. pueden hacer microservicios, pero en realidad no son microservicios, solo unas pocas interfaces que tienen planes de expansión horizontal automática. El registro del servicio resulta de poca utilidad, la apertura del servicio es un asunto determinado, hay una serie de métodos de operación para cooperar, y el servicio no se puede cerrar arbitrariamente.
9. El tráfico manejado por el juego realmente no es demasiado. Ya ha ganado mucho dinero en juegos de cartas y ajedrez en línea de 10,000. 10W es un producto particularmente poderoso.
10. ¿Algunos servidores independientes, como los de recarga, necesitan micro-servicios? Solo se puede decir que este tipo de servidor necesita procesamiento de micro-servicios, y el equipo del proyecto puede despertar en sueños.
Aunque hay muchos puntos mencionados anteriormente, de hecho, también puede considerar usar Spring Cloud para transformar, porque el clúster de juegos también tiene un registro, requiere descubrimiento de servicios y necesita organizar la secuencia de inicio, pero Spring Cloud no está diseñado para juegos. , como al menos el soporte completo de webflux (no lo estudié detenidamente). Es mejor admitir el marco protobuf rpc (funciones e interfaces relacionadas con el descubrimiento de servicios integrados) si necesita una conexión larga de un solo subproceso. La puerta de enlace admite tcp o al menos encapsula o expone algún codificador decodificador netty (o permite la inyección), etc. Espere
有热门推荐????太赞了，Intellij IDEA 竟然把 Java8 的数据流问题这么完美的解决掉了！
一入职！就遇到上亿(MySQL)大表的优化....
Spring vs Spring Boot：3大核心区别
Windows平台上三款提高工作效率的免费神器！
Spring Boot 2.3.0 新特性：优雅停机
干货分享：扫码关注下面的公众号后台回复“99”领取99套实战项目+资料
想充电就关注程序员闪充宝
文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*)