Информация об изменениях

Сообщение Re[4]: Архитектура взаимодействия сервисов от 30.07.2021 6:32

Изменено 30.07.2021 7:07 swame

Re[4]: Архитектура взаимодействия сервисов
Здравствуйте, maxkar, Вы писали:

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


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


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


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

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


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


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


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