Source of the problem:
Create a game system that will run in the context of the Internet. The client connects to the game server through the WWW service or specific client software. With the increase of traffic, the system expands continuously, and finally the background data and business logic are deployed in a distributed manner. However, compared with the centralized system, the complexity is inevitably increased, how to reduce the coupling between the various components.
challenge
Scalability, maintainability, and renewability need to be guaranteed, and services need to be divided into relatively independent components. Components are deployed in a distributed manner, and they interact through inter-process communication. Additions, deletions, and changes to services should be supported. Ideally, from a developer's point of view, a centralized system is no different from a distributed system in terms of central logic. To achieve this goal:
the service can be accessed remotely, and the location of the service should be transparent to the visitor.
Components that provide services can be added, removed, and changed, and these should also be supported at runtime.
Clients 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 with the Broker, allowing clients to access the service by exposing the interface. The client sends the request through the broker, the broker forwards the request to the server, and sends the result or exception of the request back to the client. By using the Broker pattern, applications can access remote services by sending messages.
This architectural pattern allows dynamic changes, additions, and deletions of servers, transparently from the client's perspective.
structure:
The Broker mode defines 6 classes: Client, Server, Client_Proxy, Server_Proxy, Broker, Bridge.
Server：
Responsibilities: Handle domain-specific issues, implement service details, register yourself with the Broker, handle requests and return results or exceptions.
Collaboration class: Server_Proxy, Broker
Client：
Client is an application that needs to access remote services. To do this, Client sends requests to Broker and receives responses or exceptions from Broker. Client and Server are only logically related. In fact, Client does not know the exact location of Server.
Responsibilities: 1. Implement user-side functions, 2. Send requests to Broker, 3. Receive responses and exceptions.
Collaboration class: Broker, Client_Proxy
Broker：
Brokers can be thought of as message forwarders. Brokers are also responsible for some control and management operations. It can locate the location of the server, and if an exception occurs, it can pass the exception capture to the Client. Broker needs to provide an interface for registering services to Server. If the request comes from other brokers, the local broker needs to forward the request and finally respond the result or exception to the corresponding remote broker. The services provided by the broker are very similar to the name service (eg DNS, LDAP).
Responsibilities: 1. Register the service. 2. Provide service API. 3. Forward the message. 4. Fault-tolerant processing. 5. Interaction with other Brokers. 6. positioning service.
Collaboration class: Client_Proxy, Server_Proxy, Bridge
Client_Proxy：
Connecting Client and Broker, this layer ensures the transparency of communication, so that Client calls remote services just like calling local services.
Responsibilities: 1. Encapsulate specific system calls. 2. Encapsulate communication parameters, control information, etc.
Collaboration class: Client, Broker.
Server_Proxy：
Server_proxy is corresponding to Client_Proxy, it accepts requests, unpacks messages, parses out parameters and calls the implementation interface of the service.
Responsibilities: 1. Encapsulate specific system calls. 2. Encapsulate communication parameters, control information, etc. 3. Call the service interface of the server.
Collaboration class: Server, Broker.
Bridge：
Bridge is used to connect each Broker, generally this component is optional. This role may be required when the system is composed of complex networks.
Responsibilities: 1. Encapsulate specific network features. 2. Pass the communication between Brokers.
Collaboration class: Broker.
Application Scenario 1:
direct communication. Client and Server understand each other the communication protocol between them. Broker mainly completes the handshake between Client and Server. After that, all messages and exceptions are directly interacted by the Client and the Server. (Imagine DNS). Simple object interaction is shown in the figure:
Application Scenario Two:
The Broker starts, completes its own initialization, and then enters the event loop, waiting for a message to arrive.
Server starts, first performs its own initialization, and then registers itself to the Broker.
The Broker receives the Server's registration request, adds 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, and waits for the message to arrive.
The Client calls the method of the remote service object, and Client_Proxy encapsulates the message and asks it to be sent to the Broker.
The Broker queries the available servers and forwards the request to the server.
Server_Proxy parses the message, separates parameters and control information, and calls a specific Server implementation interface. The result processed by the Server is encapsulated into a message and forwarded to the Server through Server_proxy.
The Broker forwards the corresponding message to the correct Client_Proxy, and the Client receives the response and continues with other logic.
Simple object interaction is shown in the figure:
Application scenario three:
Broker A receives the request and hands it over to the server for processing, but finds that the server is located on another network node.
Broker A forwards the request to Bridge A, and Bridge A formats the request as necessary and transmits it to Bridge B.
Bridge B formats the request as necessary, converts it into a format that Broker B can understand, and forwards it to Broker B. Broker B executes the process in scenario 2, and the processing results are returned in the reverse order as above.
Simple object interaction is shown in the figure:
Deployment diagram:
Summarize:
advantage:
- Location transparency of services.
- Component variability and extensibility. Since the Server is registered with the Broker, the Server can be dynamically added, deleted, and changed.
- Brokers can interact.
- Reusability.
- Since the components are less coupled, the work of debugging and testing is also manageable.
shortcoming:
- Efficiency; a layer of broker message forwarding is added, and the efficiency is reduced.
- Fault tolerance must be given special consideration.
- The work of debugging and testing has increased.
Reprinted from http://blog.chinaunix.net/uid-23093301-id-90459.html