Этого треда уже нет.
Это копия, сохраненная 6 апреля 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 6 апреля 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
пишу впервые микросервис на java, на спринге. аналог кинопоиска.
- 4 микросервиса
- web client (1 микросервис)
- ms1 (выполняет работу с фильмами)
- ms2 (с юзерами)
- ms3 (со статичными данными)
- архитектура микросервиса database per service (пик 2)
- у каждого своя бд (отношения бд на пик 1)
НО! эти бд связаны между собой так или иначе, что создает мне проблем
1. не понятно, как координировать между собой сервисы
например: юзер захотел посмотреть топ 10 фильмов, нажал на кнопку на клиенте, пошел запрос через rest api фильмов (ms1), на ms1 контроллер принимает запрос, берет 10 фильмов, отправляет обратно юзеру. юзер получает список из названий фильмов, их краткой инфы (год, рейтинг и т.п.), но не видит постера фильма, потому что эта статика обрабатывается другим микросервисом (ms3);
теперь, имея idшники 10 фильмов, можно с клиента отправить новый запрос по rest api, но уже на ms3, который вернет urlы постеров, которые на контроллере клиента нужно будет выдернуть и подставить в html страницу.
итого: мы поочередно отправили 2 запроса, чтобы получить корректное отображение списка из 10 фильмов. что как по мне является не правильным подходом, НО Я МОГУ ОШИБАТЬСЯ. насколько вообще нормальна подобная практика в микросервисах?
2. насколько правильно вообще создавать api запросы в контроллерах?
т.е. я могу понять ситуацию, когда контроллер получает запрос, делает обращение к бд и возвращает результат. но я не уверен, что получать запрос в контроллере, делать обращение к бд, создавать в этом же контроллере "подзапрос" (новый запрос) к другому сервису, чтобы тот этот запрос принял, обработал по своему, вернул ему результат, после чего только изначальный микросервис смог вернуть полноценный ответ пользователю. (на пик 3 проиллюстрировал операцию)
3. что делать в случае, когда условный админ хочет добавить новый фильм в базу данных?
допустим, он так же создает запрос, который в свою очередь триггерит новый запрос на N-ном узле (микросервисе), но где-то происходят неполадки, а часть данных уже обновлена где-то. если в монолите можно было использовать транзакции, то как тут это можно сделать относительно просто? добавление таймера ожидания ответа ничего не гарантирует. потому что (пик 4)
- 1) мы отправили заполненную форму о новом фильме (заголовок, актеры, постер и т.д.) микросервису MS1, и решили ожидать максимум 5 секунд, после истечения которых, запрос будет считаться незавершенным, если MS1 ему не ответит
- 2) мы отправили запрос успешно, MS1 его получил, но еще не дал никакого ответа, потому что для этого ему нужно тоже ожидать не более 5 секунд и получить ответ от MS2 (похоже на рекурсивный спуск). MS1 выполняет попытку вставить часть данных о новом фильме в свою БД
- 3) вставка в БД выполнена успешно, MS1 выполняет запрос к MS2, чтобы добавить постер к фильму
- 4) но вдруг, даже не успев отправить свой запрос, MS1 выходит из строя (сервер вырубается -> сервис падает)
- 5) клиент (админ) через 5 секунд ожидания не получает никакого ответа от MS1, понимая, что запрос выполнить не удалось
НО! на этапе 3 мы уже выполнили частично вставку в БД, как ее теперь отменять - не понятно. следовательно, такой таймер - не дает никаких гарантий.
что делать? какие советы? стоит ли запариваться для пет проекта с нормальной отказоустойчивостью? изучаю java всего только месяц (есть законченная вышка по ит специальности, но нет опыта работы, долгая история)... задача: написать внятный пет проект, чтобы было что показать на собесе. если честно, уже подумываю о простом монолите на спринге, но в сегодняшних реалиях, никто наверное это не воспримет всерьез, даже для джуна...
- 4 микросервиса
- web client (1 микросервис)
- ms1 (выполняет работу с фильмами)
- ms2 (с юзерами)
- ms3 (со статичными данными)
- архитектура микросервиса database per service (пик 2)
- у каждого своя бд (отношения бд на пик 1)
НО! эти бд связаны между собой так или иначе, что создает мне проблем
1. не понятно, как координировать между собой сервисы
например: юзер захотел посмотреть топ 10 фильмов, нажал на кнопку на клиенте, пошел запрос через rest api фильмов (ms1), на ms1 контроллер принимает запрос, берет 10 фильмов, отправляет обратно юзеру. юзер получает список из названий фильмов, их краткой инфы (год, рейтинг и т.п.), но не видит постера фильма, потому что эта статика обрабатывается другим микросервисом (ms3);
теперь, имея idшники 10 фильмов, можно с клиента отправить новый запрос по rest api, но уже на ms3, который вернет urlы постеров, которые на контроллере клиента нужно будет выдернуть и подставить в html страницу.
итого: мы поочередно отправили 2 запроса, чтобы получить корректное отображение списка из 10 фильмов. что как по мне является не правильным подходом, НО Я МОГУ ОШИБАТЬСЯ. насколько вообще нормальна подобная практика в микросервисах?
2. насколько правильно вообще создавать api запросы в контроллерах?
т.е. я могу понять ситуацию, когда контроллер получает запрос, делает обращение к бд и возвращает результат. но я не уверен, что получать запрос в контроллере, делать обращение к бд, создавать в этом же контроллере "подзапрос" (новый запрос) к другому сервису, чтобы тот этот запрос принял, обработал по своему, вернул ему результат, после чего только изначальный микросервис смог вернуть полноценный ответ пользователю. (на пик 3 проиллюстрировал операцию)
3. что делать в случае, когда условный админ хочет добавить новый фильм в базу данных?
допустим, он так же создает запрос, который в свою очередь триггерит новый запрос на N-ном узле (микросервисе), но где-то происходят неполадки, а часть данных уже обновлена где-то. если в монолите можно было использовать транзакции, то как тут это можно сделать относительно просто? добавление таймера ожидания ответа ничего не гарантирует. потому что (пик 4)
- 1) мы отправили заполненную форму о новом фильме (заголовок, актеры, постер и т.д.) микросервису MS1, и решили ожидать максимум 5 секунд, после истечения которых, запрос будет считаться незавершенным, если MS1 ему не ответит
- 2) мы отправили запрос успешно, MS1 его получил, но еще не дал никакого ответа, потому что для этого ему нужно тоже ожидать не более 5 секунд и получить ответ от MS2 (похоже на рекурсивный спуск). MS1 выполняет попытку вставить часть данных о новом фильме в свою БД
- 3) вставка в БД выполнена успешно, MS1 выполняет запрос к MS2, чтобы добавить постер к фильму
- 4) но вдруг, даже не успев отправить свой запрос, MS1 выходит из строя (сервер вырубается -> сервис падает)
- 5) клиент (админ) через 5 секунд ожидания не получает никакого ответа от MS1, понимая, что запрос выполнить не удалось
НО! на этапе 3 мы уже выполнили частично вставку в БД, как ее теперь отменять - не понятно. следовательно, такой таймер - не дает никаких гарантий.
что делать? какие советы? стоит ли запариваться для пет проекта с нормальной отказоустойчивостью? изучаю java всего только месяц (есть законченная вышка по ит специальности, но нет опыта работы, долгая история)... задача: написать внятный пет проект, чтобы было что показать на собесе. если честно, уже подумываю о простом монолите на спринге, но в сегодняшних реалиях, никто наверное это не воспримет всерьез, даже для джуна...
Есть тред для нюфань, есть тред по джаве, но ты решил высраться отдельным, будем тут сидеть и обсуждать твои решения, а то и код ревьюить, да.
>>709
))))
))))
бамп
бамп
Тред утонул или удален.
Это копия, сохраненная 6 апреля 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 6 апреля 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.