skynet 的集群方案
上周 release 了 skynet 的 0.3 版，其最重要的新特性就是给出了一套新的集群方案。
在过去，skynet 的集群限制在 255 个节点，为每个服务的地址留出了 8bit 做节点号。消息传递根据节点号，通过节点间互联的 tcp 连接，被推送到那个 skynet 节点的 harbor 服务上，再进一步投递。
这个方案可以隐藏两个 skynet 服务的位置，无论是在同一进程内还是分属不同机器上，都可以用唯一地址投递消息。但其实现比较简单，没有去考虑节点间的连接不稳定的情况。通常仅用于单台物理机承载能力不够，希望用多台硬件扩展处理能力的情况。这些机器也最好部署在同一台交换机下。
之前这个方案弹性不够。如果一台机器挂掉，使用相同的节点 id 重新接入 skynet 的后果的不可预知的。因为之前在线的服务很难知道一个节点下的旧地址全部失效，新启动的进程的内部状态已经不可能和之前相同。
所以，我用更上层的 skynet api 重新实现了一套更具弹性的集群方案。
和之前的方案不同，这次我不打算让集群间的通讯透明。如果你有一个消息是发放到集群内另一台机器中的某个服务的，需要用特别的集群消息投递 api 。节点本身用字符串名字，而不是 id 区格。集群间的消息用统一的序列化协议（为了简化协议）。
这套新的方案，可以参考 examples 下的 config.c1 和 config.c2 分别启动两个节点相互通讯。
如果使用这套方案，就可以不用老的多节点机制了（当然也可以混用）。为了简化配置，你可以将 skynet 配置为 harbor = 0 ，关闭老的多节点方案。这样，address standalone master 等配置项都不需要填写。
取而代之的是，配置一个 cluster 项，指向一个 lua 文件，描述每个节点的名字和地址。
新的 cluster 目前只支持一个 rpc call 方法 。用来调用远程服务。api 和 skynet.call 类似，但需要给出远程节点的字符串名字，且通讯协议必须用 lua 类型。
这套新方案可以看成是对原有集群的一个补充。当你需要把多台机器部署到不同机房，节点间的关系比较弱，只是少部分具名服务间需要做 rpc 调用，那么新的方案可能更加合适一些。因为当远程节点断开联系后，发起 rpc 的一方会捕获到异常；且远程节点用名字索引，不受 255 个限制。断开连接后，也可以通过重连恢复服务。
Comments
Posted by: Anonymous | (1) June 10, 2014 09:51 AM