Broker模式

Broker模式用于分布式系统，对系统中的各个组件解耦，协作，通信等。服务在Broker中注册自己，使得client可以通过它们提供的接口访问自己，client向Broker发送请求以访问服务提供的功能，Broker根据请求定位合适的服务器，然后将请求发送给它，并将结果和异常等信息返回。

我的理解，这个Broker模式就好比生意场中的代理人或者中间人，他负责联系买卖双方，通风报信，促成生意。也可以这么理解，Broker是一个中间层，它封装了各个服务的实现细节，client不必（估计也不想）知道服务的细节，只要给Broker发送请求，剩下的事情由它去办，这就使得client和server的耦合很松，整个系统的扩展性有了大的提高。

Broker模式包括六种主要的组件：clients，servers，brokers，bridges，client-side proxies和server-side proxies。

server实现某些功能并通过接口向外提供之。server的责任包括：实现服务，在本地的broker中注册自己，通过server端的proxy向client发送响应和异常信息。server的协作者包括server端的proxy和broker。

client的责任包括：实现用户的功能，通过客户端的proxy向server发送请求。它的协作者包括客户端的proxy和broker。

在文中用messenger描述broker，它是client和server之间通信的桥梁，它将client的请求发送给server，也将server的回应和异常发送给client。因此，broker必须通过某种方式实现唯一的标识，来分辨和定位数据的来源和目的地。它提供接口使得client和server都能在它那儿注册。其实这很好理解，因为只要这样，broker才能统领全局，了解所有已经存在的client和server。前段时间看了Android，现在想起来，它很可能也使用的这个模式，Android工程里的AndroidManifest.xml的功能应该就是这样，所有在工程添加的类，无论是Activity，service，还是broadcast receiver等等，都必须在AndroidManifest.xml中注册，否则应用不能实现相关的功能。我推测Android里应该专门有一个模块来管理AndroidManifest.xml，每当一个应用被按照进系统后，这个模块就检查AndroidManifest.xml，收集信息，将里面的类，服务，过滤器等等信息都收集后保存，这样当有Intent（特别的隐式的Intent）被抛出后，系统才能够定位相应的Activity或者service，否则系统是找不到的。

client端的proxy是client和broker之间的中间层，它封装系统指定的功能，例如client和broker之间的具体通信机制，内存块的分配和删除，参数和结果的排列等，可以这么说，client的proxy是一个打包器，将client的请求进行封包。而与之相对的是server端的proxy，就是一个拆包器了，同时将server的结果和异常信息打包发给client。

Bridge是一个可选组件，在Broker系统里，很可能是一个异构的系统，存在多个Broker，各个Broker之间如果要通信，就需要使用Bridge，它在各个Broker之间找出路由。

Broker模式分为两类：一类是没有broker，client端的proxy和server端的proxy之间直接通信，不用broker来中转通信，这类broker模式的好处是性能高，因为省去了一道中转，但是在两端的proxy之间需要使用同样的数据格式或者协议来传输。另一类就是有broker，两端的proxy使用不同协议或者数据格式不要紧，由broker来统一。