微服务的服务发现机制

最新推荐文章于 2025-03-23 15:53:23 发布

L13763338360

最新推荐文章于 2025-03-23 15:53:23 发布

阅读量427

点赞数

分类专栏： java

本文链接：https://blog.youkuaiyun.com/L13763338360/article/details/105731016

版权

26 篇文章

订阅专栏

当我们需要远程访问REST API或者Thrift API时，我们必须得知道服务的网络地址（IP Address和port）。

传统的应用程序都是运行在固定的物理机器上，IP Address和端口号都是相对固定的。可以通过配置文件方式来实现不定期更新的Ip Address和端口号。

在基于云的微服务应用中，服务实例的网络地址（IP Address和Port）是动态分配的，并且由于系统的auto-scaling, failures 和 upgrades等因数，一些服务运行的实例数量也是动态变化的。因此，客户端代码需要使用一个非常精细和准确的服务发现机制。

服务发现主要有两种方式：客户端发现和服务端发现

2.1.1 发现过程

服务端：服务启动的时候，向服务注册中心注册服务；在服务停止的时候，向服务注册中心注销服务。
客户端：客户发现方式时，客户端通过查询服务注册中心，获取可用的服务的实际网络地址（IP和端口），然后通过负载均衡算法来选择一个可用的服务实例，并将请求发送至该服务。

2.1.2 应用举例：Netflix OSS

Netflix OSS就是使用客户端发现方式的一个很好的例子。

2.1.3 优缺点

2.2.1 发现过程

服务端：和客户端发现一样，服务启动的时候，向服务注册中心注册服务；在服务停止的时候，向服务注册中心注销服务。

客户端：客户端向load balancer 发送请求，load balancer 查询服务注册中心找到可用的服务，然后转发请求到该服务上。

2.2.2 应用举例：Kubernetes

Kubernetes集群中每个节点都运行一个代理来实现服务发现的功能的，代理的角色就是server-side discovery，客户端通过使用主机的IP Address和Port向Proxy发送请求，Proxy再将请求转发到集群中任何一个可用的服务上。

2.2.2 优缺点

优点：服务的发现逻辑对客户端是透明的，客户只需简单的向load balancer发送请求就可以了，这就避免了为每种不同语言的客户端实现一套发现的逻辑。此外，许多软件都内置实现了这种功能
缺点：你必须得关心该组件的高可用性

服务注册中心是服务发现的核心，它保存了各个可用服务实例的网络地址（IP Address和Port）。服务注册中心必须要有高可用性和实时更新功能。

服务注册和注销有两种方式：Self-Registration和Third-Party Registration

Self-Registration：服务实例必须自己主动的到注册中心注册和注销，代表：Netflix OSS Eureka client
- 优点：非常简单，不需要任何其它辅助组件
- 缺点：使得各个服务和注册中心的耦合度比较高，服务的不同语言的客户端都得实现注册和注销的逻辑。
Third-Party Registration：服务本身不必关心注册和注销功能，而是通过其他组件（service registrarhandles）来实现服务注册功能，可以通过如事件订阅等方式来监控服务的状态，如果发现一个新的服务实例运行，就向注册中心注册该服务，如果监控到某一服务停止了，就向注册中心注销该服务
- 优点：使服务和注册中心解耦，不用为每种语言实现服务注册的逻辑
- 缺点：必须得考虑该组件的高可用性。

Netflix Eureka——提供了服务注册和查询服务信息的REST API，服务通过使用POST请求注册自己的IP Address和Port
etcd —– 高可用，分布式，强一致性的，key-value，Kubernetes和Cloud Foundry都是使用了etcd
consul —–一个用于discovering和 configuring的工具。它提供了允许客户端注册和发现服务的API。Consul可以进行服务健康检查，以确定服务的可用性
zookeeper —— 在分布式应用中被广泛使用，高性能的协调服务。 Apache Zookeeper 最初为Hadoop的一个子项目，但现在是一个顶级项目

参考