如果有遗漏,评论区告诉我进行补充
面试官: Eureka Server和Eureka Client关系?
我回答:
在微服务架构中，Eureka作为Netflix开源的服务发现组件，由Eureka Server（服务端）和Eureka Client（客户端）两大部分组成。这两者通过紧密协作实现服务的注册、发现与健康管理，是确保微服务间通信顺畅的关键。以下是对Eureka Server和Eureka Client关系的综合解析：
核心角色与职责
Eureka Server（服务注册中心）
- 职责 ：
- 维护全局服务注册表，记录所有微服务实例的元数据。
- 提供查询接口，让客户端可以拉取服务实例列表。
- 监控服务实例健康状态，自动移除失效节点。
- 关键特性 ：
- 支持高可用集群配置，避免单点故障。
- 自我保护机制在网络分区时防止误删有效服务实例。
- 数据同步功能保证多个Server之间的信息一致性。
Eureka Client（服务提供者/消费者）
- 职责 ：
- 作为服务提供者，启动时向Eureka Server注册自身，并定期续约保持活跃状态。
- 作为服务消费者，从Eureka Server获取服务列表，并基于负载均衡策略选择服务实例进行调用。
- 关键行为 ：
- 注册：启动时发送包含实例元数据的请求到Eureka Server。
- 续约：默认每30秒发送一次心跳以维持租约。
- 下线：关闭时通知Eureka Server移除其注册信息。
- 缓存：本地缓存服务列表，减少对Eureka Server的依赖。
交互流程详解
服务注册
- 当Client启动时，会向配置的Eureka Server发送注册请求，提交必要的实例信息。
- Server处理后将这些信息存入注册表，并同步至其他Server节点。
- Client本地缓存注册表副本，降低后续查询的压力。
服务发现
- Client定期向Server发起请求获取最新的服务列表。
- 结合Ribbon或Spring Cloud LoadBalancer等工具，根据特定策略选择服务实例进行调用。
- 在遇到不可用实例时，能够自动尝试其他实例以实现故障转移。
心跳与租约管理
- 客户端每30秒发送一次心跳给Server，Server据此更新最后的心跳时间。
- 若90秒内未收到某实例的心跳，则将其标记为可疑并最终从注册表中移除。
- 自我保护模式在网络不稳定时保留过期实例，防止因网络问题导致的服务不可用。
高可用与容错设计
- Server集群：多个Server互相注册形成对等网络，确保注册表的一致性和系统的高可用性。
- Client多地址配置：支持同时向多个Server注册和查询，增强系统的健壮性。
- 本地缓存：即使Server暂时不可访问，Client也能依靠本地缓存继续工作。
对比与适用场景
相较于Consul和Zookeeper，Eureka更注重高可用性（AP模型），适用于允许短暂不一致的微服务场景；而Consul和Zookeeper更适合需要强一致性的应用。
面试常见问题解答
- 自我保护机制的作用：在网络分区或不稳定情况下，防止Eureka Server错误地将健康服务标记为不可用。
- Client如何选择服务实例：依据本地缓存的服务列表，使用如轮询、随机等负载均衡策略选择健康的实例。
- Eureka与Zookeeper的区别：主要在于Eureka采用AP模型强调可用性，而Zookeeper侧重于CP模型追求一致性。
- 如何调整心跳间隔 ：可以通过修改
eureka.instance.lease-renewal-interval-in-seconds参数来调整，默认值为30秒。
总结来说，Eureka Server和Eureka Client共同构建了微服务架构中的服务治理基础，实现了动态的服务注册、发现以及有效的健康管理。理解它们的工作原理及相互作用对于深入掌握微服务架构至关重要。在面试准备过程中，除了熟悉上述知识点外，还需结合实际应用场景加深对这些概念的理解。