转：使用基于Http的消息代替WebService的数据交互

http://blog.csdn.net/cyq1984/article/details/38041671

 

系统间交互的工作，随着信息化建设的发展，以及业界对SOA的认识及其带来的低TOC（总体拥有成本）等优势，越来越受到信息化水平较高的用户的重视。

这里先抛开SOA这样的架构规划，单纯就系统间整合的协议进行讨论。

系统间的交互或者成为整合（互联互通），早在信息化系统诞生的时候，就已经出现，只是并不明显，或者由于早期开发平台、开发语言等的单一性，这种需求并没有非常大的爆发出来。

随着信息化建设的发展，以及各种不同的开发语言的发展，跨语言的不同业务系统之间的交互，成为了摆在CIO们面前的一个大问题。

早期，为了保证数据或者消息在不同的业务系统间传递的安全、有效、稳定，往往使用基于MQ的Message进行消息传递。这期间IBM的MQ产品，成为跨业务系统信息交互的重要媒介。但是，使用MQ的前提是，MQ已经提供了针对特定开发语言的API包，如MQ没有提供，则无法使用。并且，MQ产品本身作为一个商业产品，其成本也是非常高的。由于MQ支持XA事务，因此，其数据传递的有效性还是能够得到保障的。

后来，人们开始探讨使用基于RDBMS的“前置机”方式。即需要交互的双方，使用一个脱离于各自业务系统的“中间数据库”，将需要读写的数据，读写入中间数据库，再进行后续的操作。使用RDBMS的优点是，直接利用关系型数据库这种支持事务的平台，并且关系型数据库同样支持XA事务，保证数据在不同数据库之间传递的有效性。缺点是需要额外处理一套专门的中间表或者中间数据库，并且有时并不能解决所有的问题。而且，当需要交互的系统超过3个时，每个系统都需要处理多于1个中间表体系，对系统厂商造成大量的工作。

WebService曾经认为是解决异构系统间整合的最佳解决方案，不依赖于第三方任何系统的支持（不需要额外部署专门的MQ或者RDBMS服务器），大家只需要按照官方的规范，即可完成相互之间的数据交互。但是，webService存在的问题是，使用SOAP需要对消息进行多层次的封装，webservice之间进行数据交互的效率受到了严重的影响。虽然，webservice能够交互的数据格式多种多样，基本也不存在数据格式不支持的情况。但是，webservice的效率及其webservice的超时等问题，还是困扰了系统厂商。

随着httpclient的出现，以及JSON等数据格式的大范围使用，基于http的消息接口，逐渐被大家所青睐。一方面是因为，直接使用httpclient可以模拟浏览器的数据操作与封装；另一方面使用基于http的消息，可以借助于http的成熟、可靠、开源的web集群解决方案来提升总体的效率。还有，就是基于http的消息格式，几乎不受任何限制，常规应用的各种消息格式，基本都能直接使用基于http的消息进行传递。目前，大部分PaaS平台，所提供的API接口，实际上就是使用基于Http的JSON消息，来进行数据传递的。

针对基于http的消息及WebService的性能问题，笔者曾经做过测试。

在一台配置较低的PC上，同时开启服务端与客户端，10000条数据，使用基于http的消息逐条进行传递，从开始传递至全部接收并处理完毕，大概需要465秒的时间；而在同一台机器上，使用WebService进行交互，则需要1180秒。整体的性能大概查了接近60%。

因此，笔者大胆猜测，未来随着基于http进行消息传递的技术逐步完善，以及相关业界标准的进一步完善，一种新的基于http的消息格式会逐步替代webservice，成为主流。