Я надеюсь, что у кого-то здесь есть немного больше информации о внутренней работе API-шлюза Amazon AWS, чтобы помочь мне объяснить странное поведение. Чтобы установить сцену, позвольте мне описать инфраструктуру в действии (это немного упрощено, но ясно объясняет проблему).
1) Входящие запросы попадают в шлюз API, который запускает Lambda Authorizer, который проверяет различные вещи в нашей системе, чтобы убедиться, что запрос может продолжаться. Если это может продолжаться ... 2) Запрос передается (с использованием метода интеграции HTTP_PROXY) через балансировщик нагрузки приложения, а затем на экземпляр ECS Fargate (с использованием маршрутизации на основе пути), который выполняет одну из наших. NET основных служб. 3) Ответ от ECS передается обратно через шлюз к вызывающей стороне.
Наши. NET Базовые сервисы имеют экземпляр DbContext в пределах области видимости, поэтому он длится в течение всего срока действия запроса и не дольше.
Я видел странное поведение, которое предполагает, что соединения между шлюзом и бэкэнд-сервисом НЕ закрываются, как только запрос завершается. Я выполнил следующий тест, чтобы попытаться понять то, что я знаю до сих пор:
1) Попадание в конечную точку шлюза 10 раз (синхронно). Это приводит к 10 наблюдаемым соединениям с базой данных (с использованием SHOW STATUS LIKE '%connect%; и соблюдению значения threads_connected), которые остаются в состоянии CONNECTED после завершения моего HTTP-запроса (они, кажется, живут в течение 5-6 минут, но там не появляются быть точным порогом) 2) Запустите точно такой же тест, но вместо того, чтобы поразить шлюз, нажмите непосредственно на балансировщик нагрузки. Это не приводит к тому, что после завершения HTTP-запросов остаются какие-либо соединения.
Это приводит меня к мысли, что происходит одна из двух вещей: 1) Шлюз API НЕ закрывает соединения с URL-адресом прокси, как только запрос завершается ИЛИ 2) Балансировщик нагрузки НЕ закрывает соединения с внутренними службами, как только запрос завершается. У ALB есть настройка конфигурации времени простоя, которая в настоящее время установлена на 60 с. Я не считаю, что это является проблемой, поскольку в некоторых случаях я вижу, что соединения с базой данных работают в течение более 5 минут.
Я думаю, что это более вероятный вариант 1, но я ничего не вижу в документации, которая объясняет это поведение. У кого-нибудь есть идеи, что здесь может происходить, или кто-то видел такое же поведение?