通讯层与序列化

通讯层：封装与网络通讯 传输数据相关的API，成熟的框架有mina等

序列化/反序列化：这个多了 gpb，json等等

rpc：我觉得这个是更多关系业务层逻辑上的过程功能，底层的实现调用可以是通讯 ?序列化这些。

看了tim的文章 ，网络相关的问题在他的眼里通讯层与实际的IDC关系比较密切，也可以抽象出更多的问题，引用tim的话：

?

“ 目前考虑到的原因有

Connection pool作用。为了节点间更高的throughput, 通常两节点之间会使用n个固定连接来传输。n可设为CPU内核数大小。多节点互相连接的处理。一个节点需要连接n个节点发送信息。如果这部分逻辑放在业务调用层来实现，业务层会变得臃肿。处理自动重连逻辑，单个节点可以停用并重新启用。将这部分逻辑封装到通讯层，上层调用会更优雅。服务器之间通讯很短时间内不稳定(比如10s左右的中断)的处理。如果IDC内部或IDC之间通讯不稳定会造成这种现象。我们希望这种短暂的中断，不要引起业务逻辑重新选择节点，造成大量数据迁移及cache重构带来的内部振荡。海量数据传输最优化，大部分时间单个节点单向传输会>10k个数据包/s，独立的通讯层容易测试观察该环节是否存在瓶颈。”

参考文献：

?

<1>?http://timyang.net/architecture/communication-code-review/