消息解耦初探

      一般来说解耦有两条途径，一是远程请求，二是消息（推送）。这两种方式可以说使用的应用场景不一样，比如说远程请求这是主动方在调用方，而推送的主动权肯定是在生产方。为什么要解耦？这个。。。

如果用消息进行应用间解耦，消息将作为应用间的介质作为上下文传输。其实知道生产者和消费者就很容易明白，这样两个应用之间将不会有任何代码的依赖。

       这样会有一个消息提供方和消息接收方。也可以说是消息生产方和消息消费方。两者之间并不知道彼此的存在，其实严格的讲消息消费方是知道生产方的，不过是一种非常弱的依赖。这是一种推送模式，所谓推送模式就是消费生产方一直生产消息，再推送给各个消费方，这样消费方就可以进行接收消息进行消费。

下面看一下系统调用图：

 

       这里消息中心是对消息重新抽取出来的一层，这样保证应用层职责更加单一，另外一个不会因为消息的堆积导致服务瘫痪（一般来说消息中心都部署在新的机器上，不太会和其他应用耦合）。消息中心存放了生产方发送过来的消息然后再进行集中转发。这样可以在消息中心实现一些消息的处理逻辑以满足更多的业务需求。比如说阀值，可能生产方非常强悍，而消费方比较弱，这样长期会导致消息堆积越来越多。而解决这样的问题一般就是消费方使用集群来分摊压力。简单的应用场景消息中心的意义不大，因为这样会增加因为传输带来的网络开销，而中消息中心本身是需要接收和转发的，这中间肯定也会有资源消耗。

    目前模式大概有两种，第一是点对点(p2p)，就是单挑；一种是一对多，也就说所谓的发布/订阅模式。这两种方式其实本质上可以归结为一种。发布/订阅模式消费方需要在消息中心注册一个账号。让消息中心知道你的存在，到时候就会给你发送消息。