web-dev-qa-db-ja.com

ASP.NET Core Api-Gatewayミドルウェア

APIゲートウェイは初めてですが、理解について質問があります。エンドポイントの背後に一連の（マイクロ）サービスを配置しようとしています。

この目的のために、ASP.NETコアアプリケーションをセットアップし、パッケージ ThreeMammals Ocelot を追加しました。ドキュメントを利用して、アップストリームとダウンストリームを構成しました。ここまでは順調ですね。

sketch

クライアントは http：// mygateway：4242/s1 / {api}にリクエストを送信し、たとえば、予想どおりService1からJSONまたはXML応答を取得します。

http：// mygateway：4242/s2 / {api}でも同じ動作で、期待される結果も得られます！

私の理解の問題はService3にあります。 http：// mygateway/s3 / にリクエストを送信すると、index.htmlが応答として返されます。

Index.html自体は、リンクタグを介したCSSファイル「xyz.css」を必要とし、クライアントにファイルをロードさせます。

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

この場合、クライアントが「mygateway」に送信するリクエストURLは http：// mygateway：4242/xyz.css であり、 http：// mygateway：4242 / -ではありませんs/xyz.cssなので、 "mygateway"は "xyz.css"について何も認識していないため、応答は404 not foundです。

このルーティングの問題を解決するにはどうすればよいですか？

この問題をocelotミドルウェアで解決することは可能ですか？または、SinglePageApplication（SPA）を使用してサービス（Service3）に別のものが必要ですか？

おそらく、SPAをゲートウェイの背後に配置することは、単に不可能または間違っているのでしょうか。ゲートウェイの背後にあるSPAまたはMVC Webサイトにアクセスするためのヒントを教えていただければ幸いです。

ありがとうiBot

PATE： 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>
c#asp.netasp.net-coreapi-gatewayocelot
12
mMilk

アーキテクチャ設計が間違っています！

まず、これがAPI Gatewayであるものを見つけましょう。

API Gateway は、アプリケーションプログラミングインターフェイス（ [〜＃〜] api [〜＃〜] ）の前にあり、単一のエントリポイントとして機能するプログラミングです。定義されたマイクロサービスのグループ。

APIゲートウェイを使用する主な利点は、開発者がユースケースに応じて、アプリケーションの内部構造を複数の方法でカプセル化できることです。これは、直接要求に対応するだけでなく、ゲートウェイを使用して複数のバックエンドサービスを呼び出し、結果を集約できるためです。

「[〜＃〜] api [〜＃〜]ゲートウェイ」という名前は、主にAPIサービスを対象としていることを示しています。 SPAまたはMVCアプリケーションはバックエンドサービスではありません。フロントエンドアプリケーションをAPIゲートウェイの背後に配置しないでください。

一般に、アーキテクチャは次のようになります。 enter image description here

APIゲートウェイは、すべてのクライアントの単一のエントリポイントです。 SPAはサービスのクライアントであり、API Gatewayを介して呼び出す必要があります。アプリケーションに複数のクライアントアプリがある場合、それは複数のAPIゲートウェイタイプを識別するときに主要なピボットになる可能性があるため、各クライアントアプリのニーズに応じて異なるファサードを持つことができます。このケースは “ Backend for Frontend”（BFF） という名前のパターンであり、各API Gatewayは各クライアントアプリタイプに合わせて調整された異なるAPIを提供できます。

適切なアーキテクチャを構築したくない場合はどうなりますか？

  1. リダイレクトを設定できます。 APIゲートウェイのデフォルトサービスを指定するようなものです。次に、http://mygateway:4242/にアクセスするすべてのクライアントがhttp://mygateway:4242/s3/にリダイレクトされます
  2. Ocelotはミドルウェアインジェクションを可能にします。したがって、カスタムミドルウェアを挿入して、どのリクエストを確認し、どこにリダイレクトするかを確認できます。
  3. CDNを使用して、すべてのCSSおよびその他のコンテンツを保存します。
  4. CSSをHTMLファイルにインライン化します。
2
Roman Marusyk

あなたは書くことを試みることができます<base href="/s3/" /> の代わりに <base href="/" />。

ただし、ゲートウェイの前にSPAまたはMVCを使用することをお勧めします。ほとんどの場合、それはどのように使用するかによって異なります。たとえば、ドメインのプロキシ（Nginxなど）のように使用したい場合は、理にかなっています。

この優れた記事を参照してください 。

0
Ярослав Виталиевич