Как правильно спроектировать микросервисную архитектуру?
У меня планируется программа, которая имеет три части и общается с БД.
БД будет иметь следующее:
1) Информация о месте
2) Связанные места
3) Количество объектов сейчас
4) Количество объектов обычно
Первая часть - нейронка, которая вычисляет количество объектов на фото (выполняет запрос куда-то в другое приложение по определённому адресу) и отправляет их на сервер. Вторая часть - сервер, который обрабатывает приход информации от других ПО, чтобы можно было обращаться к моей проге и выдавать ответы. Эта же часть выполняет получение данных от первой части, для каждого пункта. , ну и после получения инфы о количестве объектов выполняет вычисления, после которых выполняет отправку нужных данных на чужую прогу, а также сохраняет данные в бд. Третья часть - веб-приложение, который выводит информацию про место, показывает данные о связных местах, количество объектов сейчас.
То есть первая часть просто должна запросить данные со стороны, обработать их и отправлять на сервер данные, а также id камеры, а камера будет уже привязана в бд к конкретному месту, поэтому сервер будет понимать, для какого места пришла информация. и первому сервису бд не нужна. Нейронка будет на Python (Мб сделаю на Java, но это решаемо). Вторая часть - выполняет много запросов в БД, как select, так и set, выполняет различные вычисления с обращением к бд. Сервер будет на Java Spring Третья должна выводить информацию о месте с обновлениями, потому что каждые 6 секунд данные о конкретном месте изменяются. Там на моей третьей части будет rest с fetch api js.
Я хочу правильно построить архитектуру, в идеале микросервисную. То есть сделать три микросервиса, там докер и всякое такое намутить. Но сам я никогда не проектировал микросервисную архитектуру. А сам слышал правило, что самостоятельно новичкам лучше этого не делать. Поэтому хотел бы узнать, как правильно организовать бд для них?
Ещё я слышал, что по правилам у каждого миркосервиса есть должна быть своя бд. Тут же у меня есть микросервис, который занимается своим делом и просто отправляет данные на сервер. Главная вторая часть, которая выполняет вычисления и всякое такое, с обращением к бд. Есть rest часть, которая получает данные из бд и общается с клиентом (на сайте там будет html, css,js), И поэтому хотел бы узнать, как правильно стоит спроектировать три эти части? Чтобы они могли спокойно общаться, архитектура была по канонам и чтобы на защите диплома никто не придрался?
А почему эти три вещи - это микросервисы? Они выглядят вполне себе как самостоятельные несвязанные сервисы.
Мне кажется на микросервисы тут стоит дробить только сам сервер - вторую часть. И вы уже выделили даже что то подобное на микросервисы - нечто что будет обрабатывать входящий поток, нечто что будет писать в базу, нечто что будет отдавать поток наружу, и нечто что будет производить калькуляции.
В рамках диплома нет большого смысла заморачиваться с микросервисной архитектурой, тк ни одного из факторов, где микросеврсная архитектура имеет смысл тут нет.
Некоторые вещи вероятно есть смысл делать как раздельные сервисы (ту же нейронку и api например, дальше не вчитывался), но делить ещё сильнее нет нужды.
Главное изначально обозначить, под какие требования делается разработка.
А сам слышал правило, что самостоятельно новичкам лучше этого не делать.
Ага. Когда от этого решения зависят другие люди или значительные суммы. А когда вольное творчество - это прямо таки желательно пробовать самому, ошибаться, переделывать, снова ошибаться, снова переделывать, параллельно читая что-то по теме.
Василий Банников, GavriKos, VoidVolker Вообще, у меня тема - управление дорожным движением. Типо с камер получаю данные, делаю фото, считаю машины в каждой полосе, отправляю на сервер, сервер считает новое время для светофоров, после чего отправляет на приложение светофора (типо конретному светофору отправлять время красного, время зеленого и время жёлтого), а также изменять связные светофоры по близости с эффектом важности. А веб часть позволяет добавлять новые перекрестки со светофорами, изменять текущее время, отключать светофоры, смотреть вообще какая загруженность.
Видео сейчас во всех крупных городах с камер собирается в одно место. Вот у меня как раз и получается, что система запрашивает видео или сразу фото (ещё думаю) каждые 10 секунд. Ну и надёжность высокая у сервера должна быть.
Просто по сути веб и основной сервер у меня общаются с одной БД, что задаёт вопросы с адекватностью архитектуры.
Ziptar, Творчество вольное, но всё же диплом для меня конечно место обучения, но больше хочется набить шишек на нём, а не биться головой об стену. А то переделывание на последней стадии будет очень критично
Правильно для чего именно? Прежде, чем что-то проектировать надо определиться с конкретными требованиями вашей задачи. И уже исходя из требований и ограничений проектировать архитектуру и прочее. Если требования неизвестны, то делается минимальный прототип, испытывается, результат записывается, анализируется и делаются какие-то выводы. При отсутствии результата - прототип допиливается до MVP и так далее. И вот уже по этим выводам принимаются какие-то решения - сделать другую архитектуру, изменить что-то в текущей архитектуре, как-то её дополнить/доработать или оставить как есть.
Само собой, это прям если в идеале, но когда человек 1, да ещё и времени немного, как лучше делать? Тематику я описал выше в одном из ответов на комментарии. Безусловно, надо составить подробное ТЗ по госту, но если заранее всё же как-то проектировать, чтобы примерно понимать, что это получится. Чтобы на диплом ещё думать, что там и как. Чтобы там был и докер и всякое новомодное.
ivankn_bel, повторюсь ещё раз: исходить из требований к вашему продукту. Вот например:
когда человек 1, да ещё и времени немного
Логично, что в этом случае придётся делать самый простой вариант с минимальным функционалом. Просто чтобы работало.
но всё же диплом для меня конечно место обучения
Увы, это не так. В приблизительно 95% случаях диплом - это просто показатель того остатка знаний, который остался в мозгах студента по прошествии скольких-то лет обучения. Диплом очень далёк от реальной разработки и поэтому реальных знаний там ещё меньше. Вот тут я уже писал что из себя представляет сегодняшняя система образования в рамках IT. И вряд ли что-то сильно изменится в ближайшие ещё лет 10-20 как минимум. Единственно правильный путь - самообучение.
Безусловно, надо составить подробное ТЗ по госту
А вот и не угадали. Хотите кубометры макулатуры ручками набивать и согласовывать? А вот в реальных госконторах проекты простой автоматизации средненького офиса запросто генерируют вполне себе реальные кубометры макулатуры. Задолбаешься какую-нибудь рамку месяц согласовывать. Так что забудьте про ГОСТы в IT - их тут, в разработке, практически нет. Да и самих ГОСТов на разработку тоже не особо. Может и есть какие-то выпуска нулевых там - не слежу за темой. 5 лет в IT - это считай эпоха целая.
Чтобы там был и докер и всякое новомодное.
Новомодное - не значит нужное. Если вам оно облегчит работу - берёте, если нет - то на кой чёрт оно вам надо? Сами же пишите, что времени мало.
А вообще, у вас задача уровня "просто показать, что вы что-то сделали и оно как-то возможно работает". Всё. Дальше про диплом вы можете забыть навсегда. И забудете.
Средний
Простой
