💚💜 5 стандартных сервисов и микросервисов 💜💚

В большинстве проектов, которые используют подход сервисной или микросервисной архитектуры, можно встретить эти пять основных сервисов:

✅ Аутентификация и авторизация
Управление процессами аутентификации пользователей и контроля доступа к ресурсам системы.

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

✅ Уведомления и рассылки
Отправка уведомлений и сообщений пользователям через различные каналы (email, SMS, push-уведомления).

✅ Управление контентом (блоги на сайтах, новости и подобное)
Управление статическим и динамическим контентом (тексты, изображения, видео), организация его структуры и хранения.

✅ Биллинг и платежи
Обработка и учет платежей, интеграция с платежными шлюзами, выставление счетов. Взаимодействует с внешними платежными шлюзами и банковскими системами.


Если я работаю над проектом с нуля, то использую этот список как чек-лист “С чего начать". Поможет всем IT-специалистам в задачах, связанных с проектированием архитектуры.


В мини-книге прикрепленной к посту рассказала подробнее про каждый сервис, и почему их выделяют как независимые части систем 🙌

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

🧑‍🌾 Пример: сервисы и микросервисы для проекта #FarmFreshGA 🧑‍🌾

Вчера и сегодня я рассказывала про подходы к выделению сервисов и микросервисов. Пришло время применить их на практике!

Разделим на части Backend платформы FarmFresh, которая занимается заказом фермерских продуктов и оформлением подписки на них.

🔗 О проекте

💚 Сервис аутентификации и авторизации
Отвечает за регистрацию и авторизацию пользователей, управление ролями и правами доступа. Ожидается высокая нагрузка.

💚 Сервис управления пользователями
Получение и редактирование данных профилей, настройки уведомлений, любимые товары.

💚 Сервис каталога товаров
Добавление, изменение и удаление товаров фермерами, распределение их по категориям. Поиск товаров для покупателей. Высокая нагрузка - основная функциональность системы.

💚 Сервис заказов
Обработка заказов покупателей, включая добавление в корзину и контроль статусов.

💚 Сервис подписок Создание, обновление и отмена подписок на продукты.

💚 Сервис платежей
Интеграции с внешними платежными системами для обработки платежей, работа с возвратами и отменой покупок. Основная и критическая функциональность.

💚 Сервис доставки Управление зонами доставки, расписанием и доступностью курьеров. Отслеживание статусов доставки и обновление их в сервисе заказов. Интегрируется с внешними API курьерских служб.

💚 Сервис склада
Контроль запасов продуктов от каждого фермера и учет данных при оформлении заказов пользователями. Высокая нагрузка.

💚 Сервис уведомлений Отправка уведомлений (push-, SMS, email) пользователям. Интеграция с соответствующими сервисами рассылок.

💚 Сервис маркетинга и акций
Управление скидками, акциями и специальными предложениями для покупателей.

💚 Сервис отзывов и рейтингов

💚 Cервис чата и поддержки

💚 Сервис API Gateway
Маршрутизация запросов к сервисам, а также для контроля безопасности и авторизации.

Есть еще идеи по дополнительным сервисам?
Пишите идеи в комментарии! Добавим 😎

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

💛 Спасибо 💛

Иногда сообщения, которые мы получаем, трогают до глубины души.

Они напоминают мне о том, что GetAnalyst существует не зря.

В мае я пытался сменить место работы, но мне не удавалось пройти собеседования на те места, которые мне были интересны. На тот момент я уже учился в другом месте на курсе системного аналитика, но чувствовал, что мне не хватает знаний и практики. К счастью, я встретил сайт GetAnalyst! Несмотря на то, что нужные модули мне ещё предстояли в большом курсе, я решил параллельно пойти ещё и в GA по интеграциям и архитектуре. 

В сентябре я вновь начал поиски работы и уже примерно через неделю получил два интересных оффера! Я бы точно не справился без GetAnalyst и не чувствовал бы себя так уверенно на технических интервью. Вчера был мой первый день в Сбере, и я очень счастлив, что 5 месяцев назад увидел в интернете одну из ваших статей 😄.

Спасибо, что делитесь своими историями!
Спасибо, что вы с нами!
Спасибо, что ставите ❤️👍🔥🦄 под посты!

Это мое вдохновение и поддержка всей команды!

Каждый подобный отзыв — напоминание, что знания и опыт, которыми мы делимся, помогают вам стать лучшей версией себя 🚀

Вы делаете успехи в карьере, преодолеваете "синдром самозванца" и с уверенностью осуществляете поставленные цели.

Гордимся каждым из вас! 💜

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

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


💥 Проектирование Архитектуры
🗓 Старт предобучения 3 декабря 2024
🔗 Подробности о программе и запись

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


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

💎 Пример схемы архитектуры проекта #FarmFreshGA 💎

Самое простое в проектировании архитектуры микросервисов — создать схему, в которой есть только синхронные взаимодействия и один вид API, например, REST API. Однако в реальных системах редко встречаются решения, где используется только синхронный обмен данными.

Рассказываю, что к чему при проектировании архитектуры на примере схемы, прикреплённой к посту, где пока отсутствуют асинхронные взаимодействия.


1. Для проектирования архитектуры FarmFresh выбран шаблон API Gateway
Все запросы от клиентских приложений (Frontend) направляются в единый централизованный шлюз и далее проксируются (перенаправляются) на отдельные микросервисы, в зависимости от запроса.


2. Согласно предложенной схеме, внутреннее взаимодействие микросервисов организовано также через API Gateway
Надо понимать, что такое решение не всегда удачно.
Пример: Если сервису заказов нужно вернуть полную информацию о нём на Frontend, включая данные о товарах, то вместо прямого запроса в микросервис "Каталог товаров" придётся прогонять запрос через лишний слой API Gateway. Это может создавать ненужную задержку.


3. Снаружи для клиентов может быть только REST API, а “под капотом” всё что угодно
На предложенной схеме видим, что часть микросервисов предлагает взаимодействие через gRPC для ускорения обмена данными, а часть — через REST API. Однако слишком много разных видов API может усложнить разработку и сопровождение.
Простота и единообразие — залог успешной архитектуры.
Но зависит от проекта))) Где-то это просто нужно и точка.


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


Продолжение 👇

💎 Пример схемы архитектуры проекта #FarmFreshGA (продолжение 👇) 💎


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

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

Итог: 5 сервисов обращаются к одному, что может привести к задержкам при синхронном взаимодействии из-за загрузки

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



5. У каждого микросервиса своя БД

Это строго соответствует принципам микросервисной архитектуры.

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


6. Взаимодействие с сервисом чата организовано через WebSocket

Сервис чата работает в режиме реального времени. Чтобы не нагружать API Gateway постоянными открытыми соединениями, WebSocket вынесен на отдельный слой. Это решение выбрано для повышения производительности и отказоустойчивости.
Это одно из возможных решений.

--------------

Заключение:

Предложенная схема архитектуры FarmFresh демонстрирует базовую реализацию микросервисного взаимодействия с шаблоном API Gateway.

Для повышения производительности и надёжности системы стоит рассмотреть:
👉 Внедрение асинхронного взаимодействия через брокеры сообщений.
👉 Прямые вызовы между микросервисами там, где это оправдано.
👉 Минимизацию разнообразия API-протоколов для упрощения разработки и поддержки.


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

🚀 Асинхронное взаимодействие в архитектуре систем 🚀

Часто при разработке архитектуры начинают с простого: сервисы напрямую общаются друг с другом в реальном времени, используя синхронные вызовы, например через REST API, SOAP или gRPC.

Синхронное взаимодействие предполагает, что один сервис отправляет запрос другому и ждёт ответа.

Это удобно на старте, но по мере роста системы такое взаимодействие может создавать проблемы:
😬 высокую связанность,
😬 задержки в работе из-за высокой нагрузки на микросервис,
😬 или полное "падение" цепочки сервисов в алгоритме из-за сбоя одного из них.

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

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

Ключевые преимущества такого решения:

👍 Развязка сервисов
Сервисы не зависят от доступности друг друга. Если один сервис временно недоступен, сообщения сохраняются в очереди и будут обработаны позже.

👍 Масштабируемость
Асинхронные системы легче масштабировать, так как взаимодействие сервисов не требует немедленного ответа.

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



Технологии, помогающие реализовать асинхронное взаимодействие:
1. Apache Kafka
2. RabbitMQ
3. ActiveMQ
4. Amazon MQ, Amazon SQS
5. Яндекс Message Queue (YMQ) - аналог Amazon
и другие.


Также для любого асинхронного взаимодействия можно добиться при помощи синхронных API с использованием механизмов:
1. WebHook
2. Polling
3. LongPolling
в сочетании с кронами, таймерами и воркерами.


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

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