микросервисная архитектура - глобальный обмен данными

Question

У меня интересный вопрос об архитектуре микросервиса.Дело в том, что у меня есть несколько служб, которым требуется одна центральная информация о разрешении.В нашей архитектуре все микросервисы сами управляют разрешениями, но у пользователя в нашей системе может быть несколько компаний, которыми он может управлять.Почти каждый маршрут в системе нуждается в идентификаторе компании в запросе.Теоретически, пользователь X может удалить пользователя Y из определенной компании, если пользователь Y теперь пытается предпринять какие-либо действия в этой компании, ему больше нельзя это разрешать.Но любой сервис должен знать, что пользователю больше не разрешен доступ.Для обмена этими данными между всеми службами существует 3 возможных подхода:

1) Если пользователь X удаляет пользователя Y из компании, служба помещает сообщение в Q, а работник сообщает об этом всем другим службам.менять.2) Я использую Zuul в качестве теоретического API-шлюза, который API-шлюз может проверять при каждом запросе (который имеет company_id) в запросе, если пользователю даже разрешен доступ к этой компании.Но это означает, что сам API-шлюз должен будет выполнять вызов базы данных, что не очень удобно, поскольку шлюз должен быть шлюзом и ничем иным.3) Я мог бы использовать глобальное хранилище данных, которое реплицируется на каждом микросервисе, для этого я мог бы использовать, например, etcd.Каждый микросервис может проверить, разрешен ли пользователю Y доступ к компании.

Важно во всех случаях, что если пользователю Y разрешен доступ к компании, сам микросервис все еще должен проверить, разрешено ли пользователю Yопределенное действие на эту компанию.Таким образом, это сопоставление пользователя с компанией предназначено только для того, чтобы удостовериться, что пользователь вообще имеет доступ к компании.

Я не очень доволен каким-либо из этих посягательств, потому что помещение сообщения в очередь (1) означает, чтокаждая услуга должна быть проинформирована об изменении.Использование Zuul для проверки (2) также не очень практично, потому что это должен быть только шлюз.

Answer 1

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

Для этого самого случая использования, почему бы вам не попробовать маршрут авторизации.Когда пользователь входит в вашу систему, вы разрешаете ему доступ к определенной компании.Один или больше.Эта информация может быть передана в токене, и каждая служба, которая заботится об идентификаторе компании, может забрать ее и работать с ней, поскольку токены имеют ограниченное время жизни, как только userX удалит UserY из компании, последующие токены не будут иметь company_id ибудет игнорироваться.

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

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