什么是服务发现？
在现代基于云的应用程序中，有多个服务运行，其中一些实例的多个实例。每个服务都相互通信以提供服务很常见。为了互相交流，每种服务都需要了解网络地址和移植其他服务。
我们最初可以用力地编码网络地址和端口，但我们很快就会遇到很多问题。
如果我们需要动态地扩展水平缩放含义添加更多服务实例以处理增加的负载怎么办？我们如何将请求负载到每个实例？
在现代云应用程序中，每个服务都会动态分配其网络地址，并且由于水平缩放而运行的服务数量也经常更改。
部署新版本的服务将破坏通信，如果路径是硬编码，与新服务进行通信变得困难，并且需要进行大量的手动更改。因此需要服务发现机制。
一个服务发现充当注册表，该注册表拥有所有服务实例的地址
有两种类型的服务发现模式
1. client侧发现
2.服务员侧发现
客户端发现
在客户端发现机制中，服务负责确定可用的每个实例的地址。此外，该服务本身负责使用合适的负载平衡算法之间的实例之间的请求。
客户端服务注册表的优点：
- 直接实施
- 由于事先已知实例的地址，因此可以采用有效的负载平衡算法
- 如果服务发现下降，则可以缓存地址继续运行。
- 减少延迟，因为如果我们拥有集中式负载平衡器，我们不必额外的跳跃。
客户端服务注册表的缺点：
- 该服务紧密耦合到服务注册表
- 每个服务必须为服务使用的编程语言和框架实现客户端发现逻辑。
服务器端发现
在服务器端发现机制中，每种服务通过专用负载平衡器与其他服务通信。加载平衡器通过查询服务注册表并将每个请求路由到可用的适当实例来提出请求。
服务器端发现的优势：
- 服务变得更轻，因为它不必处理服务注册表查找
- 无需为服务使用的不同语言和框架实现服务发现逻辑
服务器端发现的缺点：
- 设置并管理专用负载平衡器
- 集中式服务注册表可以是整个系统的单点
- 由于每个请求必须通过负载平衡器和服务注册表 ，网络延迟会增加。
服务注册模型
到目前为止，我们已经假设服务注册表已经知道服务的地址。让我们看看服务如何注册和检查服务注册表。
自我注册
在自我注册模型中，每项服务都有责任在服务注册表中注册和降级。注册后，该服务需要发送“心跳/ ping/ ping”服务注册表以保持注册。
第三方注册
在第三方注册模型中，这些服务不负责将自己注册到服务注册表。取而代之的是，被称为服务注册服务商的系统中的另一个组件负责在服务注册表中注册服务。服务注册服务商通过轮询部署环境或订阅事件来跟踪更改。当有新服务可用时，它会将其注册在服务注册表中，并在终止后将其拆除。
总而言之，服务发现是一个具有服务实例地址的数据库。它必须是高度可用且最新的。