Broker mode of Distributed mode (GO)

Source of the problem:

Create a game system that will run in the Internet environment. The client connects to the game server through the WWW service or the specific client software, and as the traffic increases, the system expands and the final background data and business logic are distributed. However, compared with the centralized system, the complexity is inevitably increased, how to reduce the degree of coupling between the various components.

Challenge:

The need to ensure scalability, maintainability, and updatable, the need to divide services into relatively independent components, components are distributed deployment, between them through the inter-process communication method to achieve interaction. Service additions, deletions, and changes should be supported. Ideally, a centralized system and a distributed system are no different in the central logic of the developer's point of view. To achieve this goal:

L can access services remotely, and for visitors, the location of the service should be transparent.

The components that provide services can be added, deleted, changed, and these should also be supported during the run time.

The client accessing the service should not care about the implementation details of the service.

Solution:

Introduce a broker component to decouple the client and server. The server registers itself to broker and allows the client to access the service by exposing the interface. The client sends the request through the broker, which forwards the request to the server and sends the result or exception of the request back to the client. By using broker mode, an app can access a remote service by sending a message.

This schema mode allows dynamic changes, additions, and deletions to the server, which are transparent from the client's perspective.

Structure:

The Broker pattern defines the 6 class: Client,server,client_proxy,server_proxy,broker,bridge.

Server :

L Responsibility: Handle specific domain issues, implement service details, register yourself to broker, process requests, and return results or exceptions.

L Collaboration class: Server_proxy,broker

Client:

The client is the application that needs to access the remote service, and for this purpose, the client sends a request to the broker and receives a response or exception from the broker. The client and server are only logically related, and in fact the client does not know the exact location of the server.

L Liability: 1. Realize the user-side function, 2. Send the request to broker,3. Receive the corresponding and exception.

L Collaboration class: Broker,client_proxy

Broker:

A broker can be considered a message forwarder. Broker is also responsible for some control and management operations. It can locate the location of the server and, if an exception occurs, can pass the exception capture to the client. The broker needs to provide the interface to the server for registering the service. If the request comes from another broker, the local broker needs to forward the request and eventually respond the result or exception to the appropriate remote broker. The service provided by the broker is very similar to the name service (such as DNS, LDAP).

L Liability: 1. Registration services. 2. Provide the service API. 3. Forward the message. 4. Fault-tolerant processing. 5. Interacting with other broker. 6. Location services.

L Collaboration class: Client_proxy,server_proxy,bridge

Client_proxy:

Connecting the client and broker, this layer guarantees the transparency of the communication so that the client invokes the remote service as if it were a local service.

L Liability: 1. Encapsulates a specific system call. 2. Package the communication parameters, control information and so on.

L Collaboration class: Client,broker.

Server_proxy:

Server_proxy is corresponding to the Client_proxy, which accepts the request, unpack the message, parse out the parameters and invoke the implementation interface of the service.

L Liability: 1. Encapsulates a specific system call. 2. Package the communication parameters, control information and so on. 3. Call the server's service interface.

L Collaboration class: Server,broker.

Bridge:

Bridge is used to connect to each broker, which is generally optional. This role is likely to be required when the system is made up of miscellaneous networks.

L Liability: 1. Encapsulates a specific network feature. 2. Pass the communication between the broker.

L Collaboration class: Broker.

Application Scenario One:

Direct means of communication. Client and server understand each other's communication protocols. Broker mainly completes the handshake between client and server. All messages and exceptions are then directly interacting with the server by the client. (imagine DNS). Simple Object interaction

Application Scenario Two:

L Broker starts, completes its own initialization, and then enters the event loop, waiting for the message to arrive.

L Server starts, performs its own initialization first, and then registers itself to broker.

The broker receives the server's registration request, joins it to the list of available services, and responds with an ACK to the server.

The server receives the ACK, enters the event listening loop, waits for the message to arrive.

L Client invokes the method of the remote service object, Client_proxy encapsulates the message, and sends it to the broker.

L Broker queries the server that can be used, and forwards the request to the server.

L Server_proxy Parse messages, isolate parameters and control information, and invoke a specific Server implementation interface. The results of server processing are encapsulated by Server_proxy as messages forwarded to the server.

The broker forwards the corresponding message to the correct client_proxy,client and receives the response to continue other logic.

Simple Object interaction

Application Scenario Three:

Broker a receives the request and is referred to the server for processing, but discovers that the server is located in another network node.

L Broker A forwards the request to bridge A,bridge A to format the request and transmit it to bridge B.

Bridge B will request the necessary formatting to be converted into a format that broker B can understand and forwarded to broker B. Broker B Executes the process in scenario two, and the processed results are returned in reverse order.

Simple Object interaction

Deployment:

Summary: U advantages:

1. Location transparency of the service.

2. The variability and extensibility of the components. Because the server is registered on the broker, the server can be dynamically incremented, deleted, and changed.

3. Broker can interact with each other.

4. reusability.

5. Due to the small coupling of the components, the commissioning and testing work is also controllable.

U Cons:

1. Efficiency, increase the level of broker's message forwarding, the efficiency has been reduced.

2. The ability to fault tolerance must be considered in particular.

3. The commissioning and testing of the work increased.

Go to: http://blog.chinaunix.net/uid-23093301-id-90459.html

Broker mode of Distributed mode (GO)