写点什么

Java Chassis 3 技术解密:注册中心分区隔离

  • 2024-01-16
    广东
  • 本文字数:2188 字

    阅读完需:约 7 分钟

注册中心负责实例的注册和发现,对微服务可靠运行起到举足轻重的作用。实例变更感知周期是注册中心最重要的技术指标之一。感知周期代表提供者的实例注册或者下线后,消费者感知实例注册或者下线的周期。影响实例变更感知周期的技术因素有很多。

  • 数据一致性。一致性指实例在注册中心的一个节点注册,从注册中心的不同节点能否同时读取到实例的注册信息。这个技术因素对于实例变更感知周期有一定影响,比如最终一致性的感知速度会慢,强一致性的感知速度会快。但多数场景,这个技术指标不是核心因素。

  • 变更通知机制。变更通知机制指消费者获取最新实例列表的方式,通常有几种方式:定期 Pull 的方式,消费者周期性的从注册中心查询实例列表;注册中心 Push 的方式,注册中心通过长连接、WebSocket 等协议,将实例变化通知消费者。定期 Pull 的方式感知周期相对较长,工作机制比较可靠,容错效率高,对于网络要求低,更加安全;注册中心 Push 的方式感知周期很短,容易出现事件错乱或者堆积,对于网络规划有一定要求。

  • 注册中心检测实例状态的方式。注册中心检测实例状态的方式表示如何判断实例的状态是正常还是异常。比如 Service Center 需要实例定期的发送心跳,如果在 3 个心跳周期未检测到心跳,那么认为实例异常;比如 Nacos 则根据微服务实例与注册中心的长连接状态判断实例是否异常。

此外,实例管理规模、支持元数据管理等也是注册注册中心比较常见的功能特性。比如 Java Chassis 2 要求注册中心必须支持契约的注册和管理。

Java Chassis 3 的设计目标之一,就是降低对于注册中心功能的依赖,能够支持尽可能多的注册中心,而不降低微服务自身的可靠性。 在描述 Java Chassis 3 的实例管理机制之前,先讨论一个典型的问题:注册中心分区隔离。

注册中心分区隔离是指如下场景:


微服务提供者与注册中心之间的网络发生故障,而服务消费者与注册中心之间的网络是正常的,即产生分区隔离。在发生分区隔离的场景下,现有的保活机制都会认为微服务提供者下线,进而导致微服务消费者访问微服务提供者出现大规模失败。分区隔离通常会发生在注册中心在多 AZ 部署/容灾的场景,微服务提供者和微服务消费者连接的是不同 AZ 的注册中心实例。在微服务提供者和消费者跨 AZ 部署的时候,也可能发生。

注册中心分区隔离故障会造成大面积的应用调用失败,是注册中心有关故障中,最严重的故障之一。

  • Ribbon 的解决方案

Ribbon 在客户端提供了 IPing 接口来检测实例故障,以检测注册中心错误下线实例,而实例实际可以工作的场景。 该机制在多数场景工作良好,然而在容器场景下,可能长期保留错误的实例。因为微服务提供者不是由于分区隔离错误,而是重启的场景下,如果原来的端口被其他服务占用,则会导致微服务消费者始终保留错误的实例。

public interface IPing {    boolean isAlive(Server server);}
复制代码
  • Spring Cloud 的解决方案

Spring Cloud 的机制和 Ribbon 类似,提供了 HealthCheckServiceInstanceListSupplier ,并允许开发者定义实例监控状态检测方式。

  • Java Chassis 的解决方案

Java Chassis 结合实例是否在注册中心查询到(History)、实例状态(Status)、Ping 状态(Ping)、隔离状态(Isolation)将实例分组,并给不同的组分配不同的优先级。


在 Java Chassis 3技术解密:负载均衡选择器 中,解密了 Java Chassis 分组实例使用的机制。当出现注册中心分区隔离的情况,实例在注册中心查询不到,仍然被保留到了 History 分组,只要实例 Ping 状态正常, 这个实例仍然会被使用, 从而防止了实例被错误下线。

Java Chassis 还设计了新的 Ping 机制,解决容器场景下,可能长期保留错误的实例的问题。 Ping 机制的核心逻辑包含如下几个部分:

  • 微服务提供者向注册中心注册的时候,生成实例 ID。实例 ID 需要保证进程的每次重启,都是唯一的。

  • 微服务消费者通过 PING 消息检测微服务提供者的存活状态。PING 消息包含微服务提供者的实例 ID。

  • 微服务提供者检测 PING 消息里面的实例 ID,如果实例 ID 与自己的实例 ID 相同,则返回健康,否则返回异常。


Java Chassis 提供了新的健康检查接口:

@RestSchema(schemaId = ManagementEndpoint.NAME, schemaInterface = ManagementEndpoint.class)public class ManagementEndpointImpl implements ManagementEndpoint {  private RegistrationManager registrationManager;
@Autowired public void setRegistrationManager(RegistrationManager registrationManager) { this.registrationManager = registrationManager; } @Override public boolean health(String instanceId, String registryName) { String mySelf = registrationManager.getInstanceId(registryName); if (StringUtils.isEmpty(mySelf)) { return false; } return mySelf.equals(instanceId); }}
复制代码

Java Chassis 2 结合 Service Center 的功能设计,共同保障了注册发现的可靠性。Java Chassis 3 通过应用客户端技术,降低了对于注册中心的依赖,使得 Java Chassis 3 使用不同的注册中心都能够取得很高的可靠性。 内置的实例状态分组管理和创新的 Ping 机制设计,使得 Java Chassis 3 在注册中心分区隔离故障条件下也能稳定的工作。

客户故事:注册中心推空故障是 Nacos 的经典故障,对于系统可靠性运行产生了非常大的影响。推空故障的影响机制和分区隔离故障的影响机制类似。借助于 Java Chassis 3,能够将业务影响的时间和范围降到最低。

用户头像

公众号:华为云PaaS服务,有见面礼等你哦! 2022-09-26 加入

还未添加个人简介

评论

发布
暂无评论
Java Chassis 3技术解密:注册中心分区隔离_云计算_华为云PaaS服务小智_InfoQ写作社区