为什么需要服务发现？

• 資深大佬 : xgfan

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

  这就是服务发现。

• 主 資深大佬 : mutelog

  @xgfan 你的意思是 负载均衡服务器充当了服务发现者的角色？

• 資深大佬 : copymaster

  更灵活吧

• 資深大佬 : GGGG430

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

• 資深大佬 : janxin

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

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

• 資深大佬 : CoderYellow

  简单 dns 不知道服务健康度 做不好负载均衡

• 資深大佬 : Inn0Vat10n

  你说的这个东西就是服务发现干的事情

• 資深大佬 : rrfeng

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

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

• 資深大佬 : zoharSoul

  是的, 你这个是服务发现的一种.

  istio 就可以这样

• 資深大佬 : sujin190

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

• 資深大佬 : EminemW

  方便动态拓展服务。

• 資深大佬 : gaius

  这不就是 k8s 的 service

• 資深大佬 : islxyqwe

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

• 資深大佬 : tsingke

  应该是 客户端负载 和服务端负载的 比较吧

• 資深大佬 : nulIptr

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

• 資深大佬 : coderxy

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

• 資深大佬 : coderxy

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

• 資深大佬 : threeEggs123

  老实说我也不知道为什么还要服务发现,公司这边用的是 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 对于的域名就好了?
  有没有大佬解惑的? 谢谢!!!