在面试中,关于注册中心的技术如Nacos、Eureka、SOFARegistry的考察,主要会围绕以下几个方面展开:
-
基本概念与功能
- 询问对Nacos、Eureka、SOFARegistry的基本理解和它们在微服务架构中的作用。
- 探讨这些注册中心如何支持服务的动态注册与发现,以及它们提供的额外功能,如配置管理、服务治理等。
-
AP与CP模式
- 对AP(可用性与分区容错性) 和 CP(一致性与分区容错性) 模式的理解,以及这些注册中心如何在这两种模式之间进行选择。
- 探讨在不同模式下,注册中心如何保证服务的可用性和数据一致性。
-
服务注册与发现
- 服务注册与发现的原理,包括服务如何注册到注册中心以及服务消费者如何发现并调用这些服务。
- 探讨注册中心如何处理服务的动态变化,如服务的增删改等操作。
-
配置管理
- 注册中心如何支持应用的动态配置管理,包括配置的动态更新和回滚等。
- 探讨配置管理在微服务架构中的重要性以及注册中心如何提供这一功能。
-
集群与扩展性
- 关于注册中心的集群部署和扩展性方面的考虑。
- 探讨在分布式环境下,注册中心如何保证服务的可用性和扩展性。
-
性能与稳定性
- 在面对大量服务注册与发现请求时,注册中心如何保证性能和稳定性。
- 探讨在高并发场景下,注册中心的技术和策略如何应对挑战。
-
自我保护机制
- 询问对注册中心自我保护机制的理解,以及它在确保服务可用性方面的作用。
- 探讨在面对网络分区等异常情况时,注册中心如何通过自我保护机制来保护服务的可用性。
/
什么是注册中心?
注册中心简单来说是为了解决分布式场景下,服务之间的相互发现问题
如下图,服务A想要调用服务B,需要知道B的地址,如何解决这个问题?
一般来说,分为2点。
- 服务发现:可以有一个中心化的组件或者说存储,它承载了所有服务的地址,同时提供了一个可供查询和订阅的能力,服务的消费方可以通过和这个中心化的组件交互,获得服务提供方的地址列表。
- 服务注册:同样是上文中的中心化组件,但是这个时的服务信息可以有两种措施
- 服务连接注册中心,同时上报自身的服务以及元数据(也是本文讲述的重点)
- 有一个集中的控制面(control plane)将用户定义的服务和IP的映射写入注册中心,例如: AWS 的 cloudMap
调用流程
如上图,就是一种目前主流的注册中心模式,Nacos 和 SOFARegistry 都是这种模式
- 服务A、服务B通过SDK或者Rest将自身的服务信息上报给注册中心
- 服务A需要调用服务B时,就对注册中心发起请求,拉取服务B相关的服务IP列表以及信息。
- 在获取到服务B的列表后,就可以通过自身定义的负载均衡算法访问服务B
心跳
心跳是注册中心用于解决服务不可用时,及时拉出服务,降低影响的默认方式,如下图
- 服务B的一个节点断网或者hang住,引发心跳超时,或者宕机、断链直接引发心跳失败。
- 注册中心把问题节点从自身的存储中拉出(这里的实现有点事直接删除、有的是标记为不健康)
- 服务A收到注册中心的通知,获取服务B的最新列表
Dubbo 注册中心
下面通过Dubbo的例子,来看一下注册中心是如何使用的。首先,在dubbo2.7 和3.0的配置略有不同,但是都是简单易懂的。
dubbo2.7
<!--提供方应用信息,用于计算依赖关系-->
<dubbo:application name ="hello-world-app"/>
<!--使用multicast广播注册中心,暴露服务地址-->
<dubbo:registry address="multicast:234.5.6.7:1234"/>
<!--用dubbo协议在20880端口暴露服务-->
<dubbo:protocal name ="dubbo" prot="20880"/>
<!--声明需要暴露的服务接口-->
<dubbo:service interface ="org.apache.dubbo.demo.DemoService" ref="demoService"/>
<!--和本地bean一样实现服务-->
<bean id ="demoService" class="org.apache.dubbo.demo.DemoServiceImpl"/>
dubbo3.0
dubbo.application.name=demo-app
dubbo.protocol.name=dubbo
dubbo.registry.address=zookeeper://127.0.0.1:2181
在RPC客户端只需要配置一个注册中心的地址即可,地址中包含了基础三元素
- protocol (协议类型) 比如zookeeper
- host
- prot
基于上述配置,dubbo的注册流程如下图所示
- 服务的生产方通过Dubbo 客户端向注册中心(Registry)发起注册行为(register)
- 服务的消费方通过Dubbo的客户端订阅信息(subscribe)
- 注册中心通过通知的方式,下发服务列表给服务消费方
通过上文的,可以归纳下注册中心的本质 存储 + 可运维
- 一方面注册中心需要存储能力记录服务的信息
- 另一方面,注册中心在实践过程中,需要提供必需的运维手段,比如关闭某一服务的流量