Краткий перевод статьи Building DigitalOcean’s API gateway — Maurício Linhares’ ramblings

27.01.2021

Всем привет. Сегодня я прочитал статью от Maurício Linhares. С одной стороны, она меня заинтересовала, с другой — близка по духу. Поэтому я решил кратко её законспектировать.

Предпосылки для появления Gateway

1. Монолит на Рубях Уже реализованы все базовые инфра штуки — аутентификация, обработка ошибок, тротлинг, фича флаги.
2. Растёт число команд и инженеров.
3. Хочется чего-то нового — go/python.

Возможные решения проблем

1. Service mesh — 6 лет назад не было продакшен реди.
2. Вынести всю инфра логику в отдельные библиотеки, которые написать под каждый язык. Нет времени на разработку.
3. Заиспользовать какую-нибудь готовую платформу, типа Finagle от твиттера — не подходит под Руби стек.
4. Gateway, который as is проксирует все запросы в сервисы организации. Он инкапсулирует в себе всю инфра логику.

Выбранное решение

• Подошел только Gateway.

Реализация

1. Выбираем HTTP для транспорта. Это просто, с этим сможет работать любой язык программирования.
2. Продумываем архитектуру. Хотим Self managed сервис, чтобы команды могли сами управлять роутингом. Также хотим возможность Pre/Post фильтров для запросов. Сами запросы никак не трогаем. Анализируем только специальные HTTP заголовки.
3. Делаем прототип с фильтром аутентификации. Пускаем в него продакшен трафик, без использования результата. Сравниваем результаты от Gateway и Монолита — правим баги в рассхождениях.
4. Сложные фильтры — отдельные сервисы, с которыми gateway общается. Это упрощает кодобазу gw.
5. Оборачиваем существующий Ruby монолит в виде gRPC, в который ходит Gateway, если нужна существующая логика.
6. Для управления роутингами строим отдельный сервис (изначально клиенты ходили напрямую в Консул). В сервис вставляем проверки и валидации. Это улучшает developer experience.
7. Все клиентские сервисы не общаются на прямую с Gateway. Пишется небольшая библиотека — SDK, которая встраивается в каждый сервис и реализует нужную для GW логику.

Выводы

1. Хорошая инфра команда должна быть помощником разрабов, не быть Хранителем своих сервисов, на которые нельзя дышать.
2. Для внедрения новой Инфра функциональности нужно предоставлять хорошую документаци, примеры. Нужно помнить про Ux.
3. Gateway — единая точка отказа. Нужно тестировать всё очень тщательно. Нужно показать всем, что вы — надежная инфра, и на вас можно положиться.
4. Не заставляйте разрабов пользоваться вашей новой инфой. Они должны мочь пользоваться старыми подходами, но сами захотеть смигрировать на ваше новое решение.

Категории: Программирование