网站系统建设需要什么条件建站
传统的跨语言通讯方案：
基于SOAP消息格式的WebService
基于JSON消息格式的RESTful 服务
主要弊端：
XML体积太大，解析性能极差
JSON体积相对较小，解析相对较快，但表达能力较弱
如今比较流行的跨语言通讯方案：
Google protobuf (http://code.google.com/p/protobuf)
Apache Thrift （http://thrift.apache.org/）
Apache Avro ( http://avro.apache.org/)
Google protobuf：
优势
二进制消息，性能好/效率高（空间和时间效率都很不错）
proto文件生成目标代码，简单易用
序列化反序列化直接对应程序中的数据类，不须要解析后在进行映射(XML,JSON都是这种方式)
支持向前兼容（新加字段采用默认值）和向后兼容（忽略新加字段），简化升级
支持多种语言（能够把proto文件看作IDL文件）
Netty等一些框架集成
缺点
官方只支持C++,JAVA和Python语言绑定
二进制可读性差（貌似提供了Text_Fromat功能）
二进制不具备自描述特性
默认不具有动态特性（能够经过动态定义生成消息类型或者动态编译支持）
只涉及序列化和反序列化技术，不涉及RPC功能（相似XML或者JSON的解析器）
Apache Thrift：
应用
Facebook的开源的日志收集系统(scribe: https://github.com/facebook/scribe)
淘宝的实时数据传输平台(TimeTunnel http://code.taobao.org/p/TimeTunnel/wiki/index)
Evernote开放接口(https://github.com/evernote/evernote-thrift)
Quora(http://www.quora.com/Apache-Thrift)
HBase( http://abloz.com/hbase/book.html#thrift )
…
优势
支持很是多的语言绑定
thrift文件生成目标代码，简单易用
消息定义文件支持注释
数据结构与传输表现的分离，支持多种消息格式
包含完整的客户端/服务端堆栈，可快速实现RPC
支持同步和异步通讯
缺点
和protobuf同样不支持动态特性
Apache Avro：
应用
Hadoop RPC （http://hadoop.apache.org/#What+Is+Apache+Hadoop%3F）
优势
二进制消息，性能好/效率高
使用JSON描述模式
模式和数据统一存储，消息自描述，不须要生成stub代码（支持生成IDL）
RPC调用在握手阶段交换模式定义
包含完整的客户端/服务端堆栈，可快速实现RPC
支持同步和异步通讯
支持动态消息
模式定义容许定义数据的排序（序列化时会遵循这个顺序）
提供了基于Jetty内核的服务基于Netty的服务
缺点
只支持Avro本身的序列化格式
语言绑定不如Thrift丰富
Capnproto简介
Capnproto是一款号称具有"infinity faster"的RPC框架。你可以认为它是JSON，只是它直接生成了二进制格式的消息；你可以认为它是Protocol Buffer，只是它更快而已。
Capnproto通过自定义语言来实现RPC接口和相应的操作，在这一点上和ProtoBuf以及Thrift很像，如果你用过这两种语言，那么对此应该很熟悉。
FIDL
FIDL（Fuchsia Interface Definition Language）是fuchsia系统上的远程调用机制， 相当于android上的基于binder的AIDL。
fuchsia里很多设计和android，chrome os有相似性， 可以类比学习。
FIDL的主要任务是允许客户端用不同的语言实现 和 服务端交互，底层数据传递时依赖zircon的IPC机制channel。并且通过自动生成代码来简化开发工作。