在微服务架构中，服务与服务之间需要通过服务发现来找到对方，以便发起请求。

所谓的服务发现就是一种自动监测并发现网络内的的服务的机制。可以调用者动态感知到网络上服务的变化。DNS就是最典型的服务发现系统了。

在微服务架构中的服务发现的工作原理也和DNS差不多。为什么需要一个服务发现来帮助通信呢？

在应用程序启动时读取一个配置，配置里包含所有的服务的地址，这样不好吗？当微服务架构中服务的数量较少时，这种方案没有太大的影响，也可以接受。 但是当服务变多时，甚至达到了成百上千个，那么这种方式就不好了，当有新的服务加入时，就无法被其他服务自动发现，必须修改配置，各个应用程序还不得不重启以加载配置。运维的成本是相当高。

大规模的服务集群，它的节点还会动态伸缩等，如果没有一个自动发现服务的机制，系统几乎没有办法做动态伸缩。

服务发现系统中一般包含：
1、服务提供者：上游服务，对外暴露API，有一个IP地址和端口作为其服务地址
2、服务消费者：下游服务，通过访问服务提供者的API来获取数据
3、注册中心：用来存储服务地址信息，充当前两者之间的通信桥梁。

服务发现的主要模式有
1、客户端发现模式
在这种模式下，服务启动时会将自己的地址注册的到注册中心，客户端访问注册中心获取要访问的服务的地址，然后向服务提供者发起访问。典型例子：Eureka这个组件提供了注册中心和客户端，它对服务地址的更新基于发布订阅模式中的拉取方式，也就是说客户端会定时到注册中心拉取最新的数据，这可能会出现服务这此期间进行更新，当时还调用差旧的服务，所以这种技术要求节点与服务的关系相对固定。每个服务都需要集成一个Eureka的客户端才能完成这件事。这种模式在Kubernates、容器等云原生技术兴起后，就不流行了。

2、服务端发现模式
这种模式相较于客户端发现模式而言，多了一个代理。将服务信息的拉取、负载均衡等都集中到这个代理来做。当服务消费者发起的请求会由代理接管，代理从注册中心查询到服务提供者的地址，然后根据查询到的地址，将请求发送给服务提供者。Kubernates正是使用这种模式来完成服务发现的。Kubernates的Node节点上都会有一个kube-proxy的代理，这代理会实时检测服务和端口的信息，当有变化时，kube-proxy会在对应的Node节点处修改相当的iptables路由规则，客户端服务就可以比较方便地通过服务名称访问上游服务。

这种模式相较与客户端发现模式还有一大好处，那就是不需要集成SDK，隐藏了实现细节，消除了对语言和类库的限制。