问题来源:
创建一个游戏系统,其将运行在互联网的环境中。客户端通过WWW服务或特定的客户端软件连接到游戏服务器,随着流量的增加,系统不断的膨胀,最终后台数据、业务逻辑被分布式的部署。然而相比中心化的系统,复杂度被无可避免的增大了,该如何降低各个组件之间的耦合度。
挑战:
需要保证可伸缩性、可维护性、可更新性,需要将服务划分为各个相对独立的组件,组件被分布式的部署,它们之间通过进程间通信方式实现交互。服务的增加、删除、改变都应该被支持。理想情况,以开发者的角度看,集中化的系统和分布式的系统在中心逻辑上没有什么不同。为实现这个目标:
- l 可以远程的访问服务,而对于访问者,服务的位置应该是透明的。
- l 提供服务的组件可以增加、删除、改变,而且这些在运行期同样应该被支持。
- l 访问服务的客户端不应该关心服务的实现细节。
解决方案:
引入一个Broker组件,解耦客户端和服务端。服务端注册自己到Broker,通过暴露接口的方式允许客户端接入服务。客户端是通过Broker发送请求的,Broker转发请求道服务端,并将请求的结果或异常回发给客户端。通过使用Broker模式,应用可以通过发送消息访问远程的服务。
这一架构模式允许动态的改变、添加、删除服务端,从客户端的角度,这些都是透明的。
结构:
Broker模式定义了6中类:Client,Server,Client_Proxy,Server_Proxy,Broker,Bridge。
Server :
l 责任:处理特定领域的问题,实现服务的细节,注册自己到Broker,处理请求并返回结果或异常。
l 协作类:Server_Proxy,Broker
Client:
Client是需要访问远程服务的应用程序,为此,Client发送请求到Broker,并从Broker上接收响应或异常。Client和Server只是逻辑上相关而已,实际上Client并不知道Server的确切位置。
l 责任:1. 实现用户端功能,2. 发送请求到Broker,3. 接收相应和异常。
l 协作类:Broker,Client_Proxy
Broker:
Broker可以被看成消息转发器。Broker也负责一些控制和管理操作。它能够定位服务端的位置,若发生异常,能够将异常捕获传给Client。Broker需要提供注册服务的接口给Server。如果请求来自其他的Broker,本地的Broker需要转发请求并最终将结果或异常回应给相应的远程Broker。Broker提供的服务和name service非常相像(如DNS、LDAP)。
l 责任:1. 注册服务。2. 提供服务API。3. 转发消息。4. 容错处理。5. 与其他Broker的交互。6。 定位服务。
l 协作类:Client_Proxy,Server_Proxy,Bridge
Client_Proxy:
连系Client和Broker,这一层保证了通讯的透明性,使Client调用远程服务就像调用本地的服务一样。
l 责任:1. 封装特定的系统调用。2. 封装通讯的参数、控制信息等。
l 协作类:Client,Broker。
Server_Proxy:
Server_proxy是与Client_Proxy相对应的,它接受请求,解包消息,解析出参数并调用服务的实现接口。
l 责任:1. 封装特定的系统调用。2. 封装通讯的参数、控制信息等。3. 调用server的服务接口。
l 协作类:Server,Broker。
Bridge:
Bridge用来连接各个Broker,一般这个组件是可选的。当系统是发杂的网络组成时,有可能需要这一角色。
l 责任:1. 封装特定的网络特性。2. 传递Broker之间的通讯。
l 协作类:Broker。