Сообщение Re[4]: Архитектура взаимодействия сервисов от 30.07.2021 6:32
Изменено 30.07.2021 6:53 swame
Re[4]: Архитектура взаимодействия сервисов
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, Somescout, Вы писали:
S>>Нормализация данных по сервисам: т.е. есть сервис, который хранит некие общие данные, и сервис который их использует, плюс хранит что-то своё — как их приавильно связать и организовать обмен и обновление данных.
M>На организацию данных смотреть полезно. Но еще лучше смотреть на использование данных. И даже в этом случае определяющими будет масса других факторов. Какая у вас организационная структура? Какие команды владеют сервисами? Какой технический уровень обеих команд? В течение какого времени команды могут поддерживать "обратно-совместимый" API? Сколько вообще сервисов и команд? Допустима ли задержка "репликации" данных? Какого уровня задержка? Сколько данных и с какой частотой реплицируется? Какие желаемые/реальные уровни надежности отдельных компонент? Какая у вас "вообще" архитектура принята?
M>Можно делать что-то в стиле SOA с большим использованием общих сервисов. Тогда ваш e-mail будет просто ходить в общий сервис по необходимости (даже без кеширования). Общий сервис может отправлять уведомления о каких-то изменениях через очередь сообщений, на него может реагировать e-mail. Например, при удалении пользователя переносить его почту в glacier (архив, более дешевое хранение но больше плата за доступ).
M>Или можно двигаться в сторону микросервисов (которые про bounded context). В этом случае тоже можно делать несколько стилей. Я по-умолчанию предпочту "независимый" почтовый сервис (операции вроде создать ящик, удалить ящик, прочитать ящик) и сервис интеграции. Интеграция слушает очередь сообщений и реагирует на изменения. Например, вызывает операцию "создать ящик" при создании нового пользователя. Отправитель гарантирует надежную отправку сообщения (at-least-once delivery), получатель тоже реализует надежную подписку. Вполне нормально иметь REST на обоих концах и по сообщению из очереди вычитывать последние данные (само сообщение может быть минимальным — тип сообщения и идентификатор сущности). В плюсах подхода — "зависимый" (e-mail) сервис можно легко тестировать, не нужно эмулировать "общий" сервис. При некоторой сноровке можно в тестовых средах параллельно ставить правильный общий сервис и симулятор, которые будут ходить в один e-mail (не всегда стоит так делать!).
M>Или можно внимательно посмотреть на задачу и развернуть зависимости. Пусть ваш общий сервис будет теперь фасадом для всех конкретных сервисов. Как минимум в той части, которая его касается (т.е. контроль доступа, операции с пользователями). Это может выглядеть как бред. Но здесь есть плюсы. Общее количество зависимостей не изменяется, изменяется только их направление. При этом большее количество исходящих зависимостей лучше, чем большое количество входящих. Ну вот допустим у нас авторизация на основе иерархии (начальник может читать почту подчиненных). Организация проработала пять лет и усложнилась. А еще мы выяснили, что начальники достаточно регулярно уходят в отпуск. Поэтому мы решили внести концепт "временно исполняющего обязанности". Врио получает полномочия начальника но находится на старом месте в организационной структуре. После того, как данное понятие реализовано в "ядре", все зависимые сервисы должны будут обновиться для использования новой концептуальной модели. В более простых терминах — у вас есть много копий очень похожего кода "авторизации" пользователя, по одному на сервис. Если же общий сервис работает фасадом, все проверки изменяются в нем. У нас получется только одна копия кода, отвечающего за авторизацию пользователей. Наш фасад может отвечать и за повторы/докат операций. Например, создавать почтовый ящик при создании пользователя (и повторять операцию до тех пор, пока ящик не создан). Наличие "агрегатного" состояния в одном месте позволяет легко и просто делать красивый вывод в UI: "пользователь создается, еще не создан email и payroll". Сервис e-mail в этом случае реализует авторизацию на основе "ролей сервисов" а не ролей пользователей. Ну а получение почты — это на основе почтовых ящиков.
M>Я могу и еще более странные вещи предложить. Например, можно использовать общую базу данных. Это, конечно, ужас-ужас, но если команды ничего более сложного не тянут и результат нужен "прямо сейчас" — можно и сделать. Параллельно придется планировать, как учить команды и когда все это можно будет привести в человеческий вид. Зато данные всегда консистентны и до определенного уровня сложности модель всем понятна.
M>Так что смотрите более широко на ситуацию. Что вы можете сделать. И потом выбирайте из доступного. На фоне прочих равных — спросите архитектора. Ну или становитесь сами архитектором и выбирайте еще и из своих предпочтений.
Как много всего написано. А в 90% случаев все можно свести к тому, что один сервис — источник сохраняет структурированный файлик,
а другой при старте или время от времени его перечитывает.
Судя по тому что ТС Формулирует задачу, с большой вероятностью у него задача свелась бы к такому решению, предполагаю что у него там сотня пользователей, а может десяток.
Но программист будет мутить микросервисы, докеры, контейнеры, поставит пару серверов для этого , полку с RAID, подпишется на SAAS.
Так же делают все ИТ отделы в крупных конторах с которыми я сталкивался.
M>Здравствуйте, Somescout, Вы писали:
S>>Нормализация данных по сервисам: т.е. есть сервис, который хранит некие общие данные, и сервис который их использует, плюс хранит что-то своё — как их приавильно связать и организовать обмен и обновление данных.
M>На организацию данных смотреть полезно. Но еще лучше смотреть на использование данных. И даже в этом случае определяющими будет масса других факторов. Какая у вас организационная структура? Какие команды владеют сервисами? Какой технический уровень обеих команд? В течение какого времени команды могут поддерживать "обратно-совместимый" API? Сколько вообще сервисов и команд? Допустима ли задержка "репликации" данных? Какого уровня задержка? Сколько данных и с какой частотой реплицируется? Какие желаемые/реальные уровни надежности отдельных компонент? Какая у вас "вообще" архитектура принята?
M>Можно делать что-то в стиле SOA с большим использованием общих сервисов. Тогда ваш e-mail будет просто ходить в общий сервис по необходимости (даже без кеширования). Общий сервис может отправлять уведомления о каких-то изменениях через очередь сообщений, на него может реагировать e-mail. Например, при удалении пользователя переносить его почту в glacier (архив, более дешевое хранение но больше плата за доступ).
M>Или можно двигаться в сторону микросервисов (которые про bounded context). В этом случае тоже можно делать несколько стилей. Я по-умолчанию предпочту "независимый" почтовый сервис (операции вроде создать ящик, удалить ящик, прочитать ящик) и сервис интеграции. Интеграция слушает очередь сообщений и реагирует на изменения. Например, вызывает операцию "создать ящик" при создании нового пользователя. Отправитель гарантирует надежную отправку сообщения (at-least-once delivery), получатель тоже реализует надежную подписку. Вполне нормально иметь REST на обоих концах и по сообщению из очереди вычитывать последние данные (само сообщение может быть минимальным — тип сообщения и идентификатор сущности). В плюсах подхода — "зависимый" (e-mail) сервис можно легко тестировать, не нужно эмулировать "общий" сервис. При некоторой сноровке можно в тестовых средах параллельно ставить правильный общий сервис и симулятор, которые будут ходить в один e-mail (не всегда стоит так делать!).
M>Или можно внимательно посмотреть на задачу и развернуть зависимости. Пусть ваш общий сервис будет теперь фасадом для всех конкретных сервисов. Как минимум в той части, которая его касается (т.е. контроль доступа, операции с пользователями). Это может выглядеть как бред. Но здесь есть плюсы. Общее количество зависимостей не изменяется, изменяется только их направление. При этом большее количество исходящих зависимостей лучше, чем большое количество входящих. Ну вот допустим у нас авторизация на основе иерархии (начальник может читать почту подчиненных). Организация проработала пять лет и усложнилась. А еще мы выяснили, что начальники достаточно регулярно уходят в отпуск. Поэтому мы решили внести концепт "временно исполняющего обязанности". Врио получает полномочия начальника но находится на старом месте в организационной структуре. После того, как данное понятие реализовано в "ядре", все зависимые сервисы должны будут обновиться для использования новой концептуальной модели. В более простых терминах — у вас есть много копий очень похожего кода "авторизации" пользователя, по одному на сервис. Если же общий сервис работает фасадом, все проверки изменяются в нем. У нас получется только одна копия кода, отвечающего за авторизацию пользователей. Наш фасад может отвечать и за повторы/докат операций. Например, создавать почтовый ящик при создании пользователя (и повторять операцию до тех пор, пока ящик не создан). Наличие "агрегатного" состояния в одном месте позволяет легко и просто делать красивый вывод в UI: "пользователь создается, еще не создан email и payroll". Сервис e-mail в этом случае реализует авторизацию на основе "ролей сервисов" а не ролей пользователей. Ну а получение почты — это на основе почтовых ящиков.
M>Я могу и еще более странные вещи предложить. Например, можно использовать общую базу данных. Это, конечно, ужас-ужас, но если команды ничего более сложного не тянут и результат нужен "прямо сейчас" — можно и сделать. Параллельно придется планировать, как учить команды и когда все это можно будет привести в человеческий вид. Зато данные всегда консистентны и до определенного уровня сложности модель всем понятна.
M>Так что смотрите более широко на ситуацию. Что вы можете сделать. И потом выбирайте из доступного. На фоне прочих равных — спросите архитектора. Ну или становитесь сами архитектором и выбирайте еще и из своих предпочтений.
Как много всего написано. А в 90% случаев все можно свести к тому, что один сервис — источник сохраняет структурированный файлик,
а другой при старте или время от времени его перечитывает.
Судя по тому что ТС Формулирует задачу, с большой вероятностью у него задача свелась бы к такому решению, предполагаю что у него там сотня пользователей, а может десяток.
Но программист будет мутить микросервисы, докеры, контейнеры, поставит пару серверов для этого , полку с RAID, подпишется на SAAS.
Так же делают все ИТ отделы в крупных конторах с которыми я сталкивался.
Re[4]: Архитектура взаимодействия сервисов
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, Somescout, Вы писали:
M>Я могу и еще более странные вещи предложить. Например, можно использовать общую базу данных. Это, конечно, ужас-ужас, но если команды ничего более сложного не тянут и результат нужен "прямо сейчас" — можно и сделать. Параллельно придется планировать, как учить команды и когда все это можно будет привести в человеческий вид. Зато данные всегда консистентны и до определенного уровня сложности модель всем понятна.
M>Так что смотрите более широко на ситуацию. Что вы можете сделать. И потом выбирайте из доступного. На фоне прочих равных — спросите архитектора. Ну или становитесь сами архитектором и выбирайте еще и из своих предпочтений.
Как много всего написано. А в 90% случаев все можно свести к тому, что один сервис — источник сохраняет структурированный файлик,
а другой при старте или время от времени его перечитывает.
Судя по тому что ТС Формулирует задачу, с большой вероятностью у него задача свелась бы к такому решению, предполагаю что у него там сотня пользователей, а может десяток.
Но программист будет мутить микросервисы, докеры, контейнеры, поставит пару серверов для этого , полку с RAID, подпишется на SAAS.
Так же делают все ИТ отделы в крупных конторах с которыми я сталкивался.
M>Здравствуйте, Somescout, Вы писали:
M>Я могу и еще более странные вещи предложить. Например, можно использовать общую базу данных. Это, конечно, ужас-ужас, но если команды ничего более сложного не тянут и результат нужен "прямо сейчас" — можно и сделать. Параллельно придется планировать, как учить команды и когда все это можно будет привести в человеческий вид. Зато данные всегда консистентны и до определенного уровня сложности модель всем понятна.
M>Так что смотрите более широко на ситуацию. Что вы можете сделать. И потом выбирайте из доступного. На фоне прочих равных — спросите архитектора. Ну или становитесь сами архитектором и выбирайте еще и из своих предпочтений.
Как много всего написано. А в 90% случаев все можно свести к тому, что один сервис — источник сохраняет структурированный файлик,
а другой при старте или время от времени его перечитывает.
Судя по тому что ТС Формулирует задачу, с большой вероятностью у него задача свелась бы к такому решению, предполагаю что у него там сотня пользователей, а может десяток.
Но программист будет мутить микросервисы, докеры, контейнеры, поставит пару серверов для этого , полку с RAID, подпишется на SAAS.
Так же делают все ИТ отделы в крупных конторах с которыми я сталкивался.