简单二进制编码(SBE)
SBE灵感是来自于高性能工作组的 FIX Protocol Limited (FPL)组织，其最初目标是提供金融交易的低延迟的二进制编码。
随着微服务架构普及，服务之间通讯协议的性能要求越来越高，传统的XML/JSON已经很难满足微服务直接的高速通讯，直接使用压缩的二进制编码数据成为一种选择，Google的 Protocol Buffer、来自Apache的 Thrift 和 Avro，而SBE可谓是一匹黑马。
大多数系统的性能问题是消息的编码和解码，数据与JSON/XML之间的转换比业务逻辑还要耗费CPU，SBE能够让系统更加有效率，SBE是通过一系列设计原则来完成这个目标。这些设计原则有：
1.Copy-Free：不采取中间缓冲，因为其在多次字节复制中有性能损耗。采取直接与底层缓冲编码与解码，其限制是消息大小不能超过传输缓存的大小，可以进行碎片分段。
2.Native Type Mapping：copy-free的设计也通过将数据直接编码为底层缓冲的原生类型中得到巨大好处，比如一个64位整数型能直接作为x86_64 MOV汇编指令被编码进入底层缓冲。通过这种原生的类型映射，一个字段能够以类似高阶语言如C++/Java中class类似和struct字段一样高效率访问。
3.Allocation-Free：对象的分配会导致CPU缓存流失从而降低效率，这些被分配的对象后来得收集并删除，对于Java是使用垃圾回收机制，导致stop-the-world暂停。SBE编码采取flyweight 模式，基于底层缓冲的flyweight窗口直接对消息编码与解码，相应类型的享元是基于消息头部模板id选择的。
4.Streaming Access：现代内存子系统已成为愈加复杂，该算法能够对性能和一致性有很大帮助，实现最好的性能与最一致的延迟，这是以一种上升顺序方式访问内存的方式实现的，也就是一种流。
5.Word Aligned Access：当word以非word大小边界访问时，多CPU架构表现出显著性能问题，一个word的起始地址应该是其以字节为单位大小的倍数，64位整数只能从字节地址能被8整除的地方开始，32位整数只能从被4整除的字节地址开始。。等等。
SBE的schema支持定义了消息字段起始位置的偏移概念，它假设消息是被封装在8字节大小边界内的框架协议中，为了实现紧凑与有效，消息字段应该以其类型和降序大小排序。
6.Backwards Compatibility向后兼容：兼容过去系统。
SBE项目：
real-logic/simple-binary-encoding · GitHub
Uber已经从HTTP+JSON迁移到基于TChannel的Thrift，TChannel在Node.js中比HTTP快20倍。
[该贴被banq于2015-04-05 09:32修改过]
