Как соединить МИКРОСЕРВИСЫ между собой

[@alexanderspiegel6747]

Отличная идея. Многое хочется прочитать, но глаза и так устают. А послушать можно и во время прогулки. Особенно если интересная тема. Молодцы! Спасибо!

[@gzhegow]

Ожидал увидеть организацию узла связи микросервисов (саги, транзакции на нескольких машинах), увидел описание обмена и "готовых пакетов". РРРРРРРРРРРРРРРРРРРР.........

[@globerider_]

Спасибо, интересно:)

[@Иван-н6р6п]

Полезное видео, спасибо! 🙏

[@oshastitko]

более старенькое - это как раз RPC, я этот подход реализовывал ещё в 2001-м году на с++, когда нужно было вызвать данные с одного приложения в другом, находящимся в другом офисе в другой части нашего города, соединённых диалапом :) То, что гугл это обернул в новую обёртку - это не значит, что оно стало новым. RPC - самый старый подход вызовов из всех 3-х рассмотренных технологий

[@ListenIT_channel]

Тут больше вопрос не в том, что "старее", а в том, что более актуальное и не устарело) RPC явно себя сейчас хорошо чувствует, а вот SOAP всё больше устаревает.

[@oshastitko]

@@ListenIT_channel с этим полностью соглашусь, SOAP своё отжил (наверное :) ). ЗЫ. Эх, сколько я их написал в своё время....

[@XBeatus]

Еще прикольно слышать про "высокую нагрузку" и не приспособленность к ней REST. О каких RPS речь? В плане именно потолка RPS сам по себе REST не сильно уступает тому же gRPC (формирование бинарников и их расшифровка дают 100-150 мс край). При высоких нагрузках узким горлышком становится чаще БД, чем конкретный протокол общения

[@ListenIT_channel]

Тут, думаю, слегка преувеличено про "неприспособленность REST к высоким нагрузкам". Речь больше про то, что есть определённая грань нагрузки, когда время на сериализацию/десериализацию protobuf компенсируются скоростью передачи данных. На маленьких нагрузках - действительно смысла нет - можем только ухудшить ситуацию. На больших (по конкертике есть исследования, где находится эта грань целесообразности, поищу, скину) - gRPC будет уже эффективнее. Ну и стриминг у gRPC. И жёсткий контракт.

[@XBeatus]

@@ListenIT_channel Ну тут я докапывался, конечно же, к формулировке именно. Понятное дело, что на масштабах в несколько десятков тысяч RPS REST начнет проигрывать gRPC, но это ни то, чтобы супер частый кейс, когда системы сталкиваются с такими нагрузками. Там и голый gRPC вряд ли сам по себе справится - придется придумывать что-то помимо смены протокола

[@ИванСударик]

что думаешь про redis в качестве асинхронного месенджика?

[@amigocom1301]

Для быстрого старта может и сойдёт, но в долгой перспективе мертвая идея. Pub/sub работает крайне схоже на udp и ему пофиг доставлено ли сообщение или нет.

[@augustsionis6542]

Я работаю с редисом в качестве брокера, в целом норм, зависит от нагрузки офк, если редиса мало то смотри в строку кролика

[@chatoyluck4022]

брокера? ​@@augustsionis6542

[@wsxpocxeafx]

3:08 что такое "утилизация памяти"? Это жаргон или речь про утилизацию жёсткого диска после его поломки?

[@wsxpocxeafx]

Про поломку диска шутка, но кто вас знает, может быть я угадал. Я же думаю, что под словом "утилизация" подразумевается слово "использование", возможно, "эффективное использование". Надеюсь, это не жаргон, а вполне нормальные слова, которых я не понимаю почему-то.

[@XBeatus]

В смысле у REST нет схемы данных? Это как говорить, что у SOAP нет кэширования. Все есть, просто никто не заморачивается. Или JSON Schema или Avro Schema уже на обочине где-то валяются?

[@ListenIT_channel]

В статье специально проговариавается, что в REST нет именно обязательной схемы, в отличии от того же gRPC или SOAP. А про кэширование SOAP - на уровне самого протокола его действительно нет, но это не значит, что его нельзя реализовать на уровнях клиента, прокси, сервера приложений, БД и пр. - согласен.

[@СултанАбдрахманов-ц2ю]

Чпачибо ❤

[@llRub3Nll]

интересно что ничего про ГрафКюЭль, наверное автор не сталкивался)) спасибо за видео

[@itdev4680]

О покойниках либо хорошо либо ничего

[@ListenIT_channel]

Есть такое. Про GraphQL можно глянуть отдельное подробное видео kzbin.info/www/bejne/jpzbZqqopLSnbdEsi=CnJaN2tq21jK2h56 и сравнение с другими методами интеграции kzbin.info/www/bejne/eXzcYoGmmdSjpZosi=Gnoyhsxq_c7qL2Wn

[@sphardegod5451]

​​@@itdev4680почему о покойниках? не приходилось работать, но в проекте предстоит, интересно почему так считаете

[@N5O1]

имхо graphql, rest, grpc и soap (с этим не работал) отличаются только количеством оверхеда, который тебе нужно добавить в код. это все надстройки над http и принципиальной разницы между ними нет

[@ListenIT_channel]

​@@N5O1 есть разница, как с ними работать, как сложно их поддерживать и составлять контракт, поддерживать обратную совместимость, и насколько хорошая у них пропускная способность. Ну и всё-таки не сказал бы, что правильно будет сказать "http - всё одна фигня" - http/2 в случае gRPC довольно существенно отличается от рестового http.

[@ftb2024_official]

ПОЛЕЗНО и ИНФОРМАТИВНО

[@MachineLearningSpecialis-bh7cs]

почему ассинхронность это откладывание запроса? Разве это не просто паралельное выполнение запросов??

[@burialstance]

параллельная обработка и подразумевает ответить потом

[@LuckyCatAlex]

Асинхронность и параллельность это вообще разное Первое значит существование отправителя и получателя в разных временных системах. Второе это одновременное выполнение процессов, ну или псевдопараллельное чаще. Как можно выполнить отправку запроса одновременно с приемом? Тахионные сети не изобрели еще

[@MrPushcart]

Хм, странный пример про кафку и менеджера который не видит - начала ли исполнятся заявка или нет. Это решается посредством системы которая собирает и отображает статусы заявки на каждом этапе исполнения. Менеджер посмотрит что заявка в статусе - инициализирована. Но не в статусе - обрабатывается, к примеру. И все. Можно еще алерт сделать если заявка слишком долго в каком то статусе зависла Но вообще event driven архитектура это не универсальное решение, надо думать о компромиссах. Хотя при сверх высокой нагрузке и куче микросервисов ничего лучше наверное и не найти

[@ListenIT_channel]

Да, автор так и говорит, что его ситуация - когда нет обратной связи для менеджера (ни синхронной, ни асинхронной). Согласен, это немного странно выглядит, но, видимо, какие-то ограничения были на проекте.

[@StanleyFishman]

Еще есть unix сокеты и кастомные протоколы. Ну и про кролика рассказать бы более глубоко.

[@АндрейАйкарамба]

Было интересно

[@N5O1]

13:28 а база данных зачем? а если есть база данных, то можно и вьюшку со статусами нарисоввть...

[@Ntap13]

А какая целевая "маленькая" аудитория? Если будут смотреть НЕ айтишники, то вряд ли что-то поймут. А если будут смотреть разрабы по стэку, то информация слишком простая и базовая. Самые актуальные и важные способы взаимодействия с оркестратором и перераспределением нагрузки тут опущены (хореография и агрегатор). Не рассмотрен ни один паттерн (stangler, SAGA). Просто если авторы статьи сами новички в вопросах архитектуры микросервисов, то не понятно зачем их статью читать. А если информация намеренно упрощена и сжата, то не ясно кому это будет полезно. Автору канала большое спасибо за труд. Лайк и подписка за труды и приятную подачу

[@ListenIT_channel]

Спасибо за фидбек! Тут автор дал общую информацию по интеграции - не думаю, что её можно рассматривать как исчерпывающую по интеграции микросервисов - это факт. Думаю, начинающим разработчикам может быть полезно и системным аналитикам. А про хореографию, оркестратор и SAGA, кстати, видео тоже планируется.

[@utabpe1038]

Как минимум разрабам не по стэку. Например фронтам

[@1234567821981]

Для менеджеров полезно, для общего понимания.

[@stiviek7137]

Системным аналитикам 👌

[@МаркСеменов-ю2ъ]

Текст в видео и аудио различаются, как результат, картинка только сбивает с толку

[@RomaFromHell1]

Почему не используются базы данных для обмена данными между микросервисами в рамках одного проекта? Допустим все сервисы проекта имеют доступы к бд, обмениваться сообщениями они могут через таблицы…

[@TZPrototype]

Как правило, табличные базы данных, это узкие места любого проекта. Они потребляют относительно много ресурсов и времени на работу. Можно конечно использовать для обмена сообщениями тот же Redis, но в этом нет особого смысла так как полноценные брокеры сообщений используют более оптимизированные решения под капотом и уже имеют свой api

[@lastsp9990]

Почему, используется.

[@llRub3Nll]

кажется такая архитектура есть, и его называют монолит, нет?))

[@andreybark]

если нагрузка небольшая, то можно и через таблицы в реляционной бд имитировать асинхронную очередь. Но при росте нагрузки и/или числа конкурентных пользователей быстро встанут вопросы настройки уровней изоляции транзакций, блокировок записей в этой общей таблице, что в итоге ради соблюдения ACID не даст хорошей производительности. А вот специализированные решения для асинхронных очередей сообщений используя более эффективные структуры данных (например LSM-tree вместо типичного для реляционных субд B-Tree), всякие lock-free очереди и т.п., и в целом при другом наборе требований к таким системам, дают лучшую (а и иногда предельно возможную) производительность для задач "отправки сообщений"

[@andreybark]

PS: кстати, использования имитации очередей на базе реляционных субд, дает возможность на более ранних стадиях проекта подумать о снижении связности между компонентами системы, ввести необходимые разрезы функционала по асинхронности взаимодействия, а иногда и задуматься о возможных паттернах асинхронного взаимодействия - все это пригодиться при дальнейшем росте проекта. А уже потом при необходимости доучить специфику всяких RabbitMQ и Kafka, когда нагрузка этого потребует.

[@wsxpocxeafx]

8:21 Что такое утилизация трафика?

[@RasimAlimgukov]

Лучше бы объяснили на деле как происходит связь , типы связи ничего дали

[@vsezanyato]

РЕСТом не пользовался?

[@N5O1]

12:24 автор сокрушается о том, что сложно выпоонять все быстро и гарантировать получать ответы о передаче данных, но при этом топит за бродкаст...

[@ildarnasyrov5357]

Пожалуйста, не делайте примеры из реальной жизни. Я про гонца. Давайте более точное определение. Отправляем сообщение (по http, tcp...) в какой то момент какой то сервис перестал работать и тд... Спасибо)

[@ListenIT_channel]

@@ildarnasyrov5357 дело в том, что Задача двух генералов - это не просто мой пример, а известный вопрос, который поднимается в вычислительной технике, когда возникает проблема синхронизации информации в двух системах.

[@int3rhard]

И для чего нам эти вырезки из книг и статей? Тут нет ответа на вопрос из тайтла: Как соединить микросервисы. Тема сисек не раскрыта, так сказать! 😄

[@otahjuelasso130]

Автор попытался, видимо, раскрыть чем связать, а не как

[@GarnetPetix]

1

[@VolodymyrChernigiv1300]

Ужасающе нудно

[@Александр-ъ3с3ж]

вы когда употребляете англицизмы то делайте перевод ,вы же не для себя родного это видео сделали ? "Оверхед" - это термин, который используется для описания дополнительных расходов или затрат, которые не связаны непосредственно с производством или продажей товара или услуги.

[@Jansisoev]

Так все в АйТи делают чтобы демонстрировать свою шаристость

[@Александр-ъ3с3ж]

@@Jansisoev пантуются , умный человек всегда сможет доступно объяснить другому.

[@ska6391]

Да, реклама отличная, правда отбор, как у фашистов. Меня и моих коллег, фронтенд разрабов не пустили, то есть на почту пришли отказы. Ну ок, чё

[@ListenIT_channel]

Сейчас разберёмся, в чём тут проблема.

[@ska6391]

@@ListenIT_channel короче моего кореша взяли, у нас было только одно отличие, он написал «фронтенд разработчик» в регистрации, а я «программист-разработчик». Если получится решить проблему и меня запишут на митап авито.тех, в губы тебя расцелую(гетеросексуальная шутка)

[@ListenIT_channel]

Получил официальный ответ от AvitoTech, вот, что ребята пишут: «К сожалению, возможности площадки физически ограничены, и она не может вместить всех-всех желающих. Все заявки мы одобряли вручную, и, если кому-то пришёл отказ, то, к сожалению, это означает, что офлайн-билетов попросту не осталось. Мы благодарны всем за интерес к нашему мероприятию! Кстати, можно будет посмотреть онлайн-трансляцию по ссылке: kzbin.info/www/bejne/nmSbfKhjZbCVhas »

[@ska6391]

@@ListenIT_channel ну короче работают они так себе. Спасибо, что выяснил, они мне ответили тоже самое. Но коллегу моего, с таким же стажем и профилем - взяли, а я зарегестрировался на пару часов раньше. Слишком странно, ну да ладно. Спасибо, за уделенное тобой мне внимание)

[@AvitoTech]

@@ska6391 Привет! С конференцией действительно не получается уже совсем никак :( Но мы ждём вас на наших митапах и других мероприятиях!