Отличная идея. Многое хочется прочитать, но глаза и так устают. А послушать можно и во время прогулки. Особенно если интересная тема. Молодцы! Спасибо!
@gzhegow21 күн бұрын
Ожидал увидеть организацию узла связи микросервисов (саги, транзакции на нескольких машинах), увидел описание обмена и "готовых пакетов". РРРРРРРРРРРРРРРРРРРР.........
@user-gh6ce1ht6vАй бұрын
Полезное видео, спасибо! 🙏
@globerider_16 күн бұрын
Спасибо, интересно:)
@user-oy2sx7jb4dАй бұрын
Чпачибо ❤
@Ntap13Ай бұрын
А какая целевая "маленькая" аудитория? Если будут смотреть НЕ айтишники, то вряд ли что-то поймут. А если будут смотреть разрабы по стэку, то информация слишком простая и базовая. Самые актуальные и важные способы взаимодействия с оркестратором и перераспределением нагрузки тут опущены (хореография и агрегатор). Не рассмотрен ни один паттерн (stangler, SAGA). Просто если авторы статьи сами новички в вопросах архитектуры микросервисов, то не понятно зачем их статью читать. А если информация намеренно упрощена и сжата, то не ясно кому это будет полезно. Автору канала большое спасибо за труд. Лайк и подписка за труды и приятную подачу
@ListenIT_channelАй бұрын
Спасибо за фидбек! Тут автор дал общую информацию по интеграции - не думаю, что её можно рассматривать как исчерпывающую по интеграции микросервисов - это факт. Думаю, начинающим разработчикам может быть полезно и системным аналитикам. А про хореографию, оркестратор и SAGA, кстати, видео тоже планируется.
@utabpe1038Ай бұрын
Как минимум разрабам не по стэку. Например фронтам
@123456782198124 күн бұрын
Для менеджеров полезно, для общего понимания.
@stiviek713715 күн бұрын
Системным аналитикам 👌
@MrPushcartАй бұрын
Хм, странный пример про кафку и менеджера который не видит - начала ли исполнятся заявка или нет. Это решается посредством системы которая собирает и отображает статусы заявки на каждом этапе исполнения. Менеджер посмотрит что заявка в статусе - инициализирована. Но не в статусе - обрабатывается, к примеру. И все. Можно еще алерт сделать если заявка слишком долго в каком то статусе зависла Но вообще event driven архитектура это не универсальное решение, надо думать о компромиссах. Хотя при сверх высокой нагрузке и куче микросервисов ничего лучше наверное и не найти
@ListenIT_channelАй бұрын
Да, автор так и говорит, что его ситуация - когда нет обратной связи для менеджера (ни синхронной, ни асинхронной). Согласен, это немного странно выглядит, но, видимо, какие-то ограничения были на проекте.
@ftb2024_officialАй бұрын
ПОЛЕЗНО и ИНФОРМАТИВНО
@llRub3NllАй бұрын
интересно что ничего про ГрафКюЭль, наверное автор не сталкивался)) спасибо за видео
@itdev4680Ай бұрын
О покойниках либо хорошо либо ничего
@ListenIT_channelАй бұрын
Есть такое. Про GraphQL можно глянуть отдельное подробное видео kzfaq.info/get/bejne/jtGoaNqj1LXYZ6M.htmlsi=CnJaN2tq21jK2h56 и сравнение с другими методами интеграции kzfaq.info/get/bejne/ebGpZLGhydXUn2w.htmlsi=Gnoyhsxq_c7qL2Wn
@sphardegod5451Ай бұрын
@@itdev4680почему о покойниках? не приходилось работать, но в проекте предстоит, интересно почему так считаете
@N5O1Ай бұрын
имхо graphql, rest, grpc и soap (с этим не работал) отличаются только количеством оверхеда, который тебе нужно добавить в код. это все надстройки над http и принципиальной разницы между ними нет
@ListenIT_channelАй бұрын
@@N5O1 есть разница, как с ними работать, как сложно их поддерживать и составлять контракт, поддерживать обратную совместимость, и насколько хорошая у них пропускная способность. Ну и всё-таки не сказал бы, что правильно будет сказать "http - всё одна фигня" - http/2 в случае gRPC довольно существенно отличается от рестового http.
@XBeatusАй бұрын
В смысле у REST нет схемы данных? Это как говорить, что у SOAP нет кэширования. Все есть, просто никто не заморачивается. Или JSON Schema или Avro Schema уже на обочине где-то валяются?
@ListenIT_channelАй бұрын
В статье специально проговариавается, что в REST нет именно обязательной схемы, в отличии от того же gRPC или SOAP. А про кэширование SOAP - на уровне самого протокола его действительно нет, но это не значит, что его нельзя реализовать на уровнях клиента, прокси, сервера приложений, БД и пр. - согласен.
@user-wt9ej6tl2iАй бұрын
Было интересно
@XBeatusАй бұрын
Еще прикольно слышать про "высокую нагрузку" и не приспособленность к ней REST. О каких RPS речь? В плане именно потолка RPS сам по себе REST не сильно уступает тому же gRPC (формирование бинарников и их расшифровка дают 100-150 мс край). При высоких нагрузках узким горлышком становится чаще БД, чем конкретный протокол общения
@ListenIT_channelАй бұрын
Тут, думаю, слегка преувеличено про "неприспособленность REST к высоким нагрузкам". Речь больше про то, что есть определённая грань нагрузки, когда время на сериализацию/десериализацию protobuf компенсируются скоростью передачи данных. На маленьких нагрузках - действительно смысла нет - можем только ухудшить ситуацию. На больших (по конкертике есть исследования, где находится эта грань целесообразности, поищу, скину) - gRPC будет уже эффективнее. Ну и стриминг у gRPC. И жёсткий контракт.
@XBeatusАй бұрын
@@ListenIT_channel Ну тут я докапывался, конечно же, к формулировке именно. Понятное дело, что на масштабах в несколько десятков тысяч RPS REST начнет проигрывать gRPC, но это ни то, чтобы супер частый кейс, когда системы сталкиваются с такими нагрузками. Там и голый gRPC вряд ли сам по себе справится - придется придумывать что-то помимо смены протокола
@user-fp5wm3mc6yАй бұрын
что думаешь про redis в качестве асинхронного месенджика?
@amigocom1301Ай бұрын
Для быстрого старта может и сойдёт, но в долгой перспективе мертвая идея. Pub/sub работает крайне схоже на udp и ему пофиг доставлено ли сообщение или нет.
@augustsionis654228 күн бұрын
Я работаю с редисом в качестве брокера, в целом норм, зависит от нагрузки офк, если редиса мало то смотри в строку кролика
@chatoyluck402222 күн бұрын
брокера? @@augustsionis6542
@MachineLearningSpecialis-bh7csАй бұрын
почему ассинхронность это откладывание запроса? Разве это не просто паралельное выполнение запросов??
@burialstanceАй бұрын
параллельная обработка и подразумевает ответить потом
@LuckyCatAlex26 күн бұрын
Асинхронность и параллельность это вообще разное Первое значит существование отправителя и получателя в разных временных системах. Второе это одновременное выполнение процессов, ну или псевдопараллельное чаще. Как можно выполнить отправку запроса одновременно с приемом? Тахионные сети не изобрели еще
@StanleyFishmanАй бұрын
Еще есть unix сокеты и кастомные протоколы. Ну и про кролика рассказать бы более глубоко.
@N5O1Ай бұрын
13:28 а база данных зачем? а если есть база данных, то можно и вьюшку со статусами нарисоввть...
@user-pt8pz6ew3d20 күн бұрын
Текст в видео и аудио различаются, как результат, картинка только сбивает с толку
@RomaFromHell1Ай бұрын
Почему не используются базы данных для обмена данными между микросервисами в рамках одного проекта? Допустим все сервисы проекта имеют доступы к бд, обмениваться сообщениями они могут через таблицы…
@TZPrototypeАй бұрын
Как правило, табличные базы данных, это узкие места любого проекта. Они потребляют относительно много ресурсов и времени на работу. Можно конечно использовать для обмена сообщениями тот же Redis, но в этом нет особого смысла так как полноценные брокеры сообщений используют более оптимизированные решения под капотом и уже имеют свой api
@lastsp9990Ай бұрын
Почему, используется.
@llRub3NllАй бұрын
кажется такая архитектура есть, и его называют монолит, нет?))
@andreybarkАй бұрын
если нагрузка небольшая, то можно и через таблицы в реляционной бд имитировать асинхронную очередь. Но при росте нагрузки и/или числа конкурентных пользователей быстро встанут вопросы настройки уровней изоляции транзакций, блокировок записей в этой общей таблице, что в итоге ради соблюдения ACID не даст хорошей производительности. А вот специализированные решения для асинхронных очередей сообщений используя более эффективные структуры данных (например LSM-tree вместо типичного для реляционных субд B-Tree), всякие lock-free очереди и т.п., и в целом при другом наборе требований к таким системам, дают лучшую (а и иногда предельно возможную) производительность для задач "отправки сообщений"
@andreybarkАй бұрын
PS: кстати, использования имитации очередей на базе реляционных субд, дает возможность на более ранних стадиях проекта подумать о снижении связности между компонентами системы, ввести необходимые разрезы функционала по асинхронности взаимодействия, а иногда и задуматься о возможных паттернах асинхронного взаимодействия - все это пригодиться при дальнейшем росте проекта. А уже потом при необходимости доучить специфику всяких RabbitMQ и Kafka, когда нагрузка этого потребует.
@RasimAlimgukov24 күн бұрын
Лучше бы объяснили на деле как происходит связь , типы связи ничего дали
@vsezanyato22 күн бұрын
РЕСТом не пользовался?
@int3rhardАй бұрын
И для чего нам эти вырезки из книг и статей? Тут нет ответа на вопрос из тайтла: Как соединить микросервисы. Тема сисек не раскрыта, так сказать! 😄
@otahjuelasso130Ай бұрын
Автор попытался, видимо, раскрыть чем связать, а не как
@N5O1Ай бұрын
12:24 автор сокрушается о том, что сложно выпоонять все быстро и гарантировать получать ответы о передаче данных, но при этом топит за бродкаст...
@user-tf6th1zs9s23 күн бұрын
1
@user-hw6dw3np6vАй бұрын
вы когда употребляете англицизмы то делайте перевод ,вы же не для себя родного это видео сделали ? "Оверхед" - это термин, который используется для описания дополнительных расходов или затрат, которые не связаны непосредственно с производством или продажей товара или услуги.
@Jansisoev21 күн бұрын
Так все в АйТи делают чтобы демонстрировать свою шаристость
@user-hw6dw3np6v21 күн бұрын
@@Jansisoev пантуются , умный человек всегда сможет доступно объяснить другому.
@ska6391Ай бұрын
Да, реклама отличная, правда отбор, как у фашистов. Меня и моих коллег, фронтенд разрабов не пустили, то есть на почту пришли отказы. Ну ок, чё
@ListenIT_channelАй бұрын
Сейчас разберёмся, в чём тут проблема.
@ska6391Ай бұрын
@@ListenIT_channel короче моего кореша взяли, у нас было только одно отличие, он написал «фронтенд разработчик» в регистрации, а я «программист-разработчик». Если получится решить проблему и меня запишут на митап авито.тех, в губы тебя расцелую(гетеросексуальная шутка)
@ListenIT_channelАй бұрын
Получил официальный ответ от AvitoTech, вот, что ребята пишут: «К сожалению, возможности площадки физически ограничены, и она не может вместить всех-всех желающих. Все заявки мы одобряли вручную, и, если кому-то пришёл отказ, то, к сожалению, это означает, что офлайн-билетов попросту не осталось. Мы благодарны всем за интерес к нашему мероприятию! Кстати, можно будет посмотреть онлайн-трансляцию по ссылке: kzfaq.info/get/bejne/nplofthelbHGf30.html »
@ska6391Ай бұрын
@@ListenIT_channel ну короче работают они так себе. Спасибо, что выяснил, они мне ответили тоже самое. Но коллегу моего, с таким же стажем и профилем - взяли, а я зарегестрировался на пару часов раньше. Слишком странно, ну да ладно. Спасибо, за уделенное тобой мне внимание)
@AvitoTechАй бұрын
@@ska6391 Привет! С конференцией действительно не получается уже совсем никак :( Но мы ждём вас на наших митапах и других мероприятиях!