Creating a server for online MMO games in PHP part 13 – Event-driven pattern, JSON-RPC and why not a service (SOA) architecture

If you turn to Wikipedia, one of the main principles of the service architecture is the independence of the language in which the services are written – they can be called through some common communication channel (for example, HTTP requests in a micro service architecture through REST API methods). This approach has proven itself in WEB development, but for an MMO game server it can be slow in some cases, difficult to implement and maintain, but not always.

In particular, applications for creating game maps can work as a service, written in any programming language, located on a separate physical machine – accessing the application from outside to get the map grid and its graphics occurs via HTTP at the time the player is authorized on the authorization service – which is also can “live” separately.

You can see in these cases – these are WEB applications and HTTP exchange. As for the main applications: WebSocket and the Game Server (performing calculations of different mechanics and teams of players) – they are closely related by a programming language that provides them with fast data exchange with each other at a speed of 1,600,000 requests in one direction, although in addition to data exchange, another hard there is no connection (because they work in parallel in different channels as different processes with their own code and a set of libraries).

However, it is also possible to make them as independent services (and write each one, including in different programming languages), but for this you need to implement an exchange between these services, where the fastest protocol will be data exchange through a shared memory (Shared Memory), but these the two services will need to be on the same physical machine to use this exchange.

According to official description of its reference architecture it is accepted that service-based (SOA) systems may not be scalable (although striving for this is the goal). Many developers see it differently (that services Necessarily must be autonomous and capable of scaling) presenting SOA goals as a mandatory requirement for them.