为什么需要服务发现?

如果把服务绑定到某域名,客户端只需要知道服务的域名是不是就可以了,域名背后的服务器可以藏在负载均衡器之后,负载均衡器负责跟踪活跃的服务器节点。

理论上我们只需要一个维护服务和域名的映射关系即可 ,这个时候还需要服务发现吗?

相关文章

17 thoughts on “为什么需要服务发现?

  1. 在你这个场景下:
    负载均衡服务器 1.需要发现活跃的服务器节点 2.及时移除掉异常节点

    这就是服务发现。

  2. 域名各种缓冲下来,更新一台服务器使用方要更长时间才知道,且如 etcd 之类还有消息发布功能,就是主动推送

  3. 负载均衡增加了操作成本,尤其是程序主动操作过程中会增加操作步骤,上下线都需要通知。

    但都做完了其实就完成了服务发现的所有步骤了,只是这是一个负载均衡还是一个服务查询程序的区别了。甚至你会发现,少绕过一个负载均衡可能更省钱或者更快一点。

  4. 你这个思路也是服务发现的一种:基于 DNS 的服务发现。有一些缺点无法满足:及时更新节点列表( DNS 缓存一般较长),端口支持(当然 DNS 其实也支持 service 记录……)。

    实际上服务发现和负载均衡通常绑定在一起考虑

  5. 恢复时间和异常概率是最重要的,用 etcd 或 zookeeper 这样实现的服务发现,节点的上下线一般是节点自身主动上报,这样某个节点上线或者下线整个集群几乎可以毫秒级感知到,根本无须额外人工操作,负载均衡服务添加新节点肯定是要手动,节点下线也只能做到秒级检测,加上 dns 恢复时间那时间就太长了,而对于现在大型系统成千上万甚至十万个微服务来说,节点数都能到数十万吧,再加上云时代跨区域跨机房,各微服务各节点又必须能实现自由更新重启自由决定发布进程相互不影响,无须等着晚上统一更新重启,还要能随时可以自由迁移切换机器机房,如果人工修改加秒级的恢复时间,所造成的波动异常会十分高,用户都能感知到了,所以还使用负载均衡的方式的话就太作死了

  6. 可以从一个事前固定的名字连接到服务就是服务发现,实际上很多服务发现就是基于 DNS 的(

  7. 我有个问题,你们的内部微服务系统还绑定了域名吗。
    那是不是还要 https 啊
    现在鄙人在小厂,都是 ip+端口。
    我还想到一个原因就是 rpc 服务不能绑域名。

  8. 你说的就是 DNS 负载,会有很多问题的。不如需要手动写访问地址和端口、变更节点需要手动维护等等。

  9. @nulIptr 绑定内部域名,要不要 https 看你需求,大部分不需要。 ip+端口不好的 1 是不容易理解 2 是如果 ip 发生变化很麻烦

  10. 老实说我也不知道为什么还要服务发现,公司这边用的是 AWS 一套. Route53(DNS) -> ELB (负载均衡) -> ASG(自动扩容组) -> EC2 instance(真正运行代码的机器). 通过 ASG 来做故障检测,每个 EC2 实例都会有一个 isActive 接口,来判断 EC2 是否挂了. 新代码提交触发 Jenkins, 把 ASG 后面的 EC2 instance 给换了, 也不是涉及到 DNS 缓存的切换,因为 DNS->ELB 这一条路没有变. 我看了一下 K8S 的操作(Service->Pods)以及 AWS ECS 的操作大概也是这样.
    最近在看 SpringCloud 的一下内容,我觉得如果是按照我说的这种架构,是否就不需要服务发现了?
    然后各个微服务直接就通过 Router53 或者 ELB 直接 connect 就好了.
    比如 Java 这边随便什么的 HttpClient 直接连到对应的 ELB,为什么还需要什么 Euraka,ZooKeeper 了…
    然后其他的 Python, C#相应的客户端也去直接用 Route53 对于的域名就好了?
    有没有大佬解惑的? 谢谢!!!

发表评论

电子邮件地址不会被公开。 必填项已用*标注