微服务架构之服务注册与发现

为什么需要服务注册与发现

在单体架构中一个应用程序就是一个服务包,包内的模块通过函数方法相互调用,模型足够简单,根本没有服务注册和服务发现一说。
在微服务架构中会将一个应用程序拆分为多个微服务,微服务会部署在不同的服务器、不同的容器,甚至多数据中心,微服务间要相互调用,服务注册与发现成为不可或缺的一部分。

服务注册与发现原理

服务注册与发现分为注册和发现两个关键的步骤。
服务注册:服务进程在注册中心注册自己的元数据信息,通常包括主机和端口号,有时还有身份验证信息协议版本号,以及运行环境的信息
服务发现:客户端服务进程向注册中心发起查询,来获取服务的信息。服务发现的一个重要作用就是提供给客户端一个可用的服务列表

服务注册

服务注册有两种形式:客户端注册代理注册

客户端注册

服务自己负责注册与注销的工作,服务启动时注册线程向注册中心注册,服务下线时要注销自己。
缺点是注册注销逻辑与服务的业务逻辑耦合在一起,如果服务使用不同语言开发,那需要适配多套服务注册逻辑。

代理注册

代理注册有一个单独的代理服务负责注册与注销,当服务提供者启动后以某种方式通知代理服务,然后代理服务负责向注册中心发起注册工作。
缺点是多引用了一个代理服务,并且代理服务要保持高可用状态。

服务发现

客户端发现

客户端负责向注册中心查询可用服务地址,获取到所有可用的实例地址列表后客户端根据负载均衡算法选择一个实例发起请求调用。
在这种方法下,客户端可以控制负载均衡算法,但缺点是获取实例地址、负载均衡等逻辑与服务的业务逻辑耦合在一起,如果服务发现或者负载均衡算法有变化,就需要重新上线。

代理发现

代理发现是指新增一个路由服务负责服务发现获取可用的实例列表,服务消费者如果需要调用服务A的一个实例可用直接将请求发往路由服务,路由服务根据配置好的负载均衡算法从可用的实例列表中选择一个实例将请求转发过去即可,如果实例不可用,路由服务还可以自行重试,服务提供者完全不用感知。

心跳机制

如果服务有多个实例,其中一个实例出现宕机,注册中心可以实时感应到,并且将该实例信息从列表中移出,也称为摘机。
摘机常通过心跳检测实现,分为主动和被动两种方式。
被动检测是指服务主动向注册中心发送心跳信息,时间间隔可自定义,注册中心如果在3个周期内没有收到实例的心跳信息,就会将该实例从列表中移出。
主动检测是指注册中心主动发起,每隔几秒就给所有列表中的服务实例发送心跳检测信息,如果多个周期内未发送成功或未收到回复就会主动移除该实例。

常见的服务注册与发现组件

常用的服务注册与发现有Eureka、zookeeper,consul,etcd等
在这里插入图片描述
以上总结自三歪的文章