Проблема общего доступа к порту 443 для микросервисов по умолчанию в кластере Azure Service Fabric - PullRequest
Новая
       45

Проблема общего доступа к порту 443 для микросервисов по умолчанию в кластере Azure Service Fabric

0 голосов
/ 13 декабря 2018

У нас есть Кластер, в котором развернуто несколько микросервисов, подробности следующим образом: всего 7 микросервисов, развернутых в Кластере, из которых 3 являются микросервисами без сохранения состояния и 4 являются микросервисами с контролем состояния.Реализован http.sys для предоставления защищенных конечных точек, и требуется предоставить доступ ко всем этим конечным точкам служб с портом по умолчанию 443. Чтобы различать имена псевдонимов, добавленных службами в URL.443 и доступ к этим службам с помощью URL-адресов FQDN.

Микро-службы без сохранения состояния работают нормально, как и ожидалось.

Но не могут получить доступ к микросервисам с состоянием с помощью URL-адресов FQDN.Выдает ошибку как HTTP-ошибка 503. Служба недоступна.

Если для каждой службы используются определенные порты, она работает нормально, но нам нужен доступ только через общий порт 443.

Спасибо зааванс за предложения.

1 Ответ

0 голосов
/ 13 декабря 2018

Вы не дали понять, как вы представляете эти сервисы, я предполагаю, что вы обращаетесь к ним напрямую с балансировщика нагрузки на порт 443 узла, который сервисы открывают (и совместно используют), вместо использования описанного подхода обратного прокси здесь .

Службы Stateful имеют другое поведение, которое необходимо правильно понимать при регистрации этих портов:

Службы Stateful могут размещать несколько разделов на одном хосте (процессе), дляПо этой причине каждый раздел реплики может использовать один и тот же порт.В этом случае правильный подход, описанный в документах , заключается в регистрации префикса, содержащего в нем идентификатор раздела и реплики. Если вы следовали документам, вы, вероятно, зарегистрировали службы с отслеживанием состояния, например: 

private ICommunicationListener CreateInternalListener(ServiceContext context)
{
 EndpointResourceDescription internalEndpoint = context.CodePackageActivationContext.GetEndpoint("ProcessingServiceEndpoint");
 string uriPrefix = String.Format(
        "{0}://+:{1}/{2}/{3}-{4}/",
        internalEndpoint.Protocol,
        internalEndpoint.Port,
        context.PartitionId,
        context.ReplicaOrInstanceId,
        Guid.NewGuid());

 string nodeIP = FabricRuntime.GetNodeContext().IPAddressOrFQDN;

 string uriPublished = uriPrefix.Replace("+", nodeIP);
 return new HttpCommunicationListener(uriPrefix, uriPublished, this.ProcessInternalRequest);
}

Это сделает службу доступной по URL-адресу, подобному следующему:

{scheme}://{nodeIp}:{port}/{partitionid}/{replicaid}-{guid}

Другая проблема заключается в том, что

  • Службы с сохранением состояния могут небыть доступным на всех узлах за балансировщиком нагрузки;
  • Если они есть и они разбиты на разделы, каждый раздел не будет доступен на всех узлах;
  • , если разделы есть на всех узлах,Вы также должны включить чтение вторичной реплики, иначе конечная точка не будет открыта.

По этим причинам вам следует избегать прямого предоставления сервисов с отслеживанием состояния и размещать их за прокси-сервером, как описано впервая ссылка.

...