2018-09-11最少活跃调用法，理想情况下，每个服务提供者的连接数一样多，为什么最适合性能参差不齐的情况？难道不是性能好的连接多，差的连接少，比较好吗？作者回复: 性能好的话，连接也释放得快
15
2018-09-21消费者从内存中摘除此问题用户服务者，那么注册中心是否同步摘除？注册中心不摘除问题服务者的话，是否会又同步给了消费者？这块是怎么处理的呢？ 4- 2018-12-08注册中心摘除机制说的是不是有问题 应该是把当前时间和最近一次收到心跳的时间做对比吧 超过一定时间 就摘除吧
作者回复: 是的，这个说法更严谨一些，感谢指正。
3 
2018-09-25最少活跃方式，按这个来的话，请求都打到性能不好的机器了？不会压死性能不会的机器吗作者回复: 正常情况下，性能不好的机器因为处理慢，所以活跃连接数要比性能好的要多，所以按照最少活跃负载均衡算法的话，请求会更少
3
2018-09-12作者果然是老司机，还没见过列举的这么全的，点个赞。 3
2018-09-12如果是注册中心宕机，有什么机制来保障调用成功率呢？作者回复: 后面专栏有细讲
1
2018-09-11路由规则应该是存在配置中心而不是注册中心吧？作者回复: 看情况，注册中心也可以存配置，两者可以分开部署也可以部署在一起
1
2019-09-20服务消费者摘除机制这里没听懂，消费者的列表不是注册中心给的吗？这里说的是消费者从自己的内存中的服务列表中摘除请求失败的服务吗？
2019-06-29一致性hash是根据请求的IP吧
2019-05-23赞👍，干货满满
没有开发过微服务框架不熟悉，原理能听明白，知道是怎么回事!
2019-05-04文中说：如果后端服务节点的配置没有差异，同等调用量下性能也没有差异的话，选择随机或者轮询算法比较合适；如果后端服务节点存在比较明显的配置和性能差异，选择最少活跃调用算法比较合适。
前者是否应选择随机或者最少活跃调用算法，后者是否应选择轮询算法？ 1
2019-03-14胡老师，你好。初探微服务那一篇，服务治理这块说到了自动扩缩容，本文没有说到，这块一般怎么弄？
2019-03-08老师你好，最少活跃调用算法，这个是有消费端实现的吗？我感觉应该是服务端来统计会更准确一些，因为连接服务端可以有多个客户端，那么这个比如在A客户端看来是连接数少了，比如2，但可能B客户端连接数很多，比如200，所以应该看所有客户端加起来的总连接数更准确些，不知道分析得是否正确？还请老师指点！
2019-02-11由于目前是手机游戏项目，
负载均衡应用在逻辑和战斗服务的分配上，
服务路由：根据网络延时分配战斗服
节点管理： 通过统一的注册中心，其他服务和注册中心进行心跳检查，并且订阅服务状态相关的消息，一旦对应服务挂了，消费者可以知道。不过可能会有延时
服务容错：现在所有的接口基本都是failfast，直接失败，打印日志处理。
2019-02-03应该是对于幂等的场景才需要查询服务状态吧？
非幂等等服务请求直接重试就好了啊。
2019-01-06阿忠老师好，请问本章节的服务治理 和 断路器里的服务的降级和限流 之间是什么样的关系呢？
2018-11-29最小活跃数，消费者维护的仅仅是自己与各个提供者的连接数，并不能得知服务提供者的总消费情况，这样子不能均衡吧作者回复: 是的，只知道自身的情况，大部分情况下可以反馈整体的情况
2018-11-18关于失败节点摘除有点疑惑。如果靠消费者在调用失败后才摘除异常节点的话，那么岂不会降低系统的稳定性。是否应当是注册中心和消费端一起配合进行服务端状态判断呢？作者回复: 对于大流量业务来说，调用失败的次数可以忽略，并且灵敏度要高于使用注册中心
2018-11-07.net 有什么好的微服务框架？.net core 算不算作者回复: 不太清楚，.net语言基本没接触过
2018-10-13请问下，dubbo的节点管理采用的是什么方式？