Расхождение во времени для http-вызовов между микросервисами, находящимися под нагрузкой - PullRequest
0 голосов
/ 13 октября 2018

Микросервисы Asp.Net Core в Docker / Kubernetes расходятся во мнениях относительно продолжительности межсервисных вызовов между вызывающим и вызываемым абонентами.

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

Отметки времени указывают, что промежуток времени может быть либо до , либо после вызываемый абонент сообщил, что его ответ завершен.

Примеры журналов (числа с расхождением в реальном времени)

ServiceB: [2018-10-11T22:41:41.374Z] S2S request complete to ServiceA, Duration: 11644
ServiceA: [2018-10-11T22:41:29.732Z] Request complete, Duration: 5

Caller Timing (общий класс для всех вызовов S2S)

var timer = Stopwatch.StartNew();
var response = await _httpClientFactory.CreateClient().SendAsync(request);
timer.Stop();
Logger.Info($"S2S request complete to {service}, Duration: {timer.EllapsedMilliseconds}");

Callee Timing (пользовательское промежуточное ПО Asp.Net)

var timer = Stopwatch.StartNew();
await _next(context);
timer.Stop();
Logger.Info($"Request complete, Duration: {timer.EllapsedMilliseconds}");

Это промежуточное ПОзарегистрирован как почти первый в конвейере (второй после только промежуточного программного обеспечения ActivityId / TraceId для корреляции журналов).

Действия по устранению неполадок

  • Невозможно воспроизвестипроблема на компьютере разработчика Windows
  • Контролируемый процессор, память, счетчик потоков, сборщик мусора, открытые дескрипторы (все на разумных уровнях)
  • Скорректированные спецификации процессора K8s и запрос / ограничение памяти (различные уровни)с некоторым эффектом, но не устраняет проблему)
  • Включен GC сервера с переменной среды: COMPlus_gcServer = 1
  • Проблема возникает в службах, которые находятся в пределах ресурсов и не нуждаются в автоматическом масштабировании
  • Изменен на новый сокетный транспорт Kestrel (вместо libuv)
  • Изменен на новый сокет .Net Core 2.1HttpHandler

Топология системы

Asp.Net Core 2.1 с автономным размещением Kestrel
.Net Core 2.1.5, среда выполнения
Docker / Kubernetes 1.10.5
K8s Аддоны: kube-proxy, weave, etcd, SkyDNS
AWS c5.4xlarge

Обновления

  1. Выяснилось, что промежуток времени может быть до или после того, как вызываемый абонент начинает / завершает

1 Ответ

0 голосов
/ 18 октября 2018

В этом случае эта проблема была исправлена ​​путем удаления предела CPU спецификации k8s.

Мониторинг метрики container_cpu_cfs_throttled_seconds_total обнаружил, что один из сервисных контейнеров очень часто получал паузы .Эти паузы были в основном на стороне вызывающей стороны вызовов S2S.Это увеличило истекшее время, сообщаемое вызывающим абонентом.

Снятие ограничения ЦП в спецификации k8s не позволяет k8s передавать параметры докера --cpu-quota и --cpu-period .Именно это контролирует контейнерные паузы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...