🌱 Одна из ступеней профессионального роста системного аналитика - работа в тесном сотрудничестве с архитекторами на проектах с сервисной или микросервисной архитектурой.

Мы в GetAnalyst создали программу для опытных специалистов, которая помогает на практике получить все нужные знания по архитектуре, чтобы продолжать расти в карьере и соответствовать актуальным требованиям компаний:


⚡ Проектирование архитектуры
🗓 Старт: 3 июня 2025
👉 Подробности и заявка на участие


🎁 Сегодня последний день, когда открыта запись на самых выгодных условиях:
✔️ спец. цена
✔️ дополнительное обучение по REST API в подарок


По всем вопросам пишите @getanalyst, info@getanalyst.ru или оставляйте заявку через сайт. Мы свяжемся с вами, поможем оценить текущие навыки и ответим на ваши вопросы 🤝

⚡ Доступ к обучению по Архитектуре с 31 мая до 2 июня ⚡

Пытаетесь самостоятельно разобраться в архитектуре систем и расти в карьере, но не хватает практики и понятных примеров? Давайте сделаем это вместе — пошагово и на реальном кейсе!

Мы готовим открытый практикум для системных аналитиков, чтобы вы на практике поняли, как проектируется архитектура:


🚀 От монолита к микросервисам: пошаговый план с примером
🗓 Доступ с 31 мая до 2 июня [сб - пн]
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

Занятие в записи. Вы сможете посмотреть его в удобное для вас время.


План:
✅ Плюсы и минусы монолита — на реальном проекте.
✅ Что такое SOA и MSA, чем отличаются и когда используются.
✅ Как делить монолит на микросервисы.
✅ Проработаете миграцию модуля в микросервис: БД, ER-диаграмма, вынос данных.
✅ Осознаете, почему делают модульный монолит перед переходом к микросервисам.
✅ Узнаете, как аналитик может расти в сторону архитектуры и какие навыки нужны для этого.


Вы получите знания и инструменты, которые сразу можно применить в работе.

Успейте зарегистрироваться — доступ будет открыт только с 31 мая по 2 июня! 🙌

🔵 C4 / Container - пример микросервисной архитектуры #GreenChargeGA 🔵

Уровень C4 / Container показывает независимые по коду приложения в системе — так называемые контейнеры [к].

Что включает схема на этом уровне:
✔️ Пользователи
✔️ Внешние системы
✔️ Мобильные, веб- и десктоп приложения [к]
✔️ Микросервисы [к]
✔️ API Gateway (маршрутизатор API-запросов) [к]
✔️ БД и ФХ [к]
✔️ API для взаимодействия сервисов
✔️ Брокеры для асинхронного обмена [к]

В микросервисной архитектуре этих контейнеров может быть очень много, и без хорошей визуализации легко потеряться 🤪


📌 Ранее я показывала архитектуру GreenChargeGA в виде "квадратиков и стрелочек", теперь, в прикреплённой к посту схеме, используется нотация C4 > уровень Container.

Что добавила C4:
✅ Чёткие указания на используемые API и протоколы
✅ Указание языков программирования и фреймворков всех приложений
✅ Технологии БД и файловых хранилищ

Теперь на диаграмме есть вся необходимая информация, чтобы понять архитектуру проекта без чтения документации.


Недостатки показанной архитектуры, которые будем дорабатывать:
❌ Нет связи от Firebase к фронтам, куда доставляются уведомления
❌ Синхронизация всего через один API Gateway? Плохо масштабируемая и уязвимая идея
❌ Всё синхронно внутри? Не надёжно 🥲 Надо ещё брокеров
❌ Не показаны WebHooks от платежных систем
Подумайте уже сейчас, как исправить эти недостатки на схеме 😉


💡Лайфхак
Для простоты восприятия можно объединить все микросервисы и инфраструктуру в один контейнер «Backend», а детали вынести на уровень C4/Component.
Но это будет противоречить нотации.

💡На практике
Команды часто адаптируют C4 под свои нужды. Я же рекомендую придерживаться здравого смысла, прозрачности и принципа "понятно с первого взгляда".

📚 Связанные материалы:
Нотация C4 и документация по ней
C4 / Context для проекта GreenChargeGA (предыдущий уровень)


Изучайте и сохраняйте! 💙
Это мощный и наглядный пример, к которому точно захочется вернуться, когда будете продумывать или описывать архитектуру в своих проектах.

#АрхитектураGA

📩 Всё про брокеры: как работают и зачем нужны 📩

Брокеры — это посредники в передаче сообщений между системами или сервисами.

Они позволяют асинхронно обмениваться данными и обеспечивают гарантию доставки сообщений.


👉 Принцип работы:

1. Сервис 1 (Producer/ Производитель) хочет отправить данные в Сервис 2 (Consumer/ Потребитель).

2. Сервис 2 в это время может быть перегружен или занят.

3. Чтобы Сервис 1 не ждал, пока Сервис 2 станет доступен, он кладет сообщение в Брокер и продолжает свою работу.

4. Брокер сохраняет сообщение и ставит его в очередь к обработке.

5. Как только Сервис 2 становится доступен, то он забирает сообщение из Брокера и обрабатывает его.

По сути брокеры - это временные Базы Данных,

которые гарантируют, что сообщения (данные) в них будут храниться, пока их не заберут и не обработают соответствующие системы или сервисы.

👉 Брокеры могут использоваться:
+ в сервисной и микросервисной архитектуре,
+ в событийно-ориентированной архитектуре (EDA),
+ когда нужна фоновая обработка событий в монолите,
+ для асинхронных интеграций.


👉 Брокеры сообщений предлагают два основных шаблона обмена данными:

1. Точка-точка (Point-to-Point Messaging)
Это паттерн, используемый в очередях сообщений, где существует один отправитель и один получатель. Каждое сообщение в очереди отправляется только одному получателю и может быть обработано только один раз.

2. Публикация-подписка (Publish/Subscribe Messaging)
В этом паттерне отправитель (producer) публикует сообщения в определённую тему (topic), а подписчики (consumers) подписываются на темы, чтобы получать сообщения.
Все сообщения, опубликованные в теме, доставляются всем приложениям, подписанным на неё.
Применяется в случаях, где несколько систем должны получить одну и ту же информацию.


Возможности и логика работы брокеров отличаются в зависимости от конкретного решения.

Основные решения по брокерам на рынке:
✅ Apache Kafka
✅ RabbitMQ
✅ ActiveMQ
✅ Amazon MQ, Amazon SQS
✅ Яндекс Message Queue (YMQ) - аналог Amazon
✅ и другие.

#АрхитектураGA

🔔 Уже завтра! Бесплатный практикум по Архитектуре для Системных Аналитиков 🔔

Хотите развиваться в теме проектирования архитектуры и работать в IT-продуктах с брокерами и микросервисами? Тогда вам сюда!


🚀 От монолита к микросервисам: пошаговый план с примером
🗓 Доступ с 31 мая до 2 июня [сб - пн]

👉 Узнать подробнее и зарегистрироваться

🎥 Урок в записи — смотрите в удобное время.


Что разберём:
1. Монолит: плюсы и минусы
2. SOA vs MSA: в чём разница и когда что выбрать
3. Пошаговый план деления монолита на микросервисы
4. Разбор кейса по вынесению модуля из монолита в деталях: архитектура, вынесение данных в отдельную БД, особенности
5. Почему молодым продуктам лучше делать модульный монолит
6. Как аналитику расти в сторону архитектура и что для этого нужно


Практика, реальные кейсы и ответы на вопросы.


Регистрируйтесь, получайте опыт и переходите на новый уровень в системном анализе! 🙌