I saw this question on Zhihu today: “Why is the Server of game company unwilling to microserve?
1. Background
Recently, I interviewed a game company (mandajian, listed) and asked him whether the company has any plans and considerations for micro-service architecture.
Now, let’s take a look at the answers of two highly praised people. I have sorted out the information and documents related to micro-services here.
2. This is how Hongjic93 answered
For example, MOBA/Honor of Kings /LOL, just look at the Honor of Kings client and imagine.
Account system, rune system, hero system, skin system, friend system, Messaging between friends, these are all routine operations. If the flow is large enough, of course, we can use the architecture of micro-service to do it.
But that’s not the core of the game, the core is the MOBA: Multiplayer Online Battle Arena.
What are the characteristics? 10 people between high speed multidirectional communication of game events, Streaming/Broadcast/Multicast/Pubsub various communication mode. So the core of the game is high-speed Internet communication between small groups. That’s what they call Realtime. An extra 10ms delay will make the player swear.
(1) In order to disassemble the business perfectly, the micro-service divides the original module in the same process into different services, which significantly increases the extra network overhead.
Not to mention Service Mesh, various gateways, proxies, and sidecars. (2) Microservice basically only has the mode of Request/Response. Can’t do Streaming? Microservices generally require applications to be stateless in order to scale horizontally. Streaming itself adds state.
③ I can imagine a League of Legends game using the same server to communicate between 10 players in order to improve communication performance, so that data can be exchanged locally to maximize performance.
The client or server unified gateway must support Sticky Routing. If the client connection is broken, the next one must reconnect to the same server.
Stateless for microservices, the water bottle extension requirement itself is anti-sticky Routing because Sticky Routing itself is the state.
(4) For the server cluster, there are countless king of Glory matches going on at the same time, each can be viewed as a sandbox, each sandbox is in a different state: how many times the tower was pushed, how many times you were killed, how many times the opposite is super, 20 minutes is up.
These are long-running states, and the server can’t clean up a game state until the game is over. So while these states are not written to persistent storage, they are bound to remain in memory for a long time. It’s all statuses, and if you have statuses, you can’t use microservices.
Unless you’re talking about moving all these states to Redis, the server has to do a Remote Request in the middle of the traffic flow, and the latency increases as time goes by.
Either way, it’s not good. (For example, imagine that the other party is in A’s crystal. Every operation of A is an Event, which will be Streaming into the sandbox of the server. There is A stream processor in the sandbox, and every time it receives an Event of your crystal being sent by A, it will calculate whether your crystal has burst. This calculation needs to be extremely fast, and you can’t store your crystal health data remotely.
Games like this have a high demand for network, memory and CPU optimization. During the whole process of the game, there is almost no RPC call. Remote Data, or Rrefetch, is really needed, which can be loaded at the beginning of the game.
Microservices are not a silver bullet, they are just a convenient way to disentrench old CRUD applications. They don’t touch on advanced interaction methods and they don’t touch on the real difficulty of distributed systems: state, which is not as useful as people think.
It feels like microservices have changed the Internet, except that 90% of Internet applications are just CRUD on a small scale.
It’s perfectly fine for someone who hasn’t heard of microservices, because it’s not an advanced concept, to know that microservices are not suitable for a game when you tell them that they have a good understanding and a deep understanding of game system design.
2. 3. How to Lose weight
Have you ever played a board game (the simplest kind of game)?
(1) Microservice itself is to cope with the complexity of business logic, need a new way to organize the interface. The logic of the game itself is not so complicated, such as the lobby is some basic functions, modify accounts, login, etc. The game is the logic of the game.
(2) The game logic server itself (such as Doudizhu and other cards) is stateful because of the network response performance requirements (players are far more sensitive to the feedback time of each operation than the business system).
State exists in memory, occasionally accept Redis, MySQL, etc is absolutely not acceptable, relational row database is only used for timed asynchronous persistence of data, only game server persistence in Redis can be.
(3) Game servers generally need to actively push, so the first generation of microservice gateway can not meet the demand, TCP has no gateway to use, Spring Cloud Gateway’s Web Socket may work (but TCP is definitely more reasonable than Web Socket from an attack defense perspective).
First, the Ribbon, Feign, etc., are not suitable because they are based on HTTP. There is a message disorder problem with HTTP.
For example, when a player plays a card twice, it can be out of order in HTTP. Game server clusters are typically interconnected using long connections. Maybe Dubbo? (It is said to be a long connection)
⑤ The game logic server (such as doulandlord server) generally cannot be made with Spring MVC because the threading model is completely different.
The multithreaded model is also very complex to deal with poor game performance, typically using a single process/thread to drive a fixed number of rooms (which is why the server must be stateful and cannot read or write MySQL directly). Generally direct Netty.
⑥ Automatic expansion in the game side is called open service, has a fixed process and tools and limiting mode.
⑦ Many operations of the game do not exist service degradation circuit breaker, not directly report the error to the user.
The lobby server login and registration can indeed do micro services, but in fact, it is not micro services, is several interfaces have automatic horizontal expansion scheme.
Service registration found to be of little use, open services are certain things, there are a series of operational means to cooperate, service is absolutely not casually off.
⑨ the traffic handled by the game is really not very much. Your online board game of 10,000 yuan is already very profitable, and 100,000 yuan is a very powerful product.
⑩ Do some independent servers, such as recharge, need microservitization? Let’s just say that this kind of server needs microservice processing, the project team will be laughing in their dreams.
Although there are many points above, it is also possible to consider using Spring Cloud to transform the game cluster, because the game cluster has the same registry, service discovery, and startup sequence, but Spring Cloud does not design for the game.
For example, at least fully support Webflux (not carefully researched), need a single threaded long connection preferably support Protobuf RPC framework (integrated service discovery related functions and interfaces).
The gateway supports TCP or at least encapsulates or exposes some Netty Decoder Encoder(or allows injection) etc.
The last
I sorted out a: micro-services related information and documents, Spring family bucket series, systematic information of Java, (including Java core knowledge points, interview topics and the latest Internet questions in 20 years, e-books, etc.) friends who need to get free.