API-шлюз не подключен из-за медленного микро-сервиса

Question

У меня есть API-шлюз G, который соединяется с несколькими службами S1, S2 ... и т. Д.

Схема трафика настолько уникальна, что в определенные моменты я получаю всплеск трафика (10M req / min), когда каждый пытается получить доступ к контенту с S1. Поэтому S1 начинает немного замедляться, из-за чего мой шлюз G начинает использовать все свои сокетные соединения при соединении с S1 и теперь не может больше соединяться с другими службами.

Пользователи, которые пытаются получить доступ к другим службам (длинный хвост), таким как S2, которые важны для нашего бизнеса, не могут получить к ним доступ, поскольку G не имеет доступных сокетов.

То, что мы пытались -

1. Масштабирующий шлюз API: Это хорошо как временное исправление, но становится действительно трудно предсказать всплеск трафика и значительно увеличивает затраты с нашей стороны.

2. Увеличение сокетов: мы увеличили этот параметр на наших серверах.

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

UPDATE:

1. Наш стек в основном Node.js

Answer 1

Это распространенная проблема, когда одна из служб получает больше нагрузки, чем другие службы. Вы можете использовать шаблон облака под названием Bulk Head на вашем шлюзе. В этом паттерне вы в основном разделяете ресурсы (например, пул соединений) между всеми сервисами, поэтому ни один сервис не может использовать все ресурсы. Я не уверен, какой технический стек вы используете, поэтому вам нужно найти, какая библиотека вам подойдет, например. Ядро DotNet мы используем Полли. Еще один - Hystrix.

Перегородка