Java Chassis 3技術(shù)解密：注冊中心分區(qū)隔離

注冊中心負(fù)責(zé)實例的注冊和發(fā)現(xiàn)，對微服務(wù)可靠運行起到舉足輕重的作用。實例變更感知周期是注冊中心最重要的技術(shù)指標(biāo)之一。感知周期代表提供者的實例注冊或者下線后，消費者感知實例注冊或者下線的周期。影響實例變更感知周期的技術(shù)因素有很多。

• 數(shù)據(jù)一致性。一致性指實例在注冊中心的一個節(jié)點注冊，從注冊中心的不同節(jié)點能否同時讀取到實例的注冊信息。這個技術(shù)因素對于實例變更感知周期有一定影響，比如最終一致性的感知速度會慢，強一致性的感知速度會快。但多數(shù)場景，這個技術(shù)指標(biāo)不是核心因素。
• 變更通知機制。變更通知機制指消費者獲取最新實例列表的方式，通常有幾種方式：定期Pull的方式，消費者周期性的從注冊中心查詢實例列表；注冊中心Push的方式，注冊中心通過長連接、WebSocket等協(xié)議，將實例變化通知消費者。定期Pull的方式感知周期相對較長，工作機制比較可靠，容錯效率高，對于網(wǎng)絡(luò)要求低，更加安全；注冊中心Push的方式感知周期很短，容易出現(xiàn)事件錯亂或者堆積，對于網(wǎng)絡(luò)規(guī)劃有一定要求。
• 注冊中心檢測實例狀態(tài)的方式。注冊中心檢測實例狀態(tài)的方式表示如何判斷實例的狀態(tài)是正常還是異常。比如Service Center需要實例定期的發(fā)送心跳，如果在3個心跳周期未檢測到心跳，那么認(rèn)為實例異常；比如Nacos則根據(jù)微服務(wù)實例與注冊中心的長連接狀態(tài)判斷實例是否異常。

此外，實例管理規(guī)模、支持元數(shù)據(jù)管理等也是注冊注冊中心比較常見的功能特性。比如Java Chassis 2要求注冊中心必須支持契約的注冊和管理。

Java Chassis 3的設(shè)計目標(biāo)之一，就是降低對于注冊中心功能的依賴，能夠支持盡可能多的注冊中心，而不降低微服務(wù)自身的可靠性。 在描述 Java Chassis 3的實例管理機制之前，先討論一個典型的問題：注冊中心分區(qū)隔離。

注冊中心分區(qū)隔離是指如下場景

微服務(wù)提供者與注冊中心之間的網(wǎng)絡(luò)發(fā)生故障，而服務(wù)消費者與注冊中心之間的網(wǎng)絡(luò)是正常的，即產(chǎn)生分區(qū)隔離。在發(fā)生分區(qū)隔離的場景下，現(xiàn)有的保活機制都會認(rèn)為微服務(wù)提供者下線，進而導(dǎo)致微服務(wù)消費者訪問微服務(wù)提供者出現(xiàn)大規(guī)模失敗。分區(qū)隔離通常會發(fā)生在注冊中心在多AZ部署/容災(zāi)的場景，微服務(wù)提供者和微服務(wù)消費者連接的是不同AZ的注冊中心實例。在微服務(wù)提供者和消費者跨AZ部署的時候，也可能發(fā)生。

注冊中心分區(qū)隔離故障會造成大面積的應(yīng)用調(diào)用失敗，是注冊中心有關(guān)故障中，最嚴(yán)重的故障之一。

注冊中心有關(guān)故障解決方案

Ribbon的解決方案

Ribbon在客戶端提供了 IPing 接口來檢測實例故障，以檢測注冊中心錯誤下線實例，而實例實際可以工作的場景。 該機制在多數(shù)場景工作良好，然而在容器場景下，可能長期保留錯誤的實例。因為微服務(wù)提供者不是由于分區(qū)隔離錯誤，而是重啟的場景下，如果原來的端口被其他服務(wù)占用，則會導(dǎo)致微服務(wù)消費者始終保留錯誤的實例。

public interface IPing {
    boolean isAlive(Server server);
}

Spring Cloud的解決方案

Spring Cloud的機制和Ribbon類似，提供了 HealthCheckServiceInstanceListSupplier ，并允許開發(fā)者定義實例監(jiān)控狀態(tài)檢測方式。

Java Chassis的解決方案

Java Chassis結(jié)合實例是否在注冊中心查詢到(History)、實例狀態(tài)(Status)、Ping狀態(tài)(Ping)、隔離狀態(tài)（Isolation）將實例分組，并給不同的組分配不同的優(yōu)先級。

在 Java Chassis 3技術(shù)解密：負(fù)載均衡選擇器 中，解密了Java Chassis分組實例使用的機制。當(dāng)出現(xiàn)注冊中心分區(qū)隔離的情況，實例在注冊中心查詢不到，仍然被保留到了 History 分組，只要實例 Ping 狀態(tài)正常， 這個實例仍然會被使用， 從而防止了實例被錯誤下線。

Java Chassis還設(shè)計了新的Ping機制，解決容器場景下，可能長期保留錯誤的實例的問題。 Ping機制的核心邏輯包含如下幾個部分：

• 微服務(wù)提供者向注冊中心注冊的時候，生成實例ID。實例ID需要保證進程的每次重啟，都是唯一的。
• 微服務(wù)消費者通過PING消息檢測微服務(wù)提供者的存活狀態(tài)。PING消息包含微服務(wù)提供者的實例ID。
• 微服務(wù)提供者檢測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結(jié)合Service Center的功能設(shè)計，共同保障了注冊發(fā)現(xiàn)的可靠性。Java Chassis 3通過應(yīng)用客戶端技術(shù)，降低了對于注冊中心的依賴，使得 Java Chassis 3使用不同的注冊中心都能夠取得很高的可靠性。 內(nèi)置的實例狀態(tài)分組管理和創(chuàng)新的Ping機制設(shè)計，使得 Java Chassis 3在注冊中心分區(qū)隔離故障條件下也能穩(wěn)定的工作。

客戶故事：注冊中心推空故障是 Nacos 的經(jīng)典故障，對于系統(tǒng)可靠性運行產(chǎn)生了非常大的影響。推空故障的影響機制和分區(qū)隔離故障的影響機制類似。借助于Java Chassis 3，能夠?qū)I(yè)務(wù)影響的時間和范圍降到最低。

以上就是Java Chassis3注冊中心分區(qū)隔離技術(shù)解密的詳細(xì)內(nèi)容，更多關(guān)于Java Chassis3注冊中心分區(qū)隔離的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論