次の図で表される問題を整理するために、アーキテクチャを実装する必要があります。
基本的にはパブリック API をクラウド (Azure) にデプロイする必要がありますが、データはオンプレミスのマシンにあります。オンプレミス マシンは、データを提供する Swagger API を公開します。各オンプレミス マシンには、要求をルーティングできる一意の識別子 (インストール識別子) があります。
次のリンクで提案されているアプローチに従って、Azure Service Bus の Relay モジュールに基づくソリューションを開発しました。
Azure Service Bus の Relay モジュールに基づくソリューションは、私の問題を整理し、ほとんどのニーズに適合しますが、1 つの問題があります。それは、待ち時間がひどいことです。
パブリック API とサービス バス エンドポイントを同じ地理的リージョンにデプロイしました。単純なリクエスト GET /companies には平均で 1.5 秒かかります。オンプレミス API での処理時間は非常に短く、わずか数ミリ秒です。
レイテンシを低く抑えるために、Web ソケットを使用することを考えていましたが、パブリック API へのリクエストごとに Web ソケット チャネルを開く必要があるため、シナリオを念頭に置いた最善のアプローチかどうかはわかりません。 ApiController 内のオンプレミス API に接続し、そのライフサイクルを処理します (応答を返す前に閉じます)。
明らかに、このシナリオでは、オンプレミス API の各 ApiController は、Web ソケットと http を同時にサポートする必要があります。
別の解決策として、元のリクエストをパブリック API からオンプレミス API に中継する HTTP プロキシを実装することもできますが、私の観点からは、中間に接続マネージャーを使用せずに P2P 通信を使用して、可能な限り最高のレイテンシーを実現できます。 、そのため、私の焦点は現在 Web ソケットにあります。
できるだけ標準に準拠したいので、「純粋な」Web ソケットを使用したいので、Signalr を使用しないことを意味します。
問題、解決策、および代替案を明らかにしたら、私の質問は次のとおりです。
ApiController クラスのアクション メソッド内で Web ソケットを開き、元の http 要求をパブリック API からオンプレミス API に中継するにはどうすればよいですか?
オンプレミス API で HTTP と WebSocket の両方のプロトコルをサポートするにはどうすればよいですか? オンプレミス API は、HTTP 要求だけでなく WebSocket 要求も処理できる必要があります。
私の最初の賭けは System.Net.WebSockets を使用することですが、ASP.NET Web API と統合されたときに役立つ websockets ライブラリが存在するかどうかを知りたいです。