Изменения

'''Алексей Коновкин из Nexign. API Gateway'''. Есть много стандартных, и Мегафон выбирал. Пока выбирал — они сделали свой, вроде как прототип для осознанного выбора, а в результате именно его и взяли в продакшн. Рассказ был про функциональные задачи API Gateway, которых довольно много: хранение конфигурации, версионирование, маршрутизация с учетом работоспособности узлов, балансировка, аутентификация, авторизация, логгирование, преобразование запросов, защита и квотирование и так далее. И для каждой функции есть различные подходы, о которых рассказывали с примерами реализации в стандартных продуктах, и о своем выборе реализации, который выступал как пример. Доклад не был рекламой продукта, тем более, что отдельно они его не продают, а именно рассказом о функциях и вариантах реализации, уместных в зависимости от среды использования. Включая такие штуки, как token exchange, необходимый в гетерогенной среде со многими провайдерами токенов, используемыми разными системами, так что на интеграции токены надо подменять.

Дальше был рассказ про работу с нагрузкой. Два типа обращений: быстрый интерактив и долгие фоновые, под каждый тип — свой пул потоков, на разных ядрах, чтобы оба выполнялись и не мешали друг другу. Если потоков больше чем ядер — алгоритмы мягкого и жесткого вытеснения. Специальный случай — если поток долгих обращений простаивает, стоит временно занять паузу короткими обращениями, но при появлении длинных — вернуть к основному назначению. Еще надо не забыть оставить ядра для драйверов и другой активности ОС, а то получается, что система быстро обрабатывает сообщения, только результат не отправляется, потому что сеть не может вклиниться. И отдельное ядро-вытрезвитель для потоков-хулиганов с непредсказуемой загрузкой. Ситуация отслеживается в динамике, и тут важно запускать следующий поток watchlog по очереди на всех ядрах, чтобы он отъедал производительность равномерно, ядра оставались одинаковыми.