Полезное видео! Но эта тема большая, лучше сделать серию роликов и подробно пройтись по всем аспектам. Отдельно вынести инструменты (rabbit, kafka, zero и т.д.). Отдельный ролик желательно уделить различиям между SOA (событийно-ориентированная) и MSA (микросервисная) архитектура, в нём всплывут как раз моменты применения этих архитектур и их надобность. И ещё отдельно было бы неплохо привести примеры компаний которые используют эти архитектуры. Можно кроме зарубежных привести примеры российских компаний, уже достаточно много кто использует те же Soa и Msa, многие используют комбинированный ландшафт где есть если не все то почти технологии и примеры архитектрур. Всё ИМХО)) А так как обычно, отличная подача материала и сам материал интересный! Спасибо!
Ну, кстати, такое частично у меня есть) Что такое Apache Kafka - ua-cam.com/video/Mw9YFay8-WM/v-deo.htmlsi=ZlePq9PewZtyJwTI Что такое RabbitMQ и чем он отличается от Apache Kafka - ua-cam.com/video/QRmGgixERKs/v-deo.htmlsi=db1so6m7JMkoDg_Q Различия SOA и микросервисной архитектуры - ua-cam.com/video/WaFIcJMLuNg/v-deo.htmlsi=H100HUO4mw5dIa4m
Знаю, некоторые видел) Продолжай и дальше можно отдельные ролики объединить в большую тему и благодаря которым роликам людям удобно будет познавать материал. А ещё было бы здорово расписать практики, где и зачем применяются архитектуры и системы, тут нужны примеры реализаций.
Хочу выразить благодарность автору за предоставленный материал и за ясное объяснение сложной темы. Событийно-ориентированная архитектура действительно обещает множество преимуществ, и это видео является отличным стартовым пунктом для тех, кто хочет углубиться в эту тему.
Как то много рассказано про преимущества в примерах и мало про недостатки (примеров вообще нет). Событийно-ориентированная архитектура использует много ресурсов. За брокером надо следить, ставить кучу ивентов в заббикс, масштабировать тот же брокер, деплоить кучу микросервисов, ещё и тестить как-то это надо, дев среду настраивать. На всё это нужна целая команда девопсов, причём дорогих сеньёрных девопсов. Не все компании малые и даже средние могут позволить себе такую архитектуру. И почему-то не упоминается бутылочное горлышко всей этой системы - брокер. Если упадёт брокер, то весь бизнес процесс встанет... Ну не знаю, не знаю... Эту архитектуру имеет смысл применять, только в большой компании с большим количеством групп команд и парочкой собственных ЦОДов Сейчас весь средний и малый бизнес крутится в облаке сторонних ЦОДов. Конечно Амазон может позволить себе такую архитектуру, так как он тех. гигант. Звучит круто, но очень дорого...
А что делать, если нужен ответ по событию? Ну например, клиент триггернул событие создание заказа, ему нужно вернуть ответ удалось создать или ошибку, как быть в этом случае если очереди предполагают асинхронную работу, а описанный пример - синхронную?
ИМХО - зависит от бизнес требований, но чаще всего заказ создается синхронно, перед его созданием создается транзакция в БД (или лепят сагу, если все распилили на микросервисы), в ней будут проверяться как минимум наличие товаров на складе, возможность доставки на определенную дату, время и метсо и т.п. В ответ клиент получает результат, и плюс летит событие в брокер с ивентом о создании. Последующая обработка уже ведется асинхронно (всякие уведомляшки, проверка оплаты и т.п.)
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Потрясающе! Большое спасибо!)
Круто было бы про Domain Driven Designe послушать
А вот есть такая статейка на примете, запишу 👌
Лайк, как всегда
Полезное видео!
Но эта тема большая, лучше сделать серию роликов и подробно пройтись по всем аспектам. Отдельно вынести инструменты (rabbit, kafka, zero и т.д.). Отдельный ролик желательно уделить различиям между SOA (событийно-ориентированная) и MSA (микросервисная) архитектура, в нём всплывут как раз моменты применения этих архитектур и их надобность. И ещё отдельно было бы неплохо привести примеры компаний которые используют эти архитектуры. Можно кроме зарубежных привести примеры российских компаний, уже достаточно много кто использует те же Soa и Msa, многие используют комбинированный ландшафт где есть если не все то почти технологии и примеры архитектрур.
Всё ИМХО))
А так как обычно, отличная подача материала и сам материал интересный!
Спасибо!
Ну, кстати, такое частично у меня есть)
Что такое Apache Kafka - ua-cam.com/video/Mw9YFay8-WM/v-deo.htmlsi=ZlePq9PewZtyJwTI
Что такое RabbitMQ и чем он отличается от Apache Kafka - ua-cam.com/video/QRmGgixERKs/v-deo.htmlsi=db1so6m7JMkoDg_Q
Различия SOA и микросервисной архитектуры - ua-cam.com/video/WaFIcJMLuNg/v-deo.htmlsi=H100HUO4mw5dIa4m
Знаю, некоторые видел)
Продолжай и дальше можно отдельные ролики объединить в большую тему и благодаря которым роликам людям удобно будет познавать материал.
А ещё было бы здорово расписать практики, где и зачем применяются архитектуры и системы, тут нужны примеры реализаций.
в конце, что значит данные передаются с меньшей задержкой и большей пропускной способностью? по сравнению с чем?
Хочу выразить благодарность автору за предоставленный материал и за ясное объяснение сложной темы. Событийно-ориентированная архитектура действительно обещает множество преимуществ, и это видео является отличным стартовым пунктом для тех, кто хочет углубиться в эту тему.
Как то много рассказано про преимущества в примерах и мало про недостатки (примеров вообще нет).
Событийно-ориентированная архитектура использует много ресурсов. За брокером надо следить, ставить кучу ивентов в заббикс, масштабировать тот же брокер, деплоить кучу микросервисов, ещё и тестить как-то это надо, дев среду настраивать.
На всё это нужна целая команда девопсов, причём дорогих сеньёрных девопсов. Не все компании малые и даже средние могут позволить себе такую архитектуру.
И почему-то не упоминается бутылочное горлышко всей этой системы - брокер.
Если упадёт брокер, то весь бизнес процесс встанет...
Ну не знаю, не знаю...
Эту архитектуру имеет смысл применять, только в большой компании с большим количеством групп команд и парочкой собственных ЦОДов
Сейчас весь средний и малый бизнес крутится в облаке сторонних ЦОДов.
Конечно Амазон может позволить себе такую архитектуру, так как он тех. гигант.
Звучит круто, но очень дорого...
А что делать, если нужен ответ по событию? Ну например, клиент триггернул событие создание заказа, ему нужно вернуть ответ удалось создать или ошибку, как быть в этом случае если очереди предполагают асинхронную работу, а описанный пример - синхронную?
ИМХО - зависит от бизнес требований, но чаще всего заказ создается синхронно, перед его созданием создается транзакция в БД (или лепят сагу, если все распилили на микросервисы), в ней будут проверяться как минимум наличие товаров на складе, возможность доставки на определенную дату, время и метсо и т.п.
В ответ клиент получает результат, и плюс летит событие в брокер с ивентом о создании. Последующая обработка уже ведется асинхронно (всякие уведомляшки, проверка оплаты и т.п.)
А точно дривен, а не драйвен? А так топ канал, спасибо за работу!
Не, точно "дривен") Спасибо, заходи ещё!
Мега просто и полезно, формат вызывает привыкание)
Спасибо, приходи ещё)
хороший видос. только не рассказали разницу между событийно ориентированностью и месседж ориентированностью (то бишь RabitMQ vs Kafka)
Спасибо! Про различия Кафки и Кролика, кстати, можете посмотреть в этом видео --> ua-cam.com/video/QRmGgixERKs/v-deo.html
Архитектура типа «запрос - ответ» и «клиент серверная архитектура»это одно и то же?
супер, спасибо👍
вообще-то ничто не мешает монолиту тоже быть событийно-ориентированным
Чето не понял как гарантируется доставка промежуточному серверу.