Как вы должны справиться с auth и пользователям обмен информацией по микросервисов?

TLTR: что является хорошим способом для обмена данными между службами для Auth и пользовательской информацией независимо от местоположения сервера или используемой технологии

Я пытаюсь узнать о микросервисах, и мне немного неясно, как я должен подходить к доступу к пользовательской информации и контролировать доступ с помощью нескольких служб. Пожалуйста, дайте мне знать, если я подхожу к этому совершенно неправильно.

Например, у меня есть базовый сервис для операций Blog CRUD и сервис для загрузки и хранение изображений и видео. Я еще ничего не сделал с авторизацией или пользователями (за исключением того, что я учитываю идентификаторы пользователей, которые в конечном итоге присутствуют в моих моделях (например, в моей модели блога ObjectID для автора, комментаторов и т. д.).

Я хочу сохранить это как можно более разделенным (для целей обучения больше, чем что-либо), и в то время как в данный момент я строю все это в узле.js я надеюсь, что смогу менять местами различные технологии, такие как nginx, сервис java / go / python или другое хранилище (в настоящее время mongo, но хотел бы иметь возможность переключиться на sql в качестве опции)

Как я в настоящее время эти структурированные у меня есть оба сервиса, построенные как Express.JS apps и в настоящее время я использую node-http-proxy для прокси к экспресс-сервисам (это просто для экономии при настройке nginx на данный момент, но я не хочу зависеть от nginx).

Как я должен подойти:

  • Аутентифицированный пользователь или некоторые маршруты (например, при создании новой записи или обновление / удаление), а не при получении сообщения для чтения (в конечном итоге я хотел бы включить роли тоже)

  • Заполнение пользовательской информации, например, из идентификатора пользователя, хранящегося в блоге автора, и замена его пользовательской информацией (в одном приложении я мог бы просто использовать mongoose populate

Основная цель заключается в том, что я хотел бы сохранить Auth и пользователей в отдельных службах, которые могут быть вызваны в любой другой службе и сохранены в другой БД, например, если они были расположены на разных физических серверах.

Кто-то предложил мне сделать это с помощью HTTP/S, но есть ли лучший способ сделать это и может ли кто-нибудь указать мне на любые примеры реализации, узел.js было бы предпочтительнее, но не существенно

Это, вероятно, требует некоторого реестра службы, но я немного теряюсь в том, как это будет реализовано

1 8
node.js nginx mongodb microservices

1 ответ:

Уровень аутентификации как его собственное приложение довольно хорошо вписывается в дизайн SOA. Существует конечная точка HTTP без прямого доступа к базе данных micro-service, что является лучшей практикой SOA:

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

-- Вернер Фогельс, технический директор Amazon

Ссылка на http://martinfowler.com/microservices/

Что такое уровень аутентификации или сервис и как один сервер подтверждает, что аутентификация уже установлена? Одним из видов клиентской персистентности является HTTP-куки, который подключается строго к доменному имени, поэтому нелегко повторно использовать один и тот же куки среди нескольких доменов без явного шага аутентификации.

Если вы в состоянии передача определенного ключа или заголовка http_request может обеспечить ненавязчивую аутентификацию, этот модуль стал встроенным в ядро Nginx начиная с версии 1.5.4: http://nginx.org/en/docs/http/ngx_http_auth_request_module.html 

location /upload {
    auth_request /auth;
    ...
}

location = /auth {
    internal;
    proxy_pass http://auth_service.localhost;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;
}

Конечная точка, доступная через http://auth_service.localhost (выберите свой собственный URL) изолирован и имеет свою собственную базу данных и делает только одно-аутентифицировать пользователя или нет. Механизм может полагаться на определенный ключ или заголовок или даже IP адрес. Чтобы подавить последующий запрос, вы можете кэшировать ответ.

SOA трудно, но я рекомендую прочитать это тщательно: https://www.nginx.com/blog/introduction-to-microservices/

4