Добрый день!
Уже несколько раз сталкиваюсь с абстрактно одинаковыми задачами решаемыми в разных проектах.
Есть какой-то один(или несколько) источник(-ов) данных(СУБД, файлы, tcp/ip, message broker,...), иногда они распределены на разных потоках/процессах/машинах по сети.
Есть что-то преобразующее эти данные: иногда распределенное на разных потоках/процессах/машинах, иногда нет.
Результат также нужно выдать иногда целиком, иногда по частям, иногда разным абонентам на разных потоках/процессах/машинах.
Пример: диагностика. Есть список тестов их нужно выполнить распределив по разным вычислителям, потом собрать результат и сделать отчет.
Такого "одинакового кода" для разных реализаций/применений/функционала у нас в канторе, полно.
Проблема в том что постоянно появляется необходимость реализовывать какие-то фичи, они идут как костыли в проекте на моменте потому что что-то срочно нужно проверить.
Потом про них успешно забывают, потом появляется необходимость в подобных костылях в других проектах и опять оврал, опять костыли которые потом будут забыты...
Сейчас всё это реализовано монолитно в разных больших проектах на Phyton, QT C++ в ОС linux.
Задумываюсь о том чтобы сделать какие-то облачные микросервисы на базе QT5.X и C++17 так чтобы алгоритмы максимально вынести туда, а приложения просто обращались бы с запросами о выполнении тех или иных задач и могли бы распределено получать результат. Рассчитываю таким образом получить гибкие решения в которые можно будет внедрять изменения не ломая другие проекты. Есть ли подобные паттерны/реализации/решения чтобы не городить велосипед?
P__>Уже несколько раз сталкиваюсь с абстрактно одинаковыми задачами решаемыми в разных проектах. P__>Есть какой-то один(или несколько) источник(-ов) данных(СУБД, файлы, tcp/ip, message broker,...), иногда они распределены на разных потоках/процессах/машинах по сети. P__>Есть что-то преобразующее эти данные: иногда распределенное на разных потоках/процессах/машинах, иногда нет. P__>Результат также нужно выдать иногда целиком, иногда по частям, иногда разным абонентам на разных потоках/процессах/машинах.
Здравствуйте, Pavel__, Вы писали:
P__>Да, только хочется на C++, а не на Erlang.
Микросервисы или наносервисы в кластере кубера. Кубер позволяет представить каждый микросервис унифицировано, что ускоряет и упрощяет развертывание, и управлять нагрузкой, например, на живую увеличивая-уменьшая количество реплик микросервиса для горизонтального масштабирования нагрузки. Но на C++ писать микросервисы — это мне кажется сомнительная затея, для этих целей лучше подходит Java, Kotlin или, если непреодолимая тяга к мальчикам сложным компилируемым языкам, то хотя бы на Go.
Сами паттерны — тут надо копать в сторону "распределенных паттернов", например есть хорошая книга "Распределенные системы. Паттерны проектирования". Хорошая новость в том, что в этих паттернах нет зависимости от языка программирования, нужно просто, чтобы твои микросервисы работали по POSIX-стандартам в виде докер-образов лиункса и соблюдали соглашения REST API.
P__>Задумываюсь о том чтобы сделать какие-то облачные микросервисы на базе QT5.X и C++17 так чтобы алгоритмы максимально вынести туда, а приложения просто обращались бы с запросами о выполнении тех или иных задач и могли бы распределено получать результат. Рассчитываю таким образом получить гибкие решения в которые можно будет внедрять изменения не ломая другие проекты. Есть ли подобные паттерны/реализации/решения чтобы не городить велосипед?
1) Как вы это видете, через TCP приложение будет обращаться к микросервису или как то по другому ?
2) На сколько критично время обновления микросервиса ?
Здравствуйте, Pavel__, Вы писали:
P__>Задумываюсь о том чтобы сделать какие-то облачные микросервисы на базе QT5.X и C++17 так чтобы алгоритмы максимально вынести туда, а приложения просто обращались бы с запросами о выполнении тех или иных задач и могли бы распределено получать результат. Рассчитываю таким образом получить гибкие решения в которые можно будет внедрять изменения не ломая другие проекты. Есть ли подобные паттерны/реализации/решения чтобы не городить велосипед?
Написать подпрограмму, отдельным файлом, обновлять так легче будет.
Здравствуйте, maks1180, Вы писали:
P__>>Задумываюсь о том чтобы сделать какие-то облачные микросервисы на базе QT5.X и C++17 так чтобы алгоритмы максимально вынести туда, а приложения просто обращались бы с запросами о выполнении тех или иных задач и могли бы распределено получать результат. Рассчитываю таким образом получить гибкие решения в которые можно будет внедрять изменения не ломая другие проекты. Есть ли подобные паттерны/реализации/решения чтобы не городить велосипед?
M>1) Как вы это видете, через TCP приложение будет обращаться к микросервису или как то по другому ? M>2) На сколько критично время обновления микросервиса ?
1). Через messageBroker поверх tcp/ip;
2). Вообще не критично, главное чтобы всё надежно работало.
Здравствуйте, Pavel__, Вы писали:
P__>Пример: диагностика. Есть список тестов их нужно выполнить распределив по разным вычислителям, потом собрать результат и сделать отчет.