Broker mode in distributed mode

Source:

Create a game system that runs on the Internet. The client connects to the game server through the WWW Service or a specific client software. As the traffic increases, the system continues to expand and the background data and business logic are deployed in a distributed manner. However, compared with a centralized system, the complexity is inevitably increased. How can we reduce the coupling between components.

Challenges:

To ensure scalability, maintainability, and updatability, You need to divide services into relatively independent components. components are deployed in a distributed manner and interact with each other through inter-process communication. Service addition, deletion, and change should be supported. Ideally, from the developer's perspective, centralized systems and distributed systems are logically different in the center. To achieve this goal:

L remote access to the service, and the service location for visitors should be transparent.

L The components that provide services can be added, deleted, or changed, and these components should also be supported at runtime.

L 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 the broker and allows the client to access the service by exposing the interface. The client sends a request through the broker. The broker forwards the request to the server and sends the request result or exception back to the client. By using the broker mode, applications can access remote services by sending messages.

This architecture allows you to dynamically change, add, and delete servers. These are transparent from the client perspective.

Structure:

The broker mode defines six classes: client, server, client_proxy, server_proxy, broker, and bridge.

Server:

L responsibility: handles issues in specific fields, implements service details, registers itself to the broker, Processes requests, and returns results or exceptions.

L collaboration class: server_proxy, Broker

Client:

The client is an application that needs to access the remote service. Therefore, 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. In fact, the client does not know the exact location of the server.

 

L responsibility: 1. Implement the client function; 2. send requests to the broker; 3. Receive corresponding and abnormal requests.

L collaboration class: Broker, client_proxy

BROKER:

The broker can be seen as a message forwarder. The broker is also responsible for some control and management operations. It can locate the server. If an exception occurs, it can capture the exception and send it to the client. The broker must provide an interface for registering services to the server. If the request comes from another broker, the local broker needs to forward the request and finally return the result or exception to the corresponding remote broker. The service provided by the broker is very similar to the name service (such as DNS and LDAP ).

L responsibility: 1. register the service. 2. Provide service APIs. 3. Forward messages. 4. Fault Tolerance processing. 5. Interaction with other brokers. 6. Locate the service.

L collaboration class: client_proxy, server_proxy, Bridge

Client_proxy:

Connect the client to the broker. This layer ensures the transparency of communication, so that the client can call remote services just like calling local services.

 

L responsibility: 1. encapsulate specific system calls. 2. encapsulate communication parameters and control information.

L collaboration class: client and broker.

Server_proxy:

Server_proxy corresponds to client_proxy. It accepts requests, unpacks messages, parses parameters, and CALLS service implementation interfaces.

L responsibility: 1. encapsulate specific system calls. 2. encapsulate communication parameters and control information. 3. Call the server service interface.

L collaboration: Server and broker.

Bridge:

Bridge is used to connect various brokers. Generally, this component is optional. This role may be required when the system is composed of a complex network.

L responsibility: 1. encapsulate specific network features. 2. Transfer Communication Between Brokers.

L collaboration class: Broker.

Application Scenario 1:

Direct communication. The client and server understand each other's communication protocols. The broker completes the handshake between the client and the server. All subsequent messages and exceptions are directly interacted with the server by the client. (Imagine dns ). Simple Object Interaction

Application Scenario 2:

 

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

L server starts, first executes its own initialization, and then registers itself to the broker.

L The broker receives the Server registration request, adds it to the list of available services, and responds to ack to the server.

L server receives ack and enters the event listening loop, waiting for the message to arrive.

L The client calls the method of the remote service object. client_proxy encapsulates the message and sends it to the broker.

L The broker queries available servers and forwards requests to the server.

L server_proxy parses messages, separates parameters and control information, and CALLS specific server implementation interfaces. The server encapsulates the processed results into messages and forwards them to the server through server_proxy.

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

Simple Object Interaction

Application Scenario 3:

 

L broker a receives the request and submits it to the server for processing. However, it finds that the server is located on another network node.

L broker a forwards the request to bridge a. Bridge a formats the request and sends it to bridge B.

L bridge B formats the request as expected by broker B and forwards it to broker B. Broker B executes the process in scenario 2, and the processing result is returned in the reverse order above.

Simple Object Interaction

Deployment:

 

 

Summary:  U advantages:

1. Service location transparency.

2. Component variability and scalability. Since the server is registered on the broker, the server can be dynamically added, deleted, or changed.

3. Interaction between brokers.

4. reusability.

5. Due to the small Coupling Degree of components, debugging and testing work is also controllable.

 

U disadvantages:

1. efficiency; added a layer of broker message forwarding, reducing the efficiency.

2. Special consideration must be given to fault tolerance capabilities.

3. More debugging and testing work.

 

[Reprint] http://blog.chinaunix.net/uid-23093301-id-90459.html

 

Broker mode in distributed mode