好多有关分布式计算以及系统集成的探讨，当前都把重点放在Web服务技术方面，然而，它所依靠的同步通信机制，在实际存在的企业应用里，常常会显得力不从心。

Web服务的通信核心

Web服务是一种技术方案，其本质是应用程序间通过交换结构化消息来进行集成，它以通用的HTTP协议以及XML格式作为基础，目的在于达成不同系统间的互操作，这种设计思想能够允许一个Java应用去调用部署在另一个服务器上的.NET组件，或者使得企业内部系统与合作伙伴的外部系统开展数据交换。

其核心标准所在之处为SOAP协议以及WSDL描述，SOAP所定义的偏偏是消息的格式，然而WSDL却宛如一份服务说明书，详尽无比地说明了服务所处位置，还有可用的操作以及数据格式，服务请求方借助查找WSDL，弄明白怎样去构造消息，并且经由网络发送给服务提供方，借由这样的方式成就一次远程调用。

同步通信的固有局限

然而，被广泛运用的Web服务模型通常采用请求/应答的同步模式，客户端发出请求之后，必须等待且占用连接情形直至服务器返回结果，在网络延迟较高抑或服务器处理时间偏长的场景当中，会致使客户端长时间处于阻塞状态，资源利用率并不高。

尤为关键的是，此类模型欠缺针对异步以及可靠传输的原生支持，一旦网络于传输进程里中断，消息便有可能遗失，并且不存在内置的重试或者确认机制，对于那些要求7x24小时稳定运作、不容许数据遗失的企业关键业务而言，这是一个相当显著的缺陷。

企业集成的异步需求

现实里的企业应用集成时常面对着复杂状况，举例来说，一个订单系统于处理完毕支付之后，要去通知物流系统以及库存系统，然而后面这两者的响应速度与处理状态是不可以阻塞订单主流程的，这就需求异步的、基于事件驱动的消息传递。

处在这样的场景当中，发送方把消息发出去之后就能够接着继续之后的工作，用不着去等待。消息是由中间件来负责保证最终被传达到一个或者多个接收方那里。这种解耦的能力提高了系统的整体可靠性以及可伸缩性，这是构建强壮的分布式系统的关键所在。

消息中间件的作用

消息中间件是专门用来解决上述问题而产生的专用软件，它作为独立的基础设施，在应用程序之间提供异步且可靠的消息传输，同时在不同协议和操作系统之间也提供异步且可靠的消息传输，其核心功能涵盖消息的路由，还包括消息的排队，也有消息的持久化存储，并且要有可靠的投递保证 。

举个例子，在目标服务处于暂时无法使用的状况下 ，中间件能够把消息持久化存到队列里 ，等到目标服务恢复之后就能再次进行投递 ，以此来保证消息不会遗失 。如此便给企业级应用赋予了具备可恢复特性的 消息传送能力 ，而这是同步的HTTP协议不容易达成的 。

结合服务的增强路径

为了使Web服务的能力得以增强，业界主要朝着两个方向展开探索，一个方向是于Web服务协议栈的内部实施扩展，像是借助WS-ReliableMessaging等标准，在应用层协议之上增添可靠消息传输的语义以及保证。

另一个方向是，把Web服务架构搭建于成熟的消息中间件之上，这表示要将SOAP消息当作有效载荷，借助企业服务总线或者消息队列予以传输，于此情形下，Web服务能够直接运用底层中间件所提供的异步、可靠、处于事务性状态等高级特性。

构建灵活的企业架构

将网络服务跟消息中间件相结合，能够明显提升其灵活性以及适用领域，服务之间不再被紧密的同步调用给绑定，能够形成松耦合的、事件驱动的集成架构，这为构建复杂的企业应用集成解决方案跟面向服务的架构给予了更坚实的基础？

这种组合呀，使开发者有了依据业务需求来挑选通信模式的可能：在那些存在即时得出结果需求的场景当中，会运用同步调用的方式，而针对于流程驱动或者事件通知的场景呢，就会采用异步消息的举措。这样一种灵活性，促使Web服务技术能够更加良好地契合企业那种复杂多变且真实的环境了。

你觉得，于未来企业 IT 架构之内，异步消息模式会将同步的请求 - 响 应模式完全替代掉，进而成为系统之间通信的主导形式吗？欢迎于评论区去分享你的看法，同时也麻烦为本文点赞予以支持。