Слишком однобоко получилось, к сожалению. Как будто у MSA сплошные плюсы . Что у MSA с - консистентностью данных? - динамическим изменение бизнес правил в начале проекта (да и вообще, насколько легко координировать изменения бизнес логики) - что с затратами на инфраструктуру и сложностью поддержки потенциального «зоопарка» технологий (в том числе, с точки зрения найма сотрудников) - и т.д.
@frameworkfoton2030 Жыл бұрын
Все таки все зависит от задачи, если не планируется повышения загрузки сервера и подключения сторонних сервисов SOA, весь код в одном проекте можно сказать, проще производить логирование и дебагинг. Основная потребность для MSA это именно ресурсы, мы распределяет систему, отвалился один сервис, его ветка не работает остальные ветки работают. И за это приходится платить вовсе не дублированием, а усложнением архитектуры именно в MSA очень сложно координировать взаимодействия между сервисами при обновлении, изменении например в шардировании и репликации данных, изменении формата обмена, протокола и т.д.,а также собрать воедино всю логику приложения. Чувство, что рассказывающий или не работал в реальности с такими проектами и действительно не понимает всех особенностей либо это мейнстримное видео типа микросервис круто остальное фигня, чтобы на бежали хейтеры и пошёл халивар, не любитель иностранных заимствований, но так короче и надеюсь понятнее.
@rikitarurikitaru77162 жыл бұрын
Звуки из Героев 3 - это потрясающе))
@datski_live7 ай бұрын
Просто офигительное пояснение, осознал, что я спроектировал гибрид и надо выбивать время на рефакторинг в сторону msa, спасибо
@ListenIT_channel7 ай бұрын
Круто, рад, что помогло!
@АлександрДубровский-ч5ь3 ай бұрын
Остановись) гибрид это прекрасно. Здесь сухая теория. Если ты в одного разрабатываешь, то у тебя не может быть ни соа ни мса. Скорее распределенный монолит. Это самая эфыективная форма по для малых команд
@ystanislavv Жыл бұрын
Большая часть указанных отличий свойственны и MSA и SOA. Но все недостатки отнесены к SOA, а достоинства к - MSA. Эти отличия - скорее свойства отдельных проектов. Достоинства - как хотели, а недостатки - как получилось...
@smilesrg Жыл бұрын
Это перевод какой-то статьи, которая рекламирует MSA
@mansur.gabidullin2 жыл бұрын
Отличный материал для тех, кто уже немного знаком SOA и MSA по отдельности, для того чтобы лучше понять различия и особенности двух архитектур.
@kirn36811 ай бұрын
согласен, без примеров тем, кто не очень в теме - сложновато уловить суть
@Petrov--Pavel2 жыл бұрын
материал классный, но начитка тяжела для восприятия. Чтобы более менее вникнуть в смысл, раза 4-5 возвращался к середине видео. Что значит слово макирование на 7:01?
@ListenIT_channel2 жыл бұрын
Мок - это заглушка, замена какого-то сервиса при тестировании. Можно тут почитать это - vk.com/@simbirsoft_team-moki-dlya-chainikov-terminy-instrumenty-i-hello-world
@Petrov--Pavel2 жыл бұрын
@@ListenIT_channel спасибо.
@ИльяТретьяков-б1т7 ай бұрын
Я думаю, что возвращаться несколько раз к материалу при изучении - это норма.
@0111010101010012 жыл бұрын
Великолепный канал
@DIMOKK2 жыл бұрын
Крутое видео, было б полезно услышать про DDD
@ListenIT_channel2 жыл бұрын
Спасибо, учтём 👌
@user-race-Vulcan Жыл бұрын
Как всегда, лаконично, ясно, грамотно и качественно! Топ 5+!
@user-bo7mb9cf4d2 жыл бұрын
Отличная подача. Хорошие источники. Минимум воды. Лайк! Ждем видео о DDD :)
@Rogov_Oleg Жыл бұрын
Типичная болтовня совершенно не подкреплённая никакими жизненными примерами
@bekhruziskandarzoda3726 Жыл бұрын
А почему считается, что в MSA для обмена данными используется брокер сообщений? А если данными обмениваются по gRPC? Разве от этого архитектура перестает быть микросервисной? Могу что-то напутать, заранее спасибо!
@ИльяТретьяков-б1т7 ай бұрын
Имею малую экспертизу, лишь моя догадка: если микросервисы будут друг с другом взаимодействовать напрямую через gRPC, то они потеряют автономность и будут зависеть друг от друга. Т.е. с помощью брокера сообщений можно сделать асинхронное взаимодействие: отправил сообщение в очередь и не думаешь, обработано оно или нет. А если обмениваться информацией по gRPC, то попытался отослать запрос и упал - т.е. один сервис не может существовать без другого - теряется автономность микросервисов.
@bekhruziskandarzoda37266 ай бұрын
@@ИльяТретьяков-б1т не, это логично, согласен. Но мне показалось, будто тут утверждается, что как раз таки общение через MQ это один из критериев микросервиса, что ошибочно, потому что на практике общение может происходить (и чаще даже происходит) через обычный REST или же RPC
@VkusnyashkaMMM2 жыл бұрын
Однозначно лайк, большое спасибо!
@ФилиппБаринов-ф2х7 ай бұрын
а что значит мокируются зависимости системы при тестировании?
@derzskyi13 жыл бұрын
Годно, спасибо
@VladikBezsmertnyi Жыл бұрын
Супер видео - но хотелось бы послушать про DDD
@андрейшаульский-в5к Жыл бұрын
Интересно изложено
@ArchDevWorkshop2 жыл бұрын
Крутая подача! Спасибо!
@smilesrg Жыл бұрын
Реклама микросервисной архитектуры. В нынешние времена считается, что микросервисная архитектура обладает своими недостатками, и отнюдь не является серебряной пулей.
@P_B_N_D10 ай бұрын
Очень быстро говорите. Вы хотите в формат шортса уложиться?
@ДенисКошкаров-м3в Жыл бұрын
Видео получилось довольно однобоким. Его стоило бы назвать преимущества MSA по сравнению с SOA. У MSA как я вижу есть минусы, это дублирование кода, а так же потенциальные проблемы с внесением изменений. Как я вижу вносить изменения в одном месте проще, чем искать в каждом сервисе куски кода, которые необходимо изменить.
@Poseidonboy Жыл бұрын
Не думаю, что дублирование кода в этом случае проблема. Каждый микросервис имеет разную причину для изменений, со временем эти одинаковые классы перестанут быть похожими. Ну по крайней мере так будет, если микросервисы разделяются по Common Closure Principle. По похожей причине например создаются DTO объекты, которые передаются через границы, они могут быть идентичными в начале, но со временем DTO каждого слоя измениться по своим причинам.
@ystanislavv Жыл бұрын
Вот и получается дублирование. Несколько микросервисов работают с одной и той же сущностью, но каждый по-своему. А это значит, что их работу нужно координировать/синхронизировать.@@Poseidonboy
@Poseidonboy Жыл бұрын
А я и пишу про дублирование... Только со временем сущности перестанут быть похожими на друг друга, если МСы разделены по ответственностям. У этих казалось бы одинаковых сущностей будут разные причины для изменения. А координировать работу придется как раз в SOA ибо там одна сущность передается по сервисам @@ystanislavv
@lexkomlev Жыл бұрын
Отличное видео - простое разделение мух и котлет.
@meteysh2 жыл бұрын
Да. DDD интересно было бы
@ListenIT_channel2 жыл бұрын
Приняли 👌
@olegivanov2287 ай бұрын
что такое "переиспользование сервиса" ?
@ListenIT_channel7 ай бұрын
Вкратце, это использование этого сервиса в других процессах и в сочетании с другими сервисами. Например, сервис платежей используем и при оплате заказа, и для оформления подписки (пример странный, но суть, думаю, вы поняли).
@Артем-э1н4н5 ай бұрын
Странно я думал микросервисы это тоже soa
@АлексейТимченко-я6я Жыл бұрын
материал отличный, подача ужасная. монолог очень быстрый однотонный. ужасно тяжело воспринимать информацию
@vifvrTtb0vmFtbyrM_Q2 жыл бұрын
Херня полная. Не все микросервисы одинаково полезны
@АлександрДубровский-ч5ь3 ай бұрын
По факту плюсы и минусы перепутаны
@vasx222 Жыл бұрын
Я думаю автор путает понятия SOA и распределенный монолит