微服务架构之服务发现

2023-12-13 09:28:32

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

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

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

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

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

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

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

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

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

文章来源:https://blog.csdn.net/weixin_40763897/article/details/134867545
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。