Channel for those who want to understand Software Development & IT. Get deep knowledge of how the industry works. If you are a system or business analyst, automated or manual tester, software engineer, or planning to become - Welcome! 🚀
Минусы монолита описанные как будто бы больше на мифы смахивают (особенно если смотреть на них не в вакууме, а сравнивать с микросервисами): - "в монолите сложно понять какой модуль на какой влияет", - не согласен. Сложно понять какие микросервисы друг на друга влияют (сама по себе трассировка, сервис дискавери, поиск проблем и отслеживание циклических вызовов, совместимость апи и прочие проблемы), как и в целом сопровождение микросервисов на порядок сложнеее чем совпровождение монолита, тк в случае монолита простым поиском по коду проекта или дебаггером все можно просмотреть и в билд тайме 99% ошибок взаимодействия ловить можно, надо только те же самые хорошие практики современные использовать чтобы не скатывать все к "big ball of mud" - "сложно масштабировать" - какая по сути разница копию всего приложения развернуть или только его части? разверните X копий (или настройте автоскейл горизонтальный как вам надо) и если нагрузка на модуль платежей будет выше чем нагрузка на модуль такси, то просто какой-то больший процент реплик будет занят обработкой платежей, а какой-то меньший процент реплик займет обработка запросов такси. Ну и в крайних случаях, если очень хочется, можно вынести какой-нибудь ОДИН модуль из монолита, не трогая большую часть других модулей. - "гибкость и простота разаработки, обновления" - ну так если у вас монолит модульный, вы можете эти модули как угодно тасовать, менять и тд (и в том числе, как уже упоминал выше, можно вынести некоторые модули из монолита если такая потребность по какой-то очень важной причине настанет). По поводу истории с булевыми флагами и тестированием - уже давно придумали разные стратегии выкатки сложных обнвлений - типо канареек , фича флагов, A/B и прочих стратегий, которые в монолите тоже можно применять схожим образом как и в случае с микросервисами
Спасибо за развернутый ответ По первому пункту - речь идет о протекании абстракций, в микросервисах эта проблема отсутствует т.к. код физически разделен network и общается через API (предлагаю случаи с некорректно построенной архитектурой, API не рассматривать). Отсюда есть большой плюс, что локальное внесение изменений в код (без изменений API) не может сломать код в другом микросервисе По второму пункту - про содержание микросервисов, в видео это отмеченно, что микросервисы требуют дополнительных затрат т.к. все процессы тестировния, логирования и тд нам нужно поддерживать для всех микросервисов. В монолите за счет меньшего количество сущностей администрирование упрощается По третьему пункту - про масштабирование. Если в монолите мы изначально заложим возможность масштабирования, то в этом случае можно эволюционно прийти к скейлинга отдельных модулей (выделяя их или нет). Часто так бывает, что монолит пишут без видения того что инстансов может быть несколько и как следствие даже простейшее создание второго инстанса может быть проблемой, в отличии от микросервисов где это является ключевым вопросов (то есть мы его никак не потеряем) По последнему пункту - про обновления, действительно если в код заложить систему плагинов то ей можно управлять так же гибко как и в случае с микросервисами, системой флагов или другими механизмами (бренчинг и тд). Но как показывает практика никто этого не делает и в большинстве случаев код прийдется переписывать. Резюмирую - если архитектор с головой то он и монолит построит такой, что большой части проблем удастся избежать. Плюс микросервисов здесь в том что все эти вопросы мы разбираем на самом первом этапе проектирования
Спасибо за видео. Очень интересное но как по мне уж слишком поверхностное. Автор подчеркивает важность демонстрации практического опыта на собеседовании но именно этого самого практического опыта использования этих паттернов автором в этом видео и не хватает. Надеюсь в будующих видео будет что-то основанное на реальных проектах. Хотя возможно для начинающих видео будет полезно чтобы не искать по гуглам все эти паттерны.
Всё доходчиво) Возник вопрос по поводу JWT. Допустим есть API Gateway сервис и Security сервис, который после первоначальной проверки имя:пароль генерирует JWT, используя RSA шифрование и отдает его клиенту. Каким образом лучше всего осуществить проверку этого токена, не отправляя каждый запрос от клиента в Security, у которого (только!) есть доступ к RSA ключам? Сейчас на Gateway применяется фильтр, который отправляет запросы к другим микросервисам сначала в Security на верификацию JWT. Как-то криво по-моему(
Есть несколько подходов, если я правильно понял ваш случай - это случай когда для каждого микросервиса мы осуществляет запрос и проверку токена, такой подход отлично работает с точки зрения безопасности, но у него есть минусы и один из основных это проблема масштабирования (при большом количестве микросервисов и запросов рост нагрузки будет экспоненциальным). В таком случае чаще всего переходят на аутентификацию на edge (по перимитру), что сильно упрощает масштабирование, но снижает "строгость" проверок для каждого вызова внутри безопасной зоны Подробно данных подход хорошо изложен в блоге Netflix (они как раз столкнулись с проблемой управления и масштабирования) - netflixtechblog.com/edge-authentication-and-token-agnostic-identity-propagation-514e47e0b602
Мне кажется автор натягивает сову на глобус говоря, что RabbitMQ это про Push. Сам брокер не знает адреса потребителей, они к нему подключаются и запрашивают новые сообщения. Это только запутывает
Действительно это может немного смущать что rabbitmq ориентирован на push based. В нем есть два типа API push & pull но в большинстве случаев используется push подход (www.rabbitmq.com/docs/consumers#subscribing )
Действительно в самых простых случая очередь можно заменить на реверс + LB Но это только часть функциональности, очереди так же: - Автоматически масштабируются при добавлении и удалении нод из кластера - Могут гарантировать транзакционность и использовать различные стратегии доставки - Часть из очередей могут использоваться в виде хранилища events в event-driven архитектуре - Так же поверх них удобно строить real-time стримы данных и событий и не переживать за то что какой-то из consumer упадет Важно посмотреть на кейс и уже после решать нужна ли очередь или нет
@@digital_train - Балансировщик тоже может добавлять и удалять ноды - Если пользователь не получает ответ в течении 30 секунд, то в большинстве случаев он перестает его ждать и уходит. Поэтому нет смысла накапливать сообщения в надежде когда-то там обработать все. - Событийная архитектура усложняет разработку, если система не помещается на сервер, то лучше использовать шардирование, а не разбиение на подсистемы, что связаны событиями. - После падения консюмеров забивается и падает очередь, что делает ее бессмысленной для спасения. Проще разруливать падение на клиенте путем повторных запросов.
Есть задачи, в которых поток запросов имеет ярко выраженные короткие пики, а в остальное время почти ноль. В этих случаях, если время ответа некритично или ответ вообще не предусмотрен, очередь очень помогает дешево разгрузить обработчики.
У меня вопрос по event sourcing. Вот Вы сказали, что мы каждый шаг пользователя фиксируем. Имеется ввиду прям i/o фиксация в бд. Или у нас просто собираются данные в некую коллекцию, а затем по завершении действий пользователем делаем запись в бд? При втором варианте конечно есть риск потери данных при сбое, но первый вариант кажется суперзатратным, все таки идёт постоянная запись в бд. Если юзер просто играется и добавляет товар через плюсик по одному до 20шт, затем удаляет, для меня это 20 транзакций?😢
Отличный вопрос, спасибо что задали его! Действительно если рассмотреть реальную систему то такой подход будет слишком трудозатратен с тз "бека". Поэтому в примере с обычным e-commerce это будет слишком накладно + потеря корзины пользователя который ушел на несколько часов не так критична С другой стороны если мы продаем что-то на что есть жесткий лимит и пользователь будет сильно разочарован в случае отказа - например билет на самолет ил театр, то стоит фиксировать не саму корзину а событие старта процесса покупки тем самым мы снизим нагрузку на "бек", а с другой стороны сможем обеспечить гарантию только одной продажи для пользователя
Про multi stage pipeline очень вскользь сказано, хотелось бы на конкретном примере. Например как организовать транзакцию когда идет целый ряд событий как результат одного. К примеру типовая ситуация: заказ от пользователя (оплата-пересчет остатков-информирование).
Отличный вопрос, как раз разбирали его на теме про паттерны микросервисной архитектуры. Если коротко - транзакционность между микросервисами это дорого и сложно, но есть подходы к организации Тут пример ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ViCD4ERj578.htmlsi=M7WRUakxvd6PIYtH 1. Event sourcing 2. Saga pattern
Канал о помощи начинающим ИТ инженерам, тестировщикам и аналитикам Вот тут для примера мы рассматриваем архитектуру и паттерны микросервисов, что полезно для инженеров ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ViCD4ERj578.html
Если мы говорим на задержку на чтение и обработку сообщения то за счет структуры Kafka сообщение будет проходить быстрее, т.к. там по сути отсутствует умный роутинг и т.д. Но если наша задача выглядит как в зависимости от сложной логики раскидать сообщение по группам, с какими-нибудь полиси. То тут RabbitMQ будет быстрее так как в Kafka нет внутренних механизмов и все прийдется делать во внешнем сервисе, следовательно только передача сообщения между очередью и сервисом съест львиную долю времени Если суммировать, смотрите на ваш кейс_
Благодарю за видео, вкатывающимся будет очень полезно. Хотелось бы услышать каким образом работать с информацией, чтобы это все перерастало в навык, ибо информации на любые темы более чем достаточно, а вот как работать с ней - это большой вопрос)
Думаю вы единственный человек, который смог передать многолетний опыт за час встречи настолько доступно и понятно 👍 Все строго по сути и делу - за час вы смогли сделать из полной каши в моей голове полное понимание «что, зачем и почему», которое возможно так бы и не сформировалось в дальнейшем за несколько лет работы автотестировщиком без вашей лекции, круто 🔥 Этот канал и весь ваш совокупный опыт в этой сфере очень ценны, продолжайте, супер полезно 🙂👍
