软件系统开发中的数据交换协议

作者 孙立 发布于 2011年5月8日

领域

企业架构,

架构 & 设计,

语言 & 开发

主题

Java EE ,

Java ,

Websphere ,

Ruby ,

Memcached ,

MySQL ,

.NET ,

IBM ,

缓存 ,

应用服务器 ,

动态语言 ,

REST ,

语言 ,

Web 2.0 ,

企业级敏捷 ,

关系型数据库 ,

集群与缓存 ,

性能和可伸缩性 ,

编程 ,

架构 ,

敏捷 ,

XML ,

数据库 ,

企业架构

在很多地方都有“数据交换”这个概念，本文所说的“数据交换” 是指在计算机网络中，一个系统把数据传递给另外一个系统。这非常类似于一个人要告诉另外一个人一件事情。

当一个人要把一件事情告诉另外一个人的时候，我们可以通过电话、邮件、短信、IM工具或者当面说的方式来交流。这种方式类似于系统数据交换要通过 tcp、udp、管道等等的方式实现。当两个人交流的时候，我们需要一种共同的语言才能明白对方的意思，同样的，两个系统要交换数据，也需要定义一种双方都明白的协议，我们称为“数据交换协议”。

数据交换协议

数据交换协议的目的是让两个系统进行正确的数据交互。所以几乎各种开发语言都提供了方便使用的数据交换功能。比如说使用JAVA语言的开发的系统使用 MySQL数据库存储数据，就是通过MySQL数据交换协议跟MySQL做数据交换；通过JAVA的RMI可以方便的做跨机器的分布式数据交换，RMI也就是一种数据交换协议。

一般我们在不同的系统、不同的语言之间交换数据的时候，我们会选择一种通用的交换协议或者自己定义一种容易使用的交换协议。 WebService曾经非常流行， 在Web 2.0时代，轻量级的REST协议又开始受到追捧。那么究竟在我们的系统中应该选择什么样的协议呢？

如何选择数据交换协议

选择什么样的协议跟我们的应用场景有很大的关系。我们需要考虑我们开发是否方便、接口是否容易发布、是否需要考虑带宽占用成本、序列化和反序列化的性能、接口协议的扩展性等等。下面我们看下几个比较常用的交换协议实现。

协议	实现	跨语言	性能	传输量	RPC
xml	广泛	几乎所有	低	很大	N（可实现）
json	广泛	大量	一般	一般	N（可实现）
php serialize	PHPRPC	大量	一般	一般	Y
hessian	hessian	大量	一般	小	Y
thrift	thrift	大量	高	小	Y
protobuf	protobuf	大量	高	小	N（可实现）
ice	ice	大量	高	小	Y
avro	Apache Avro	少量	高	小	Y
messagepack	messagepack	大量	高	小	Y

上面表格列出了一些常用数据交换协议的一些特性的比较。这里并没有比较好坏，只是想说明不同数据交换协议是有区别的，所以我们需要在我们的应用场景中进行选择。

开放式

像微博，SNS这种开放平台、对静态html页面提供javascript接口调用的系统都属于这种类型 。这种类型的特点是：

• 调用方不完全可控，而且是针对公网的，你可能不知道是谁、是什么语言、是什么方式在调用你提供的数据接口；
• 接口访问量一般都非常大，要求具有很高的性能和吞吐量；
• 需要考虑安全问题，外部提交的数据可能不是合法的。

所以在这种情况下，需要考虑数据传输的带宽消耗和数据交换协议的易用性，以及多语言支持程度。以前对于html页面使用的javascript接口调用一般都使用XML格式，最近几年几乎都转成了json格式了，因为json传输量更小，比XML更加容易使用。 而对于开放平台，由于使用的场景很多，所以需要提供多种交换协议格式。基本上都会提供XML和json。为了提高平台本身的性能和客户端的性能，也可以提供protobuf这种二进制交换协议并且增加压缩支持，以节省带宽传输和解析的性能消耗。

内部服务

对于一个大型系统来说，内部服务的数据交换无处不在。从最基本和常见的数据库数据交换、memcached缓存数据交换、消息队列的数据交换到系统之间使用的RPC服务框架等等，都可以算作内部服务的数据交换。内部服务的特点是不用考虑防火墙，不对外开放，速度快（基本无带宽成本）。

内部服务的数据交换协议的选择空间非常大，一般需要考虑：

• 数据交换协议的性能
• 是否需要跨语言支持
• 数据交换协议的消息体大小

持久化存储

对于持久化存储来说，每一种数据交换协议其实都可以实现。一般需要根据应用场景考虑：

• 是否人工可阅读
• 存储的空间消耗
• 序列化和反序列化的性能
• 是否经过压缩

跨语言

假设我们的网站前端页面展示层使用PHP语言开发，中间业务逻辑使用JAVA语言开发，那么就涉及到跨语言数据交换的问题。只要系统不是单纯的使用一种语言，那么就必须考虑这个问题。事实上，考虑未来的扩展和需求变化问题，也最好考虑跨语言的数据交互协议。

数据交换协议可升级

在选择数据交换协议的时候，我们同样需要考虑类似于数据库表的?schema设计时的扩展问题。比如一个提供用户信息的数据交换协议接口，现在包含用户名、性别、住址的信息，在升级过程中，增加了一个最后登录的IP信息。如果不考虑数据交换协议升级带来的影响，很可能会导致以前的客户端出现异常或者旧的数据无法正确解析的问题。

兼容协议的巧用

兼容协议的巧用非常有用，新产品兼容提供现有成熟的数据交换协议，可以降低使用门槛和产品的开发速度。比如新浪开源的memcacheQ就使用了memcached协议。

总结

数据交换协议的各种通用开源实现非常多，数据交换协议只是一个非常宽泛的说法，其实只要实现了数据的序列化和反序列化 ，那么就可以说是一个可以交换数据的协议。数据交换协议的性能其实就是序列化和反序列化的性能，如果加上RPC，那么跟RPC实现本身的性能也有非常大的关系。

我的新浪微博@sunli1223 ,欢迎与我讨论。

参考链接：

• java序列化和反序列化性能比较：https://github.com/eishay/jvm-serializers/wiki
• Java跨语言调用实现方案 http://rdc.taobao.com/team/jm/archives/389

1. 返回顶部

   xml还会长期是主流

   发表人 Kimm King

   1、webservice是rpc的主流，在soa/esb上更是如此。
   2、除了作者比较的各种特点外，描述能力和可读性也是重要的两方面。
   xml比json描述能力更强，有严格的schema的约束，有xslt、transform、jaxb、xmlbeans、xstream等转换和绑定，有各种更高级的应用和规范。
   3、比二进制、半二进制可读、易处理。
   
   
   当然如文中所述，xml缺点也很多。

   回复

• 更早的 >