服务发现的作用是什么，有什么好处

• 資深大佬 : snappyone

  域名方便还是 ip 加端口方便

• 資深大佬 : chinvo

  微服务可以启动大量实例，随机任何端口，分布在一堆不同的机器上。

  不用服务发现，怎么访问。

• 資深大佬 : chaleaoch

  同一个服务 同时上线 100 个实例.
  你用 nginx 绑定 IP 要写 100 条转发.
  突然有一个容器挂了.
  要手动修改.

  那我如果有 10*10 个服务呢?

  服务注册与发现将实现自动化上述操作.

• 資深大佬 : chinvo

  讲道理啊，只是把 API 按领域分开，不叫微服务，叫领域编程。

  微服务首先得微，得专一化，得灵活化

• 主 資深大佬 : awanganddong

  我这样理解对不对，
  就是服务之间一般是通过 ip 地址和端口之间访问。

  如果服务比较多的话，就提供一个接口来实现获取域名和端口。

• 資深大佬 : xlui

  假设存在微服务化的 A 服务和 B 服务，均集群化部署，A 服务部署 3 台机器，B 服务部署 4 台机器。B 服务对外暴露了某个接口，端口号为 9876 。A 服务想调用必须指定 9876 端口，但是因为 B 服务部署了 4 台机器，A 服务怎么知道需要调用哪台机器呢？

  这个时候我们就需要引入一个服务发现中间件 C，A 和 B 的所有机器在启动时都到 C 注册，注册内容为 IP+端口。A 在调用 B 时，通过 C 获取到当前在线的、注册了 9876 端口的某台 B 机器，然后直接发起调用（ IP+端口）。

  引申一下可以借助 C 实现流量路由、统计等等功能；
  再引申一下可以借助 C 把端口干掉，通过接口名称的形式调用。

• 主 資深大佬 : awanganddong

  明白了，谢谢大家

• 資深大佬 : luozic

  SOA 最成功的部分主要就两个： （ 至于接口标准化这种事情，倒不如说是 microservice 与 OpenAPI （ swagger ）的贡献）

  A: 一个服务注册与发现机制；
  B: MQ，现在到处用的都是。
  可以去了解一下 SOA 主要解决啥问题。。。

  详细解释为啥要这个服务发现与注册。 核心是实现大量服务的集成（考虑到时间和空间上各个服务发布进度并不一致，or 走 devops 灰度上线流程，请问，该服务的调用方，以及该服务依赖的服务如何准确有效率的集成）。

• 資深大佬 : taowen

  https://zhuanlan.zhihu.com/p/25650431 服务注册发现与调度

• 資深大佬 : Cbdy

  这是 Java 程序员为了把很简单的事情描述得很复杂发明的术语

  所谓“服务发现”就是“流量”从 service name 到 service instance 的过程
  实际的例子如：特定端点的 HTTP 请求从网关路由到实际处理请求的机器的过程

• 資深大佬 : miv

  打个比方，在没有域名的时候，可以直接通过 ip 去访问。
  那么，有人就发现这种方式太不银性，不好记。
  为了为了偷懒不去记这个 ip 就需要一个 dns 服务器。
  通过 dns 服务器去帮你记住 ip，而你只需要记住域名就可以。
  服务发现，说白了就是这样一个 dns 服务器，现在有了它，访问不同的服务只需要通过服务名。
  比如我访问 a 服务，就会自动负载均衡到绑定 a 服务的 ip 节点上。
  这不香嘛？哈哈。
  有了它，我再也不需要写死服务 ip 的地址，面相服务名编程，而且所有的服务都需要经过它，那么我可以进行全局的流量控制或者一些负载均衡。

• 資深大佬 : yazoox

  @miv 如果“发现服务器”down 了，怎么恢复？

• 資深大佬 : luckykev1n

  本质上也是一种解耦的方式

• 資深大佬 : crclz

  @yazoox 用 dns 。dns 是分布式的（ dns 的 D 字），不会 down 。MongoDB 的集群连接字符串就支持 DNS，和服务发现很相似。如果不用 DNS，可以事先在客户端硬编码 N 台服务器的 IP，这样就可以承受 N-1 台宕机。

• 資深大佬 : yeqizhang

  其实很多中间件，或者 cs 架构的东西，都是为了存一些数据，就像上面说的通过服务名就可以找到服务 ip，这样一个 kv 的数据。然后再加上数据的维护的一些功能。比如 zk

• 資深大佬 : nicebird

  非常简单，就是一个 DNS 功能，给 ip 、port 做了一层抽象，方便之后换 ip 、port，如宕机的时候。

• 資深大佬 : github2020

  想象一下外卖服务：

  骑手：服务节点
  外卖 APP 平台：服务网关
  顾客：服务调用者

  骑手只要登陆 APP，就可以接单了，这就像是服务注册；
  我们作为顾客，并不关心具体有多少骑手、是哪一个骑手送餐，我们只要从 APP 订餐，系统就会自动指派可提供服务的骑手。

• 資深大佬 : incompatible

  用一句话通俗地讲就是 dns 啊

• 資深大佬 : wangxiaoaer

  docker compose 的模式下用不上吧，自带 DNS 解析和负载均衡。不知道对不对。

• 資深大佬 : jorneyr

  网状结构与星型结构的区别

• 資深大佬 : Takamine

  路由表。