多进程连接管理

目前多进程程序用的是最简单的连接思路。

有A B ...进程A -> BB -> A分别建立连接。

即n*(n-1) 个

缺点: 此连接方式导致随进程数连接剧增，进程数多必然会导致连接难以操控，而且资源如线程占用过多。
而且难以想象连接是hardcode情况下的难以维护问题。
优点: 建立简单，维护连接简单。
好在目前采用的是配置文件方式：

A:    connects: BB:    connects: A

只需要在connects属性中只添加你要的连接到的进程编号。这种方式下可以避免代码的连接管理维护问题(hardcode)。
目前这种方式在进程数不是很多情况下，还是算可以接受。而且怎么说，游戏进程数也不会那么的庞大。

当然如果实在嫌弃连接数问题难以自拔，可以考虑如下：

有A B ...进程A -> B建立连接。

这种情况下，虽然只进行一次连接，但是两边通信只靠一条通道。
缺点: 维护连接会麻烦点。

说说其他：
不管方式如何，我们只是要一个tcp发送通道而已。
那么想当然我们只需要例如

send(serverId, Msg);

只要知道我们要告诉的服务器编号和消息即可，至于怎么发送，连接怎么管理，消息编码等此处不多说。
那么这种情况有什么不好的地方呢，如果单单只是对部分功能来说还算可以。比如有AOI进程ID: 9999。那么必然在玩家身上有标记表明当前所在的进程ID。
而对于某个功能服务来说，可能会难以理解，因为我明明要发给服务A什么消息，为什么需要我一定指定这个服务进程ID。
所以当然好的方式是以名字方式来映射服务连接ip这些。

send(充值服务, Msg);

这里就必然涉及到名字服务解析的问题。
一般的微服务中比如eureka，有虚拟服务名称概念。只要知道服务名字，即可发送数据。所有的连接服务提供者全部统一注册到同一地方，统一管理。
那么其实我们也可以参考此类似的思路，把所有的进程连接至统一的管理中心master，以名字方式做好映射关系。
当需要发送至某服务时，只需要先查询是否是本地服务，或者是本地缓存服务信息，然后在底层做转换发送，对上层不可见。