Промежуточное программное обеспечение ASP.NET Core Api-Gateway
Я новичок в шлюзах API и у меня есть вопрос понимания. Я тоже стараюсь поставить ряд (микро) сервисов за конечной точкой.
Для этого я установил ASP.NET Core Application и добавил пакет https://github.com/ThreeMammals/Ocelot. С помощью документации я настроил Up- и Downstreams. Все идет нормально.
Клиент отправляет запрос на http://mygateway:4242/s1/{api} и, например, получает ответ JSON или XML от Service1, как и ожидалось.
Такое же поведение для http://mygateway:4242/s2/{api} с ожидаемым результатом!
Мое понимание проблемы с Service3. Когда я отправляю запрос на http://mygateway/s3/, я получаю index.html в качестве ответа.
Сам по себе index.html требует CSS-файл 'xyz.css' с помощью тега link и заставляет клиента загрузить файл.
<head>
<link rel="stylesheet" type="text/css" href="xyz.css">
</head>
URL-адрес запроса, который клиент отправляет на "mygateway", в этом случае - http://mygateway:4242/xyz.css а не http://mygateway:4242/s3/xyz.css, поэтому ответное сообщение 404 не найдено, так как "mygateway" ничего не знает о "xyz.css"
Как я могу исправить эту проблему маршрутизации (?)?
Можно ли решить эту проблему с помощью промежуточного программного обеспечения ocelot? Или мне нужно что-то еще для службы (Service3) с SinglePageApplication (SPA)?
Может быть, просто невозможно или неправильно разместить SPA за шлюзом? Я надеюсь, что вы можете дать мне несколько советов, чтобы получить доступ к веб-сайту SPA или MVC за шлюзом.
Спасибо iBot
UPATE: приложен код index.html. Я думаю, что это прямо вперед.
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Title</title>
<base href="/" />
<link rel="stylesheet" type="text/css" href="dist/xyz.css">
</head>
<body>
<div id="appContainer"></div>
<script src="dist/xyz.js" asp-append-version="true"></script>
</body>
</html>
2 ответа
Ваш дизайн архитектуры не так!
Сначала давайте выясним, что это за API-шлюз.
Шлюз API - это программирование, которое находится перед интерфейсом прикладного программирования ( API) и действует как единая точка входа для определенной группы микросервисов.
Основным преимуществом использования шлюзов API является то, что они позволяют разработчикам инкапсулировать внутреннюю структуру приложения несколькими способами, в зависимости от варианта использования. Это связано с тем, что, помимо учета прямых запросов, шлюзы могут использоваться для вызова нескольких внутренних служб и агрегирования результатов.
Хорошо, название "API Gateway" показывает нам, что оно в основном предназначено для сервисов API! Приложения SPA или MVC не являются внутренними сервисами. Вы не должны размещать свои приложения перед шлюзом API.
В общем, ваша архитектура должна выглядеть так: 
Шлюз API является единой точкой входа для всех клиентов. SPA является клиентом ваших услуг и должен вызывать его через API Gateway. Если ваше приложение имеет несколько клиентских приложений, это может быть основной опорой при определении нескольких типов шлюзов API, так что вы можете иметь различный фасад для нужд каждого клиентского приложения. Этот случай представляет собой шаблон с именем "Backend for Frontend" (BFF), в котором каждый API-шлюз может предоставлять разные API, адаптированные для каждого типа клиентских приложений.
Что если вы не хотите строить правильную архитектуру?
- Вы можете настроить перенаправление. Это что-то вроде указания службы по умолчанию шлюза API. Тогда все клиенты, которые идут в
http://mygateway:4242/будет перенаправлен наhttp://mygateway:4242/s3/ - Ocelot позволяет Middleware Injection. Таким образом, вы можете внедрить ваше собственное промежуточное ПО, где вы будете проверять, какой запрос и куда его перенаправить.
- Используйте CDN для хранения всего CSS и другого контента.
- Встроенные CSS в HTML-файлы.
Существует библиотека.Net Core 3 с открытым исходным кодом для создания шлюза Api.
Библиотека называется AspNetCore.ApiGateway.
- Делает создание шлюза Api простым делом!!
- Поддержка авторизации
- Поддержка Swagger.
Предположим, в вашем решении есть 2 серверных микросервиса: Weather API, Stock API.
Ваш API шлюза предоставляет конечные точки, которые являются фасадом над конечными точками вашего внутреннего API.
Допустим, у вашего внутреннего API есть конечная точка GET, например:
- HTTP GET / прогноз погоды / прогноз
В вашем проекте API шлюза:
- Создайте оркестровку Api.
В Orchestrator настройте Api (например, погодную службу) и Key (например, прогноз), как показано ниже.
public static class ApiOrchestration
{
public static void Create(IApiOrchestrator orchestrator, IApplicationBuilder app)
{
orchestrator.AddApi("weatherservice", "http://localhost:58262/")
.AddRoute("forecast", GatewayVerb.GET, new RouteInfo { Path = "weatherforecast/forecast", ResponseType = typeof(IEnumerable<WeatherForecast>) })
.AddApi("stockservice", "http://localhost:58352/")
.AddRoute("stocks", GatewayVerb.GET, new RouteInfo { Path = "stock", ResponseType = typeof(IEnumerable<StockQuote>) });
}
}
- Подключитесь к Startup.cs
public void ConfigureServices(IServiceCollection services)
{
.
.
//Api gateway
services.AddApiGateway();
services.AddControllers();
services.AddSwaggerGen(c =>
{
c.SwaggerDoc("v1", new OpenApiInfo { Title = "My Api Gateway", Version = "v1" });
});
}
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
.
.
app.UseSwagger();
app.UseSwaggerUI(c =>
{
c.SwaggerEndpoint("/swagger/v1/swagger.json", "My Api Gateway");
});
//Api gateway
app.UseApiGateway(orchestrator => ApiOrchestration.Create(orchestrator, app));
.
.
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
});
}
Шлюз Swagger выглядит так, как показано ниже:
Чтобы вызвать прогнозный маршрут на метеослужбе,
вы можете ввести ключ Api и ключ маршрута в Swagger, как показано ниже:
Это затронет конечную точку прогноза / прогноза погоды на внутреннем интерфейсе Weather API.
особенности
- Вы можете использовать свой собственный HttpClient для работы с серверным Api.
- Вы можете создать свою собственную реализацию, чтобы задействовать бэкэнд Api.
Вы можете попробовать написать<base href="/s3/" /> вместо <base href="/" />,
Но лучше использовать SPA или MVC перед шлюзом. В большинстве случаев это зависит от того, как вы будете его использовать. Например, если вы хотите использовать его как прокси вашего домена (например, Nginx), это имеет смысл.