Приветствую.

Возник вопрос: пусть есть два сервиса, первый из которых хранит структуру организации и пользователей, а второй использует данные первой для реализации приложения — почта/автоматизация/что-угодно. Есть ли какие-то best practices, описывающие как должно это всё вместе работать? То есть, например, как должны данные загружаться (и должны ли) из первого сервиса во второй, как отслеживать изменения (и информировать о них), как отслеживать целостность баз.

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

ЗЫ. Интересна именно практика, голая теория в данном случае довольно бессмысленна.

Здравствуйте, Somescout, Вы писали:

S>Приветствую.

S>Возник вопрос: пусть есть два сервиса, первый из которых хранит структуру организации и пользователей,

S>ЗЫ. Интересна именно практика, голая теория в данном случае довольно бессмысленна.

Так практика это LDAP протокол и OpenLDAP как реализация сервера который
хранит структуру организации и пользователей.

Здравствуйте, Somescout, Вы писали:

S>Приветствую.

S>Возник вопрос: пусть есть два сервиса, первый из которых хранит структуру организации и пользователей, а второй использует данные первой для реализации приложения — почта/автоматизация/что-угодно. Есть ли какие-то best practices, описывающие как должно это всё вместе работать? То есть, например, как должны данные загружаться (и должны ли) из первого сервиса во второй, как отслеживать изменения (и информировать о них), как отслеживать целостность баз.

S>То есть в принципе эти вопросы решаемы, но в первом приближении решения выглядят костылями, заставляющими задуматься о том нужно ли реализовывать всё это подобным образом в принципе.

S>ЗЫ. Интересна именно практика, голая теория в данном случае довольно бессмысленна.

Смотря для чего.
Когда-то давно писал небольшой веб-ап на этом https://docs.oracle.com/cd/E18930_01/html/821-2418/beabo.html
юзал jdbc. т.е. на весь сервер приложений может быть одна отдельная базка с пользователями, группами и ролями.
прикольно в общем-то. последнее время лепим для каждой апликухи локальных пользователей(asp.net хотя тоже можно контекст вынести).
тут должен решать архитектор исходя из реальных требований и тех. возможностей.
с клиентской стороны юзал https://grails.org/ там работа через спринг-плагин.
Вообщем, нормально. главное чтобы источник пользователей находился в серверной, а то у телекома например есть услуга — аренда стойки.
вот если им отдашь сервак, то могут и не отдать. )))

Здравствуйте, Zhendos, Вы писали:

Z>Так практика это LDAP протокол и OpenLDAP как реализация сервера который
Z>хранит структуру организации и пользователей.

Уточню: пользователи приведены для примера. Без разницы какие именно данные будут, имеется в виду как связать локальные данные с сервисом, который хранит общие.

Здравствуйте, vaa, Вы писали:

vaa>Смотря для чего.
Нормализация данных по сервисам: т.е. есть сервис, который хранит некие общие данные, и сервис который их использует, плюс хранит что-то своё — как их приавильно связать и организовать обмен и обновление данных.

vaa>Когда-то давно писал небольшой веб-ап на этом https://docs.oracle.com/cd/E18930_01/html/821-2418/beabo.html
vaa>юзал jdbc. т.е. на весь сервер приложений может быть одна отдельная базка с пользователями, группами и ролями.
vaa>прикольно в общем-то. последнее время лепим для каждой апликухи локальных пользователей(asp.net хотя тоже можно контекст вынести).
vaa>тут должен решать архитектор исходя из реальных требований и тех. возможностей.
vaa>с клиентской стороны юзал https://grails.org/ там работа через спринг-плагин.
vaa>Вообщем, нормально. главное чтобы источник пользователей находился в серверной, а то у телекома например есть услуга — аренда стойки.
vaa>вот если им отдашь сервак, то могут и не отдать. )))
Если я правильно понимаю, речь об авторизации?

Здравствуйте, Somescout, Вы писали:

Z>>Так практика это LDAP протокол и OpenLDAP как реализация сервера который
Z>>хранит структуру организации и пользователей.

S>Уточню: пользователи приведены для примера. Без разницы какие именно данные будут, имеется в виду как связать локальные данные с сервисом, который хранит общие.

В идеале никаких локальных данных не должно быть, точка истины должна быть одна — это сервис. Если тебе нужны данные, ты их запрашиваешь у него и точка.

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

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

Здравствуйте, Somescout, Вы писали:

S>Здравствуйте, vaa, Вы писали:

vaa>>Смотря для чего.
S>Нормализация данных по сервисам: т.е. есть сервис, который хранит некие общие данные, и сервис который их использует, плюс хранит что-то своё — как их приавильно связать и организовать обмен и обновление данных.
Мне кажется это слишком абстрактно.
я бы подумал о том какие данные. какая среда. в впн организации достаточно наверно было бы tcp коммуникаций(возможно даже прямой доступ к базе).
если могут быть проблемы с сетью(роутеры и т.п.) — http.

S>Если я правильно понимаю, речь об авторизации?
да

Здравствуйте, Somescout, Вы писали:

S>Приветствую.

S>Возник вопрос: пусть есть два сервиса, первый из которых хранит структуру организации и пользователей, а второй использует данные первой для реализации приложения — почта/автоматизация/что-угодно. Есть ли какие-то best practices, описывающие как должно это всё вместе работать?
Ну, в идеале всё должно быть по максимуму нормализовано и изолировано.
То есть в вашем примере есть сервис identity, в котором есть информация о пользователях, их паролях, и прочей личной информации.
Есть сервис hierarchy, в котором информация о структуре организации. (Если два этих сервиса объединить, то получится LDAP).

Есть какой-то сервис, скажем, почта. В нём нет информации ни о пользователях, ни о структуре. В нём есть, скажем, почтовые ящики.

В зависимости от предпочтений архитектора и анализа потребностей пользователей, детали могут отличаться. Но в целом, почтовый сервис отвечает за доставку почты в ящики.
Аутентификация при доступе к ящикам рулится по информации из сервиса identity. Авторизация — по информации из сервиса hierarchy (например, начальник отдела может получить доступ к ящику любого сотрудника своего отдела; сотрудник может получить доступ к ящику другого сотрудника в том случае, если тот другой назначил его своим заместителем/помощником).

Никакого "копирования" информации не происходит. Информация о том, в какие группы и роли входит пользователь, в худшем случае копируется из hierarchy сервиса в сессию почтового сервиса и является эфемерной — как только сессия прокисла, она исчезает. В лучшем случае даже такого копирования не происходит — почтовый сервис запрашивает у сервиса иерархии подтверждение того, что пользователю А можно открыть мейлбокс Б, и с какими правами. А по каким причинам тот сервис так ответил — не наше дело.

Как-то так.

Здравствуйте, Somescout, Вы писали:

S>Нормализация данных по сервисам: т.е. есть сервис, который хранит некие общие данные, и сервис который их использует, плюс хранит что-то своё — как их приавильно связать и организовать обмен и обновление данных.

На организацию данных смотреть полезно. Но еще лучше смотреть на использование данных. И даже в этом случае определяющими будет масса других факторов. Какая у вас организационная структура? Какие команды владеют сервисами? Какой технический уровень обеих команд? В течение какого времени команды могут поддерживать "обратно-совместимый" API? Сколько вообще сервисов и команд? Допустима ли задержка "репликации" данных? Какого уровня задержка? Сколько данных и с какой частотой реплицируется? Какие желаемые/реальные уровни надежности отдельных компонент? Какая у вас "вообще" архитектура принята?

Можно делать что-то в стиле SOA с большим использованием общих сервисов. Тогда ваш e-mail будет просто ходить в общий сервис по необходимости (даже без кеширования). Общий сервис может отправлять уведомления о каких-то изменениях через очередь сообщений, на него может реагировать e-mail. Например, при удалении пользователя переносить его почту в glacier (архив, более дешевое хранение но больше плата за доступ).

Или можно двигаться в сторону микросервисов (которые про bounded context). В этом случае тоже можно делать несколько стилей. Я по-умолчанию предпочту "независимый" почтовый сервис (операции вроде создать ящик, удалить ящик, прочитать ящик) и сервис интеграции. Интеграция слушает очередь сообщений и реагирует на изменения. Например, вызывает операцию "создать ящик" при создании нового пользователя. Отправитель гарантирует надежную отправку сообщения (at-least-once delivery), получатель тоже реализует надежную подписку. Вполне нормально иметь REST на обоих концах и по сообщению из очереди вычитывать последние данные (само сообщение может быть минимальным — тип сообщения и идентификатор сущности). В плюсах подхода — "зависимый" (e-mail) сервис можно легко тестировать, не нужно эмулировать "общий" сервис. При некоторой сноровке можно в тестовых средах параллельно ставить правильный общий сервис и симулятор, которые будут ходить в один e-mail (не всегда стоит так делать!).

Или можно внимательно посмотреть на задачу и развернуть зависимости. Пусть ваш общий сервис будет теперь фасадом для всех конкретных сервисов. Как минимум в той части, которая его касается (т.е. контроль доступа, операции с пользователями). Это может выглядеть как бред. Но здесь есть плюсы. Общее количество зависимостей не изменяется, изменяется только их направление. При этом большее количество исходящих зависимостей лучше, чем большое количество входящих. Ну вот допустим у нас авторизация на основе иерархии (начальник может читать почту подчиненных). Организация проработала пять лет и усложнилась. А еще мы выяснили, что начальники достаточно регулярно уходят в отпуск. Поэтому мы решили внести концепт "временно исполняющего обязанности". Врио получает полномочия начальника но находится на старом месте в организационной структуре. После того, как данное понятие реализовано в "ядре", все зависимые сервисы должны будут обновиться для использования новой концептуальной модели. В более простых терминах — у вас есть много копий очень похожего кода "авторизации" пользователя, по одному на сервис. Если же общий сервис работает фасадом, все проверки изменяются в нем. У нас получется только одна копия кода, отвечающего за авторизацию пользователей. Наш фасад может отвечать и за повторы/докат операций. Например, создавать почтовый ящик при создании пользователя (и повторять операцию до тех пор, пока ящик не создан). Наличие "агрегатного" состояния в одном месте позволяет легко и просто делать красивый вывод в UI: "пользователь создается, еще не создан email и payroll". Сервис e-mail в этом случае реализует авторизацию на основе "ролей сервисов" а не ролей пользователей. Ну а получение почты — это на основе почтовых ящиков.

Я могу и еще более странные вещи предложить. Например, можно использовать общую базу данных. Это, конечно, ужас-ужас, но если команды ничего более сложного не тянут и результат нужен "прямо сейчас" — можно и сделать. Параллельно придется планировать, как учить команды и когда все это можно будет привести в человеческий вид. Зато данные всегда консистентны и до определенного уровня сложности модель всем понятна.

Так что смотрите более широко на ситуацию. Что вы можете сделать. И потом выбирайте из доступного. На фоне прочих равных — спросите архитектора. Ну или становитесь сами архитектором и выбирайте еще и из своих предпочтений.

Здравствуйте, maxkar, Вы писали:

M>Здравствуйте, Somescout, Вы писали:

M>Я могу и еще более странные вещи предложить. Например, можно использовать общую базу данных. Это, конечно, ужас-ужас, но если команды ничего более сложного не тянут и результат нужен "прямо сейчас" — можно и сделать. Параллельно придется планировать, как учить команды и когда все это можно будет привести в человеческий вид. Зато данные всегда консистентны и до определенного уровня сложности модель всем понятна.

M>Так что смотрите более широко на ситуацию. Что вы можете сделать. И потом выбирайте из доступного. На фоне прочих равных — спросите архитектора. Ну или становитесь сами архитектором и выбирайте еще и из своих предпочтений.

Как много всего написано. А в 90% случаев все можно свести к тому, что один сервис — источник сохраняет структурированный файлик,
а другой при старте или время от времени его перечитывает.
Судя по тому что ТС Формулирует задачу, с большой вероятностью у него задача свелась бы к такому решению, предполагаю что у него там сотня пользователей, а может десяток.
Но программист будет мутить микросервисы, докеры, контейнеры, поставит оракл, пару серверов для этого , полку с RAID, подпишется на SAAS.
Так же делают все ИТ отделы в крупных конторах с которыми я сталкивался.