问题

[SaorenXi]

1，文档不充分，不系统，导致难以学习，推广
2，之前一直没人维护，不利于推广
3，加个QQ群，QQ群里只有11个人，加群答案写了问“surging”是什么，回了几个答案都直接不对，直接被拒绝，不利于推广

[fanliang11]

1.首先，针对于社区版提供源码进行学习，作者没有其它义务提供文档，和技术上的帮助，你们可以自发完善，而不是让作者一个人发光发热，你也可以捐助作者或者购买企业版，你也可以进行宣传，用你的劳动来进行换取，让作者熬夜帮你解决。
2.surging主要由本人维护，本人会减少社区版维护，你可以自发提交pr,社区项目不是一个人的事情
3.surging有自己的一套微服务理论体系，和市面上所谓的asp.net core基于k8s微服务，ocelot,kong,我是不认同的，个人认为微服务是何物都分不清，所以你对于surging是什么非常重要，就怕两个观点有所碰撞，所以，群1和群2加起来才2100人。

[LuceLuo]

哈哈，你说的问题我都提了很多次了，然后放弃了。最后劝解那些准备运用于项目的人一定要谨慎。
首先要按需使用，作者提供了很多组件，可能很多是你不需要的。路由更新是1分钟的，在实际项目中应该是不可以用的，太长了；健康检查是通过访问超时来做的被动检查，这个时间也会很长，所以在实际使用中会出现大量的访问错误。本人算是入坑了，所以改成了主动报备的健康检查机制，虽然会丢失一些作者设计的其他机制，但是本人觉得这样更加稳定有效。还有一个点是原有的服务检查是全量的，而不是自己服务需要哪些检查哪些，这也是一种浪费吧。

[fanliang11]

注册中心分为consul和zookeeper, 一个是通过心跳更新，一个是push 更新节点，而你所说的1分钟更新节点，只是默认的，你完全可以进行更改，如果你只是小型项目完全可以减少其心跳间隔，但是针对于几千个服务，几百个服务提供者，1分钟都算小的，基本很多都是2，3分钟内。而针对于新的服务更新完全可以忍受这几分钟的熔断报错，这几分钟可能换来的是几倍的性能提升，如果你有钱，那加机器就另说了

[LuceLuo]

我这边是用的Consul，原有的健康检查还有一个点是这样的，在第一次访问该服务的时候，才会把这个服务加入到健康检查里面的，所以如果服务端更新部署启动时间晚于客户端（我这边是k8s，ip会变的），那么接口的第一次调用绝对是不通的，没做健康检查，取的是历史地址。

[fanliang11]

你说的这些都有配置，你要表达什么，你的服务太少，等有几千个服务，几十个服务提供者，还不给你多余的机器你就知道了，可以打开全量更新，还有不懂的可以购买企业版，社区版请自己解决

[SaorenXi]

欸

[SaorenXi]

出多少钱作者愿意把完整的文档写出来

[MetSystem]

@SaorenXi 可以直接投资做作者的老板，下达绩效考核 本月不出来绩效考核为0