ali_1 Ответов: 1

Я могу получить образец проекта конструирование с использованием C#?

Всем Привет,

Я ищу образец микросервисного приложения по крайней мере с двумя сервисами.
Я смущен тем, как шлюз API управляет запросами от служб и как он передает данные в пользовательский интерфейс?

Что я уже пробовал:

Я создал три службы и веб-приложение, но не знаю, как создать шлюз API.

Richard MacCutchan

Попробуйте поискать в Google или посмотрите документацию.

Nathan Minier

Недостаточно конкретно.

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

Когда вы говорите UI, вы имеете в виду JS-управляемое браузерное приложение (SPA/PWA и т. д.) Или вы запускаете собственное приложение с доступом к микросервисам?

1 Ответов

Рейтинг:
2

Aydin Homay

Привет
Я думаю, API Gateway, я должен упомянуть, что эта тема связана с составом сервиса. Итак, сначала вам нужно ответить на этот вопрос: какова ваша стратегия композиции услуг? Вы собираетесь полагаться на оркестровку или хореографию?

Хореография служб не приведет вас к созданию шлюза API, потому что наличие шлюза API означает создание централизованного сотрудничества служб. Проще говоря, оркестровка службы.
Некоторые ссылки рекомендуют использовать API Gateway, когда количество микросервисов не превышает нескольких. И я с этим абсолютно согласен.
Подробнее читайте здесь Микросервисы в .NET Core: с примерами в Nancy - Christian Horsdal, Christian Horsdal Gammelgaard - Google Books[^]

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

Таким образом, мораль этой истории заключается в том, что API Gateway перенаправит ваши запросы в отзывчивый сервис. Это означает, что запрашивающий службу попросит шлюз API перенаправить запрос на отзывчивую службу (может существовать несколько зеркал службы с одинаковыми обязанностями в архитектуре микросервиса из-за балансировки нагрузки службы) с соблюдением целевого интерфейса службы, а затем получит ответ и снова доставит его запрашивающему службу с уважаемым интерфейсом службы.

Что означает это на практике?
1 - Создайте свое решение на основе микросервисов, используя ваши предпочтительные технологии и фреймворки (например, Nancy и OWIN)
2 - Определите маршруты для предоставления функциональных возможностей HTTP (CURD) остальной части системы на ваших сервисах
3 - Создайте другую службу и назовите ее API Gateway. Обратите внимание, что эта служба будет предоставлять разные прокси-серверы для доступа к разным службам (это более или менее одна и та же концепция агрегации служб).
4 - передайте все запросы на шлюз API, потому что только эта служба знает конечные точки, которые могут быть вызваны службой, и передайте запрос шлюзу и дождитесь ответа.

Я надеюсь, что этот ответ даст хотя бы хорошее начало для решения вашей проблемы.

По крайней мере, но не в последнюю очередь, вы можете прочитать приведенную ниже статью:
Погружение в архитектуру микросервисов - Часть I[^]

Овации,
-- АХ