实现一个轻量的分布式服务器可靠通信组件#1

最近实现了一个分布式游戏服务器间进行远程通信的组件
整体的感觉是在应用层又自己简单实现了一遍IP层+TCP层做的事w(ﾟДﾟ)w

分布式服务器结构

对于服务器间通信，现有的做法是：
1.直连的服务器间
通过封装的SendMsg接口实现点对点或广播

2.非直连的服务器间
人工规划传输过程
这个过程如果以传纸条作比方的话，就是：
小红如果想给小明传纸条，需要把纸条给小刚，并且告诉小刚再把纸条给小兰，并且告诉小兰把纸条交给小明。最后由小兰把纸条交到小明手上。
如果小红事先不认识小刚，或者小红不知道小刚认识小兰，或者小红不知道小兰认识小明，这纸条就传不了。

非直连服务器消息传输

可以看到对于非直连的服务器目前的通信方式存在几个问题
1.传输过程依赖使用者提前规划
2.发送方无法判断接收方实际的连接状态，哪怕是没有连接到网络中的目标也会选择发送

设计方向：

1.利用现有的网络结构实现服务器间的消息转发，不添加额外的网络连接
2.每个进程（节点）可以感知到整个网络中的所有节点，并与其通信
3.支持通过节点id发送消息（点对点）和通过节点类型发送消息（广播）
4.发送者只需声明目标节点id或类型，无需关心传输过程，路径规划以及消息转发由模块内部完成

设计的重点和难点

1.网络拓扑结构管理

a.将通过网络互连的服务器进程组抽象为一张有向图。服务器进程对应图中的节点，网络连接对应有向边（由sock客户端指向sock服务器）
b.每个节点根据网络连接的连接或者断开，维护本地记录的网络拓扑结构，并同步给相邻的节点
c.根据其他节点同步过来的信息更新网络拓扑结构

2.发包管理

a.可以直接向指定目标节点发包，也可以根据节点类型筛选出一批节点进行广播
b.根据本地维护的拓扑结构规划传输路径,向路径中的下一跳节点发送消息包
c.接收远程数据包，选择转发或者本进程处理

3.可靠传输控制

对于没有直接网络连接关系的一对节点，消息包会经过若干个中间节点的转发后到达目标节点
这就不能再依赖原有的传输层协议（TCP）来保证一对通信节点间消息收发的可靠性和有序行，需要由模块通过自己的机制来实现

可靠性：
A节点发往B节点的包需要保证B节点一定能够收到
如果由于中间节点宕机或者其他问题导致丢包，需要由模块重发，直到B收到为止

有序性：
由于网络结构是图结构，一对节点间的通路可能有多条，这会导致连续发送的包不保证以同样的过程传过中间的网络。
A先后发给B节点packet1和packet2两个包，对B的上层应用来说要先感知packet1再感知packet2
如果实际上B先收到了packet2,需要等待packet1到达之后再转交给上层处理

事实上可选择的分布式网络通信模式不止一种，在讨论初期有几种其他的可选方向

1.消息队列（MessageQueue,如Rabbit、Active、Kafka等）

优点：
有成熟的企业级框架可以直接使用
缺点：
消息队列的实时性并不强
对于游戏服务器的通信显得过重，实际只需要一个轻量级的通信组件

2.中心通信节点（组）

增加一个专门用于消息转发的中心节点，所有服务器进程都与其建立连接，消息的发送全部通过中心节点转发
优点：
理解起来简单
消息传输路径明确
缺点：
对中心节点的稳定性要求非常高，节点挂掉之后整个网络内部的通信将瘫痪
当服务器进程不断增多时，中心节点可能成为瓶颈，单个节点可能不满足需求，需要以进程组的方式存在
如果以进程组的方式实现，则需要处理动态扩容以及负载均衡等问题

经过讨论最后还是决定先实现一版基于图结构的分布式通信方法

具体的实现细节请参见后续篇幅：
网络拓扑结构管理
发包管理
可靠传输控制
其他待补充