it-swarm.com.de

ASP.NET Core Api-Gateway-Middleware

Ich bin neu in API-Gateways und habe eine Frage des Verständnisses ... Ich versuche, eine Reihe von (Mikro-) Diensten hinter einen Endpunkt zu stellen.

Zu diesem Zweck habe ich eine ASP.NET-Kernanwendung eingerichtet und das Paket ThreeMammals Ocelot ..__ hinzugefügt. Mit Hilfe der Dokumentation habe ich die Up- und Downstreams ..__ konfiguriert. Soweit so gut .

 sketch

Der Client fordert eine Anfrage an http: // mygateway: 4242/s1/ {api} und erhält wie erwartet beispielsweise eine JSON- oder XML-Antwort von Service1.

Gleiches Verhalten für http: // mygateway: 4242/s2/ {api} mit dem erwarteten Ergebnis!

Ich verstehe das Problem mit Service3 . Wenn ich eine Anfrage an http: // mygateway/s3/ sende, erhalte ich die index.html als Antwort.

Die index.html selbst benötigt die CSS-Datei 'xyz.css' via link-tag und zwingt den Client, die Datei zu laden.

<head>
  <link rel="stylesheet" type="text/css" href="xyz.css">
</head>

Die Anforderungs-URL, die der Client an "mygateway" sendet, lautet in diesem Fall http: // mygateway: 4242/xyz.css und nicht http: // mygateway: 4242/s3 /xyz.css und so ist der Antwortende 404 nicht gefunden, da "mygateway" nichts über "xyz.css" weiß

Wie kann ich dieses Routingproblem (?) Beheben? 

Ist es möglich, dieses Problem mit der Middleware von ocelot zu lösen? Oder brauche ich noch etwas für den Service (Service3) mit der SinglePageApplication (SPA)?

Vielleicht ist es einfach nicht möglich oder falsch, den SPA hinter dem Gateway zu platzieren? Ich hoffe, Sie können mir ein paar Tipps geben, um Zugang zu einer SPA- oder MVC-Website hinter einem Gateway zu erhalten.

Danke iBot


UPATE: Umfasst den Code von index.html. Ich denke das ist direkt.

<!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>
6
mMilk

Ihr Architekturdesign ist falsch!

Zuerst wollen wir herausfinden, was das API-Gateway ist.

Ein API Gateway programmiert vor einer Anwendungsprogrammierschnittstelle ( API ) und fungiert als zentraler Einstiegspunkt für eine definierte Gruppe von Mikrodienstleistungen. 

Ein Hauptvorteil der Verwendung von API-Gateways besteht darin, dass Entwickler die interne Struktur einer Anwendung je nach Anwendungsfall auf verschiedene Arten kapseln können. Dies liegt daran, dass Gateways nicht nur direkte Anforderungen berücksichtigen, sondern auch zum Aufrufen mehrerer Back-End-Services und zum Aggregieren der Ergebnisse verwendet werden können.

Ok, der Name "API Gateway" zeigt uns, dass es hauptsächlich für API-Dienste gedacht ist! SPA- oder MVC-Anwendungen sind keine Back-End-Services. Sie sollten Ihre Front-End-Anwendungen nicht hinter dem API-Gateway platzieren.

Im Allgemeinen sollte Ihre Architektur so aussehen:  enter image description here

Ein API-Gateway ist der zentrale Einstiegspunkt für alle Clients. SPA ist Kunde Ihrer Dienste und sollte es über API Gateway anrufen. Wenn Ihre Anwendung über mehrere Client-Apps verfügt, kann dies bei der Identifizierung der verschiedenen API-Gateways-Typen ein wichtiger Drehpunkt sein, sodass Sie für die Anforderungen der einzelnen Client-Apps eine andere Fassade haben können. In diesem Fall handelt es sich um ein Muster mit dem Namen "Backend for Frontend" (BFF) , bei dem jedes API-Gateway eine unterschiedliche API für jeden Client-App-Typ bereitstellen kann.

Was ist, wenn Sie keine richtige Architektur aufbauen möchten?

  1. Sie können die Weiterleitung konfigurieren. Es ist ähnlich, einen Standarddienst des API-Gateways anzugeben. Dann werden alle Clients, die zu http://mygateway:4242/ gehen, zu http://mygateway:4242/s3/ umgeleitet.
  2. Ocelot erlaubt Middleware Injection. Sie können also Ihre benutzerdefinierte Middleware einfügen, in der Sie prüfen, welche Anforderung und wohin sie umgeleitet werden soll.
  3. Verwenden Sie CDN zum Speichern aller CSS und anderer Inhalte.
  4. Inline-CSS in HTML-Dateien.
2
Roman Marusyk

Sie können versuchen, <base href="/s3/" /> anstelle von <base href="/" /> zu schreiben.

Es ist jedoch besser, das SPA oder MVC vor dem Gateway zu verwenden. In den meisten Fällen hängt es davon ab, wie Sie es verwenden werden. Wenn Sie es beispielsweise als Proxy Ihrer Domain (z. B. Nginx) verwenden möchten, ist dies sinnvoll. 

Siehe diesen guten Artikel darüber .