Отличная идея. Многое хочется прочитать, но глаза и так устают. А послушать можно и во время прогулки. Особенно если интересная тема. Молодцы! Спасибо!
Ожидал увидеть организацию узла связи микросервисов (саги, транзакции на нескольких машинах), увидел описание обмена и "готовых пакетов". РРРРРРРРРРРРРРРРРРРР.........
Есть такое. Про GraphQL можно глянуть отдельное подробное видео czcams.com/video/Xkx5wroOt7o/video.htmlsi=CnJaN2tq21jK2h56 и сравнение с другими методами интеграции czcams.com/video/CKy1Npdopo8/video.htmlsi=Gnoyhsxq_c7qL2Wn
имхо graphql, rest, grpc и soap (с этим не работал) отличаются только количеством оверхеда, который тебе нужно добавить в код. это все надстройки над http и принципиальной разницы между ними нет
@@N5O1 есть разница, как с ними работать, как сложно их поддерживать и составлять контракт, поддерживать обратную совместимость, и насколько хорошая у них пропускная способность. Ну и всё-таки не сказал бы, что правильно будет сказать "http - всё одна фигня" - http/2 в случае gRPC довольно существенно отличается от рестового http.
Хм, странный пример про кафку и менеджера который не видит - начала ли исполнятся заявка или нет. Это решается посредством системы которая собирает и отображает статусы заявки на каждом этапе исполнения. Менеджер посмотрит что заявка в статусе - инициализирована. Но не в статусе - обрабатывается, к примеру. И все. Можно еще алерт сделать если заявка слишком долго в каком то статусе зависла Но вообще event driven архитектура это не универсальное решение, надо думать о компромиссах. Хотя при сверх высокой нагрузке и куче микросервисов ничего лучше наверное и не найти
Да, автор так и говорит, что его ситуация - когда нет обратной связи для менеджера (ни синхронной, ни асинхронной). Согласен, это немного странно выглядит, но, видимо, какие-то ограничения были на проекте.
А какая целевая "маленькая" аудитория? Если будут смотреть НЕ айтишники, то вряд ли что-то поймут. А если будут смотреть разрабы по стэку, то информация слишком простая и базовая. Самые актуальные и важные способы взаимодействия с оркестратором и перераспределением нагрузки тут опущены (хореография и агрегатор). Не рассмотрен ни один паттерн (stangler, SAGA). Просто если авторы статьи сами новички в вопросах архитектуры микросервисов, то не понятно зачем их статью читать. А если информация намеренно упрощена и сжата, то не ясно кому это будет полезно. Автору канала большое спасибо за труд. Лайк и подписка за труды и приятную подачу
Спасибо за фидбек! Тут автор дал общую информацию по интеграции - не думаю, что её можно рассматривать как исчерпывающую по интеграции микросервисов - это факт. Думаю, начинающим разработчикам может быть полезно и системным аналитикам. А про хореографию, оркестратор и SAGA, кстати, видео тоже планируется.
В смысле у REST нет схемы данных? Это как говорить, что у SOAP нет кэширования. Все есть, просто никто не заморачивается. Или JSON Schema или Avro Schema уже на обочине где-то валяются?
В статье специально проговариавается, что в REST нет именно обязательной схемы, в отличии от того же gRPC или SOAP. А про кэширование SOAP - на уровне самого протокола его действительно нет, но это не значит, что его нельзя реализовать на уровнях клиента, прокси, сервера приложений, БД и пр. - согласен.
Еще прикольно слышать про "высокую нагрузку" и не приспособленность к ней REST. О каких RPS речь? В плане именно потолка RPS сам по себе REST не сильно уступает тому же gRPC (формирование бинарников и их расшифровка дают 100-150 мс край). При высоких нагрузках узким горлышком становится чаще БД, чем конкретный протокол общения
Тут, думаю, слегка преувеличено про "неприспособленность REST к высоким нагрузкам". Речь больше про то, что есть определённая грань нагрузки, когда время на сериализацию/десериализацию protobuf компенсируются скоростью передачи данных. На маленьких нагрузках - действительно смысла нет - можем только ухудшить ситуацию. На больших (по конкертике есть исследования, где находится эта грань целесообразности, поищу, скину) - gRPC будет уже эффективнее. Ну и стриминг у gRPC. И жёсткий контракт.
@@ListenIT_channel Ну тут я докапывался, конечно же, к формулировке именно. Понятное дело, что на масштабах в несколько десятков тысяч RPS REST начнет проигрывать gRPC, но это ни то, чтобы супер частый кейс, когда системы сталкиваются с такими нагрузками. Там и голый gRPC вряд ли сам по себе справится - придется придумывать что-то помимо смены протокола
Асинхронность и параллельность это вообще разное Первое значит существование отправителя и получателя в разных временных системах. Второе это одновременное выполнение процессов, ну или псевдопараллельное чаще. Как можно выполнить отправку запроса одновременно с приемом? Тахионные сети не изобрели еще
Для быстрого старта может и сойдёт, но в долгой перспективе мертвая идея. Pub/sub работает крайне схоже на udp и ему пофиг доставлено ли сообщение или нет.
Почему не используются базы данных для обмена данными между микросервисами в рамках одного проекта? Допустим все сервисы проекта имеют доступы к бд, обмениваться сообщениями они могут через таблицы…
Как правило, табличные базы данных, это узкие места любого проекта. Они потребляют относительно много ресурсов и времени на работу. Можно конечно использовать для обмена сообщениями тот же Redis, но в этом нет особого смысла так как полноценные брокеры сообщений используют более оптимизированные решения под капотом и уже имеют свой api
если нагрузка небольшая, то можно и через таблицы в реляционной бд имитировать асинхронную очередь. Но при росте нагрузки и/или числа конкурентных пользователей быстро встанут вопросы настройки уровней изоляции транзакций, блокировок записей в этой общей таблице, что в итоге ради соблюдения ACID не даст хорошей производительности. А вот специализированные решения для асинхронных очередей сообщений используя более эффективные структуры данных (например LSM-tree вместо типичного для реляционных субд B-Tree), всякие lock-free очереди и т.п., и в целом при другом наборе требований к таким системам, дают лучшую (а и иногда предельно возможную) производительность для задач "отправки сообщений"
PS: кстати, использования имитации очередей на базе реляционных субд, дает возможность на более ранних стадиях проекта подумать о снижении связности между компонентами системы, ввести необходимые разрезы функционала по асинхронности взаимодействия, а иногда и задуматься о возможных паттернах асинхронного взаимодействия - все это пригодиться при дальнейшем росте проекта. А уже потом при необходимости доучить специфику всяких RabbitMQ и Kafka, когда нагрузка этого потребует.
вы когда употребляете англицизмы то делайте перевод ,вы же не для себя родного это видео сделали ? "Оверхед" - это термин, который используется для описания дополнительных расходов или затрат, которые не связаны непосредственно с производством или продажей товара или услуги.
@@ListenIT_channel короче моего кореша взяли, у нас было только одно отличие, он написал «фронтенд разработчик» в регистрации, а я «программист-разработчик». Если получится решить проблему и меня запишут на митап авито.тех, в губы тебя расцелую(гетеросексуальная шутка)
Получил официальный ответ от AvitoTech, вот, что ребята пишут: «К сожалению, возможности площадки физически ограничены, и она не может вместить всех-всех желающих. Все заявки мы одобряли вручную, и, если кому-то пришёл отказ, то, к сожалению, это означает, что офлайн-билетов попросту не осталось. Мы благодарны всем за интерес к нашему мероприятию! Кстати, можно будет посмотреть онлайн-трансляцию по ссылке: czcams.com/video/h38Ku-0KbOI/video.html »
@@ListenIT_channel ну короче работают они так себе. Спасибо, что выяснил, они мне ответили тоже самое. Но коллегу моего, с таким же стажем и профилем - взяли, а я зарегестрировался на пару часов раньше. Слишком странно, ну да ладно. Спасибо, за уделенное тобой мне внимание)
Отличная идея. Многое хочется прочитать, но глаза и так устают. А послушать можно и во время прогулки. Особенно если интересная тема. Молодцы! Спасибо!
Ожидал увидеть организацию узла связи микросервисов (саги, транзакции на нескольких машинах), увидел описание обмена и "готовых пакетов". РРРРРРРРРРРРРРРРРРРР.........
Полезное видео, спасибо! 🙏
Спасибо, интересно:)
Чпачибо ❤
ПОЛЕЗНО и ИНФОРМАТИВНО
интересно что ничего про ГрафКюЭль, наверное автор не сталкивался)) спасибо за видео
О покойниках либо хорошо либо ничего
Есть такое. Про GraphQL можно глянуть отдельное подробное видео czcams.com/video/Xkx5wroOt7o/video.htmlsi=CnJaN2tq21jK2h56 и сравнение с другими методами интеграции czcams.com/video/CKy1Npdopo8/video.htmlsi=Gnoyhsxq_c7qL2Wn
@@itdev4680почему о покойниках? не приходилось работать, но в проекте предстоит, интересно почему так считаете
имхо graphql, rest, grpc и soap (с этим не работал) отличаются только количеством оверхеда, который тебе нужно добавить в код.
это все надстройки над http и принципиальной разницы между ними нет
@@N5O1 есть разница, как с ними работать, как сложно их поддерживать и составлять контракт, поддерживать обратную совместимость, и насколько хорошая у них пропускная способность. Ну и всё-таки не сказал бы, что правильно будет сказать "http - всё одна фигня" - http/2 в случае gRPC довольно существенно отличается от рестового http.
Хм, странный пример про кафку и менеджера который не видит - начала ли исполнятся заявка или нет. Это решается посредством системы которая собирает и отображает статусы заявки на каждом этапе исполнения. Менеджер посмотрит что заявка в статусе - инициализирована. Но не в статусе - обрабатывается, к примеру. И все. Можно еще алерт сделать если заявка слишком долго в каком то статусе зависла
Но вообще event driven архитектура это не универсальное решение, надо думать о компромиссах. Хотя при сверх высокой нагрузке и куче микросервисов ничего лучше наверное и не найти
Да, автор так и говорит, что его ситуация - когда нет обратной связи для менеджера (ни синхронной, ни асинхронной). Согласен, это немного странно выглядит, но, видимо, какие-то ограничения были на проекте.
Было интересно
А какая целевая "маленькая" аудитория? Если будут смотреть НЕ айтишники, то вряд ли что-то поймут. А если будут смотреть разрабы по стэку, то информация слишком простая и базовая. Самые актуальные и важные способы взаимодействия с оркестратором и перераспределением нагрузки тут опущены (хореография и агрегатор). Не рассмотрен ни один паттерн (stangler, SAGA). Просто если авторы статьи сами новички в вопросах архитектуры микросервисов, то не понятно зачем их статью читать. А если информация намеренно упрощена и сжата, то не ясно кому это будет полезно. Автору канала большое спасибо за труд. Лайк и подписка за труды и приятную подачу
Спасибо за фидбек! Тут автор дал общую информацию по интеграции - не думаю, что её можно рассматривать как исчерпывающую по интеграции микросервисов - это факт. Думаю, начинающим разработчикам может быть полезно и системным аналитикам.
А про хореографию, оркестратор и SAGA, кстати, видео тоже планируется.
Как минимум разрабам не по стэку. Например фронтам
Для менеджеров полезно, для общего понимания.
Системным аналитикам 👌
В смысле у REST нет схемы данных? Это как говорить, что у SOAP нет кэширования. Все есть, просто никто не заморачивается. Или JSON Schema или Avro Schema уже на обочине где-то валяются?
В статье специально проговариавается, что в REST нет именно обязательной схемы, в отличии от того же gRPC или SOAP. А про кэширование SOAP - на уровне самого протокола его действительно нет, но это не значит, что его нельзя реализовать на уровнях клиента, прокси, сервера приложений, БД и пр. - согласен.
Еще прикольно слышать про "высокую нагрузку" и не приспособленность к ней REST. О каких RPS речь? В плане именно потолка RPS сам по себе REST не сильно уступает тому же gRPC (формирование бинарников и их расшифровка дают 100-150 мс край). При высоких нагрузках узким горлышком становится чаще БД, чем конкретный протокол общения
Тут, думаю, слегка преувеличено про "неприспособленность REST к высоким нагрузкам". Речь больше про то, что есть определённая грань нагрузки, когда время на сериализацию/десериализацию protobuf компенсируются скоростью передачи данных. На маленьких нагрузках - действительно смысла нет - можем только ухудшить ситуацию. На больших (по конкертике есть исследования, где находится эта грань целесообразности, поищу, скину) - gRPC будет уже эффективнее. Ну и стриминг у gRPC. И жёсткий контракт.
@@ListenIT_channel Ну тут я докапывался, конечно же, к формулировке именно. Понятное дело, что на масштабах в несколько десятков тысяч RPS REST начнет проигрывать gRPC, но это ни то, чтобы супер частый кейс, когда системы сталкиваются с такими нагрузками. Там и голый gRPC вряд ли сам по себе справится - придется придумывать что-то помимо смены протокола
Текст в видео и аудио различаются, как результат, картинка только сбивает с толку
почему ассинхронность это откладывание запроса? Разве это не просто паралельное выполнение запросов??
параллельная обработка и подразумевает ответить потом
Асинхронность и параллельность это вообще разное
Первое значит существование отправителя и получателя в разных временных системах. Второе это одновременное выполнение процессов, ну или псевдопараллельное чаще.
Как можно выполнить отправку запроса одновременно с приемом? Тахионные сети не изобрели еще
Еще есть unix сокеты и кастомные протоколы. Ну и про кролика рассказать бы более глубоко.
13:28 а база данных зачем? а если есть база данных, то можно и вьюшку со статусами нарисоввть...
что думаешь про redis в качестве асинхронного месенджика?
Для быстрого старта может и сойдёт, но в долгой перспективе мертвая идея. Pub/sub работает крайне схоже на udp и ему пофиг доставлено ли сообщение или нет.
Я работаю с редисом в качестве брокера, в целом норм, зависит от нагрузки офк, если редиса мало то смотри в строку кролика
брокера? @@augustsionis6542
И для чего нам эти вырезки из книг и статей? Тут нет ответа на вопрос из тайтла: Как соединить микросервисы. Тема сисек не раскрыта, так сказать! 😄
Автор попытался, видимо, раскрыть чем связать, а не как
Лучше бы объяснили на деле как происходит связь , типы связи ничего дали
РЕСТом не пользовался?
12:24 автор сокрушается о том, что сложно выпоонять все быстро и гарантировать получать ответы о передаче данных, но при этом топит за бродкаст...
Почему не используются базы данных для обмена данными между микросервисами в рамках одного проекта? Допустим все сервисы проекта имеют доступы к бд, обмениваться сообщениями они могут через таблицы…
Как правило, табличные базы данных, это узкие места любого проекта. Они потребляют относительно много ресурсов и времени на работу. Можно конечно использовать для обмена сообщениями тот же Redis, но в этом нет особого смысла так как полноценные брокеры сообщений используют более оптимизированные решения под капотом и уже имеют свой api
Почему, используется.
кажется такая архитектура есть, и его называют монолит, нет?))
если нагрузка небольшая, то можно и через таблицы в реляционной бд имитировать асинхронную очередь.
Но при росте нагрузки и/или числа конкурентных пользователей быстро встанут вопросы настройки уровней изоляции транзакций, блокировок записей в этой общей таблице, что в итоге ради соблюдения ACID не даст хорошей производительности.
А вот специализированные решения для асинхронных очередей сообщений используя более эффективные структуры данных (например LSM-tree вместо типичного для реляционных субд B-Tree), всякие lock-free очереди и т.п., и в целом при другом наборе требований к таким системам, дают лучшую (а и иногда предельно возможную) производительность для задач "отправки сообщений"
PS: кстати, использования имитации очередей на базе реляционных субд, дает возможность на более ранних стадиях проекта подумать о снижении связности между компонентами системы, ввести необходимые разрезы функционала по асинхронности взаимодействия, а иногда и задуматься о возможных паттернах асинхронного взаимодействия - все это пригодиться при дальнейшем росте проекта. А уже потом при необходимости доучить специфику всяких RabbitMQ и Kafka, когда нагрузка этого потребует.
1
вы когда употребляете англицизмы то делайте перевод ,вы же не для себя родного это видео сделали ?
"Оверхед" - это термин, который используется для описания дополнительных расходов или затрат, которые не связаны непосредственно с производством или продажей товара или услуги.
Так все в АйТи делают чтобы демонстрировать свою шаристость
@@Jansisoev пантуются , умный человек всегда сможет доступно объяснить другому.
Да, реклама отличная, правда отбор, как у фашистов. Меня и моих коллег, фронтенд разрабов не пустили, то есть на почту пришли отказы. Ну ок, чё
Сейчас разберёмся, в чём тут проблема.
@@ListenIT_channel короче моего кореша взяли, у нас было только одно отличие, он написал «фронтенд разработчик» в регистрации, а я «программист-разработчик». Если получится решить проблему и меня запишут на митап авито.тех, в губы тебя расцелую(гетеросексуальная шутка)
Получил официальный ответ от AvitoTech, вот, что ребята пишут:
«К сожалению, возможности площадки физически ограничены, и она не может вместить всех-всех желающих. Все заявки мы одобряли вручную, и, если кому-то пришёл отказ, то, к сожалению, это означает, что офлайн-билетов попросту не осталось.
Мы благодарны всем за интерес к нашему мероприятию! Кстати, можно будет посмотреть онлайн-трансляцию по ссылке: czcams.com/video/h38Ku-0KbOI/video.html »
@@ListenIT_channel ну короче работают они так себе. Спасибо, что выяснил, они мне ответили тоже самое.
Но коллегу моего, с таким же стажем и профилем - взяли, а я зарегестрировался на пару часов раньше. Слишком странно, ну да ладно. Спасибо, за уделенное тобой мне внимание)
@@ska6391 Привет! С конференцией действительно не получается уже совсем никак :( Но мы ждём вас на наших митапах и других мероприятиях!