Раньше аналитикам достаточно было “хорошо собирать требования и писать понятные спецификации”.
А теперь всё чаще спрашивают понимание архитектуры.
Не “что такое Kafka”, а:
• где нужен брокер, а где синхронный API;
• что будет при таймауте и дублях сообщений;
• как обеспечиваем целостность и согласованность данных между сервисами;
• в каком случае выбрать gRPC, а где лучше подойдёт REST API.
На программе «Проектирование архитектуры» в GetAnalyst мы уже помогли 250+ аналитикам получить практический опыт работы со сложными сервисными и микросервисными системами.
Благодаря этому они выросли внутри своих компаний, сменили работу и даже перешли в карьерный трек Solutions Architect 😍
Приглашаем и вас получить самые актуальные навыки по архитектуре для СА в новом потоке:
📌 Проектирование архитектуры
📅 Старт 17 марта 2026
🎁 По заявкам до 10 марта
лучшие цены и доступ к пакету практикумов по REST API в подарок.
👉 Кому актуально
Опытным системным аналитикам (Middle и выше), кто уже работал с интеграциями и хочет:
+ вырасти в Senior внутри компании,
+ перейти в более сложные продуктовые/платформенные проекты.
👉 По итогам
✅ Освоите монолит, SOA, микросервисы - MSA, EDA
✅ Получите опыт в проектировании архитектуры с нуля
✅ Познакомитесь с GraphQL, gRPC, WebSocket, SSE
✅ Научитесь работать с брокерами RabbitMQ / Kafka
✅ Получите опыт в нотации C4 для архитектуры
✅ Сможете уверенно обсуждать архитектурные решения на интервью и в проектах
Вопросы? Пишите @getanalyst или info@getanalyst.ru. Поможем оценить текущий уровень и дадим рекомендации по дальнейшим шагам в карьерном развитии 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
📌 8 Шаблонов Микросервисной архитектуры, о которых спрашивают 📌
1️⃣ API Gateway
Единая точка входа для всех внешних запросов.
Отвечает за маршрутизацию, кэширование, аутентификацию.
2️⃣ Service Registry and Discovery
Динамическое обнаружение и регистрация сервисов.
Это механизм? по которому сервисы сами находят адреса друг друга. Он помогает им корректно взаимодействовать без жёстко прописанных адресов.
3️⃣ Backends for Frontends (BFF)
Отдельные адаптивные бэкенды под каждый вид клиентов. Например: Web и Mobile.
Каждый клиент получает ровно те данные и в том виде, который ему нужен.
4️⃣ Event Driven
Микросервисы обмениваются информацией не напрямую, а через публикацию и подписку на «события» в общем брокере: один сервис публикует сообщение о случившемся изменении, а все заинтересованные сервисы, подписанные на эти события, асинхронно получают и обрабатывают их.
5️⃣ CQRS (Command Query Responsibility Segregation)
Шаблон, в котором операции изменения состояния системы (Commands) отделяются от операций чтения данных (Queries).
• Commands реализуют запись данных, с их валидацией.
• Queries оптимизированы под быстрое получение и агрегации, отчёты.
6️⃣ Database-per-Service
Изоляция данных каждого сервиса в своей БД.
Минимизирует зависимость между микросервисами.
Главная проблема - сложность синхронизации данных.
7️⃣ Оркестрация
Центральный сервис управляет порядком вызовов.
Обеспечивает:
• последовательность выполнения алгоритмов, которые используют разные микросервисы,
• целостность и контроль транзакций.
Пример сервиса-оркерстратора: Camunda.
8️⃣ Хореография
Сервисы обмениваются событиями напрямую через брокер, которые управляет порядком выполнения алгоримов, в которых задействованы разные микросервисы.
⚙️ Как применяют?
• В зависимости НФТ (нефункциональных требований).
• Часто комбинируют несколько подходов.
Сохраните себе шпаргалку и используйте при проектировании архитектуры микросервисов, анализе своих проектов и подготовке к собеседованиям 🙌
Исходник: png | noscript (анимация)
#АрхитектураGA
1️⃣ API Gateway
Единая точка входа для всех внешних запросов.
Отвечает за маршрутизацию, кэширование, аутентификацию.
2️⃣ Service Registry and Discovery
Динамическое обнаружение и регистрация сервисов.
Это механизм? по которому сервисы сами находят адреса друг друга. Он помогает им корректно взаимодействовать без жёстко прописанных адресов.
3️⃣ Backends for Frontends (BFF)
Отдельные адаптивные бэкенды под каждый вид клиентов. Например: Web и Mobile.
Каждый клиент получает ровно те данные и в том виде, который ему нужен.
4️⃣ Event Driven
Микросервисы обмениваются информацией не напрямую, а через публикацию и подписку на «события» в общем брокере: один сервис публикует сообщение о случившемся изменении, а все заинтересованные сервисы, подписанные на эти события, асинхронно получают и обрабатывают их.
5️⃣ CQRS (Command Query Responsibility Segregation)
Шаблон, в котором операции изменения состояния системы (Commands) отделяются от операций чтения данных (Queries).
• Commands реализуют запись данных, с их валидацией.
• Queries оптимизированы под быстрое получение и агрегации, отчёты.
6️⃣ Database-per-Service
Изоляция данных каждого сервиса в своей БД.
Минимизирует зависимость между микросервисами.
Главная проблема - сложность синхронизации данных.
7️⃣ Оркестрация
Центральный сервис управляет порядком вызовов.
Обеспечивает:
• последовательность выполнения алгоритмов, которые используют разные микросервисы,
• целостность и контроль транзакций.
Пример сервиса-оркерстратора: Camunda.
8️⃣ Хореография
Сервисы обмениваются событиями напрямую через брокер, которые управляет порядком выполнения алгоримов, в которых задействованы разные микросервисы.
⚙️ Как применяют?
• В зависимости НФТ (нефункциональных требований).
• Часто комбинируют несколько подходов.
Сохраните себе шпаргалку и используйте при проектировании архитектуры микросервисов, анализе своих проектов и подготовке к собеседованиям 🙌
Исходник: png | noscript (анимация)
#АрхитектураGA
🔥27❤7
🚀 Планирую открытый онлайн-практикум по Архитектуре. Какая тема больше всего актуальна?
Anonymous Poll
36%
API Gateway - всё в деталях
33%
C4 - разработка с нуля
37%
Хореогрфия микросервисов + Брокеры
27%
Оркестрация микросервисов
17%
Монолит vs Микросервисы
39%
Архитектура приложений с AI - построение с нуля
❤19
Тем временем у меня пошёл 6-й месяц учёбы в Университете Джонса Хопкинса по AI 🤩
И это вообще не история “вот ChatGPT, сюда вставь готовый промпт”.
Нам показывают искусственный интеллект (AI) "под капотом", чтобы мы понимали, что именно происходит, когда модель “умно отвечает”.
За последние полгода я, кажется, написала больше кода, чем за 6 лет обучения в МИФИ 😅
Потому что работа с AI в роли разработчика реально “сдвигает” сознание: ты начинаешь видеть не только результат, но и механику.
И это не про “вайб-кодинг”.
Это формат:
+ делаем блок кода на Python под конкретную задачу - c AI или без,
+ разбираемся что сделали построчно,
+ делаем следующую задачу.
Делаем мини-проекты под разные домены: медицина, IT-компании, онлайн-торговля, финтех и другие.
Что было последние пару месяцев:
👉 Безопасная разработка приложений с AI
От защиты промптов и архитектуры до соблюдения законодательства.
👉 AI-агенты
Их можно делать без программирования. Но нам "магию" использовать не разрешили.
Всё запрограммировала, побесилась, но это было полезно для понимания как работает "магия", и как улучшить мою работу.
👉 MCP (Model Context Protocol)
Стандарт для интеграций LLM с системами и данными: как подключать инструменты и источники системно, и в каких случаях MCP уместен, а где проще и надёжнее традиционная интеграция.
👉 Fine-Tuning и RAG
Адаптируем нейросети под задачи бизнеса. Мне безумно понравились несколько практических задач, которые мы делали на Python!
В итоге одну из них решила добавить в финальный модуль по программированию для наших студентов на ИИ-Акселераторе 😍
В общем, учёба в Хопкинсе открыла для меня AI с той глубокой технической стороны, которая раньше вызывала вопросы.
До сих пор не знаю как я успеваю учиться.
Полноценных выходных не было давно 🙈
Но я точно знаю, что этот огромный вклад времени в обучение уже повлиял на мою работу и развитие 🙌
И это вообще не история “вот ChatGPT, сюда вставь готовый промпт”.
Нам показывают искусственный интеллект (AI) "под капотом", чтобы мы понимали, что именно происходит, когда модель “умно отвечает”.
За последние полгода я, кажется, написала больше кода, чем за 6 лет обучения в МИФИ 😅
Потому что работа с AI в роли разработчика реально “сдвигает” сознание: ты начинаешь видеть не только результат, но и механику.
И это не про “вайб-кодинг”.
Это формат:
+ делаем блок кода на Python под конкретную задачу - c AI или без,
+ разбираемся что сделали построчно,
+ делаем следующую задачу.
Делаем мини-проекты под разные домены: медицина, IT-компании, онлайн-торговля, финтех и другие.
Что было последние пару месяцев:
👉 Безопасная разработка приложений с AI
От защиты промптов и архитектуры до соблюдения законодательства.
👉 AI-агенты
Их можно делать без программирования. Но нам "магию" использовать не разрешили.
Всё запрограммировала, побесилась, но это было полезно для понимания как работает "магия", и как улучшить мою работу.
👉 MCP (Model Context Protocol)
Стандарт для интеграций LLM с системами и данными: как подключать инструменты и источники системно, и в каких случаях MCP уместен, а где проще и надёжнее традиционная интеграция.
👉 Fine-Tuning и RAG
Адаптируем нейросети под задачи бизнеса. Мне безумно понравились несколько практических задач, которые мы делали на Python!
В итоге одну из них решила добавить в финальный модуль по программированию для наших студентов на ИИ-Акселераторе 😍
В общем, учёба в Хопкинсе открыла для меня AI с той глубокой технической стороны, которая раньше вызывала вопросы.
До сих пор не знаю как я успеваю учиться.
Полноценных выходных не было давно 🙈
Но я точно знаю, что этот огромный вклад времени в обучение уже повлиял на мою работу и развитие 🙌
🔥89❤32👍8🦄3❤🔥1😁1💯1
🟢 БД и SQL - новый проект по ИИ-платформе | сегодня, в 19:00 Мск 🤖🎁
Если вам хочется иметь ясность и уверенность в проектировании БД, то как раз сегодня стартует серия практикумов по БД и SQL с новым проектом!
Будем строить БД с нуля, проектировать миграции, делать SQL-запросы, работать с ИИ и не только! 😊
Сегодня собираем ER-диаграмму физ. модели для ИИ-платформы и раскладываем по полочкам, как хранить в БД чаты и сообщения.
Подключайтесь на первое занятие:
🟢 Проектирование БД с нуля: создание ER-диаграммы
🤖 Проект: ИИ-платформа
🗓 2 марта (пн), 19:00 Мск
🔗 Подробности и запись
🎁 Скидка -15% по промокоду «ВЕСНА2026»
только до конца дня, в честь старта проекта.
✔️ Сразу после подключения вам доступна запись занятия по продвинутым SQL-запросам.
✔️ Запись сегодняшнего практикума появится на следующий день после занятия.
Вопросы? Пишите @getanalyst или info@getanalyst.ru.
До встречи онлайн! 😊
И с весной вас! Скорейшего перехода в 🌸🌿🌱
Если вам хочется иметь ясность и уверенность в проектировании БД, то как раз сегодня стартует серия практикумов по БД и SQL с новым проектом!
Будем строить БД с нуля, проектировать миграции, делать SQL-запросы, работать с ИИ и не только! 😊
Сегодня собираем ER-диаграмму физ. модели для ИИ-платформы и раскладываем по полочкам, как хранить в БД чаты и сообщения.
Подключайтесь на первое занятие:
🟢 Проектирование БД с нуля: создание ER-диаграммы
🤖 Проект: ИИ-платформа
🎁 Скидка -15% по промокоду «ВЕСНА2026»
только до конца дня, в честь старта проекта.
✔️ Сразу после подключения вам доступна запись занятия по продвинутым SQL-запросам.
✔️ Запись сегодняшнего практикума появится на следующий день после занятия.
Вопросы? Пишите @getanalyst или info@getanalyst.ru.
До встречи онлайн! 😊
И с весной вас! Скорейшего перехода в 🌸🌿🌱
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8
🚦 Всё про брокеры: как работают и зачем нужны 🚥
Брокеры — это посредники в передаче сообщений между системами или сервисами.
Они позволяют асинхронно обмениваться данными и обеспечивают гарантию доставки сообщений.
👉 Принцип работы:
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
Брокеры — это посредники в передаче сообщений между системами или сервисами.
Они позволяют асинхронно обмениваться данными и обеспечивают гарантию доставки сообщений.
👉 Принцип работы:
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
3🔥22❤8👎1👌1
💃 Хореография vs Оркестрация в микросервисной архитектуре 🎻
В микросервисной архитектуре (МСА) есть два основных подхода к управлению процессами между сервисами:
💃 хореография,
🎻 оркестрация.
Суть — несколько микросервисов должны отработать один сквозной сценарий, в правильном порядке и без “потерянных” шагов.
Пример из #AdFlowGA
Разрешение на публикацию объявления — это не просто “всё, публикуемся”.
Это триггер для цепочки действий:
1️⃣ запросить токен ERID для маркировки рекламы,
2️⃣ после этого отправить объявление на публикацию (ВК Реклама / Яндекс.Директ и др.)
3️⃣ запустить учёт бюджета рекламной кампании
С точки зрения архитектуры, этот процесс может быть реализован по-разному:
📌 Хореография
Каждый сервис сам реагирует на события и выполняет свою часть процесса.
Взаимодействие между сервисами происходит через брокер сообщений (обычно Kafka), без централизованного управляющего компонента.
Как это выглядит в AdFlowGA (примеры событий):
+ Срабатывает событие → publication.allowed
+ publication.allowed → МС Маркировки запрашивает ERID и публикует событие → erid.received
+ erid.received → МС Коннектор публикует объявление на площадке → ad.published
+ ad.published → МС Рекламные кампании запускает учёт бюджета
👉 Главное здесь — думать не “кто кого вызывает”, а какие события должны появляться в системе и что должен сделать каждый сервис, когда событие произошло.
📌 Оркестрация
Здесь управление процессом сосредоточено в отдельном компоненте — оркестраторе.
Пример оркестратора “из коробки”: Camunda.
Оркестратор вызывает нужные микросервисы по порядку:
▫️ получить ERID →
▫️ опубликовать на площадку →
▫️ начать отсчет бюджета кампании
и отслеживает их выполнение.
Вся логика сценария сосредоточена в одном месте, что упрощает контроль и трассировку бизнес-процесса.
👉 Что выбрать?
Оба подхода имеют свои преимущества и применяются в зависимости от целей:
💃 Хореография подходит для гибких, масштабируемых систем с высокой степенью независимости компонентов;
🎻 Оркестрация — для сценариев, требующих строгой последовательности, централизованного контроля и отслеживания хода выполнения.
Сводится к простому: где важна строгая последовательность, а где процесс можно построить как связку независимых шагов, выполняемых асинхронно.
#АрхитектураGA #AdFlowGA
В микросервисной архитектуре (МСА) есть два основных подхода к управлению процессами между сервисами:
💃 хореография,
🎻 оркестрация.
Суть — несколько микросервисов должны отработать один сквозной сценарий, в правильном порядке и без “потерянных” шагов.
Пример из #AdFlowGA
Разрешение на публикацию объявления — это не просто “всё, публикуемся”.
Это триггер для цепочки действий:
1️⃣ запросить токен ERID для маркировки рекламы,
2️⃣ после этого отправить объявление на публикацию (ВК Реклама / Яндекс.Директ и др.)
3️⃣ запустить учёт бюджета рекламной кампании
С точки зрения архитектуры, этот процесс может быть реализован по-разному:
📌 Хореография
Каждый сервис сам реагирует на события и выполняет свою часть процесса.
Взаимодействие между сервисами происходит через брокер сообщений (обычно Kafka), без централизованного управляющего компонента.
Как это выглядит в AdFlowGA (примеры событий):
+ Срабатывает событие → publication.allowed
+ publication.allowed → МС Маркировки запрашивает ERID и публикует событие → erid.received
+ erid.received → МС Коннектор публикует объявление на площадке → ad.published
+ ad.published → МС Рекламные кампании запускает учёт бюджета
👉 Главное здесь — думать не “кто кого вызывает”, а какие события должны появляться в системе и что должен сделать каждый сервис, когда событие произошло.
📌 Оркестрация
Здесь управление процессом сосредоточено в отдельном компоненте — оркестраторе.
Пример оркестратора “из коробки”: Camunda.
Оркестратор вызывает нужные микросервисы по порядку:
▫️ получить ERID →
▫️ опубликовать на площадку →
▫️ начать отсчет бюджета кампании
и отслеживает их выполнение.
Вся логика сценария сосредоточена в одном месте, что упрощает контроль и трассировку бизнес-процесса.
👉 Что выбрать?
Оба подхода имеют свои преимущества и применяются в зависимости от целей:
💃 Хореография подходит для гибких, масштабируемых систем с высокой степенью независимости компонентов;
🎻 Оркестрация — для сценариев, требующих строгой последовательности, централизованного контроля и отслеживания хода выполнения.
Сводится к простому: где важна строгая последовательность, а где процесс можно построить как связку независимых шагов, выполняемых асинхронно.
#АрхитектураGA #AdFlowGA
❤24🔥4👍1🤔1
🔴 Задача по архитектуре, которой проверяют опыт Senior СА 🔴
Перед вами описание бизнес-процесса в рекламной платформе #AdFlowGA.
Есть схема со всеми компонентами архитектуры, которые нужны для реализации процесса — но на ней нет стрелок.
👉 Бизнес-процесс:
➡️ Старт:
В админке модератор нажимает одну кнопку: «Опубликовать креатив (объявление)».
➡️ Система должна:
1) Зафиксировать прохождение модерации в истории
2) Получить токен маркировки (ERID)
3) Опубликовать объявление на площадке VK / Telegram / Yandex
4) Зафиксировать старт рекламной кампании
5) Зафиксировать успешную публикацию в истории объявления
6) Отправить уведомления рекламодателю
7) Записать событие о завершении модерации в аудит
👉 Схема:
прикреплена к посту.
+ описание архитектуры и первичное решение есть тут.
👉 Задание:
Показать на схеме архитектуры, как будет выполняться процесс от начала до конца.
Добавить стрелки и подписать номера шагов.
Условия:
+ Всё запускается одной кнопкой.
+ В системе много микросервисов и внешних интеграций.
+ Нужно, чтобы процесс был надёжным.
❌ На чём ошибаются системные аналитики, решая эту задачу в реальном времени:
1. Делают всё синхронно
2. Не видят точек оптимизации
3. Не могут правильно принять решение между хореографией и оркестрацией
4. Не думают про повторы и дубли (идемпотентность)
5. Не поднимают вопрос “что, если процесс упал на середине”
6. Полагаются на то, что внешние системы всегда доступны
7. Путают ответственность сервисов
8. Не задумываются о результатах для модератора
Я обязательно опубликую несколько вариантов решения задачи в рамках нашего проекта.
А пока — забирайте исходник, решайте сами и можете поделитесь схемами в комментариях:
🔗 [ссылка на исходник draw io / png]
Это ваша возможность попрактиковаться в решении сложных задач с собеседований на Senior! 💪
#АрхитектураGA
Перед вами описание бизнес-процесса в рекламной платформе #AdFlowGA.
Есть схема со всеми компонентами архитектуры, которые нужны для реализации процесса — но на ней нет стрелок.
👉 Бизнес-процесс:
➡️ Старт:
В админке модератор нажимает одну кнопку: «Опубликовать креатив (объявление)».
➡️ Система должна:
1) Зафиксировать прохождение модерации в истории
2) Получить токен маркировки (ERID)
3) Опубликовать объявление на площадке VK / Telegram / Yandex
4) Зафиксировать старт рекламной кампании
5) Зафиксировать успешную публикацию в истории объявления
6) Отправить уведомления рекламодателю
7) Записать событие о завершении модерации в аудит
👉 Схема:
прикреплена к посту.
+ описание архитектуры и первичное решение есть тут.
👉 Задание:
Показать на схеме архитектуры, как будет выполняться процесс от начала до конца.
Добавить стрелки и подписать номера шагов.
Условия:
+ Всё запускается одной кнопкой.
+ В системе много микросервисов и внешних интеграций.
+ Нужно, чтобы процесс был надёжным.
❌ На чём ошибаются системные аналитики, решая эту задачу в реальном времени:
1. Делают всё синхронно
2. Не видят точек оптимизации
3. Не могут правильно принять решение между хореографией и оркестрацией
4. Не думают про повторы и дубли (идемпотентность)
5. Не поднимают вопрос “что, если процесс упал на середине”
6. Полагаются на то, что внешние системы всегда доступны
7. Путают ответственность сервисов
8. Не задумываются о результатах для модератора
Я обязательно опубликую несколько вариантов решения задачи в рамках нашего проекта.
А пока — забирайте исходник, решайте сами и можете поделитесь схемами в комментариях:
Это ваша возможность попрактиковаться в решении сложных задач с собеседований на Senior! 💪
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥32❤13👎1🤩1💯1
🎻 Оркестрация микросервисов: полный практический гайд + материалы 📚
Оркестрация – это подход, при котором специальный сервис-оркестратор управляет группой микросервисов (МС).
👉 Оркестратор:
1. знает какие сервисы вызвать по API (обычно REST / gRPC)
2. в каком порядке
3. работает с условиями, сложными алгоритмами
4. если что-то пойдёт не так, то он "откатит" операцию на всех МС, которые уже были вызваны
Так сложный процесс превращается в цепочку задач. А Оркестратор следит за их выполнением.
👉 Как работает оркестратор
на примере Интернет-магазина:
1. Покупатель оформляет заказ через Web-приложение
2. Web-приложение отправляет запрос в API Gateway
POST .../orders
3. API Gateway маршрутизирует запрос на Оркестратор
4. Оркестратор присваивает id новой операции и вызывает API сервиса заказов
5. Сервис Заказов создает новый заказ в БД.
Результат - в Оркестратор
6. Оркестратор вызывает сервис Склада, чтобы зарезервировать товар
7. Склад подтверждает резерв или сообщает об отсутствии товара.
Результат - в Оркестратор
8. Оркестратор вызывает сервис Доставка для оформления отправления
9. Сервис доставки рассчитывает маршрут и время доставки, оформляет доставку.
Результат - в Оркестратор
10. Оркестратор вызывает сервис Уведомлений для отправки email/SMS о подтверждении заказа и доставке
11. Сервис Уведомлений выполняет отправку.
Результат - в Оркестратор
12. Оркестратор отправляет итоговый ответ в API Gateway, откуда он возвращается в Web-приложение
🔹Оркестратор вызывает API сервисов и ждёт ответ.
🔹Он может сохранять состояние процесса, чтобы возобновить его при сбое.
🔹 Если что-то идёт не так, оркестратор выполнит компенсации - откатит выполненные шаги.
📦 Готовые решения для оркестрации:
▫️ Camunda – BPM-движок с поддержкой диаграмм процессов (BPMN)
▫️ OpenBPM - аналог Camunda в России
📚 Подборка материалов:
🎧 Camunda и BPMN в микросервисах для процессов техподдержки
📝 Оркестрация и API Gateway – разбор реального примера
🎧 Внедряем Camunda: обзор и моделирование BPMN
#АрхитектураGA
Оркестрация – это подход, при котором специальный сервис-оркестратор управляет группой микросервисов (МС).
👉 Оркестратор:
1. знает какие сервисы вызвать по API (обычно REST / gRPC)
2. в каком порядке
3. работает с условиями, сложными алгоритмами
4. если что-то пойдёт не так, то он "откатит" операцию на всех МС, которые уже были вызваны
Так сложный процесс превращается в цепочку задач. А Оркестратор следит за их выполнением.
👉 Как работает оркестратор
на примере Интернет-магазина:
1. Покупатель оформляет заказ через Web-приложение
2. Web-приложение отправляет запрос в API Gateway
POST .../orders
3. API Gateway маршрутизирует запрос на Оркестратор
4. Оркестратор присваивает id новой операции и вызывает API сервиса заказов
5. Сервис Заказов создает новый заказ в БД.
Результат - в Оркестратор
6. Оркестратор вызывает сервис Склада, чтобы зарезервировать товар
7. Склад подтверждает резерв или сообщает об отсутствии товара.
Результат - в Оркестратор
8. Оркестратор вызывает сервис Доставка для оформления отправления
9. Сервис доставки рассчитывает маршрут и время доставки, оформляет доставку.
Результат - в Оркестратор
10. Оркестратор вызывает сервис Уведомлений для отправки email/SMS о подтверждении заказа и доставке
11. Сервис Уведомлений выполняет отправку.
Результат - в Оркестратор
12. Оркестратор отправляет итоговый ответ в API Gateway, откуда он возвращается в Web-приложение
🔹Оркестратор вызывает API сервисов и ждёт ответ.
🔹Он может сохранять состояние процесса, чтобы возобновить его при сбое.
🔹 Если что-то идёт не так, оркестратор выполнит компенсации - откатит выполненные шаги.
📦 Готовые решения для оркестрации:
▫️ Camunda – BPM-движок с поддержкой диаграмм процессов (BPMN)
▫️ OpenBPM - аналог Camunda в России
📚 Подборка материалов:
🎧 Camunda и BPMN в микросервисах для процессов техподдержки
📝 Оркестрация и API Gateway – разбор реального примера
🎧 Внедряем Camunda: обзор и моделирование BPMN
#АрхитектураGA
🔥20❤8👍2
В микросервисах важны не только сервисы, но и связи между ними. Если интеграции не продуманы — данные расходятся, появляются дубли, а разбор инцидентов превращается в хаос.
Чтобы вы на практике научились проектировать такие процессы, мы готовим новый открытый онлайн-практикум:
🟢 Онлайн
План практикума:
1. Как и зачем проектировать микросервисы
2. API Gateway: роль в архитектуре и границы ответственности
3. Введение в брокеры сообщений: Kafka
4. Хореография микросервисов: практика описания процессов через события
Урок будет полезен, если вы:
• готовитесь к интервью на Middle+ / Senior СА,
• хотите расширить техническую базу и работать с архитектурными задачами,
• или стремитесь работать в команде, где микросервисы — это реальность, а не теория.
Нужен реальный опыт в архитектуре?
Регистрируйтесь и присоединяйтесь к эфиру 12 марта в 19:00 Мск! 🔥
———
Онлайн-практикум является вводным уроком к программе Проектирование архитектуры для системных аналитиков, которая стартует 17 марта.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17❤6
Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
Разобрали, как low-code внедряют в крупные корпоративные системы: с полноценной разработкой и реальными нагрузками — и как системный аналитик с его помощью двигает продукт наравне с разработчиками.
Обсудили классный проект с голосовым роботом-помощником 🤖
Если вы хотите больше работать с техническими задачами, говорить с разработчиками на одном языке и приносить результат для продукта не только “в требованиях”, а в работающих решениях — этот выпуск для вас!
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video
🌐 GetAnalyst — профессиональная среда для тех, кто хочет уверенно расти в системном анализе и архитектуре
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12❤8❤🔥1😢1💯1
This media is not supported in your browser
VIEW IN TELEGRAM
❤7😱1🤣1
А так…. все ссылки собрала для вас тут 🙃
Разрешено в РФ
✅ VK
✅ Мессенджер Max
✅ RuTube
✅ Сайт GetAnalyst.ru
В нестабильной зоне - Telegram:
⚠️ GetAnalyst Навыки - продвинутый уровень
⚠️ Для начинающих в СА и БА
⚠️ Чат сообщества
⚠️ Подкаст (здесь ссылки на все аудио-площадки)
Доступно под VPN:
🔺 Instagram
🔺 LinkedIn
🔺 YouTube
👉 Подписывайтесь сейчас, чтобы не терять доступ к базе знаний GetAnalyst и продолжать ежедневное обучение 🚀
С добром и заботой,
Екатерина Ананьева,
и команда GetAnalyst 🤍
Разрешено в РФ
✅ VK
✅ Мессенджер Max
✅ RuTube
✅ Сайт GetAnalyst.ru
В нестабильной зоне - Telegram:
⚠️ GetAnalyst Навыки - продвинутый уровень
⚠️ Для начинающих в СА и БА
⚠️ Чат сообщества
⚠️ Подкаст (здесь ссылки на все аудио-площадки)
Доступно под VPN:
🔺 YouTube
👉 Подписывайтесь сейчас, чтобы не терять доступ к базе знаний GetAnalyst и продолжать ежедневное обучение 🚀
С добром и заботой,
Екатерина Ананьева,
и команда GetAnalyst 🤍
1❤27👌5🤔1🤣1
Мы умеем быть разными: мягкими, сильными, умными, красивыми — и гораздо глубже, чем просто внешность.
Мы держим в голове десятки задач, замечаем детали, собираем хаос в логику. И часто держим на себе больше, чем о нас принято думать. Не только в работе, но и в жизни.
С 8 марта, дорогие девушки!
Пусть весна и любовь согревают вас, а ваше сияние — всё вокруг 🌸💐🩷☀️
Пусть вас ценят по-настоящему — и в работе, и в жизни! 💙
Мы держим в голове десятки задач, замечаем детали, собираем хаос в логику. И часто держим на себе больше, чем о нас принято думать. Не только в работе, но и в жизни.
С 8 марта, дорогие девушки!
Пусть весна и любовь согревают вас, а ваше сияние — всё вокруг 🌸💐🩷☀️
Пусть вас ценят по-настоящему — и в работе, и в жизни! 💙
1❤45❤🔥13🎉4🍾3