理解服务发现的基本原理

前言

  随着微服务的大范围应用，微服务中每个服务能做到按需伸缩拓展的优点也充分的体现在我们平常的工作中。但也暴露出一个问题，就是微服务中每个服务的实例可能不止一个，我们消费方(Consumer)用传统在项目配置中提供方(Provider)ip+port来访问服务提供方的方式就存在如下问题：

1. 部署在云环境中，服务实例的网络地址可能是动态分配的；
2. 服务一般有多个实例做负载均衡，由于宕机或者升级，服务实例的网络地址会经常改变；
3. 项目后期如果访问量级变大，需要增加服务节点的时候；

  在这个基础上，当服务地址改变的时候我们直接有效的访问并实现负载均衡？

服务发现是什么？

  服务发现就是服务消费方通过服务发现中心智能的发现服务提供方的网络地址，从而远程调用的过程。

  如上图所示，我们每一个微服务都需要将自己的地址上报到服务发现中心，服务发现中心里有一个服务发现注册表，就是专门记录与维护服务实例的地址，如果service A要调用Service B的服务，它可以在服务发现中心根据服务名非常方便的找到他下面的所有网络地址，然后根据负载均衡的算法找到这个服务具体的服务实例，最后发起远程调用。

服务发现优点有哪些？

  服务发现的主要好处是无需配置：不用使用编码的形式配置网络地址，只需服务的名字就能使用服务。在现代的体系架构中，单个服务实例的启动和销毁很常见，所以应该做到：无需了解整个架构的部署拓扑，就能找到这个实例。

常用服务发现框架有哪些？

目前我们比较常用的服务发现中心框架主要有：Nacos,Eureka,Consul,zookeeper。