为什么需要服务发现？

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

这就是服务发现。

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

更灵活吧

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

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

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

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

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

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

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

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

istio 就可以这样

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

方便动态拓展服务。

这不就是 k8s 的 service

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

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

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

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

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

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

@threeEggs123 你这个自动扩容组不就是服务发现么

@julyclyde 这里的 ASG 只是管理了他自己服务器 EC2 的状态，比如是否健康，有几台实例工作。并不知道其他服务的状态，其实也不需要。如果是 spring cloud 的话，这里的 ASG 应该只是提供了 actuator 的功能。服务发现我理解是可以知道同一注册中心的其他服务状态，比如其他服务的 IP，端口。我这里的 ASG 并不具备知道其他服务的状态的功能。
公司的架构类似于 service mesh，其实我也不是很懂，国庆恶补一波。

@threeEggs123 你的 ELB 的转发目标不是自动扩容组嘛？

@julyclyde 每个服务都有一个 ELB，每个 ELB 只转发到它自己服务的 ASG 。

@threeEggs123 对啊，ASG 就是让 ELB 发现实例变化的机制啊

@julyclyde 对