Почему мой RPC службы приложений Service Fabric Inter занимает 2 минуты? - PullRequest
0 голосов
/ 08 февраля 2019

У меня есть два приложения (скажем, app1 и app2) в моем кластере.Оба этих приложения имеют службу без сохранения состояния в качестве шлюза для подключения к внутренним службам с отслеживанием состояния.Я пытаюсь совершать звонки между этими двумя приложениями.Я установил обратный прокси-сервис Служба от app1 к app2.

URL к app2 из app1: http://localhost:19081/app2/stateless_app2_service/api/values

Вышеописанный сценарий отлично работает в локальном кластере.Но при развертывании в кластере Azure для доступа к app2 требуется 2 минуты.

Может ли кто-нибудь помочь мне указать, что я делаю неправильно, что и вызвало такую ​​задержку?Это связано с какой-либо из конфигураций кластера?Я включил порт 19081 для обратного прокси-сервера в ARM при создании кластера.

Ниже представлен журнал событий для вызовов, выполняемых через службы в кластере Azure.Звонок получен через 2 минуты.Это происходит с каждым вызовом, который включает взаимодействие между приложениями в кластере Azure.

enter image description here

Код:

Stateless_app1_service

protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
        {
            return new ServiceInstanceListener[]
            {
                new ServiceInstanceListener(serviceContext =>
                    new KestrelCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) =>
                    {
                        ServiceEventSource.Current.ServiceMessage(serviceContext, $"Starting Kestrel on {url}");

                        return new WebHostBuilder()
                                    .UseKestrel()
                                    .ConfigureAppConfiguration((builderContext, config) =>
                                    {
                                       config.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true);
                                    })
                                    .ConfigureServices(
                                        services => services
                                            .AddSingleton<HttpClient>(new HttpClient())
                                            .AddSingleton<StatelessServiceContext>(serviceContext)
                                            .AddSingleton<ILogger>(GenerateLogger()))                                        
                                    .UseContentRoot(Directory.GetCurrentDirectory())                                    
                                    .UseStartup<Startup>()
                                    .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
                                    .UseUrls(url)
                                    .Build();
                    }))
            };
        }

Посылка вызова:

_logger.TrackEvent("SF - Call made to other application");                
var response2 = await _httpClient.GetAsync($"{_reverseProxy}/{_appNameConnectors}/{_apiNameConnectors}/api/Values");
_logger.TrackEvent("SF- RPC - Call successfully finished!");

1 Ответ

0 голосов
/ 08 февраля 2019

Без трассировки на сетевом уровне будет немного сложно угадать проблему.

Я бы порекомендовал вам проверить прямое подключение к услуге, используя имя днс (если включено), как http://service1.application1

То есть:

Uri uri = new Uri("http://service1.application1:8080/api/values");
HttpClient client = new HttpClient();
var response = await client.GetAsync(uri);

если это решит проблему, мы можем определить проблему, связанную с прокси, если не решит, вам нужно будет исследовать сетевую связь или:

  • поставить оба наТот же узел в Azure и проверить связь
  • проверить правила брандмауэра
  • Антивирус
  • Проверить, не связана ли проблема с конечной точкой, принимающей вызов
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...