🔵 С4 - нотация моделирования для схем архитектуры 🔵
Можешь показать схему архитектуры системы в виде прямоугольников и стрелочек? Отлично!
Но если в отрасли есть стандарты, лучше использовать их.
Предлагаю познакомиться с нотацией моделирования архитектуры C4 👇
C4 помогает представлять архитектуру системы в виде 4-х уровней:
👉 Контекст (C4/Context)
Система, её интеграции и пользователи.
✔️ Главный прямоугольник - наша система
✔️ Серые прямоугольники - внешние
✔️ Пользователи
👩💻 Полезна бизнес- и техническим специалистам
👉 Контейнер (C4/Container)
Независимые по коду приложения в системе, детализация главного прямоугольника c C4 / Context.
✔️ Пользователи и внешние системы с уровня C4 / Context
✔️ Мобильные, веб- и десктоп приложения
✔️ Сервер-приложения: монолит, сервисы, микросервисы, API Gateway
✔️ Базы данных и файловые хранилища
✔️ Виды API
✔️ Технологии (языки программирования, СУБД, протоколы для API и др)
✔️ Базы данных и файловые хранилища
✔️ Очереди и брокеры
Схему удобнее использовать в адаптированном виде, когда на этом уровне не показывают сервисы и микросервисы, а переносят их на уровень глубже - C4 / Component. Иначе она очень перегружена.
👩💻 Полезна архитекторам, разработчикам и системным аналитикам.
👉 Компонент (C4/Component)
Модули кода и зависимости между ними.
Детализирует один из контейнеров с C4 / Container.
На каждый контейнер своя схема.
Отлично подходит для детализации модульного монолита.
👉 Код (C4/Code)
На этом уровне детализируют каждый компонент c C4/ Component, показывая его реализацию в коде. Обычно это UML-диаграмма классов или другая визуализация.
Материалы:
🔗 Официальный сайт C4
🔗 Пример архитектуры C4 в Miro
🔗 Нотация С4 — примеры диаграмм и инструменты
Основные инструменты:
🔗 Draw.io
🔗 Structurizr
Примеры схем:
🔗 RideFlow - заказ такси
🔗 TelMed - телемедицина
🔗 BookingGA - аренда недвижимости (МСА с брокерами)
🔗 GreenChargeGA - зарядки для электроавто (МСА с брокерами)
Элементы нотации с пояснениями в картинках к посту 🙌
#АрхитектураGA
Можешь показать схему архитектуры системы в виде прямоугольников и стрелочек? Отлично!
Но если в отрасли есть стандарты, лучше использовать их.
Предлагаю познакомиться с нотацией моделирования архитектуры C4 👇
C4 помогает представлять архитектуру системы в виде 4-х уровней:
👉 Контекст (C4/Context)
Система, её интеграции и пользователи.
✔️ Главный прямоугольник - наша система
✔️ Серые прямоугольники - внешние
✔️ Пользователи
👩💻 Полезна бизнес- и техническим специалистам
👉 Контейнер (C4/Container)
Независимые по коду приложения в системе, детализация главного прямоугольника c C4 / Context.
✔️ Пользователи и внешние системы с уровня C4 / Context
✔️ Мобильные, веб- и десктоп приложения
✔️ Сервер-приложения: монолит, сервисы, микросервисы, API Gateway
✔️ Базы данных и файловые хранилища
✔️ Виды API
✔️ Технологии (языки программирования, СУБД, протоколы для API и др)
✔️ Базы данных и файловые хранилища
✔️ Очереди и брокеры
Схему удобнее использовать в адаптированном виде, когда на этом уровне не показывают сервисы и микросервисы, а переносят их на уровень глубже - C4 / Component. Иначе она очень перегружена.
👩💻 Полезна архитекторам, разработчикам и системным аналитикам.
👉 Компонент (C4/Component)
Модули кода и зависимости между ними.
Детализирует один из контейнеров с C4 / Container.
На каждый контейнер своя схема.
Отлично подходит для детализации модульного монолита.
👉 Код (C4/Code)
На этом уровне детализируют каждый компонент c C4/ Component, показывая его реализацию в коде. Обычно это UML-диаграмма классов или другая визуализация.
Материалы:
Основные инструменты:
Примеры схем:
Элементы нотации с пояснениями в картинках к посту 🙌
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥24❤6👍5
Очередь сообщений — это структура данных,
которая хранит сообщения до тех пор, пока их не заберёт получатель.
Брокер сообщений — это программное обеспечение,
которое управляет обменом сообщений между приложениями.
Он может включать в себя множество очередей сообщений и дополнительно поддерживать топики, маршрутизацию, обработку и механизмы гарантии доставки.
Вопросы с подвохом, которые вы можете встретить на собеседованиях для Middle+ Системного аналитика:
👉 1. Если у нас есть очередь сообщений, зачем нужен брокер?
👉 2. Может ли очередь работать без брокера?
👉 3. Могу ли я использовать брокер без очередей сообщений?
👉 4. Если я использую очередь сообщений, могу ли я гарантировать доставку сообщения?
👉 5. Очередь всегда работает по принципу FIFO (первое пришло - первое вышло из очереди)?
👉 6. Может ли очередь работать с несколькими производителями и потребителями?
Подробная статья:
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤20👍7❤🔥1
Брокеры — это посредники в передаче сообщений между системами или сервисами.
Они позволяют асинхронно обмениваться данными и обеспечивают гарантию доставки сообщений.
👉 Принцип работы:
1. Сервис 1 (Producer/ Производитель) хочет отправить данные в Сервис 2 (Consumer/ Потребитель).
2. Сервис 2 в это время может быть перегружен или занят.
3. Чтобы Сервис 1 не ждал, пока Сервис 2 станет доступен, он кладет сообщение в Брокер и продолжает свою работу.
4. Брокер сохраняет сообщение и ставит его в очередь к обработке.
5. Как только Сервис 2 становится доступен, то он забирает сообщение из Брокера и обрабатывает его.
По сути брокеры - это временные Базы Данных,
которые гарантируют, что сообщения (данные) в них будут храниться, пока их не заберут и не обработают соответствующие системы или сервисы.
👉 Брокеры могут использоваться:
+ в сервисной и микросервисной архитектуре (хореография),
+ в событийно-ориентированной архитектуре (EDA),
+ когда нужна фоновая обработка событий в монолите,
+ для асинхронных интеграций.
👉 Брокеры сообщений предлагают два основных шаблона обмена данными:
1. Точка-точка (Point-to-Point Messaging)
Это паттерн, используемый в очередях сообщений, где существует один отправитель и один получатель. Каждое сообщение в очереди отправляется только одному получателю и может быть обработано только один раз.
2. Публикация-подписка (Publish/Subscribe)
В этом паттерне отправитель (producer) публикует сообщения в определённую тему (topic), а подписчики (consumers) подписываются на темы, чтобы получать сообщения.
Все сообщения, опубликованные в теме, доставляются всем приложениям, подписанным на неё.
Применяется в случаях, где несколько систем должны получить одну и ту же информацию.
Возможности и логика работы брокеров отличаются в зависимости от конкретного решения.
Основные решения по брокерам на рынке:
✅ Apache Kafka
✅ RabbitMQ
✅ ActiveMQ
✅ Amazon MQ, Amazon SQS
✅ Яндекс Message Queue (YMQ) - аналог Amazon
✅ и другие.
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18👍9🔥6❤🔥1👌1
🕺Хореография микросервисов - детальный разбор с примером 💃
👉 Хореография — это архитектурный шаблон взаимодействия микросервисов, в котором бизнес-процессы реализуются как цепочка независимых реакций на события.
Каждый сервис знает только:
▫️ какие события он слушает,
▫️ что делает при их получении,
▫️ какие события публикует дальше.
👉 Интеграция сервисов в таком подходе в основном асинхронная, через брокер сообщений (Kafka, RabbitMQ) / event bus.
👉 Пример хореографии
Оформления заказа с привязанной карты в сервисе доставки еды
🟡 Запуск хореографии:
Пользователь нажимает "Оформить заказ" в web-приложении:
1. П
2.
3.
+ обновляет статус заказа в БД на "Ожидает оплаты"
+ публикует событие в
❗️ Деньги с пользователя не списаны
4.
5.
🟡 Асинхронная работа - хореография:
Запускается параллельный поток событий. Frontend и пользователь могут идти по своим делам.
1.
2.
Параллельно:
----
3А. С Уведомлений читает событие "Платеж упешен" из
3C. С Заказов читает событие "Платеж упешен" из
3B. Рестораны читает событие "Платеж упешен" и проверяет:
+ кухня не перегружена?
+ доступность блюд?
+ время работы и т.п.
4. Если ок, то С Рестораны публикует событие "Заказ подтверждён".
----
Параллельно:
4А. С Уведомлений читает "Заказ подтверждён"..❌
4C. С Заказы читает "Заказ подтверждён"..❌
4B. С Курьеры читает "Заказ подтверждён"..
Далее на картинке к посту 🖼
#АрхитектураGA #FoodDeliveryGA
👉 Хореография — это архитектурный шаблон взаимодействия микросервисов, в котором бизнес-процессы реализуются как цепочка независимых реакций на события.
Каждый сервис знает только:
▫️ какие события он слушает,
▫️ что делает при их получении,
▫️ какие события публикует дальше.
👉 Интеграция сервисов в таком подходе в основном асинхронная, через брокер сообщений (Kafka, RabbitMQ) / event bus.
👉 Пример хореографии
Оформления заказа с привязанной карты в сервисе доставки еды
🟡 Запуск хореографии:
Пользователь нажимает "Оформить заказ" в web-приложении:
1. П
риложение отправляет запрос на API Gateway2.
API Gateway проверяет авторизацию и маршрутизирует заказ в Сервис Заказов3.
Сервис Заказов:+ обновляет статус заказа в БД на "Ожидает оплаты"
+ публикует событие в
Брокер Kafka - "Заказ подтверждён"❗️ Деньги с пользователя не списаны
4.
Сервис Заказов возвращает ответ на API Gateway.5.
API Gateway возвращает ответ с инфо о заказе на web-приложение, где показываем пользователю сообщение "Заказ принят"❌🟡 Асинхронная работа - хореография:
Запускается параллельный поток событий. Frontend и пользователь могут идти по своим делам.
1.
Сервис Платежи (далее - С) читает событие "Ожидает оплаты" из Kafka и запускает логику списания денег с карты пользователя.2.
Платежи публикует событие "Платеж упешен" в Kafka.Параллельно:
----
3А. С Уведомлений читает событие "Платеж упешен" из
Kafka и отправляет push+sms пользователю❌3C. С Заказов читает событие "Платеж упешен" из
Kafka и меняет его статус в своей БД на "Оплачен"❌3B. Рестораны читает событие "Платеж упешен" и проверяет:
+ кухня не перегружена?
+ доступность блюд?
+ время работы и т.п.
4. Если ок, то С Рестораны публикует событие "Заказ подтверждён".
----
Параллельно:
4А. С Уведомлений читает "Заказ подтверждён"..❌
4C. С Заказы читает "Заказ подтверждён"..❌
4B. С Курьеры читает "Заказ подтверждён"..
Далее на картинке к посту 🖼
❌ - конец процесса
#АрхитектураGA #FoodDeliveryGA
❤20❤🔥7🔥3
1️⃣ Когда хореография микросервисов хуже оркестрации?
✔️ Надо явно видеть шаги процесса и управлять им
✔️ Когда важны SLA и время на выполнение шагов
В таких случаях удобнее, когда:
+ есть компонент, который явно хранит состояние процесса
+ видно “шаги” и переходы по ним
С этим помогает оркестрация.
2️⃣ Сервис записал данные в свою БД, но упал до публикации события. Что произойдёт в хореографии и как это чинить?
Ситуация:
Обработка данных на микросервисе прошла, но событие в брокер не опубликовано → остальные сервисы никогда не узнают об изменении.
Решение:
Transactional Outbox / Outbox pattern:
В одной транзакции к БД с бизнес-данными пишем запись в специальную outbox-таблицу.
Отдельный воркер (фоновый процесс) читает из outbox и публикует событие в брокер, с ретраями.
Также иногда используют Change Data Capture (CDC) по БД - отслеживание изменений.
3️⃣ Как в хореографии реализовать шаг, который зависит сразу от двух событий из разных сервисов?
+ хранит состояние двух параметров: userId - , orderId
+ пришло первое событие — пометили “жду второе”
+ пришло второе — выполняем действие (начисляем бонус)
Это уже кусочек оркестрации, спрятанный внутри одного сервиса.
Также нужно учесть что делать, если второе событие не пришло.
4️⃣ Как в хореографии реализовать таймаут шага?
Например, оплата должна пройти за 15 минут, иначе заказ отменяем.
1. При старте процесса публикуется событие "оплата началась"
2. Параллельно где-то создаётся “таймер” на 15 минут (например, Cron)
3. Если за 15 минут не пришло событие "Платеж успешен" / "Ошибка оплаты":
+ таймер генерирует событие "Ошибка таймаута по платежу",
+ другие сервисы реагируют: отменяют заказ, снимают резерв и т.п.
Важно понять: управление интервалами времени в работе процесса не решается «само по себе» брокером — нужен компонент, который хранит состояние ожидания.
5️⃣ Биллинг слушает событие "Заказ оплачен" и должен списать деньги ровно один раз. Любое сообщение может прийти дважды. Как вы гарантируете отсутствие двойного списания?
«брокер гарантирует доставку ровно один раз»
Реализуем проверки на уровне потребителя события:
+ идемпотентность операций: бизнес-ключ (orderId + paymentId)
+ уникальность в БД на этот ключ
+ таблица processed_messages с messageId и состоянием.
6️⃣ Можно ли построить систему только на хореографии, без оркестрации?
+ всё равно появятся сервисы-агрегаторы / процесс-менеджеры / scheduler’ы, которые управляют процессами
+ как только один сервис начинает хранить состояние процесса и ждать другие события, он выполняет роль локального оркестратора.
Более правильный ответ: в реальных системах почти всегда смесь подходов хореографии и оркестрации.
7️⃣ Вы добавляете новый микросервис в существующую хореографию процессов. Как сделать так, чтобы он не поломал остальных, когда начнёт слушать существующие события?
+ слушает существующие события без изменения процесса их работы
+ никакие его действия не должны влиять на текущие цепочки по процессам
Важно:
+ не добавлять обязательные поля в существующие события (сообщения), которые отправляем в брокер
+ не менять JSON (формат сообщений) уже используемых событий
+ если нужно другое поведение — вводить новые типы событий, а не менять старые.
А какие ещё вопросы по брокерам и хореографии вы встречали на собеседованиях на СА? Делитесь в комментариях ✍️
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥31❤6❤🔥2👍2🤩1
GetAnalyst_Kafka_8_шагов_чтобы_разобраться.png
522.6 KB
1️⃣ Что такое Kafka?
2️⃣ Сообщения в Kafka
3️⃣ Topics & Partitions
4️⃣ Kafka Producer
5️⃣ Kafka Consumer
6️⃣ Kafka Cluster
7️⃣ Сценарии использования Kafka
Сохраняйте схему в личный архив.
Это идеальный чек-лист для подготовки к собеседованиям ✅
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23❤🔥7👍4❤3👎1
📚👩💻 Доступ к бесплатному обучению по Архитектуре открыт 👩💻 📚
Всем, кто уже зарегистрировался, письмо с доступом пришло на почту сегодня утром.
💎 Хореография и оркестрация микросервисов: практика проектирования процессов
🗓 Доступ до 2 декабря [вт]
🕘 ~4 часа, смотрете в удобное время
🔗 Зарегистрироваться
👉 План:
1. Основы архитектуры: монолит и микросервисы
2. Разработка схемы архитектуры
3. Оркестрация процессов: практика
4. Введение в брокеры сообщений (RabbitMQ, Kafka)
5. Хореография процессов: практика
👉 Это не типичный демо-урок, а полноформатное практическое обучение, после которого вы получите реальные инструменты и знания для работы.
Планируйте слот в календаре и смотрите его, пока доступ открыт 🙌
-----
Этот открытый урок - вводное занятие к практической программе Проектирование архитектуры для системных аналитиков
-----
Вопрос? Пишите @getanalyst или info@getanalyst.ru 🤝
Всем, кто уже зарегистрировался, письмо с доступом пришло на почту сегодня утром.
💎 Хореография и оркестрация микросервисов: практика проектирования процессов
🕘 ~4 часа, смотрете в удобное время
👉 План:
1. Основы архитектуры: монолит и микросервисы
2. Разработка схемы архитектуры
3. Оркестрация процессов: практика
4. Введение в брокеры сообщений (RabbitMQ, Kafka)
5. Хореография процессов: практика
👉 Это не типичный демо-урок, а полноформатное практическое обучение, после которого вы получите реальные инструменты и знания для работы.
Планируйте слот в календаре и смотрите его, пока доступ открыт 🙌
-----
Этот открытый урок - вводное занятие к практической программе Проектирование архитектуры для системных аналитиков
-----
Вопрос? Пишите @getanalyst или info@getanalyst.ru 🤝
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16❤7
Последние месяцы я минимум по 10 часов в неделю учусь - лучший технический университет США прокачивает меня в Generative AI. На прошлой неделе, например, разбиралась с библиотеками в Python для обучения LLM-моделей и работы с NLP.
А параллельно с этим я работаю над AI-Акселератором для аналитиков.
Большая загрузка, мало времени на отдых, без выходных больше месяца. Но я полна мотивации и в восторге от того, что получается 🤩
Программа по AI для аналитиков — это не база про ChatGPT.
Я собираю весь тот опыт, который получила за последние 3 года учёбы и работы:
+ принципы работы нейросетей,
+ что надо знать, прежде чем их использовать,
+ как безопасно встроить AI в свою работу,
+ инструменты,
+ развертывание локальных LLM,
+ интеграции по API,
+ автоматизация процессов через low code,
+ где AI реально экономит время, а где только создаёт иллюзию продуктивности.
Мой перфекционист в восторге от содержания 🫠
Для меня это особенно вдохновляющий период в GetAnalyst:
🔹 Мне удалось привлечь экспертов из США, которые делают ревью материалов по отдельным урокам и помогают докрутить контент
🔹 В курсе будут занятия, записанные специально для GetAnalyst экспертом по AI из Стэнфорда
🔹 Много практики, разбор ошибок и лайфхаки
Этот год я сознательно посвятила обучению, чтобы сместить фокус на AI-проекты и работать с новыми клиентами на разработку.
И сейчас искренне рада, что могу делиться своим опытом с вами.
И чем глубже во всё это погружаюсь, тем сильнее вижу - направление всё ещё очень не развито. Здесь ещё можно успеть занять своё место, пока рынок только формируется, и стать передовиком в транформации и улучшении своей профессии.
Так что да, я сейчас тону в презентациях, схемах, записях…
Но именно это зажигает искру и даёт ощущение сильной мотивации и радости 💙
А параллельно с этим я работаю над AI-Акселератором для аналитиков.
Большая загрузка, мало времени на отдых, без выходных больше месяца. Но я полна мотивации и в восторге от того, что получается 🤩
Программа по AI для аналитиков — это не база про ChatGPT.
Я собираю весь тот опыт, который получила за последние 3 года учёбы и работы:
+ принципы работы нейросетей,
+ что надо знать, прежде чем их использовать,
+ как безопасно встроить AI в свою работу,
+ инструменты,
+ развертывание локальных LLM,
+ интеграции по API,
+ автоматизация процессов через low code,
+ где AI реально экономит время, а где только создаёт иллюзию продуктивности.
Мой перфекционист в восторге от содержания 🫠
Для меня это особенно вдохновляющий период в GetAnalyst:
🔹 Мне удалось привлечь экспертов из США, которые делают ревью материалов по отдельным урокам и помогают докрутить контент
🔹 В курсе будут занятия, записанные специально для GetAnalyst экспертом по AI из Стэнфорда
🔹 Много практики, разбор ошибок и лайфхаки
Этот год я сознательно посвятила обучению, чтобы сместить фокус на AI-проекты и работать с новыми клиентами на разработку.
И сейчас искренне рада, что могу делиться своим опытом с вами.
И чем глубже во всё это погружаюсь, тем сильнее вижу - направление всё ещё очень не развито. Здесь ещё можно успеть занять своё место, пока рынок только формируется, и стать передовиком в транформации и улучшении своей профессии.
Так что да, я сейчас тону в презентациях, схемах, записях…
Но именно это зажигает искру и даёт ощущение сильной мотивации и радости 💙
🔥72❤21❤🔥4🤔3😍2
1. Что такое RabbitMQ и зачем он нужен
2. Как работает RabbitMQ
3. Очереди, обменники (exchange), routing и binding key - ключевая терминология и внутреннее устройство брокера
4. Типы обменников: direct, fanout, topic, headers
5. Пошаговый разбор примера использования RabbitMQ в микросервисной архитектуре
Подробно разбирали брокер в подкасте:
🎧 RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам
Сохраняйте в закладки и делитесь с коллегами
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤27🔥16❤🔥15😍2👍1