introduce

This is a series

  1. Explore Golang cloud native game server development, 5 minutes to learn the Nano game server framework
  2. Explore Golang Cloud native game server development, using Gorilla WebSocket as an official example
  3. Explore Golang cloud native game server development, Nano built-in distributed game server solution test case

The sample warehouse

The official example I modified: distributed-chat

The connection and difference between distributed and cluster

Distribution refers to the distribution of different businesses in different places; Cluster refers to the centralization of several servers to achieve the same business.

Every node in the distribution can be a cluster. And clustering is not necessarily distributed.

The difference between distributed and cluster

explore

We’re going to 3-distributed chat

Start the master server

Used to manage or schedule other servers in the cluster.

First compile:

go build -o distributed
Copy the code

And then:

# It listens at 127.0.0.1:34567, which is also the gRPC server address
# It provides two services externally:
# topicservice. NewUser ->> common logic for processing NewUser requests from the gateway, etc
# topicService. Stats ->> cluster machine service call statistics etc
Component: Hanlder: Hanlder: Hanlder: Hanlder: Hanlder: Hanlder: Hanlder: Hanlder: Hanlder
./distributed master --listen "127.0.0.1:34567"
Copy the code

Start the chat server and add it to the cluster

Real game business logic services

# --master 127.0.0.1:34567
# It listens at 127.0.0.1:34580, which is also the gRPC server address
# It provides two services externally:
# RoomService.JoinRoom ->> Add client sessions to Group for unified management
# roomService. SyncMessage ->> broadcast messages, which call group-managed sessions and write messages to their webSocket connections
./distributed chat --master "127.0.0.1:34567" --listen "127.0.0.1:34580"
Copy the code

Start the gateway server and add it to the cluster

The entry address that the client really wants to connect to:

# -gate-address "127.0.0.1:34590
# It listens at 127.0.0.1:34570, which is also the gRPC server address
# It provides two services externally:
# bindService. Login # Authentication aspect to processing
# # BindService. BindChatServer directly tied to specific to the chat server
./distributed gate --master "127.0.0.1:34567" --listen "127.0.0.1:34570" --gate-address "127.0.0.1:34590"
Copy the code

Remote Service Remote Service

After registering with the Master node, each server in a cluster registers services provided by other nodes in the cluster as its Remote Service.

So when our client calls starx.notify(‘ roomService.syncMessage ‘… The gateway Server will actually call its Remote Service, which will eventually go to the Chat Server node.

The specific process

http://127.0.0.1:12345/web/

Login(Gate Server) -> TopicService.NewUser(Master Server) -> RoomService.JoinRoom(Chat Server)

Users send messages: Gate Server -> RoomService.syncMessage (Chat Server)