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

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

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

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

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

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

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

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

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

Ribbon的解決方案

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

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

Spring Cloud的解決方案

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

Java Chassis的解決方案

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

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

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

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

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

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

最新評論