Alejandro Yakovlev

В 13 уроке Symfony применяем архитектурный шаблон SAGA. В теоретической части рассматриваем основные принципы паттерна, какие проблемы решает, как и когда его стоит использовать. Взглянем на плюсы и минсусы координации повествованием с помощью хореографии и оркестрации. В качестве примера представлен сценарий оформления заказа в различных кейсах. В практической части, реализуем сагу оформления заказа в архитектуре модульного монолита с использованием фреймворка Symfony.

12 урок Symfony вышел эксклюзивно на Boosty! Реализуем асинхронный обмен сообщениями между модулями на примере сценария оформления заказа. Содержание: - проблемы синхронных вызовов; - улучшаем показатель доступности системы; - настройка транспортов компонента Messenger, маршрутизация и сериализация сообщений, consuming; - работа с RabbitMQ; - обеспечение итоговой согласованности агрегатов с помощью доменных событий, применение шаблона Event-Carried StateTransfer UPD: Добавлена 2 часть 12 урока, где рассматривается применение паттерна Transactional Outbox для обеспечения надежной отправки событий в брокер сообщений.

#вопрос

В рамках микросервисной архитектуры, чтобы получить в одном сервисе данные из другого сервиса нужно выполнить например http запрос, например, курлом. Это ж дико тормозит систему, какие есть ещё способы взаимодействия между сервисами? Их + и -

Тормозит почему? 🤔 Если система тормозит из-за большого объема передаваемых данных 1. Используй сжатие данных. HTTP Compression при передаче JSON или XML. Полезно при больших объемах текстовых данных. Может ухудшить время отклика и повлиять на производительность. 2. Можно перейти на более компактные форматы передачи данных, такие как Protocol Buffers, и использовать gRPC для коммуникции. Это добавит технической сложнсоти. 3. Используй шаблон "связь через общие данные", например, с помощью общих баз данных, файловых хранилищ или согласованных кэшей, однако будь осторожен с повышенной связанностью между сервисами и проблемами согласованности данных. Здесь как и в следюущем пункте появится новая точка отказа. 4. Используй Kafka для потоковой передачи больших данных. При тормозах из-за нагрузки на микросервис 1. Используй запросы батчами, вместо единичных запросов к ресурсам. 2. Используй кэширование. Но помни о точке отказа. Redis не резиновый. 3. Если сервис не справляется с потоком запросов, рассмотри переход к событийному взаимодействию и дуплицированию данных на стороне каждого сервиса. Вместо того чтобы сервисам ходить друг к другу на поклон, пусть автономно выполняют свои обяанности при получении детализированных событий. 4. Если слабое место БД, то нужно ее оптимизировать. Индексация, денормализация, репликация, шардирование. Созадвай материализвоаныне представления. Используй CQRS подход, чтобы читать из реплик или из быстрых хранилищ. 5. Масштабируй вдоль и поперек. Вертикальное масштабирование увеличивает ресурсы одного сервера, в то время как горизонтальное добавляет дополнительные серверы. Если тупнякии вызваны "болтливостью" микросервисов Пересмотри декомпозицию и границы сервисов. Вопросы, котопрые можешь себе задать: Верно ли очерчены границы? Есть ли связанность? Есть вызовы нижестоящих сервисов в цепочке? Можно ли вынести какой-нибудь вызов из этой цепочки или сделать его асинхронным не нарушая бизнес требования? Конечно же потребуется рефакторинг 😱 для улучшения архитектуры. Свой вопрос можешь задать в форме https://forms.gle/zJ4CHci7164z3t1s6

#вопрос

относительно реализации связей между агрегатами: правильно ли я понимаю, что исходя из данной концепции (DDD), привычных связей с FK между сущностями не будет, останутся лишь string значения с ulid и методы в репозиториях для чтения/записи в базу?

_ Верное понимание. Агрегаты должны ссылаться друг на друга по идентификаторам. Обычно это string или int. Такая связь помогает явно обозначить границы агрегатов и сделать их менее связанными. При этом агрегаты могут иметь обычные отношения с сущностями, которые существуют в границах агрегата. При построении DTO или создании представления для read модели, данные о связанных агрегатах подтягиваются через репозитории. Создание внешних ключей между сущностями нужно осознанно контролировать. Обычно FK создаются автоматом при создании миграции, но допускать их бесконтрольное создение не стоит. В будущем это ударит по производительности и может привести к блокировкам.

🍒 Авторские телеграм-каналы о разработке и IT в целом Сейчас время, когда на нас льётся огромный поток информации. Компаний борются за внимание людей. А тут ещё так удачно появились генеративные ИИ. И как итог — куча некачественного бездушного контента. Остаётся только искать живые авторские каналы, где люди пока ещё пишут что-то от себя и делятся своим опытом. На днях проводил розыгрыш билета на конференцию, где нужно было рассказать об авторских телеграм-каналах. Прислали много каналов, отобрал айтишные. О многих ранее не слышал. • Диджитализируй! — Алексей Голобурдин • PHP Fart Time — Алексей Гагарин и Павел Бучнев • Галера Морева — Антон Морев • ПЫХ и PHP умирает?! — Валентин Удальцов • Пятиминутка PHP — Пётр Мязин • adelf on programming — Адель Файзрахманов • ebanoePHP — Артур Пантелеев • SOER — Евгений Сергеев • igancev.ru и phpinfo(); — Иван Ганцев • ArturKryukov video — Артур Крюков • emacsway-log — Иван Закревский • Evgeniy Kuvshinov — Евгений Кувшинов • ElisDN.ru — Дмитрий Елисеев • samdark blog — Александр Макаров • dependency hell — Антон Кучеров • Tolstoy Live — Егор Толстой • johenews — Дмитрий Ковалёв • Вастрик.Пынь — Василий Зубарев • Beer::PHP — Кирилл Сулимовский • agoalofalife — Илья Чубаров • Alek OS — Александр Осадин • Заметки разработчика — Алексей Лоскутов • Сашок Горшок (DEV & MGMT) — Александр Яковлев Мой канал тоже упомянули — Сергей Предводителев, такая вот рекурсия 😀 Все каналы в одной папке: https://t.me/addlist/JxfuRk29W3k1ZGMy UPD. Ещё авторский канал: • О разработке и не только — Виктор Тыщенко ❤ Репост приветствуется.

С кем поведёшься, от того и наберёшься 👍