急急急,sofa-rpc-node 运行简单demo出的小问题,解不开,求指导。
发布于 9 个月前 作者 RajanZhan 2022 次浏览 来自 问答

我运行官方的例子(https://npm.taobao.org/package/sofa-rpc-node/v/1.6.0),一直报的错。如下 2018-11-25 11:23:47,345 WARN 8708 nodejs.ResponseTimeoutError: register to channel: [email protected]:2181 failed, will retry after 3s, Server no response in 3000ms, address#127.0.0.1:7777 使用直连模式就没问题,使用 ZookeeperRegistry 就一直报错。求指导。

42 回复

rpc 的话 Grpc 支持不错,一直在用~

其他的没试过,抱歉

安装和启动 zookeeper 了吗?

@gxcsoccer 大佬,你们做的rpc还需要zk,真厉害。

来自酷炫的 CNodeMD

@zy445566 你可能是对 rpc 有什么误解吧。

@gxcsoccer 不,因为我认为一般来说rpc是作为通讯的协议。如果加上zk可能对很多人来说都是没有必要的,即使是grpc和thrift也没有强制加上zk。 很多人的需求可能就是内网的通讯工具,而不是因为一个通讯工具,又上一个全家桶,尤其是对小项目来说这是非常不合算的。 如果说这个东西天生就只给大项目使用,我倒很理解。但大部分并不是,求指点迷津。

@zy445566 我们目前是在 k8s 里用,负载均衡对 rpc 层面是无感知的。

k8s 生成一个虚IP(用作负载均衡),写在容器的环境变量里。

代码读取容器的环境变量,连接对应服务的 ip 。

@zuohuadong 这话说的,好歹半年前也在k8s里面解决过内存泄漏的,用至少还是用过的 但是对于项目而言,我只是觉得在小项目中,没什么用途。所以才觉得很奇怪。 退一步说,如果在你们的k8s服务里面加sofa-rpc,你会怎么加?

@zy445566 表示,阿里开源的产品不敢用~ 被 坑怕了~ SUI Tengine Alisql …

如果你不是外国人的身份的话,他们可能让你加钉钉群然后问,也可能 关掉你的 issues 。

istio 这个比较有意思,可以去看看~

@zy445566 古云: 阿里开源项目:十个项目九个死,还有一个不更新。 圈子里都猜测 阿里的开源项目全是为了 KPI ,考核完就不更新了。

真实情况应该不是这,但确实阿里的开源项目 只管生,不管养。

@zuohuadong 来,立个 flag,看各自的负责的项目(非参与),2 年后谁的还在?

@atian25 小公司,没得比。

但是相对于 谷歌 微软 facebook 这些的开源项目呢?、

以 AngularJS 为例, 2.x 发布后(断层式更新), 1.x 维护了这么多年~

国外如果有点欺负人的话,拿 百度 来说,放弃的项目: ueditor 。 虽然不维护了,但是 安全问题依然更新着。

@zuohuadong 跟公司有什么关系,开源社区你我身份有什么不同? 大厂的项目,很多也是私人时间维护的,你以为公司会专门成立一个实体小组专门负责么?

不能『严以律人,宽以待己』啊。

一方面说阿里的只管生不管养,大家最好都不用。一方面对于自己的项目,觉得自己小,没信心维护。

那你自己的项目,现在是要推广还是不推广呢?如果推广,现在用了你项目的人,到时候你弃坑,他们哪里哭去呢?

@atian25 对个人来说,我倒是没有什么抱怨的。对阿里项目纯属吐槽,之前也非常喜欢阿里的一些开源项目。

也可能是因为国内环境如此吧。

国内x软,每年那么多外包项目,开源倒没见几个。

另外,像 linux mint 每个月有 至少8000 美金的捐赠,来维持项目。 但国内来说,靠捐赠活不下来。

完全是出于对开源环境的吐槽~

我们也一直希望在满足生存的前提下 维护开源项目。

@waitingsong 反应了半天,莫名戳中笑点

@zuohuadong

表示,阿里开源的产品不敢用~

兄弟,今天被你 一语成谶 了

@zy445566 此之蜜糖,彼之砒霜。这个蛋蛋味道如何…… 多好一个项目,费了多少人力精力才有今天的信任。这一蛋,不但搞得信用危机,恐怕还弄得广大阿里同事在外面都抬不起头。 一个企业还是有机制避免这种黑天鹅事件的好。

@waitingsong 我觉得核心问题在于阿里对待开源项目的态度吧,再说得深一些,可能跟企业文化有关了。 知乎上有人说: HR 造假聊天记录,月饼事件,支付宝6.1彩蛋…

虽然不是很认同企业文化这个观点,但阿里项目确实不敢用

额,一个月前的讨论,没想到这么快就打脸了。 其实我们更多的应该思考:9月份提交的代码,一直到事发,竟然没人提出来。🤔

@Yangk030208 早有外国哥们发了 issue 提出疑问的,结果被维护者关闭了。

@zuohuadong 我觉得企业文化、团队协作都不理想。 HR 造假聊天记录,月饼事件,支付宝6.1彩蛋,给我的感觉是内部官大一级一手遮天压死人,对外自傲自大。 成住坏空,不知道阿里在哪个阶段……

@waitingsong 好吧,确实是文化的问题了。

@Yangk030208 应该是企业氛围问题。我以前给阿里项目提 PR,出现过维护者不仔细看内容就给关闭的情况 (也许未关闭 issue 是 KPI 相关?)。似乎让我感受到阿里传递给你的自傲心态。 记得 士兵突击 里面说到每支军队的军魂是由诞生之初首任军事长官决定的。有的善攻有的善守,有的攻必克守必坚 。

@waitingsong 你敢将你提交过的 pr 链接发上来吗? 自豪地采用 CNodeJS ionic

@fengmk2 egg-cluster 提交的 PR 被你们的某人随手就关闭了。 有啥敢不敢的好像在诬陷你似的。

@fengmk2 https://github.com/eggjs/egg-cluster/pull/63 如何? 代码写好,测试也写了。 来几次就没人愿意提 PR了。到时候也许又有人说我们免费用你们的开源不贡献还要吐槽了吧。。。

@fengmk2 我觉得嘛 恐怕,也许你或者你们团队的心态不适。 没文化?没关系,年轻人有时间慢慢学。 没经验?没关系,年轻人有时间慢慢历练。 年轻人就是要折腾,在不断试错中成长。 但,能力越大破坏力越大。 个人项目随便你咋折腾。企业项目别玩个性。 公司(团队)的一个重要机制是避免个体玩脱了整个项目。 兵法云 以正合以奇胜。 正为中军,奇为奇兵。 是为正为团队,奇在个人。即团队循规蹈矩,个人鼓励创(dao)新(dan)。 否则,一支穿云箭,(好嘛) 千军万马来相(tu)见(cao)。

换个说法,在此次🎄蛋事件中同组低级别 的同事能否阻止这个commit 的提交,敢不敢提出自己的质疑?这个问题可值得你们仔细思考。 对你来说 假如你是 P5.6.7 敢不敢明确质疑 , 甚至越级报告 ? 若不敢,那就不是你的问题了,也不是这次捣蛋当事人的问题了。

@waitingsong https://github.com/eggjs/egg-cluster/pull/63#issuecomment-377694425 这里 @atian25 已经解析过为什么 close,然后重新 reopen了。你提交的另外一个关联 pr https://github.com/eggjs/egg-scripts/pull/20 也有 @popomore 的回复 https://github.com/eggjs/egg-scripts/pull/20#issuecomment-411963763 ,并且有新的 pr实现

我看过程很正常,https://github.com/eggjs/egg-cluster/pull/63 的 pr 最终也是你 close 掉的,也看不到什么原因没有推进下去。 还是很感谢你对 egg 的开源贡献的。

@zuohuadong 天天在有关 egg 的帖子下带节奏有意思?

@okoala c艹都有人喷,egg就喷不得了? 摆事实讲道理,喷回去意义何在?

来自酷炫的 CNodeMD

因为 egg-scripts 是用在生产环境的 CLI,会比较慎重一点,不想引入太多的无关依赖。

不支持 win 的一个主要原因是:在 win 下没有纯 JS 的好用的 pid list 工具,很多都是 C 的,而我们知道在 Node 里面,C 的模块跨平台兼容性不太好,因此引入此类依赖会非常的谨慎。

我印象中当时是在另一个 issue 里面讨论,我的建议是社区可以继承 egg-scripts 写一个 egg-scripts-win 给 win 的用户专用。 当时 waitingsong 很快就提交了 PR,这点很感谢,当时我 close 的原因如上所述,我更倾向于独立一个 CLI 的方式。

waitingsong 关闭的原因,我猜测是太久没合并?我记得好像是在微信沟通过,我倾向于独立 CLI (如果是我个人传达不清晰,我道歉,还是很感谢对 Egg 的支持。)

在开源社区,PR 不被合并我感觉是挺常见的事,我自己提的不少 PR 也经常没被合并,原因可能是:理念不一致、作者太忙时间线被淹没(有时只能积极的去推进)。

@okoala @zy445566

没必要这么针锋相对,社区是包容的,允许有不同的声音的,时间会证明一切,退潮后谁在裸奔一目了然。

彩蛋事件,本来不太想回复的,不过既然这样,在这里提下我的看法吧:

  • 就彩蛋本身,是一件非常蠢的事,偏右和他的团队也已经受到非常严重的处罚了。做错了就要立正认打,很正常,错的地方就改,正确的继续坚持。
  • 选择一个框架,放弃一个框架,是开发者的自由,也是前端常有的事,心态放平和点。
  • 重要的是我们从事件中发现了什么问题,如何去解决,而不是讨论什么人品之类的问题。毕竟大家都是开发者,只是为了在网上发泄什么,并不能提升自己吧?有那时间,你们还不如去讨论下 https://github.com/ant-design/ant-design/issues/13895#issuecomment-450324522

@okoala 也许一些阿里的同学会觉得很委屈,阿里那么大,几万人,为什么外界会粗暴的用个例去指责和代表所有人。 这事其实挺常见,就像你在知乎等地方,也会看到『贵国』、『贵乎』之类的说法,把不同人做过的事,全部结在一起代表一个大集体,事实如何,我们作为『贵国』的一份子,都很明白是什么情况。

至于一些上升到企业文化,人身攻击的,无视就好了,有则改之,无则加勉。在这个平台上,享受它带来的 buff,自然会一并承担相应的责任要求,以及你会觉得委屈的一些攻击和诋毁。这很正常,只要记住我们的初心,抱着一颗敬畏的心,同时也要不吭不卑,专心做事,时间会证明一切。

@atian25
flutter 的做法让我一直很尊敬。 尽管一个问题被提了 4-5遍,尽管这个问题不属于BUG,甚至只是配置问题。 flutter 团队从来不轻易关闭 issues ,除非用户确认问题已解决,或者长期无回复,又或者用户主动关闭。

也导致 flutter 上 未解决的 issues 显得特别多,甚至很多人认为问题多,但这又怎么样?

@zy445566 你好好说话那大家都好好说话,楼主问的如何解决问题,你们就来带节奏,有帮解决问题? 要喷就请单独开个贴~

@zuohuadong 每个项目都有它自己的管理规则和规范,就好像 Vue 甚至都不允许用户在 Issue 进行一般的答疑讨论。

你的意思是 Egg 经常无视用户反馈无故关闭 Issue ? 请给出对应的 issue 地址我们复查下。

对我们来说:

  • 提 Issue 必须带上最小可复现方式,这是很多开源项目最基本的要求,开源不是做外包,降低沟通成本是美德。
  • 没有可复现方式的 issue,我们都是会标注一个 label,然后 N 天内没有进一步反馈的,bot 会自动关闭。
  • 至于一部分非答疑范畴的,关闭没啥问题吧,譬如你做 nest 的答疑,难道要回答如何在电脑上安装一个 npm 之类的无关问题?

如果你真有深度参与过很多开源项目的话,会发现,我们其实跟大部分的开源项目没啥区别。

至少我们的单元测试覆盖率,我们的 PR 流程,我们的代码规范,不说非常顶尖,但也是主流开源的配置了,欢迎提交你的代码库我们比比。

Egg 的开源协作流程规范 image.png

@okoala C++之父曾经说过“世界上只有两种编程语言: 要么充满了抱怨; 要么没人使用。” 我上一条评论的意思是希望你能讲出你的道理,喷对于你的形象也是有损伤的,退一步说即使别人喷喷也是正常的,除非你的东西没人用。 请不要这么敏感直接就把我的语气加上恶意或者不好好说话的标签,摆正心态,越做越好,谢谢。

@okoala 注意下语气,不要人身攻击,就事论事。

PS,楼上的各位,不觉得大家严重离题了么?这个主题并不是讨论阿里相关问题的。

建议:

@fengmk2 你漏掉了问题的核心 “fell free to reopen if any other good idea.” https://github.com/eggjs/egg-cluster/pull/63#issuecomment-377694021 当时情况是我之前还有个用 node-ffi 实现的获取 pid 以及窗口控制的 PR。那个方法効费比太差,被我放弃。然后我重新用 windows 自带的 tasklist 命令实现了获取 pid 以及端口等信息。代码完成,测试写好,PR 提交上去立刻就给我关了,还来个 “good idea” ? 说明就没仔细看我的实现方案。 你说项目是个人业余时间来维护没时间即刻处理,这我理解。但实际的处理方法只能让我感受到一丝的傲慢。 你说 reopen 了, 我辛辛苦苦完善了代码提交上来,过了几个月没人搭理。然后过了四个月,有个兄弟用 wmic 实现了查找 pid 功能: https://github.com/eggjs/egg-scripts/pull/22 既然有人实现了功能并且已经合并到主分支我不关闭 PR 还等着下蛋么。 另: 不过我觉得 wmic 方法不足之处在于需要访问网络。并且我这儿防火墙会有它频繁访问的记录,不知道为何。

以上所述在于陈述事实,不是来讨公道或找麻烦。 自己业务本来就忙,没精力纠葛这些。 你们是业余时间维护,我不仅业余时间甚至还投入工作时间来提 PR。 不过如此浪费我的时间,我不仅懒得回帖,以后连 PR/issue 都懒得提了。 本来这帖都不准备写的,主要是考虑下面这个事情才顺便说说:

https://github.com/eggjs/egg-cluster/pull/75 这都过去五个月了,不会 最终又是我自己 close 掉 了吧……

我始终认为: 细节决定成败,三观决定高低

antd 对细节的追求达到成功,却因后者跌了大跟头。冷暖自知。

楼主见谅在你的问题贴内讨论无关话题。 可程序员劳心劳力还要应付人事人际关系,实在累。权当消遣回血吧。 再说功夫在诗外,有人从剑招提升书法,有人借毛主席语录来练(功)夫。 各花入各眼,修行在个人。

回到顶部