Ремонт, сервис, услуги » Информация » Пример микросервисной архитектуры с Saga на MassTransit




Пример микросервисной архитектуры с Saga на MassTransit

Автор: addministr от 10-05-2022, 08:45

Категория: Информация



Привет, Хабр! В общем работаю я значит Архитектором Програмных Решений. Мы тут монолиты на микросервисы переводим поэтому я решил для наших разработчиков написать пример того как работают саги и за одно может оно и вам понадобиться поэтому выложил сюда. Статья будет дополняться по мере поступления вопросов от вас и от наших разработчиков. Саги используются для описания процесса изменения состояния системы для исполнения, которого нужно сделать запрос более чем в один сетевой сервис. Они используются:1)      Для обеспечения порядка исполнения. Для систем, работающих на событиях это не гарантировано. Чтобы действие Б выполнилось строго после действия А нужно посылать ответные события на событие А и строго после того как получено это ответное событие запускать Б. 2)      Для компенсации действий. Если действие Б провалилось по какой-то причине, то сага может выполнить компенсирующее запросы для действия А. 3)      Для описания процесса. Если процесс большой и сложный, то его удобно расписать в виде Саги чтобы в одном месте видеть, что происходит. Тут Сага служит как схема BPM описывающая что мы Делам А потом делаем Б если Б успешно, то делаем С иначе делаем D и т. д. 4)      Для гарантированного выполнения каково-то набора действий. Если мы сделали А, то Сага может повторять пытаться выполнить действие Б до фиксированного количества ретраев. 5)      Для обеспечения консистентной системы. Например, когда нужно изменить состояние микросервиса А и микросервиса Б строго в соответствии друг с другом. Тут небольшое отступление. Обычно в внутри системы между микросервисами используют один формат  (например AMPQ или gRPC) а снаружи могут быть системы использующие SOAP, HTTP и так далее. Для того чтобы изолировать внутренние сервисы от особенностей внешней среды обычно использую два типа сервисов переводчиков. Gateway и Proxy. Их основная задач переводит из одного протокола в другой. Например из HTTP в AMPQ. Отличия в том что Gateway используется для того чтобы переводить и изолировать запросы снаружи внутрь. Например SpaGateway используется для перевода запросов с фронта. Proxy используется для переводов изнутри наружу. Например SmtpServerProxy для перевода запросов от нас к почтовому серверу. Если каждый микросервис рассматривать как какой-то объект или библиотеку, то для их архитектуры принципы SOLID и другие в этом роде очень даже применимы. В целом Saga исполняет роль «Мозга», у которого есть «Органы» это микросервисы. Ну или можно рассматривать Сагу как начальника у которого есть подчиненные микросервисы. В сложных процессах выделяют главную сагу. Главный процесс и дочерние саги – под процессы. Родительская сага отдает команды дочерним Сагам (под процессы) которые уже в свою очередь отдают команды микросервисам. Наша сага будет максимально простой. Без компенсирующих действий. Суть ее логики: У нас есть отдельно микросервис предметов из которого можно взять определенное количество предметов или добавить. Есть микросервис денег откуда можно либо взять, либо добавить определенное количество денег. Мы проработаем простой сценарий где сага сначала берет из микросервиса денег определенную сумму (холдирует ее) и потом забирает из микросервиса предметов определенное количество (уменьшает количество на складе) предметов.Диаграмма размещения:
Диаграмма последовательности:
Схема запросов:
Пример микросервисной архитектуры с Saga на MassTransit

MoneyMicroservice

Для начала необходимые зависимости можно поставить командами:

Install-Package MassTransit.AspNetCore
Install-Package MassTransit.RabbitMQ
Install-Package MassTransit.EntityFrameworkТак же необходимо поставить на RabbitMq Delayed Message Exchange Создаем сообщения запрос и ответ для работы с шиной

//Рекомендуется для контрактов использовать интерфейсы чтобы не было возможности
//в них прикрутить какую-то логику.
//Хотя уже с новой версией C# где можно реализации и интерфейсам прикреплять
//подход больше не актуален
public interface IGetMoneyRequest
{
public Guid OrderId { get; }
}

public interface IGetMoneyResponse
{
public Guid OrderId { get; }
}Создаем обработчик этого сообщения

public class GetMoneyConsumer : IConsumer
{
public Task Consume(ConsumeContext context)
{
return context.RespondAsync(new { context.Message.OrderId });
}
}
Дальше добавляем в стартапе наш обработчик в список обработчиков

builder.Services.AddMassTransit(cfg =>
{
//Для сообщения AddMoneyRequest будет установлен адрес add-money-request
cfg.SetKebabCaseEndpointNameFormatter();
//Чтобы работала обработка запросов надо поставить расширение на RabbitMq rabbitmq_delayed_message_exchange
cfg.AddDelayedMessageScheduler();
//Тут регистрируем наши обработчики сообщений
cfg.AddConsumerMicroservices With Sagas

 

Источник: https://habr.com/ru/post/664962/





Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Архив | Связь с админом | Конфиденциальность

RSS канал новостей     Яндекс.Метрика