详解微服务技术中进程间通信( 四 ) _微服务

HATEOAS的优势在于不再需要将URL硬编码到客户端的代码里面去了，另一个好处是由于资源的返回结果中已经包含允许的操作的链接，客户端不用去猜测当前状态下能对资源做哪些操作了。

使用基于HTTP的协议的好处有：

HTTP对与大家来说简单而熟悉。
可以用一些有Postman这种插件的浏览器来测试API，也可以用curl这种命令行工具来测试（返回结果是用JSON或者其它类型的文本格式）
直接支持请求/响应风格的通信
HTTP是防火墙友好的
不需要有中间代理，这让系统的架构得到简化

使用HTTP也有缺点：

只支持请求/响应的交互风格，这使得在使用HTTP来发送通知的时候，服务端必须总是发送HTTP响应回来。
因为客户端和服务端直接通信（中间没有缓冲消息），他们在交换信息期间必须同时处于运行状态。
客户端必须知道每个服务实例的地址（比如URL），正如在上一篇文章中描述的，在现代应用中，这倒不是个重要的问题，一般客户端都需要使用服务发现机制来定位服务实例的位置。

开发者社区最近发现了接口定义语言对RESTful API的新价值，这方面有一些选择，包括RAML和Swagger 。一些诸如Swagger的IDL允许定义出请求和响应消息的格式，其它一些诸如RAML的IDL则要求使用独立的规范，如JSON schema 。在描述API的同时，IDL一般也有工具来给接口定义生成客户端桩和服务端骨架。

Thrift
Apache Thrift是REST的一种有趣的替代方案，它是开发跨语言RPC客户端和服务端的框架，Thrift提供C语言风格的IDL来定义你的API，使用Thrift编译器生成客户桩和服务骨架，编译器能够生成各种语言的代码，包括C++，JAVA，Python，php，Ruby，Erlang和Node.js 。

一个Thrift接口包含一个或多个服务，定义服务与定义Java接口类似，是一些强输入方法的集合，Thrift方法可以定义城返回一个值（也可能是void的），或者定义成单向方法。返回一个值的方法都会实现请求/响应的交互风格。客户端等待请求，并且有可能抛出异常。单向方法其实是符合通知风格的交互，服务端不会发送响应。

Thrift支持多钟消息格式：JSON，二进制，紧凑的二进制。二进制格式通常比JSON更高效一些，因为解析它更快。对于紧凑二进制格式，如它的名字一样，它是节省空间的消息。而JSON，当然是对人和浏览器友好的一种格式。在Thrift中，也可以自己选择传输协议，其中包括原始TCP和HTTP 。TCP一般比HTTP更高效一些，当然，HTTP是对防火墙、浏览器和人友好的。

消息格式
前面已经讨论过HTTP和Thrift，现在介绍消息格式的问题。如果使用消息系统或者REST，需要确定消息格式。其它一些如Thrift这种IPC机制只支持有限的集中消息格式，或许就一种而已。在任何一种情况中，使用跨语言的消息格式是很重要的。甚至你现在只是用一种语言来实现你的微服务，很可能你将来会使用其它的语言。

有两种主要的消息格式：文本和二进制码。基于文本的格式有JSON，XML这些。它们的优点在于是人可读的，而且是自描述的。在JSON中，对象的属性被表示成名称-值对的集合。类似的，在XML中，属性被表示成名字元素和值。这可以让消息消费者能够找到感兴趣的值，同时忽略其它的。而且，对格式的小量改动可以容易的兼顾到后向兼容性。

XML文档的结构是在XML schema文件中定义的，渐渐的社区的开发者意识到JSON也需要类似的机制，其中一个解决办法是使用JSON schema，以独立方式存在或者是如Swagger这种IDL的一部分。

基于消息的格式的一个缺点是比较繁琐，尤其是XML 。因为消息是自描述的，除了包含属性的值之外，消息里还包含属性的名称。另外一个劣势是，解析消息文本需要开销。基于这些，你可能更想使用二进制码格式

有几种二进制格式可供选择。当用Thrift RPC，你可以选择二进制的Thrift 。如果使用消息格式，比较流行的选择是Protocol Buffers和Apache Avro 。这两种格式都提供输入的IDL来定义消息结构。不同之处在于，Protocol Buffers使用标签域，而Avro，它的消费者在翻译消息前，需要提前知道消息的schema 。这篇博客完美解释了Thrift，Protocol Buffers和Avro的异同之处。

总结
微服务必须使用一种进程间通信机制，当设计你的服务如何通信时，需要考虑各种问题：服务如何交互，如何为每个服务设计API，如何演进API，以及如何处理部分失败问题。有两种微服务可用的IPC机制，异步的消息机制和同步的请求/响应机制。在这一系列文章的下一篇文章中，我们会研究在微服务架构中的服务发现问题。