为什么要使用服务发现?
传统的项目而言，服务器端的服务实例的网络地址是相对固定的。而基于云端、现代化的微服务服务实例的网络地址往往是动态更新的。由于服务器端的服务实例扩展、维护、升级，导致服务器端服务实例的IP地址、端口发生变化，从而使得客户端无法获取服务实例新的地址进行正常的调用。
服务发现为解决此类问题的一个解决方案，服务发现实时的获取服务器端服务实例的最新网络地址生成服务注册表，并提供给路由器或客户端服务实例的可用信息。服务注册表可以理解为一个包含所有服务信息的数据库。
服务发现的两种模式：客户端服务发现 、 服务器端服务发现。
客户端服务发现
客户端服务发现指的是客户端直接去服务注册表中查询服务实例信息，并对所有可用的服务实例进行负载均衡算法获得一个最终的服务实例地址，去进行请求。
服务实例在服务启动时向服务注册表注册服务信息，并定期发送心跳来更新服务信息。服务注册表会根据发送来的心跳判断服务是否正常运行，若多次收不到心跳则会剔除对应的服务实例。当然服务实例也可以像服务注册表注销服务信息。
客户端服务发现的优点：不需要额外配制路由器、负载均衡器，由客户端直接查询注册表并进行负载均衡。
缺点：需要客户端与服务注册绑定，客户端要根据服务端的编程语言和框架 来实现服务发现逻辑。
Eureka、Zookeeper就是客户端服务发现的方式
服务端服务发现
服务端服务发现不由客户端直接去查询服务注册表，客户端正常的请求负载均衡器，由负载均衡器进行与服务注册表的交互，最终通过负载均衡器的负载均衡算法找到可用服务实例并请求。而服务实例在服务注册表的注册与注销等机制 与 客户端服务发现一致。
服务器端服务发现的优点：客户端不需要关注服务发现的实现，只需要正常的向负载均衡器发送请求即可。
这减少了编程语言框架需要完成的发现逻辑
缺点：除非负载均衡器由部署环境提供，否则会成为一个需要配置和管理的高可用系统组件。
consul是服务器端服务发现的典型框架。
服务注册表
服务注册表是服务发现的核心部分，可以理解为一个服务实例信息的数据库。服务注册表提供一组服务发现的Rest API供客户端查询服务实例，服务器端注册、更新、注销服务实例。
POST请求进行服务实例注册
PUT请求进行定时发送更新服务实例信息（心跳）
DELETE请求进行服务实例注销
GET请求进行服务实例查询
服务注册的方式
服务注册方式可以分为由服务实例自己注册，称为自注册模式，也可以由第三方组件进行注册，称为第三方注册模式。
自注册模式的优点是服务实例自己进行注册，无需第三方组件。缺点是服务实例与服务注册表耦合。
第三方注册模式，服务实例则不需要向服务注册表注册；相反，被称为服务注册器的另一个系统模块会处理。服务注册器会通过查询部署环境或订阅事件的方式来跟踪运行实例的更改。一旦侦测到有新的可用服务实例，会向注册表注册此服务。服务管理器也负责注销终止的服务实例。
优点是服务实例与服务注册表解耦，缺点是需要一个高可用的第三方服务管理器组件。