dusterio 13 ноя 2016 в 13:23

Простой API gateway на базе PHP и Lumen

7 мин

41K

PHP*Программирование*API*Laravel*

Туториал

+21

Комментарии 12

zcasper 13 ноя 2016 в 18:21

Мне кажется тут стоило упомянуть о ESB (Enterprise Service Bus)…

boodda 13 ноя 2016 в 22:05

интересно. у меня вопрос почему в конфигах все значения настроек надо прописывать строками, для чего это. я не хочу помнить их, пишите как константы классов. ide всегда напомнит и дополнит все что я хочу и еще и с комментариями. не пишите строки!

dusterio 14 ноя 2016 в 01:49

потому что конфиг в формате JSON? да и где там классы в конфигах? :)

webmoder 14 ноя 2016 в 09:55

Не думали реализовать проброс «Request ID» в запросах к микросервисам?

dusterio 14 ноя 2016 в 12:30

Сейчас пробрасывается User ID из токена и оригинальный IP. В принципе, очень просто добавить любые другие заголовки. А как бы Вы использовали Request ID?

webmoder 14 ноя 2016 в 13:56

Использовал бы для логирования всей цепочки запросов к микросервисам.
т.к не всегда понятно на каком этапе/микросервисе произошла ошибка. А имея идентификатор запроса инициированного на API Gateway, можно гараздо проще разобраться с проблемным местом.

это дело можно визуализировать

webmoder 14 ноя 2016 в 15:13

Скорее всего не стоит постоянно логировать каждый request. Достаточно иметь возможность проброса, который будет работать в режиме debug. Хотя это уже зависит от задач.

НЛО прилетело и опубликовало эту надпись здесь

dusterio 18 ноя 2016 в 01:20

Да, существует одна общая БД юзеров, на основе которой выдаются OAuth2 токены. В каждом запросе к микросервису есть заголовок X-User с идентификатором пользователя, то есть микросервис всегда знает, что любой запрос к нему — прошел аутентификацию. Микросервису остается сделать авторизацию основываясь на любой своей внутренней логике. Это традиционный способ для этой архитектуры — так советуют делать книги.

tzurbaev 18 ноя 2016 в 07:46

А как быть с изменениями базы? Если у меня N сервисов, которые напрямую работают с таблицей юзеров, ведь потребуется вносить изменения в каждый из них, если будут проводиться серьезные изменения в БД?

Сейчас читаю "Создание микросервисов" Сэма Ньюмана, там нет явного запрета на использование такого подхода, но довольно подробно описываются риски при использовании общей БД — в том числе и изменения структуры. Опыта в этой тематике пока что мало, поэтому для начала решил сделать так: есть основная БД приложения, в которой хранятся все данные пользователей. Микросервисы, которые тоже должны работать с юзерами, просто получают необходимые данные при регистрации пользователя и обновляют их при изменении профиля.

dusterio 18 ноя 2016 в 07:49

Сервисы не должны работать напрямую с таблицей юзеров — от API gateway передается только сам факт успешной аутентификации и немного дополнительных полей (scopes/права, ID юзера).

Если необходимо реализовать свою (для конкретного сервиса) авторизацию — традиционно нужна _отдельная_ база данных. Это основа философии — один сервис не должен задевать другой, все должно деплоиться по-отдельности без проблем.

Если данные о пользователе используются более чем 1-2 сервисами — их можно хранить в общей базе (которую можно держать «при» API gateway), если данные нужны конкретному сервису — в его местной базе.

tzurbaev 18 ноя 2016 в 09:26

Видимо я неправильно вас понял, спасибо.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время