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

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

💥 Проектирование архитектуры
🗓 Старт: 4 марта 2025
👉 Подробности о программе и заявка на участие

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

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

⚙️ Микросервисная архитектура (МСА) — это современный подход к разработке высоконагруженных приложений.

Ключевые компоненты, которые используются для его реализации:


✅ Клиенты — это Frontend-приложения или другие системы, которые взаимодействуют с Backend (сервер-приложением).


✅ CDN (Content Delivery Network) — сеть серверов, стратегически распределенных по всему миру. Они кэшируют и доставляют статические ресурсы (изображения, скрипты и т. д.) пользователям с ближайшего сервера, оптимизируя время загрузки.


✅ API Gateway — единая точка входа для всех клиентов API. Он маршрутизирует запросы на нужные микросервисы, благодаря чему клиентам не надо думать о том, к какому сервису обратиться для вызова конкретной функции.

Он также может управлять аутентификацией, ограничением количества запросов (rate limiting) и другими доп. функциями.


✅ Микросервисы — это независимые компоненты, каждый из которых выполняет свою конкретную бизнес-логику.

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


✅ Брокер сообщений — обеспечивает асинхронное взаимодействие между микросервисами.

Развязка сервисов через брокер (например, Kafka, RabbitMQ) делает систему более гибкой и отказоустойчивой, позволяя микросервисам работать независимо.


✅ Базы данных — в МСА действует принцип "база данных на сервис". Это принцип предотвращает жёсткие связи между сервисами и позволяет использовать разные технологии хранения данных (polyglot persistence), выбирая оптимальные решения под конкретные задачи.


✅ Identity Provider — отвечает за аутентификацию (проверку личности пользователя) и авторизацию (определение прав доступа).


✅ Service Registry and Discovery — это динамический каталог, в котором микросервисы регистрируются и находят друг друга.


✅ Service Coordination — инструменты, которые помогают управлять координацией и синхронизацией распределенных сервисов, обеспечивая их бесперебойную работу и согласованность данных.


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

Как каждый год деградировать в навыках и опыте? 😬 Дорасти до топовой должности.

Перейти в режим "я уже всё знаю".
Годами сидеть в одной компании.
Получать стабильное повышение 5-10% в год.
И быть уверенным, что ты вау!


А потом, спустя 5+ лет, выйти на рынок, потому что стало скучно… и офигеть.

👉 Потому что технологии ушли далеко вперёд, а твои "ценные знания" вдруг оказались базой, на которой уже давно строят что-то более сложное.

Хотя бывает, что повезло, компания в тренде, и ты постоянно пробуешь новые подходы, внедряешь современные технологии. Но так бывает не всегда. И из таких компаний не уходят, потому что скучно))


Как пример, по моим ощущениям, 5 лет назад REST API, Kafka и микросервисы были чем-то уникальным для СА 🙌

Это были бонусы, которые ценились на отдельных проектах, и делали умножение ЗП на лучший коэффициент при выходе в новую компанию.

Сегодня же про Kafka и микросервисы спрашивают на каждом третьем собеседовании. REST API — вообще must-have для Middle СА. И не выпендриться уже, что я такая вот уникальная 🙁


👉 Такой вот жестокий мир IT.
Сидеть на месте тут не очень получается.


Я вообще постоянно переживаю, что могу отстать и не узнать что-то важное. Это отлично мотивирует.

Сейчас будущее за нейросетями.

Поэтому, на страхе отстать от жизни, я:
+ Пишу прототипы приложений
+ Езжу на конференции по AI
+ Разбираюсь с инфраструктурой, безопасностью и архитектурными проблемами AI
+ Считаю токены и оптимизирую запросы

И при всём при этом...
Я сижу с "синдромом самозванца" 😁
Это обычное явление, если ты постоянно изучаешь что-то новое))

IT — это про вечное обучение.

Те, кто приходят в IT только ради денег, надолго здесь не задерживаются.

Мы постоянно учимся.
Много работаем.
Это сфера, где ты либо постоянно растёшь, либо быстро устареваешь.


Так что если вам кажется, что вы ничего не знаете — это нормально.

Это ощущение заставляет
шевелить извилинами 🧠,
постоянно расти,
и быть лучшими в нашей профессии))

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

В этой подборке вы найдёте теорию вместе с разборами реальных рабочих задач.

Каждый материал подкреплён примерами для лучшего восприятия информации 🙌


REST API
▫️ Проектирование REST API: спорные вопросы с проектов и собеседований
🔹 Вопросы и ответы по REST API: собеседование на системного аналитика
▫️ Книга по JSON в REST API
▫️ Headers
▫️ Виды авторизации в API
▫️ Протокол HTTP
🔺 Связь базы данных и дизайна REST API
🔺 Postman: навык тестирования REST API за вечер

Интеграции
▫️ Как аналитику работать с задачами на интеграции — пошаговая инструкция
▫️ Интеграции - что это и основные способы
▫️ Отличия между обычными и интеграционными Use Case
▫️ Пример интеграционного Use Case
▫️ Практическое руководство по Postman - тестирование API DaData (с нуля до результатов)
▫️ Полный шаблон постановки задачи на интеграционный REST API-метод
🔹 Проблемы в работе с задачами на интеграции
▫️ UML-диаграмма: разбор задачи и инструменты

БД и SQL
🔹 Связь "многие-ко-многим": разбор задачи с собеседования
🔺 Проектирование БД: логический уровень
🔹 Нормальные формы БД
▫️ ER-диаграмма БД через код

Архитектура
▫️ 7 шаблонов проектирования архитектуры, которые важно понимать СА
▫️ Монолит, Сервисная и Микросервисная архитектура - сравнение
▫️ Как показать схему архитектуры: примеры решений
▫️ Нотация C4 для моделирования архитектуры
🔹 gRPС vs REST - что выбрать для проекта
🔹 Нефункциональные требования
▫️ GraphQL — знакомство на практике через Postman [пошаговая инструкция]
▫️ Очередь сообщений VS Брокер - вопросы с подвохами
▫️ Kafka


▫️ - статьи и книги
🔹 - подкасты
🔺 - видео YouTube

Сохраняйте, чтобы не потерять 👌

🔥 3 реальных задачи, которые решают брокеры 🔥

Брокеры сообщений — это не просто очереди для передачи данных. Это ТОП-инструмент для построения асинхронных, отказоустойчивых и масштабируемых систем.

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


Разберем три основных кейса, когда без брокеров не обойтись:

📌 1. Централизованная отправка уведомлений

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

Вместо этого сервисы просто отправляют события в брокер, а сервис уведомлений обрабатывает их, когда будет готов.

👍 Почему так лучше?

+ Уменьшается связанность между сервисами
Если сервис уведомлений перегружен и не может принять сообщение сразу, оно сохранится в брокере.
Отправивший задачу на уведомление сервис не зависает в ожидании ответа, а продолжает работу.

+ Гибкое масштабирование
Когда 15 сервисов генерируют уведомления, для их обработки может понадобиться от 5 до 15 экземпляров сервиса уведомлений.
Без брокера система должна мгновенно реагировать на всплески нагрузки и увеличивать количество работающих копий сервиса уведомлений.
С брокером это не критично — сообщения просто ставятся в очередь и обрабатываются позже.

+ Можно легко добавлять новые каналы уведомлений (почта, пуши, SMS)
Например, в сервисе заказов сменился статус товара на "Доставлен".
Пользователь подписан на push, SMS и email-уведомления
Вместо того, чтобы сервису заказов делать три запроса или один долгий и ждать, пока каждое уведомление отправится, мы положим событие о смене статуса в брокер с пометкой о каналах доставки. А сервис уведомлений позже его обработает.
Таким образом, сервису заказов не придётся длительно ожидать ответ о доставке всех уведомлений.


📌 2. Централизованный сбор событий для мониторинга

Все сервисы отправляют в брокер данные о своих состояниях, ошибках, метриках. Из брокера эти события забирает система мониторинга, анализирует их и отправляет алерты DevOps-инженерам.

👍 Почему так лучше?

+ Все данные собираются в одном месте
Логи, ошибки, метрики и другие события поступают в брокер от всех сервисов, упрощая их обработку и анализ.

+ Гибкость и независимость от конкретной системы мониторинга
Можно легко подключать новые инструменты анализа и визуализации (Prometheus, ELK, Grafana и др.), не внося изменения в код сервисов, которые генерируют события.
Без брокера пришлось бы перенастраивать все сервисы на доставку в новый сервис мониторинга.

+ Гибкое масштабирование


📌 3. Реакция нескольких сервисов на одно событие

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

Пример:
При успешной оплате заказа в Интернет-Магазине сервис платежей отправляет событие "Оплата успешна" в брокер.

На это событие реагируют три сервиса:
▫️ Сервис заказов переводит статус заказа в "Оплачен"
▫️ Сервис склада списывает товары и создает задачу на сборку
▫️ Сервис уведомлений отправляет клиенту подтверждение об оплате

Если бы сервис платежей напрямую дергал API каждого сервиса, это привело бы к сильной связанности и проблемам при сбоях.

Сервис склада упал?
➖ Прервали процесс обработки события оплаты, потому что не получилось достучаться до склада
➖ Или потеряли уведомление о платеже и оно не дошло на склад

Брокер позволяет сделать процесс асинхронным и надежным.

👍 Почему так лучше?

+ Уменьшается связанность между сервисами
За счет асинхронного обмена и отвязки от режима реального времени, когда все должны работать и быть доступны.

+ Можно легко добавлять новые подписчики без изменений в коде исходного сервиса
Например, когда после успешной оплаты надо еще начислить бонусные баллы в сервисе лояльности, то мы добавим новый обработчик события из брокера, но не будем трогать код сервиса платежей.

+ Лучше отказоустойчивость
Нет риска, что событие не обработается в каком-либо сервисе - брокер даёт гарантию доставки.

+ Гибкое масштабирование


Итого:
Брокеры — залог гибкой, масштабируемой и отказоустойчивой архитектуры 👍

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

💫 Kafka - что надо знать для работы Системному аналитику 💫

Apache Kafka — это распределённая платформа потоковой обработки данных.

Предназначена для публикации, хранения и обработки событий/сообщений в реальном времени.


Основные компоненты:

✔️ Продюсеры (Producers)

1) Генерируют сообщения/события к обработке и отправляют в топики (темы).

2) Определяют, в какую партицию топика записывать данные: автоматически или по заданным правилам.

3) Могут быть чем угодно: микросервисы, устройства IoT и другие приложения.

4) Поддерживают режимы отправки:
+ Синхронный — ждёт подтверждения от Kafka перед отправкой следующего сообщения.
+ Асинхронный — отправляет сообщения без ожидания ответа.

5) Могут гарантировать доставку с разными уровнями подтверждения (acks):
+ acks=0 — без ожидания подтверждения (возможна потеря данных, высокая скорость).
+ acks=1 — подтверждение только от лидера партиции (среднее).
+ acks=all — подтверждение от всех реплик (максимальная надёжность).


✔️ Потребители (Consumers)

1) Подписываются на один или несколько топиков и получают сообщения/события.

2) Могут работать как отдельные клиенты или объединяться в группы (Consumer Groups) для параллельной обработки сообщений.

3) В группе консьюмеров каждый участник обрабатывает свою часть партиций.

4) Kafka гарантирует, что каждое сообщение будет обработано хотя бы одним потребителем в группе.

5) Модели доставки сообщений:
+ at-least-once — как минимум 1 раз, возможны дубликаты.
+ exactly-once — ровно один раз.


✔️ Топики (Topics) — логическая тема, куда продюсеры отправляют сообщения, а потребители их читают


✔️ Партиции (Partitions) — подмножество данных внутри топика, которое позволяет распределять нагрузку и масштабировать обработку сообщений. Каждый топик состоит из одной или нескольких партиций


✔️ Брокер (Broker) — сервер Kafka, который отвечает за хранение, управление и передачу данных внутри кластера


✔️ Кластер — это группа брокеров, работающих вместе для масштабирования и распределённой обработки данных


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

📚 Мини-книга по Интеграциям для Системных аналитиков: самое важное 📚

Интеграция — это процесс объединения различных систем и приложений в единое целое, чтобы они могли работать вместе, обмениваться данными и выполнять задачи, как одна система.


Например, нам в приложении для медитаций надо сделать возможность оплаты подписки 🧘‍♀️

Получается, надо делать сложный банковский процессинг для проверки карт кучи банков, списания с них денег, проверки CVV, отправки проверочных кодов, безопасность приема и обработки платежей...?
В общем эту всю кучу банковских задач мы делать не хотим. Мы же не банк! 🥲

Поэтому, для упрощения своей жизни, мы подключим готовое банковское решение "Интернет-эквайринг" - то есть сделаем интеграцию с банковской системой.
Обычно это интеграции по API.


Главная идея интеграций:

Если не хочешь "изобретать велосипед", просто подключи (интегрируй) уже готовое решение в свою систему.

👉 Виды интеграций:

1) по окружениям:
▫️ Внешние - когда мы хотим подключить к нашей системе чужую систему, от других разработчиков.
▫️ Внутренние
- у нас на проекте сервисная или микросервисная архитектура, и нам надо сделать так, чтобы сервисы обменивались данными друг с другом по API или через брокеры (очереди).
- мобильное приложение работает с данными благодаря интеграции с сервером по API.

2) по направлению:
▫️ Во внешние системы - когда мы используем API чужих систем.
▫️ К нашей системе - когда мы сами разрабатываем свой API, чтобы к нам подключались (например, по примеру выше, мы банк, и даем другим свой API для подключения)


👉 Способы обмена данными:
▫️ Синхронный - отправили данные и получили ответ сразу.
▫️ Асинхронный - отправили данные и продолжили работу без ожидания ответа. Обработка в фоне.


👉 Основные способы интеграции:
▫️ API
▫️ Библиотеки и SDK
▫️ Брокеры (очереди сообщений)
▫️ Файлы
▫️ Общая БД


📚 Подробнее о том, что такое интеграции и какие они бывают, рассказала в мини-книге с картинками и примерами.

Файл прикреплен к посту.

Загружаем, изучаем и запоминаем 👍

#ИнтеграцииGA