服务发现-从原理到实现

服务发现-从原理到实现

服务发现,作为互联网从业人员,大家应该都不陌生,一个完善的服务集群,微服务是必不可少的功能之一。

最近一直想写这个话题,也一直在构思,但不知道从何入手,或者说不知道写哪方面。如果单纯写如何实现,这个未免太乏味枯燥了;而如果只是介绍现有成熟方案呢,却达不到我的目的。想了很久,准备先从微服务的架构入手,切入 服务发现 要解决什么问题,搭配常见的处理模式,最后介绍下现有的处理方案。

微服务服务于分布式系统,是个分散式系统。服务部署跨主机、网段、机房乃至大区。各个服务之间通过RPC(remote procedure call)进行调用。然后,在架构上最重要的一环,就是服务发现。如果说服务发现是微服务架构的灵魂也当之无愧,试想一下,当一个系统被拆分成多个服务,且被大量部署的时候,有什么能比"找到"想调用的服务在哪里,以及能否正常提供服务重要呢?同样的,有新服务启动时,如何让其他服务知道该服务在哪里?

微服务考研的是治理大量服务的能力,包含多种服务,同样也包含多个实例。

1概念

服务发现之所以重要,是因为它解决了微服务架构最关键的问题:如何精准的定位需要调用的服务ip以及端口。无论使用哪种方式来提供服务发现功能,大致上都包含以下三点:

Register, 服务启动时候进行注册

Query, 查询已注册服务信息

Healthy Check,确认服务状态是否健康

整个过程很简单。大致就是在服务启动的时候,先去进行注册,并且定时反馈本身功能是否正常。由服务发现机制统一负责维护一份正确或者可用的服务清单。因此,服务本身需要能随时接受查下,反馈调用方服务所要的信息。

2注册模式

一整套服务发现机制顺利运行,首先就得维护一份可用的服务列表。包含服务注册与移除功能,以及健康检查。服务是如何向注册中心"宣告"自身的存在?健康检查,是如何确认这些服务是可用的呢?

做法大致分为两类:

自注册模式 自注册,顾名思义,就是上述这些动作,有服务(client)本身来维护。每个服务启动后,需要到统一的服务注册中心进行注册登记,服务正常终止后,也可以到注册中心移除自身的注册记录。在服务执行过程中,通过不断的发送心跳信息,来通知注册中心,本服务运行正常。注册中心只要超过一定的时间没有收到心跳消息,就可以将这个服务状态判断为异常,进而移除该服务的注册记录。

三方注册模式 这个模式与自注册模式相比,区别就是健康检查的动作不是有服务本身(client)来负责,而是由其它第三方服务来确认。有时候服务自身发送心跳信息的方式并不精确,因为可能服务本身已经存在故障,某些接口功能不可用,但仍然可以不断的发送心跳信息,导致注册中心没有发觉该服务已经异常,从而源源不断的将流量打到已经异常的服务上来。

这时候,要确认服务是否正常运转的健康检查机制,就不能只依靠心跳,必须通过其它第三方的验证(ping),不断的从外部来确认服务本身的健康状态。

这些都是有助于协助注册中心提高服务列表精确到的方法。能越精确的提高服务清单状态的可靠性,整套微服务架构的可靠度就会更高。这些方法不是互斥的,在必要的时候,可以搭配使用。

3发现模式

服务发现的发现机制主要包括三种:

服务提供者:服务启动时将服务信息注册到注册中心,服务退出时将注册中心的服务信息删除掉。

服务消费者:从服务注册表获取服务提供者的最新网络位置等服务信息,维护与服务提供者之间的通信。

注册中心:服务提供者和服务消费者之间的一个桥梁

服务发现机制的关键部分是注册中心。注册中心提供管理和查询服务注册信息的API。当服务提供者的实例发生变更时(新增/删除服务),服务注册表更新最新的状态列表,并将其最新列表以适当的方式通知给服务消费者。目前大多数的微服务框架使用Netflix Eureka、Etcd、Consul或Apache Zookeeper等作为注册中心。

为了说明服务发现模式是如何解决微服务实例地址动态变化的问题,下面介绍两种主要的服务发现模式:

客户端发现模式

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zwwdsd.html