请求/响应OR基于事件的通信模式

同步通信：发起一个远程调用，调用方会阻塞自己并等待整个操作的完成

异步通信：调用方不需要等待操作完成就可以返回，甚至可能不需要关心这个操作完成与否

 

同步通信可以知道事情到底成功与否，异步通信对于运行时间比较长的任务来说比较有用，否则就需要在客户端和服务器之间开启一个长连接，这种方式可以保证在网络很卡的情况下用户界面依然很流畅。

 

Dubbo框架也可以既可以使用同步的通信方式，也可以使用异步的Future或者Callback方式实现异步的通信方式，消息队列Jms也是实现异步通信的一种方式，他们的异步方式有什么区别呢？

他们的区别在于前者协作风格是请求/响应方式，而Jms是基于事件的协作方式，客户端不是发起请求，而是发布一个事件，然后期待其他的写作者接收到该消息，并且知道该怎么做。业务逻辑并非集中在某个核心大脑，而是平均分布在不同的协作者中，这样耦合性很低，可以灵活增加或者替换订阅者；并且子系统故障不会影响整体可用性：“保存并转发（store-and-forward）”的机制：当订阅者不可用时，消息服务器会将消息存入持久存储器中，当订阅者恢复可用时，再把这些错过的消息传给它们，它保证了即使发生局部故障，预定订阅者最终也会接收到这条消息。但是使用协作方式的缺点是：多个订阅者分别处理发布的事件，看不到明显的业务流程视图，并且需要做一些额外的工作来监控流程，以确保其正确地运行（每个订阅者都完成了任务）。

 

同步调用比较简单，很容易知道当前的请求是否成功，整个流程是否正常，如果想避免在耗时业务上的困境，可以采用异步请求加回调的方式。而基于事件的协作方式，可大大减少服务间的耦合但增加了系统的复杂性。

 

使用dubbo或者Jms都可以缓解系统瓶颈，提高可伸缩性。