Микросервисная архитектура в .NET Core: шаблон или библиотека для вызова служб друг другом

Question

Я впервые использую micro-service architecture.

Некоторые из моих служб (.NET Core Web API) должны обмениваться данными друг с другом через HTTP-запросы.Для этого я делаю обертку вокруг HttpClient.

Но я подозреваю, что заново изобретаю колесо.Среди практиков микросервисов есть шаблон или даже сторонняя библиотека для решения этой проблемы?

Answer 1

В архитектуре микросервисов наиболее важным является четкое разделение проблем и границ приложений.Представьте себе простую установку с микро-услугами Product and Price

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

• клиент службы «Продукт» сделает HTTP-вызов API продукта.
• API продукта вызовет API цены, чтобы узнать цены на продукты
• API продукта зависит от API цены для создания ответа

Это синхронные части процесса, обычно достигаемые через HTTP-вызовы через границы.У вас также будут асинхронные части вашего решения, в этом примере

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

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

Answer 2

Прежде всего, если вы не используете контейнеры, запустите вместе с оркестровкой (обе изначально поддерживаются в Visual Studio, при условии, что у вас действительно установлен Docker и т. Д.).Среди множества преимуществ вы можете ссылаться на свои сервисы через имя хоста, не беспокоясь о портах и ​​разных местах для разных сред.

Что касается фактической связи.Здесь нет действительно волшебного решения.HttpClient - это то, что вы используете, конечно, и, как правило, да, вы хотите иметь обертку для этого, чтобы абстрагироваться от низкоуровневых HTTP-коммуникаций, чтобы остальная часть вашего кода могла просто вызывать простые методы для этой обертки.

Если вы не используете IHttpClientFactory, начните.Если у вас уже есть класс-оболочка, вы на полпути, и благодаря этому вы не только получаете эффективное управление HttpMessageHandler s, поэтому вы не исчерпываете пул соединений вашего сервера, но вы также можете использовать интеграцию Polly дляобрабатывать временные ошибки HTTP и даже выполнять политики повторных попыток, автоматические выключатели и т. д. для ваших микросервисных подключений.

Наконец, есть библиотека Refit , которая может сделать все немного проще.Я нахожу его более полезным с огромными сторонними API, такими как Facebook, Google и т. Д.Поскольку микросервисы должны быть простыми по своему дизайну, вы, вероятно, не будете экономить много кода, просто имея собственный класс-обертку.Независимо от того, как это работает, вы определяете интерфейс, который представляет API, а затем Refit использует его для фактического выполнения соответствующих запросов.Это что-то вроде класса-обертки бесплатно, но вам все равно нужно создать интерфейс.