fanyh

我明白你的意思 这样一来可能随着slave更换会出现一些问题 ``` if node_address[name] ~= address then -- address changed if node_sender[name] then -- reset connection if node_sender[name] exist node_channel[name] = nil table.insert(reload, name) end node_address[name] = address end...

我自己写了个cluster wrapper 来实现 route 和 load level 节点不可用这个比较麻烦 各种功能都支持 那差不多就等于弄个etcd 我目前使用的http来承担这些职责 另外 云大侠 cluserd 中 对应 ``` assert(address == false or type(address) == "string") if node_address[name] ~= address then --...

仔细思考了下 sender拒绝服务 可能结果会更糟糕 如果业务持有sender (应该很少有具体业务持有sender；所以持有还是在 cluster.lua:get_sender上) - 如果在dispatch时判断sender是否异常 抛出skynet.error 这样跟kill node 后调用cluster.call 抛出node不存在 也没差了 - 如果在dispatch返回服务拒绝 作为一个异常信号,这还需要业务层感知这个信息 但按cluser目前的设计来说，业务层不需要感知此内容 （ps:按当前版本设计思路的话，我觉得应该修改cluster.call/send 和 释放clust 在最近的cluster设计结构中 我觉得业务不应当持有sender 如果业务持有 那业务在reload时也应当自行释放sender 引用 cluster目前的设计思路对于业务层来说是1个很好的闭环 （业务层不需要了解对端服务器部署位置 仅需要向自己感兴趣的service 投递消息）...

我觉得既然参考了微服务设计方案；就应该淡化指向性定义(取消skynet name定义)； 我们游戏的模式是一套skynet集群中运行一个项目（游戏） 现在的作法淡化skynet name；然后吧所有的(无法指定game上的;如：跨服聊天等)业务放在若干个skynet进程中，进程本身只关心启动的service和开放的ip:端口 服务发现时可以使用ip:port来做进程标记（这个是唯一的） 因为skynet本身不会告诉业务那些service过载 同时考虑到load level 的问题，于是我们重度依赖了debug 获取stat;于是采用save db来代替etcd(服务汇总&发现) 上层业务实现1个cluster wrapper 来服务 来代替cluster的直接调度(调度方式仅需保持和skynet.call/send 一致) wrapper中维持node valid(可以阻止node 出现过载时，业务持续输入导致情况恶化) & register route trick 目前尚存不足： 1. 上层业务无法感知目标service是否存在,可能存在特定service 无任何可用节点;(如：特定节点过载后 无备用节点） 2....

> 我觉得消息回传你可以考虑实现成 message queue 服务。在 mq 服务上创建一个 queue ，然后需要回传的消息 pub 回复消息进去，接收方可以 sub 这个 queue 。 目前实现方案是按照mq的方式实现的；可能存在某些极限/边界情况下出现多个 slave node pub相同的消息到上层业务; 目前我想到的2种解决方案： 1. zeroatom提到的sub响应的每个msg仅能作为notify，需要上层业务发起一次（上层业务执行判断实现需要发起）rpc才能取得最终数据 2. 直接在上层业务的cluster wrapper里将pass掉的node 的 mq 监听 直接关掉；这个node 在他重启前将不在启用（有点简单粗暴）...

这几天又想了想消息回传的问题 我最大的痛点在于 构架的调度器设计为 业务逻辑无需知晓节点调度情况 实际业务环境又可能需要干涉调度逻辑（例如：某些情况下就算node 假死也不切换node） 最终我还是打算给调度器开放一个register接口来注册路由策略；最终来决定是否熔断/retry 熔断后也就不考虑node restore的这种复杂情形；除非node restarted 这样一来我的很多问题也将将变得简单很多，对于使用者来说也不会造成太大额外负担（至少比处理预期外的pub msg简单不少）

我们需要同时支持 全球服项目/分服项目 多种业务环境 目前这样做是为了能够更好的把项目运行在k8s中，尽可能多的利用k8s的特性同时减少开发组的制作难度 异常对开这种处理措施比较简单啊 在战斗节点侧 像云大侠说那样建立msg queue ,你吧msg queue 前面包一个heart_monitor； agent 侧保持ping ；这样逻辑就顺了， 我有点不太明白的是什么叫 等心跳感知还有大量的connect? 你的2个节点互发消息是建立的2个tcp? 如： agent call ``` cluster.call("battle node", "battle service", ...) ``` battle push msg...

这种我还是建议你实现个simple msg queue; battle service 需要向agent 投递消息 调 skynet.send("msg queue"); msg queue 再push 将消息push 到 agent (这样可以减少一些你调度1次就产生1个connected faild的情况) 在msg queue 里面处理链接异常 包括不限于retry 但是在heart timeout 前 connect 是 没办法停止的，只能说可以减少一点 当然我更推荐你 用一条tcp...

我明白你的意思了；但我觉得你始终需要再包装一次 或者你魔改一个你自己的cluster_sender; 你如果用云大侠提供的原神调度，你这个问题没办法避免

目前采用cluster+etcd liker 组网已经过去几个月了，已经推广到多个项目中使用，虽然仍然存在部分问题，但在可接受范围内 考虑到很多业务场景实际上不期望知晓组网总节点数，仅关心与自己业务息息相关的node, 于是我们把etcd作为service并入了工程内，cluser server game server 通过etcd service的落地信息来同步node的上下线; 这里存在一个延时信息，我们在game etcd service中尽量的磨平了 延时对业务的负面影响；业务统一使用包装过的cluster proxyd 访问组网节点，当然也可以自己定向，不过需要自行处理掉线等问题。 在设计过程遇到最大的问题是还是cluster proxyd 和 etcd的维持上，整体来说这种组网模式对整个项目人员的要求会比直接使用定向业务组网这种方式高一些 表述得略显凌乱，终归来说这种组网模式的还是有可行性的，目前我们应用层产生的问题还是比较少;反而是cluster proxyd还有优化空间，对过载的保护做法略显粗暴，将就能用 待项目顺利上线一段时候后再将我们的组网结构呈现出来接受大家批评。