Статьи

Spring Cloud Rest Client с основами ленты Netflix

В предыдущем посте в блоге я рассмотрел различные варианты REST-клиента в мире Spring Cloud . Все параметры охватывают компонент Netflix OSS, называемый Ribbon, который управляет аспектами, связанными с распределением нагрузки между вызовами между различными экземплярами, размещающими службу, обработкой отказов, тайм-аутов и т. Д. Здесь я расскажу о нескольких способах настройки поведения базовых компонентов Ribbon, когда используется с Spring Cloud и дополните его более обширными настройками.

Создание клиента REST

Напомним, сначала рассмотрим случай, когда нужно вызвать простой сервис:

Типичный способ сделать этот вызов с помощью Spring — это вставить в RestTemplate и использовать его для выполнения этого вызова следующим образом:

public class RestTemplateBasedPongClient implements PongClient {

  @Autowired
  private RestTemplate restTemplate;

  @Override
  public MessageAcknowledgement sendMessage(Message message) {
    String pongServiceUrl = "http://serviceurl/message";
    HttpEntity<Message> requestEntity = new HttpEntity<>(message);
    ResponseEntity<MessageAcknowledgement> response =  this.restTemplate.exchange(pongServiceUrl, HttpMethod.POST, requestEntity, MessageAcknowledgement.class, Maps.newHashMap());
    return response.getBody();
  }
}

Здесь нет ничего особенного. Однако при использовании Spring Cloud один и тот же код ведет себя по-разному, теперь RestTemplate внутренне использует библиотеки ленты Netflix OSS для выполнения вызова. Это помогает, поскольку типичный поток вызовов состоит в том, чтобы сначала найти экземпляры, выполняющие службу, а затем распределить нагрузки между вызовами между экземплярами и поддерживать это состояние.

REST-клиент с лентой

Позвольте мне сделать небольшое отступление, чтобы коснуться ленты. В ленте используется абстракция, называемая «Именованный клиент», для управления поведением вызова удаленной службы — имя, под которым служба зарегистрирована в Eureka, время ожидания для вызовов службы, сколько повторных попыток в службе. случаи сбоев и т. д. Они указываются в файлах конфигурации, и записи, как правило, располагаются в этих строках. Обратите внимание, что здесь «Именованный клиент» — это «samplepong», а свойства имеют префикс:

samplepong.ribbon.MaxAutoRetries=2
samplepong.ribbon.MaxAutoRetriesNextServer=2
samplepong.ribbon.OkToRetryOnAllOperations=true
samplepong.ribbon.ServerListRefreshInterval=2000
samplepong.ribbon.ConnectTimeout=5000
samplepong.ribbon.ReadTimeout=90000
samplepong.ribbon.EnableZoneAffinity=false
samplepong.ribbon.DeploymentContextBasedVipAddresses=sample-pong
samplepong.ribbon.NIWSServerListClassName=com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList

Возвращаясь к Spring Cloud, он очень умно поддерживает концепцию «именованного клиента» через имя хоста Url, поэтому вызов RestTemplate теперь будет выглядеть так:

ResponseEntity<MessageAcknowledgement> response =  this.restTemplate.exchange("http://samplepong/message", HttpMethod.POST, requestEntity, MessageAcknowledgement.class, Maps.newHashMap());

«Samplepong» в URL-адресе — это «именованный клиент», и любую настройку поведения базовой ленты можно выполнить, указав свойства с помощью этого префикса. Поскольку это приложения Spring Cloud, свойства могут быть точно определены в формате yaml по следующим строкам:

samplepong:
  ribbon:
    DeploymentContextBasedVipAddresses: sample-pong
    ReadTimeout: 5000
    MaxAutoRetries: 2

Вывод

Это охватывает основы того, как Spring Cloud абстрагирует базовые библиотеки Ribbon, чтобы обеспечить интуитивно понятный интерфейс для выполнения вызовов удаленных служб в облачной среде. Я рассмотрел некоторые детали некоторых настроек, о которых я расскажу в новом посте. Вот мое репозиторий GitHub с кодом, который я использовал для этой статьи.