对于微服务，go有etcd，node使用什么搭建微服务呢？在网上看到的文章都提到了seneca 大家一般使用什么呢？
https://moleculer.services/ 感觉这个人用的多一些。
微服务最主要的是服务于发现。虽然 k8s 也有自己的一套，不过是部署级别的，不是业务级别。
@MiYogurt 不要随便评价k8s, 误导别人. k8s service自带服务发现与负载均衡, 与健康检查配合, 差不多够用了. 你觉得它不够强大, 各种ingress也要依赖它实现.
@xiaozhongliu 莫名其妙，我评价了什么？误导了什么？我说了微服务只有服务与发现？还是可以写代码到k8s里面，所以它也是业务界别的？又不是云提供商，谁会把k8s里面代码嵌入到业务里面。k8s并不是开发框架，而且微服务并不是只有go语言。
再说了，评价又咋了？法律规定？还是道德底线？说错了又怎样，该坐牢还是要罚款？
@MiYogurt 你最开始说的 “微服务最主要的是服务于发现。虽然 k8s 也有自己的一套，不过是部署级别的，不是业务级别。” 这一段我们说道说道: 服务发现只是微服务治理的一小部分. k8s service自带服务发现与负载均衡, 不是特别强大, 但已经很强大了. 如果你需要更强, nginx ingress, traefik, istio ingress各种选择多的是. 服务发现是什么, 部署是什么, 什么叫属于部署级别的, 真看不出来你想说什么. 不是业务级别? 你的业务级别指什么? 微服务治理不管你用node框架做还是基础设施来做, 是不是你所谓的业务级别, 我想界定出来结果是一样的. 总体来说, 你这一段通过自以为是的不正确评价, 会让不明所以的人觉得k8s可能对于做微服务来说相对不靠谱. 所以前面我说的话在这里再说一次: 不要随便评价k8s, 误导别人. 对于其他没用过k8s的人, 越早开始学习越好, 使用docker & k8s并展开到其周边生态, 尤其是做后端的同学.
现在的事实是, node没有比较成熟的开源微服务治理方案. k8s + service mesh做微服务治理已经并且将越来越流行. 这对node以致所有语言来说是福音, 对于有些语言比如Java来说本身是福音, 但对他们的Dubbo, Spring Cloud等微服务治理方案是个冲击. 如果你要说service mesh流行吗?没听过?那我只能建议你先了解一下CNCF. 估计你更没听过了.
至于上面有人说什么触动利益. 其他不说, 请自行先去了解一下为什么会有CNCF. 为什么会有云原生这个概念. 然后不要随便酸, 请指明我到底是为了谁的利益, 我好给你继续解释清楚.
@xiaozhongliu 他说的是开发框架，上来就 k8s、k8s ，它更多是作为容器去做部署，我说的业务级别，就是类似于 service mesh 嵌入一个sdk一样，或者嵌入一个框架，而且微服务最直观给的感受的就是服务与发现，分而治之，再说了 k8s 是万能的么？你有考虑一个前端和 noder 学习成本吗？什么公司都能随便整k8s ? cncf 还真没听过，好像是一个组织，难道我需该什么都懂么，service mesh 倒是前几年就开始搞起来了。我就问，为什么人不能评价 k8s ? 一千万个人有一千万个哈姆雷特，哈姆雷特属于任何人吗？我评价哈姆雷特就有罪吗？你这么一说搞得我说的有错一样，误导了一大群人，说k8s不好，大家都别用，我有这样说嘛？这 这让我莫名其妙。
云容器，你是大佬，惹不起，只会 20% 的我不配拥有发言权。 溜了，溜了。
不需要框架 ISTIO搞定所有 微服务的难点除了业务点拆分的边界识别难度外 剩下就是服务间通信的方案选择了 Istio应该是最好的选择 但通信性能可能不如其他微服务框架