[Анализ и проектирование систем, .NET, Проектирование и рефакторинг, Микросервисы] Взаимодействия. RPC vs REST vs MQ
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
По работе мне довелось провести ряд собеседований на позицию Backend-разработчика. Особо важным для оценки архитектурных навыков мне кажется следующий вопрос:
Если вам необходимо спроектировать взаимодействие двух систем, в каких случаях вы выберете RPC, в каких REST, а в каких MQ?
Если ответ на этот вопрос у вас вызывает затруднения, загляните в мой небольшой ЛикБез на тему.
Для начала, нужно определиться концептуально, какие вообще бывают взаимодействия (в самом общем виде).
Во-первых, вызовы могут быть синхронные и асинхронные. Сам по себе вопрос об этом выборе интересен. И я думаю, что очень многие всегда будут отдавать предпочтение асинхронному async/await без конкретной причины — тоже хороший вопрос для интервью.
Во-вторых, модель взаимодействий может быть однонаправленная (one-way) и вызовы вида запрос-ответ. Если вы исповедуете CQS, соблюдаете требование идемпотентности, то скорее всего вызовы будут однонаправленными.
В-третьих, приложения, которые взаимодействуют между собой, могут иметь разную архитектуру, а именно — строение доменной логики.
оригинал
Выбор
Если предполагается асинхронное взаимодействие, а ответ не требуется - это идеальный случай использовать брокер сообщений. Положительной стороной такого решения становиться устойчивость к сбоям и повышенным нагрузкам.
Выбирая вид взаимодействия для остальных случаев, правильно будет принимать решение, исходя из организации доменной логики.
Сценарий транзакции
Организует бизнес-логику в процедуры, которые управляют каждая своим запросом.
Данная форма доменной логики — типичный сценарий хранимой процедуры, который за одну транзакцию выполняет ряд действий над данными. Иногда такую же форму может иметь микросервис декомпозированный по бизнес-возможности или глаголу. API подобных процедур нередко может представлять собой набор параметров, часть из которых может передаваться пустыми.
Исходя из определения, данного Мартином Фаулером, вызывать необходимо определённый сценарий и в определённой последовательности. RPC подход появился именно отсюда. Т.е. подойдут такие протоколы как: Sockets, WebSockets, gRPC, SOAP и другие.
Обработчик таблицы
Одна сущность обрабатывает всю бизнес-логику для всех строк таблицы БД или представления.
Для данной формы организации доменной логики характерна работа над отдельными таблицами, с помощью репозиториев, реализующих CRUD-операции. Сервис строится с использованием API-Controller — адаптера к репозиторию реализующий удалённый вызов CRUD-процедур с использование протокола HTTP. Таким образом, если ваше приложение базируется на БД с отдельными репозиториями, вам наиболее подходит REST протокол. В ряде случаев, особенно полезным становится использование протокола OData, расширяющего REST.
Модель предметной области
Объектная модель домена, объединяющая данные и поведение.
Это такая форма организации доменной логики, которая взаимодействуют с кластером доменных сущностей — агрегатом. Данное взаимодействие для соблюдения инвариантов агрегата должно происходить через методы агрегата. Содержание (устройство агрегата) делает доменную модель значительно более похожей на сценарий транзакции чем на модуль таблицы. Ниже пример агрегата из книги Эванса.
Шаблон доменная модели, как можно видеть, очень похож на сценарий транзакции, но (1) имеет очерченные границы (Bounded Context), и (2) связан с доменной сущностью (агрегатом). Структура данных при этом сокрыта за абстракцией и может быть реляционном виде, а ещё проще когда в нереляционном.
Если сервис делается по принципам предметно-ориентированного проектирования, то есть несколько сложностей. В работе со своей командой, я столкнулся с тем, что для соблюдения инвариантов сущности, получения больших возможностей масштабирования, эффективнее всего будет создавать версии агрегата. При этом, если вы корректно оперируете агрегатом через его методы, классический REST уже не подходит. В частности, для работы с версиями модели, необходимо соблюдать требование идемпотентности — одна бизнес-операция может изменить соответственно только последнюю версию агрегата. Корректно в данном случае использовать только глагол POST, с разными dto разных операций, или конкретным указанием через маршрутизацию контроллера. Согласитесь — это не REST.
Совершенно по-новому в этом отношении смотрится gRPC — замена Windows Comunication Foundation. С последним очень часто бывают существенные проблемы соразвития, особенно если интеграция происходит с командой, интеграция с которой оставляет желать лучшего (т.е. худшие варианты карты контекстов тут не подходят). В рамках же смыслового ядра считаю технологию оправданной. А сам RPC подход был бы наиболее верным.
Отдельные возможности открываются для брокеров сообщений как средство получения ответа от сервиса, ведь доменная модель идеально подходит для получения очень чистых событий предметной области, потребителями которых могут быть любые другие сервисы, а сама ШИНА ДОМЕННЫХ СОБЫТИЙ может стать превосходным средством масштабирования. Организуя архитектуру определяемую событиями, важно не забывать про возможность циклического вызова, про маркеры корреляции.
Вполне ясно что можно скрестить ужа с ежом, добавить много особых кейсов. Но в самых типовых случаях, правильно обратиться к классификации бизнес-логики Фаулера, а потом уже к технологиям и протоколам. И всё же, если считаете что есть кейс который нужно сюда внести, напишите об этом в комментарии. Думайте про архитектуру!
Что почитать
- Мартин Фаулер | Шаблоны корпоративных приложений | ISBN 978-5-8459-1611-2 | Глава 9. Представление бизнес-логики
- Хоп Грегор, Вульф Бобби | Шаблоны интеграции корпоративных приложений | ISBN 978-5-8459-1946-5
- Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем | Эрик Эванс | ISBN 978-5-6040724-9-3
- Крис Ричардсон | Микросервисы. Паттерны разработки и рефакторинга | ISBN 978-5-4461-0996-8 | Глава 5. Проектирование бизнес-логики в микросервисной архитектуре.
===========
Источник:
habr.com
===========
Похожие новости:
- [Разработка мобильных приложений, Проектирование и рефакторинг, Разработка под Android, Kotlin] Разработка на Android: как найти подходящую абстракцию для работы со строками (перевод)
- [Java, Микросервисы] Микросервисы: от CRUD до Native Image. Часть первая
- [Тестирование IT-систем, Программирование, Тестирование веб-сервисов, Карьера в IT-индустрии] Перспективы разработчика в автоматизации тестирования ПО
- [Анализ и проектирование систем, Визуализация данных, Управление разработкой] Как селф-сервис BI убивает кровавый энтерпрайз
- [.NET] .NET 5 + Source Generator = Javascript
- [Анализ и проектирование систем, Открытые данные, Управление сообществом] Что происходит с молодежной наукой в России?
- [Разработка мобильных приложений, Интервью] Очень технический выпуск: про DDD и проектирование сложных систем
- [Анализ и проектирование систем, Подготовка технической документации] Требования от системного аналитика и шаблоны документации
- [Высокая производительность, Профессиональная литература, Микросервисы, Kubernetes] Тестирование микросервисно-ориентированных приложений (перевод)
- [.NET, CRM-системы, Microsoft Azure, DevOps] CI/CD для Dynamics CRM на базе Azure DevOps
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_.net, #_proektirovanie_i_refaktoring (Проектирование и рефакторинг), #_mikroservisy (Микросервисы), #_rest, #_rpc, #_mq, #_.net, #_ddd, #_sobesedovanie_voprosy (собеседование вопросы), #_arhitektura (архитектура), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_.net, #_proektirovanie_i_refaktoring (
Проектирование и рефакторинг
), #_mikroservisy (
Микросервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:14
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
По работе мне довелось провести ряд собеседований на позицию Backend-разработчика. Особо важным для оценки архитектурных навыков мне кажется следующий вопрос: Если вам необходимо спроектировать взаимодействие двух систем, в каких случаях вы выберете RPC, в каких REST, а в каких MQ? Если ответ на этот вопрос у вас вызывает затруднения, загляните в мой небольшой ЛикБез на тему. Для начала, нужно определиться концептуально, какие вообще бывают взаимодействия (в самом общем виде). Во-первых, вызовы могут быть синхронные и асинхронные. Сам по себе вопрос об этом выборе интересен. И я думаю, что очень многие всегда будут отдавать предпочтение асинхронному async/await без конкретной причины — тоже хороший вопрос для интервью.  Во-вторых, модель взаимодействий может быть однонаправленная (one-way) и вызовы вида запрос-ответ. Если вы исповедуете CQS, соблюдаете требование идемпотентности, то скорее всего вызовы будут однонаправленными. В-третьих, приложения, которые взаимодействуют между собой, могут иметь разную архитектуру, а именно — строение доменной логики.  оригинал Выбор Если предполагается асинхронное взаимодействие, а ответ не требуется - это идеальный случай использовать брокер сообщений. Положительной стороной такого решения становиться устойчивость к сбоям и повышенным нагрузкам. Выбирая вид взаимодействия для остальных случаев, правильно будет принимать решение, исходя из организации доменной логики. Сценарий транзакции Организует бизнес-логику в процедуры, которые управляют каждая своим запросом.  Данная форма доменной логики — типичный сценарий хранимой процедуры, который за одну транзакцию выполняет ряд действий над данными. Иногда такую же форму может иметь микросервис декомпозированный по бизнес-возможности или глаголу. API подобных процедур нередко может представлять собой набор параметров, часть из которых может передаваться пустыми. Исходя из определения, данного Мартином Фаулером, вызывать необходимо определённый сценарий и в определённой последовательности. RPC подход появился именно отсюда. Т.е. подойдут такие протоколы как: Sockets, WebSockets, gRPC, SOAP и другие. Обработчик таблицы Одна сущность обрабатывает всю бизнес-логику для всех строк таблицы БД или представления.  Для данной формы организации доменной логики характерна работа над отдельными таблицами, с помощью репозиториев, реализующих CRUD-операции. Сервис строится с использованием API-Controller — адаптера к репозиторию реализующий удалённый вызов CRUD-процедур с использование протокола HTTP. Таким образом, если ваше приложение базируется на БД с отдельными репозиториями, вам наиболее подходит REST протокол. В ряде случаев, особенно полезным становится использование протокола OData, расширяющего REST. Модель предметной области Объектная модель домена, объединяющая данные и поведение.  Это такая форма организации доменной логики, которая взаимодействуют с кластером доменных сущностей — агрегатом. Данное взаимодействие для соблюдения инвариантов агрегата должно происходить через методы агрегата. Содержание (устройство агрегата) делает доменную модель значительно более похожей на сценарий транзакции чем на модуль таблицы. Ниже пример агрегата из книги Эванса.  Шаблон доменная модели, как можно видеть, очень похож на сценарий транзакции, но (1) имеет очерченные границы (Bounded Context), и (2) связан с доменной сущностью (агрегатом). Структура данных при этом сокрыта за абстракцией и может быть реляционном виде, а ещё проще когда в нереляционном. Если сервис делается по принципам предметно-ориентированного проектирования, то есть несколько сложностей. В работе со своей командой, я столкнулся с тем, что для соблюдения инвариантов сущности, получения больших возможностей масштабирования, эффективнее всего будет создавать версии агрегата. При этом, если вы корректно оперируете агрегатом через его методы, классический REST уже не подходит. В частности, для работы с версиями модели, необходимо соблюдать требование идемпотентности — одна бизнес-операция может изменить соответственно только последнюю версию агрегата. Корректно в данном случае использовать только глагол POST, с разными dto разных операций, или конкретным указанием через маршрутизацию контроллера. Согласитесь — это не REST. Совершенно по-новому в этом отношении смотрится gRPC — замена Windows Comunication Foundation. С последним очень часто бывают существенные проблемы соразвития, особенно если интеграция происходит с командой, интеграция с которой оставляет желать лучшего (т.е. худшие варианты карты контекстов тут не подходят). В рамках же смыслового ядра считаю технологию оправданной. А сам RPC подход был бы наиболее верным. Отдельные возможности открываются для брокеров сообщений как средство получения ответа от сервиса, ведь доменная модель идеально подходит для получения очень чистых событий предметной области, потребителями которых могут быть любые другие сервисы, а сама ШИНА ДОМЕННЫХ СОБЫТИЙ может стать превосходным средством масштабирования. Организуя архитектуру определяемую событиями, важно не забывать про возможность циклического вызова, про маркеры корреляции. Вполне ясно что можно скрестить ужа с ежом, добавить много особых кейсов. Но в самых типовых случаях, правильно обратиться к классификации бизнес-логики Фаулера, а потом уже к технологиям и протоколам. И всё же, если считаете что есть кейс который нужно сюда внести, напишите об этом в комментарии. Думайте про архитектуру!  Что почитать
=========== Источник: habr.com =========== Похожие новости:
Анализ и проектирование систем ), #_.net, #_proektirovanie_i_refaktoring ( Проектирование и рефакторинг ), #_mikroservisy ( Микросервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:14
Часовой пояс: UTC + 5