编码和扩展
当有变更如数据结构变更时，我们常常需要考虑兼容。可以使用灰度等方式，因此会造成新老代码并存的现象，当然你可以直接隔离，让新代码读新数据，老代码读老数据，但若是无法隔离时，我们需要考虑向前兼容和向后兼容。向前兼容即老代码可以兼容新数据，向后兼容即新代码也可以用老数据。
当我们使用数据时，常常是2个维度
- 在内存中使用，数据在对象中，是一个个数据结构，如list，set等
- 在网络传输，磁盘等中，是一类 self-contained sequence byte，如JSON，XML等
2个阶段的转换，就是我们通常所说的编码环节，也能叫序列化等
一、编码
1.1 特定语言的编码
如java的serializable，这些序列化方式适合特定语言绑定的，这使得这些序列化不能通用，也一般不保证兼容性
1.2 Json,XML，二进制
json，xml，csv等都是文本形式的通用format，这使得对人类理解比较友好
但这些也有一些问题存在，如对二进制的不支持，一些数字类型的精度缺失等
当你数据小时，一般不会有这考虑，但当数据很大，如TB等时，传输的速度重要性就体现了出来。要考虑json比xml更迅速。有很多特定的编码对xml，json等做了扩展如BJson等，但再实际中，都没有像Json、xml一样得到广泛使用
1.3Thrift and Protocol Buffers
这是facebook和google各自支持的编码格式，2者都需要预先定义数据结构
此外还有用于hadoop的Avro等
关于编码，在这只做了解，不深究
2.数据流
数据流，即从一个地方转移到另一个地方，归根结底就3种方式
- 通过数据库
- 通过服务，RPC Or restful
- 作为消息传输
关于RPC：remote producer call，本意是想让远程调用像本地服务一样使用，但我们必须明确的一点是，由于网络的存在，你永远不可能真正对到像本地一样调用远程服务。因此现代的RPC框架都是清晰得考虑到这些，做了各种超时，重试策略等方面的改进
比较restful和RPC，尽管rpc再调用时，可能速度更快，但restful有着意义清晰，调试方便，支持齐全等优点。因此在实际中，公共服务常使用restful，而内部的服务可以根据需要选择RPC
关于兼容性：在考虑RPC的兼容性时，由于我们都是先变更服务层，再变更客户端。因此我们需要考虑的是，request的向前兼容和response的向后兼容
消息系统：
最重要的一点是关于它异步的特点，所有的消息必然都是异步的。
消息系统，我们一般要使用消息代理（message broker）或者叫消息中间件的服务队消息进行暂存
比较消息系统和RPC
- 消息系统解耦了服务和客户端，客户端不需要知道服务端的真实IP等信息
- 消息系统可以防止因为宕机导致数据丢失
- 允许一条消息发给多给目的地
消息系统的 actor model，这是一个关于控制并发的模型，不做深入，就是通过消息消除了race codition，没一个actor都根据消息的先后顺序进行处理
distributed actor framework essentially integrates a message broker and the actor
programming model into a single framework
