发布订阅风格
使用场景
很多项目中都有消息分发或者事件通知机制，尤其是模块化程度高的项目。
比如：在你的系统中，很多模块都对 新建用户 感兴趣。权限模块希望给新用户设置默认权限，报表模块希望重新生成当月的报表，邮件系统希望给用户发送激活邮件...诸如此类的代码都写到新建用户的业务逻辑后面，会加大耦合度，降低可维护性，并且对于每个模块都是一个独立系统的情况，这种方式更是不可取。
对于简单的情形，观察者模式 The Observer Pattern 就足够了。如果系统中有很多地方都需要收发消息，那么它就不适用了。否则会造成类数量的膨胀，增加类的复杂性，这时候就需要一种更集中的机制来处理这些业务逻辑。
发布订阅
首先，很多邮件标注不要求回复，现实中也有很多不期待答复的请求（请求不带状态）。
发布/订阅模式定义了一种一对多的依赖关系，让多个订阅者对象同时监听某一个主题对象。这个主题对象在自身状态变化时，会通知所有订阅者对象，使它们能够自动更新自己的状态。
特点
一个订阅者可以订阅多个发布者
消息是会到达所有订阅者处，订阅者根据 filter 丢掉自己不需要的消息(filter 是在订阅端起作用的)
每个订阅者都会接收到每条消息的一个副本
基于推送 push，其中消息自动地向订阅者广播，它们无须请求或轮询主题来获得新消息
发布/订阅模式内部，有多种不同类型的订阅者。非持久订阅者是临时订阅类型，它们只是在主动侦听主题时才接收消息。
持久订阅者将接收到发布的每条消息的一个副本，即便在发布消息，它们处于"离线"状态时也是如此。
另外还有动态持久订阅者和受管的持久订阅者等类型。
优势
- 降低了模块间的耦合度：发布者与订阅者松散地耦合，并且不需要知道对方的存在。相关操作都集中在 Publisher 中。 可扩展性强：系统复杂后，可以把消息订阅和分发机制单独作为一个模块来实现，增加新特性以满足需求
- 提高了安全性：通信基础设施仅将已发布的消息传输到订阅相应主题的应用程序。特定应用程序可以直接交换消息，排除来自消息交换的其他应用程序。
- 提高了可测试性：Topics通常会减少测试所需的信息的数量
缺点
其实算是本身的设计问题，因为如下：
- 发布者不知道订阅者是否接受到消息
- 订阅者也不知道自己收到没有
- 发送者不知道订阅者的执行情况
- 订阅者接收消息的时间不明确
Basic Model
Basic Model
Example
example
clould P/S
