Привет Это канал lon it и сегодня мы слушаем статью способ общения микросервисов для самых маленьких от коллектива мак селекта и автора Дмитрия Литвина который написал эту статью на сайте hub.com Спасибо коллективу и автору за статью и ссылочка на статью Конечно будет в описании к этому видео Ну а пока мы не начали Я бы вам хотел рассказать об одном классном мероприятии которое проходит в it сообществе Авито тех устраивает свою собственную конференцию Avita All Day Long кто и как создаёт крупнейший в мире classified по пользователей можно не просто узнать А пообщаться повор сыграть в квиз и остаться
на автопати с этими людьми в программе там доклады и дискуссии по трендам индустрии коллеги поделятся опытом и решениями которые вы сможете использовать для себя как по хордам например платформенные инструменты L код Back driven UI и Ops с нуля так и по софта техника формулировки правильных вопросов команде И главное самому себе И решение конфликтов продуктов и тем лидов А ещё сможете пощупать технологические продукты теха MC Авито плата и Sigma на конф будут представлены демо станции Где у вас будет шанс затестил гов на рынке avit Old Long пройдёт 20 июля в центре событий РБК в Москве это
будет большой день в большом техе тебе там нужно быть так что прыгай по ссылочки в описании и регистрируйся на Avita All Day Long но Мы возвращаемся к нашим микросервиса микросервисная архитектура Ну давайте скажем честно она сейчас популярно сейчас даже если речь идёт о создании одного небольшого приложения как правило его реализуют в виде пачки микросервисов которые запущены отдельно И как-то реплицируемый говорили что если у вас небольшое приложение то в микросервисах смысла особо нет сейчас уже даже на маленьких приложениях иногда это делается так как эти микросервисы между собой будут взаимодействовать Давайте начнём с того почему вообще об
этом нужно задумываться мы разворачиваем сервисы в облаках как правило это означает что и общение микросервиса будет происходить по сети разные экзотические и эзотерические способы Мы в этой статье рассматривать не будем а общение микросервиса по сети тащит за собой много проблем например проблема доступности мы не знаем Какой из микросервисов сейчас доступен для общения А какой упал или потерял Коннект также задержка передачи потери и дублирования пакетов то есть мы думаем что отправили пакет Но получатель его не принял или получил в двойном экземпляре и нам об этом ничего не известно хорошо иллюстрирует проблему Так называемая задача двух генералов
Представьте что вы генерал на поле боя второй генерал ваш союзник он отрезан от вас вражеской армии но нужно координировать с ним начало атаки посылаете Гонца он может спокойно доехать и передать сообщение или же погибнуть по дороге причём его ещё могут убить по пути обратно То есть он вам не сможет сообщить что сообщение на самом деле уже доставлено Можно ли в этой ситуации обеспечить себе уверенность в доставке или не доставке сообщения в общем случае когда есть два сервиса разделённых сетью эта задача не особо решаема ссылку на Википедию по этой задаче я оставлю в описании можете почитать
и ещё одна проблема - это нагрузка на трафик и память сервисы бывают нагруженные поэтому общение приходится оптимизировать от этого всё становится сложнее естественно если использовать какие-то асинхронные системы общения то Придётся хранить информацию какое-то время А значит появляется вопрос к утилизации памяти или диска но при всех этих проблемах хочется чтобы общение было отказ устойчивым часто бывает что сервисы падают каскадом один у бал запрос не обрабатывает вслед за ним валятся другие сервисы которые его вызывали всё от того что они не могут получить ответ на свой запрос так по цепочке происходит полный коллапс А ещё всё это общение
нужно как-то поддерживать реализовать API один раз несложно и с этим справится каждый разработчик А вот создать API так чтобы можно было удобно вносить в него изменения это уже более хитрая задача с учётом противоречивых требований которые мы сейчас описали нам доступен целый зоопарк разнородных решений в разных комбинациях они дают ответы на те вопросы которые мы сейчас озвучили при этом идеального варианта конечно не существует во-первых У нас есть синхронные способы общения то есть мы делаем вызов и ждём чение ответа среди них у нас есть синхронный rest like и аналоги в чистом виде rest встречается довольно редко но
в целом он конечно один из самых популярных При желании через костели его можно сделать асинхронным но этот случай Мы тут пока не будем рассматривать также из синхронных У нас есть grpc это rpc удалённый вызов процедур на бинарном формате сообщений поверх http2 от Google и также у нас есть so это rpc с форматом xml это решение очень любили использовать в энтерпрайз и оно чаще встречается в более старых системах Ну конечно если подробнее хотите про послушать про PC и про SOP вы можете послушать отдельные видео у нас про них всё было записано уже Советую послушать с популярными
синхронными решениями разобрались какие у нас есть асинхронные способы общения Что это значит Это когда мы отправляем сообщение а ответ придёт когда-нибудь потом или он в принципе не предусмотрен у нас есть медн например через rabit MQ zer MQ Или например Active MQ они все разные и об этом мы далее поговорим Есть стриминг например кавка в принципе кавка похожа на мессенджер платформу но автор выделил её отдельно так как отличия всё-таки есть опять же и отдельные видео про rabit MQ и про кафку и совместное видео про их сравнение между собой всё это уже есть на канале ссылочку в
описании обязательно оставлю ну а дальше автор предлагает пройтись по основным инструментам с которыми автор лично сталкивался в работе Ну а продвинутых слушателей приглашаем в комментарии дополнить этот опыт как всегда начнём с нашего любимого самого популярного rest API по автора 90% сервисов работает на rest API это отправная точка с которой все начинают его так любят потому что во-первых нужен минимум библиотек как клиенту так и серверу http у нас и так работает в json можно писать или читать стрин такой API легко вызывать с фронта легко прочитать ответ сервера из JavaScript с помощью gson парсера также довольно лёгкий
Старт для потребления API узнал endpoint посмотрел пример запроса ответа и можно начинать общение также довольно удобно что это текстовый формат легко дебажить и логировать видя что у него внутри в сообщении админы его любят за то что можно заглядывать в данные http запроса и что-то с ними делать например настраивать роутинг трафика на основе данных http запросов L7 или балансировку нагрузки по полю ID из запроса Ну и конечно у реста лёгкая для понимания синхронная парадигма запрос Ответ здесь нет подводных камней ответ либо получен тут же либо нет но во всей этой простоте есть свои проблемы каждый из
особенностей rest API который делает е столь простым и популярным на самом деле имеет оборотную сторону во-первых он синхронный если вызываемый сервис недоступен нельзя отложить передачу или получение информации на более позднее время если какой-то простой батч должен передать сообщение и завершиться но получатель лежит то будут проблемы второе - это Пир to Пир нужно обращаться напрямую к искомому сервису более того здесь нет бродкастинг то есть если нужно отправить одни и те же данные в пять разных сервисов то Придётся сделать пять запросов сервисы получаются более связанными и могут погибать в волне отказов то что rest имеет текстовый формат
Тоже имеет свои моменты в жине Много лишних данных это Например ключи значения которые порождают дополнительный трафик компрессия не позволяет сжать так как хотелось бы плюс потребляет процессор для экономии некоторые пытаются назвать ключи компактнее но глобально это не решает проблему также нет схемы данных Вместо неё используют Open API Swag про него тоже Мы отдельно говорили ссылочка в описании будет будет но он внедряется не всегда и в целом Это всего лишь свод рекомендаций а не чёткий закон он может не соответствовать действительности Ну и концепция всё есть ресурс может быть неудобно и непонятно части разработчиков лично автору не
нравится что не все задачи легко решаются в рамках этой концепции иногда не совсем понятно как всё уложить в понятие ресурса Конечно есть уже прижившийся способы описывать разные проблемные случаи вроде изменений статусов объектов но фактически это костыли ито rest API неплохое решение когда нет высоких нагрузок и получается хорошо контролировать доступность микросервисов взаимодействие по rest API проще отслеживать чем асинхронный обмен потому что сразу видно что ответ не приходит или приходит не в том формате дальше медленно переходим к grpc jpc - это достаточно хорошая альтернатива rest что у нас jpc он использует бинарный формат проба у него утилизация
трафика лучше и можно слать только значения не передавая ключи конечно ты не можешь прочитать в консо сообщения глазами как это мог бы сделать с Джейсоном то есть приходится писать дополнительную утилиту которая будет парсить его перед тем как прочитать Зато на больших нагрузках всё это будет лучше работать также у него есть схема данных по которой генерируется dto Data Transfer object на запрос ответ с жёсткой схемой работать удобнее прото бав накладывает ограничения на изменение схемы данных чтобы сохранялась обратная совместимость это И плюс И иногда минус Также можно передавать не один запрос а слать объекты один за другим
то есть стримить jpc в стриминге кстати довольно активно используется у него есть встроенный механизм Back pressure То есть если сообщение отправляются слишком быстро и Получатель не может их переварить этот механизм позволяет замедлить передачу Ну и отправка запроса выглядит как вызов методов в коде используется rpc стиль с вызовом процедур недостаток у него в том что нужно подключать библиотеку jpc для своего языка Но кажется она есть для всех популярных языков в том числе для фронта на JS jpc подходит если у вас в Облаке крутится целый комбайн из кучей микросервисов которым нужно между собой передавать много данных под
высокой нагрузкой для внешних пользователей он конечно не так удобен как СТ Но для внутреннего общения это самое топ потому что здесь жёстко фиксируется схема и потребляется меньше трафика лично автор на высоких нагрузках с jpc никогда не экспериментировал Но кажется что он оптимален там где стоимость трафика выше чем затраты на то чтобы заставить разработчиков читать документацию про добав чтобы они не модифицировать поля там где Нельзя этого делать говорят что Google любит его использовать внутри и есть ощущение что на западе его в целом применяют довольно часто как раз потому что Google пиарит эту тему Ну и Прямо
скажем эта вещь далеко не бесполезная дальше Давайте немножко про более старенькое про соп лично автор не очень любит xml чуть что он перестаёт нормально парси лайзер начинает ругаться по любому поводу и в новых проектах его сейчас довольно редко можно увидеть кроме случаев когда нужно общаться с сервисом который написан лет 15 назад со придумали тогда когда J ещё не был популярен и много Кто пользовался xml сам формат xml сложнее Джена больше разных правил и получается многословно плюс всё это обёрнутый данных и клиентскими библиотеками для генерации rpc запроса и ответ что не очень легковес большого опыта работы
с у автора нет так что и опознать все плюсы и минусы он ещё не успел хотя мы Наше видео про so Помним и предыдущее видео про сравнение rer PC и so тоже помним Ну и в целом автор довольно лаконично здесь описал его минусы дальше ныряем в ндн rabit MQ Zero MQ Active MQ и кавка все перечисленные инструменты занимаются отправкой сообщений они очень разные но в целом верно следующее они обычно синхронные то есть шлёшь сообщение и оно доставится когда-то в будущем никакого запрос ответ есть решение где прямой очереди соответствует обратная очередь для отправки ответа на сообщение
Но это нельзя назвать синхронной историей они бы с брокером и без него но с точки зрения автора именно брокер даёт слабую связанность общению правда бывают кейсы где всё это реализуется очень медленно поэтому брокер иногда считается верхе дом они бывают с хранилищем persistence и без него in Memory в случае отказа брокер с хранилищем например кавка который пишет всё сразу на диск ничего не потеряет правда только при условии что вы позаботились настроить кластер как следует так можно хранить логи например за последние полгода но при чтении старых данных с диска всё по томае а также они бывают с
балансировкой нагрузки и без текстовые и бинарные со схемой данных или без неё с одним получателем или с поддержкой бродкаста автору возможность бродкастинг нравится больше всего можно реализовать модель издатель Подписчик когда тебе не интересно кто подписался на тему твоя задача просто писать в неё сообщения и также они бывают с подтверждением получения и без него выбор системы при реализации собственного проекта - это поиск ответов на частные вопросы нуж или тебе подтверждение доставки или запись на диск И это очень важные ответы потому что они влияют не только на логику работы Но и на производительность автор лично использовал только
кафку Поэтому будет в рассуждениях отталкиваться от неё с одной стороны асинхронные взаимодействие - это конечно круто с другой стороны они тоже не Панацея на одном из проектов где работал автор кавка использовалась для того чтобы передать на БК заявки с фронта который оформляют менеджеры по продажам кажется что это хорошее решение если БК по каким-то причинам не отвечал то за заявка не терялась а попадала в очередь и обрабатывала когда БК восстанавливался с другой стороны при такой схеме взаимодействия команда автора не могла отправить менеджерам ответ Может ли вообще выполниться клиентская заявка менеджер довольно закрывал Окно но на бке
выяснял что заявка не может быть выполнено А у команды Не было никакого канала обратной связи плюс автор постоянно сталкивался с повторно отправленным заявками или отменой уже отменённые потому что сообщения применялись не мгновенно А складывались в очередь и иногда могло пройти несколько часов пока Сообщение обрабатывается Например если сервис лежал в теории здесь можно было бы реализовать обратную очередь или вообще обойтись rest API и в этом случае менеджер бы видел что заявка не обрабатывается и предпринял бы какие-то действия кавка и прочие перечисленные инструменты - это дополнительный слой абстракции который обеспечивает асинхронность и отказоустойчивость он хорошо работает там
где всё это действительно востребовано в сложной архитектуре с большим количеством исполнителей которых хочется подключать и отключать кавка умеет следить за тем чтобы сообщения не терялись правильно всё распараллеливания дедупликация при необходимости Оборотная сторона медали в том что в асинхронном взаимодействии сложнее разобраться ответ не приходит сразу он может не прийти вообще или появиться через несколько часов в ответном топике у команды автора множество историй про кафку и в том числе связанных с багами самой Кафки кажется что у любого разработчика есть свои примеры странного поведения брокера конкретно кафку ещё довольно сложно настраивать и ка что не так много людей
знают как это действительно правильно делать там очень много нюансов которые нужно учесть в своё время команда автора организовывала книжный клуб каждую неделю в оффлайне читали по главе из какой-нибудь полезной книги и собирались чтобы обсудить прочитанное как раз так команда и изучила книгу по кавка и это было Мега полезно пока автор это не прочитал он не понимал по-настоящему Но кажется и этих знаний недостаточно чтобы применять кафку направо и налево без дополнительного чтения документации Ну а на этом всё спасибо что послушали эту статью надеюсь вам как и мне было интересно если понравилось видео то поставь ему лайк
подписывайся на канал Ну и пиши обязательно в комментариях Что ты думаешь по поводу этого видео и что ты думаешь по поводу конкретных ситуаций которых говорил автор Наверняка у тебя тоже есть какой-нибудь крутой опыт работы с микросервисами если хочется поддержать денежкой канал то это тоже Возможно либо подписавшись на бусте либо разовым переводом на юмани Ну и конечно подписывайся на нашу телегу там есть статьи и переводы статей которых нету на Ютюбе интересная информация про технологии мемчики и ещё Конечно мы выкладываем каждый раз туда аудио версии всех статей чтобы можно было с выключенным экраном по дороге в наушниках
слушателей Snet Ну всё пока
