背景

在工控行业等场合, 要求每台服务器都是多网卡, 且通过不同网络, 不同交换机互联, 即每个服务都至少有两个ip地址可以访问, 当一路网络(交换机)出现问题, 这个服务也能通过另外一路网络正常工作, 从而保证服务的高可用性.

多网络需求

• 双网络情况下, AB服务分别部署在两台机器上, 每台服务器有两个网络(两个ip), x & y代表不同的网络, 比如A服务ip为: ip_x_1, ip_y_1, B服务ip为: ip_x_2, ip_y_2
• 对同一个服务, 如果某个网络是联通的, 则一直选择这个网络通信, 除非不通, 才切换到另外一个网络;

• 服务采用集群概念, 没有主从概念, 核心是出现问题需要切换到另外一个网络, 从而保证服务的高可用性;

• 客户端A和服务端B(部署了n台机器), 只要和某一个节点, 某一个网络通信成功, 就可以正常工作;

设计思路

框架支持双网的修改:

• 服务都绑定在0.0.0.0上, 这样所有网卡都绑定了;
• 在t_node_info表需要增加映射关系, 添加这个节点对应的内网ip(多个), 这个映射关系让tarsnode自己上报, tarsnode启动时上报自己的ip, 记录到框架中!
• tarsregistry加载服务的时候, 如果发现是0.0.0.0, 将地址换成这个节点对应的多个ip地址
• tarsregistry做名字服务查询服务的ip时, 就会查询服务的多个ip地址(因为上一个环节记录了服务的多个ip)
• 客户端和服务器端rpc时, 首先会拿到服务器对应多个ip地址, 依次轮流通信, 如果通信失败, 则切换到下一个ip地址

普通rpc调用通过以上方式即可完成双网支持, 且有网络不通, 则会自动屏蔽(需要调节rpc通信网络故障的敏感度), 但是对于raft机制的服务而言, 需要做额外的处理, 以保证raft机制的正常工作:

• raft节点的判断, 不再以ip为维度判断, 以EndpointF中的nodeName为key判断有哪些节点, 以节点名称作为key, 而不是以ip作为key
• 同一个节点可能对应多个ip list, 将多个ip组合成一个地址, 然后获取prx, 例如: obj@tcp -h ip1 -p port1:tcp -h ip2 -p port2
• 节点间通信时, prx->rpc调用时, 会依次轮流通信, 如果通信失败, 则切换到下一个ip地址

原则上, 可以支持n网, 而不仅仅是双网!