我运行官方的例子（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: SofaRpcRegistry@127.0.0.1:2181 failed, will retry after 3s, Server no response in 3000ms, address#127.0.0.1:7777 使用直连模式就没问题，使用 ZookeeperRegistry 就一直报错。求指导。
@gxcsoccer 不，因为我认为一般来说rpc是作为通讯的协议。如果加上zk可能对很多人来说都是没有必要的，即使是grpc和thrift也没有强制加上zk。 很多人的需求可能就是内网的通讯工具，而不是因为一个通讯工具，又上一个全家桶，尤其是对小项目来说这是非常不合算的。 如果说这个东西天生就只给大项目使用，我倒很理解。但大部分并不是，求指点迷津。
@zuohuadong 这话说的，好歹半年前也在k8s里面解决过内存泄漏的，用至少还是用过的 但是对于项目而言，我只是觉得在小项目中，没什么用途。所以才觉得很奇怪。 退一步说，如果在你们的k8s服务里面加sofa-rpc，你会怎么加？
@zy445566 表示，阿里开源的产品不敢用～ 被 坑怕了～ SUI Tengine Alisql …
如果你不是外国人的身份的话，他们可能让你加钉钉群然后问，也可能 关掉你的 issues 。
istio 这个比较有意思，可以去看看～
@zy445566 古云： 阿里开源项目：十个项目九个死，还有一个不更新。 圈子里都猜测 阿里的开源项目全是为了 KPI ，考核完就不更新了。
真实情况应该不是这，但确实阿里的开源项目 只管生，不管养。
@atian25 小公司，没得比。
但是相对于 谷歌 微软 facebook 这些的开源项目呢？、
以 AngularJS 为例， 2.x 发布后（断层式更新）， 1.x 维护了这么多年～
国外如果有点欺负人的话，拿 百度 来说，放弃的项目： ueditor 。 虽然不维护了，但是 安全问题依然更新着。
@zuohuadong 跟公司有什么关系，开源社区你我身份有什么不同？ 大厂的项目，很多也是私人时间维护的，你以为公司会专门成立一个实体小组专门负责么？
不能『严以律人，宽以待己』啊。
一方面说阿里的只管生不管养，大家最好都不用。一方面对于自己的项目，觉得自己小，没信心维护。
那你自己的项目，现在是要推广还是不推广呢？如果推广，现在用了你项目的人，到时候你弃坑，他们哪里哭去呢？
@atian25 对个人来说，我倒是没有什么抱怨的。对阿里项目纯属吐槽，之前也非常喜欢阿里的一些开源项目。
也可能是因为国内环境如此吧。
国内x软，每年那么多外包项目，开源倒没见几个。
另外，像 linux mint 每个月有 至少8000 美金的捐赠，来维持项目。 但国内来说，靠捐赠活不下来。
完全是出于对开源环境的吐槽～
我们也一直希望在满足生存的前提下 维护开源项目。
@zy445566 此之蜜糖，彼之砒霜。这个蛋蛋味道如何…… 多好一个项目，费了多少人力精力才有今天的信任。这一蛋，不但搞得信用危机，恐怕还弄得广大阿里同事在外面都抬不起头。 一个企业还是有机制避免这种黑天鹅事件的好。
@waitingsong 我觉得核心问题在于阿里对待开源项目的态度吧，再说得深一些，可能跟企业文化有关了。 知乎上有人说： HR 造假聊天记录，月饼事件，支付宝6.1彩蛋…
虽然不是很认同企业文化这个观点，但阿里项目确实不敢用
@zuohuadong 我觉得企业文化、团队协作都不理想。 HR 造假聊天记录，月饼事件，支付宝6.1彩蛋，给我的感觉是内部官大一级一手遮天压死人，对外自傲自大。 成住坏空，不知道阿里在哪个阶段……
@Yangk030208 应该是企业氛围问题。我以前给阿里项目提 PR，出现过维护者不仔细看内容就给关闭的情况 （也许未关闭 issue 是 KPI 相关？）。似乎让我感受到阿里传递给你的自傲心态。 记得 士兵突击 里面说到每支军队的军魂是由诞生之初首任军事长官决定的。有的善攻有的善守，有的攻必克守必坚 。
@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 的开源贡献的。
因为 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 也经常没被合并，原因可能是：理念不一致、作者太忙时间线被淹没（有时只能积极的去推进）。
没必要这么针锋相对，社区是包容的，允许有不同的声音的，时间会证明一切，退潮后谁在裸奔一目了然。
彩蛋事件，本来不太想回复的，不过既然这样，在这里提下我的看法吧：
- 就彩蛋本身，是一件非常蠢的事，偏右和他的团队也已经受到非常严重的处罚了。做错了就要立正认打，很正常，错的地方就改，正确的继续坚持。
- 选择一个框架，放弃一个框架，是开发者的自由，也是前端常有的事，心态放平和点。
- 重要的是我们从事件中发现了什么问题，如何去解决，而不是讨论什么人品之类的问题。毕竟大家都是开发者，只是为了在网上发泄什么，并不能提升自己吧？有那时间，你们还不如去讨论下 https://github.com/ant-design/ant-design/issues/13895#issuecomment-450324522
@okoala 也许一些阿里的同学会觉得很委屈，阿里那么大，几万人，为什么外界会粗暴的用个例去指责和代表所有人。 这事其实挺常见，就像你在知乎等地方，也会看到『贵国』、『贵乎』之类的说法，把不同人做过的事，全部结在一起代表一个大集体，事实如何，我们作为『贵国』的一份子，都很明白是什么情况。
至于一些上升到企业文化，人身攻击的，无视就好了，有则改之，无则加勉。在这个平台上，享受它带来的 buff，自然会一并承担相应的责任要求，以及你会觉得委屈的一些攻击和诋毁。这很正常，只要记住我们的初心，抱着一颗敬畏的心，同时也要不吭不卑，专心做事，时间会证明一切。
@atian25
flutter 的做法让我一直很尊敬。
尽管一个问题被提了 4-5遍，尽管这个问题不属于BUG，甚至只是配置问题。
flutter 团队从来不轻易关闭 issues ，除非用户确认问题已解决，或者长期无回复，又或者用户主动关闭。
也导致 flutter 上 未解决的 issues 显得特别多，甚至很多人认为问题多，但这又怎么样？
@zuohuadong 每个项目都有它自己的管理规则和规范，就好像 Vue 甚至都不允许用户在 Issue 进行一般的答疑讨论。
你的意思是 Egg 经常无视用户反馈无故关闭 Issue ？ 请给出对应的 issue 地址我们复查下。
对我们来说：
- 提 Issue 必须带上最小可复现方式，这是很多开源项目最基本的要求，开源不是做外包，降低沟通成本是美德。
- 没有可复现方式的 issue，我们都是会标注一个 label，然后 N 天内没有进一步反馈的，bot 会自动关闭。
- 至于一部分非答疑范畴的，关闭没啥问题吧，譬如你做 nest 的答疑，难道要回答如何在电脑上安装一个 npm 之类的无关问题？
如果你真有深度参与过很多开源项目的话，会发现，我们其实跟大部分的开源项目没啥区别。
至少我们的单元测试覆盖率，我们的 PR 流程，我们的代码规范，不说非常顶尖，但也是主流开源的配置了，欢迎提交你的代码库我们比比。
@okoala C++之父曾经说过“世界上只有两种编程语言: 要么充满了抱怨; 要么没人使用。” 我上一条评论的意思是希望你能讲出你的道理，喷对于你的形象也是有损伤的,退一步说即使别人喷喷也是正常的，除非你的东西没人用。 请不要这么敏感直接就把我的语气加上恶意或者不好好说话的标签，摆正心态，越做越好，谢谢。
@okoala 注意下语气，不要人身攻击，就事论事。
PS，楼上的各位，不觉得大家严重离题了么？这个主题并不是讨论阿里相关问题的。
建议：
- 如果是想讨论 AntD 事件的，去 https://cnodejs.org/topic/5c2115af76c4964062a1d53c 讨论。
- 如果想讨论流程改进的，去 https://github.com/ant-design/ant-design/issues/13895#issuecomment-450324522 。
- 如果是想讨论阿里开源的，也可以新开一个帖子。
- 如果想互相 PK 的，可以加个微信私聊下，不要在公共场合。
@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 对细节的追求达到成功，却因后者跌了大跟头。冷暖自知。
楼主见谅在你的问题贴内讨论无关话题。 可程序员劳心劳力还要应付人事人际关系，实在累。权当消遣回血吧。 再说功夫在诗外，有人从剑招提升书法，有人借毛主席语录来练(功)夫。 各花入各眼，修行在个人。
