Azure Service Fabricを使用してデプロイされたマイクロサービスのAPIゲートウェイ/プロキシパターン
Azure Service FabricのBUILD会議ビデオを見た後、これが現在のマイクロサービスベースのアーキテクチャにどのように適しているか想像していません。ただし、どのように解決しようとするのか完全にはわからないことが1つあります。それは、APIゲートウェイ/プロキシです。
RESTエンドポイントを公開するAzure Service Fabric内でN個のサービスを実行している、自明ではないマイクロサービスアーキテクチャを検討してください。多くの場合、これらの断片化されたAPIエンドポイントを消費者がサービスファブリックインスタンスに直接接続するのを避けるために使用する単一エントリAPI Azure Service Fabricソリューションはあらゆる点で非常に完成しているように思えるので、そうでないときに明らかなものを見逃したのではないかと思うBUILDトークで言及された機能の中でこれを簡単に解決する方法を参照してください。
Vulcanのようなサービスは、サービスにルーティングするパスを etcd に登録させることにより、この問題を解決することを目的としています。これを解決する方法の1つは、他のサービスが登録できる別のステートフルWebサービスを作成し、サービス名とそれらにルーティングする必要があるパスを提供することだと思います。ステートフルWebサービスは、その状態に基づいてトラフィックを正しいインスタンスにルーティングできます。ただし、これは完全に理想的ではないようです。アプリケーションが削除されたときにルートを削除し、一般的にクラスター内にデプロイされたサービスと状態の同期を保つなどです。誰かがこれを考えたり、Azure Service Fabric内でこれを解決する方法を考えたりしましたか？
これを行うために必要なサービスの登録/検出は、実際にはすでに存在しています。ネーミングサービスと呼ばれるステートフルシステムサービスがあります。これは基本的に、サービスインスタンスとそれらがリッスンしているエンドポイントのレジストラです。したがって、サービス（ステートレスまたはステートフル）を起動して、そのリスナーを開くと、アドレスがネームサービスに登録されます。
記入する必要があるのは、ユーザーが対話する「ゲートウェイ」です。ネームサービスがステートフル部分を管理するため、これはステートフルである必要はありません。ただし、自分に合ったアドレッシングスキームを考え出す必要があります。そうすると、リクエストが適切な場所に転送されます。基本的にこのようなもの：
- リクエストを受信します。
- NSを使用して、要求を受け取ることができるサービスを見つけます。
- 要求を要求に転送し、応答をユーザーに戻します。
- サービスがもう存在しない場合、404。
一般に、サービスが互いにどのように通信するかについては何も指示するのは好きではありませんが、完全な組み込みソリューションとしてHTTPのこの問題を解決する方法を考えています。
この目的のためにHTTPゲートウェイサービスも実装しました。内部プロトコルに対して1つのHTTPゲートウェイを使用できるように、ASP.NET 5ミドルウェアを使用して、HTTPベースの内部サービス（ASP.NET WebAPIなど）のゲートウェイを実装しました。 ServicePartitionClientおよびCommunicationClientFactoryBaseからの再試行ロジックを使用して、要求をたとえば/ serviceからfabric：/ myapp/myserviceなどの内部Service Fabricアドレスにルーティングします。
このミドルウェアをオープンソース化しました。ここで見つけることができます： https://github.com/c3-ls/ServiceFabric-HttpServiceGateway
プロジェクトのwikiにはさらにドキュメントがあります。
この機能は、サービスファブリックのリリース5.0以降、httpエンドポイント用に組み込まれています。ドキュメントは https://Azure.Microsoft.com/en-us/documentation/articles/service-fabric-reverseproxy/ で入手できます。
Traefik と呼ばれるオープンソースプロジェクトを使用して、驚くほどの成功を収めました。 Azure Service Fabri cラッパーがあります。これは、本質的には、Managed ExecutableとしてクラスターにデプロイされるGoLang exeです。
サーキットブレーカー、加重ラウンドロビンLB、パスとヘッダーバージョンのルーティングをサポートします（複数のAPIバージョンをホストするのに最適です）。また、設定と正常性の統計を表示するための便利なポータルがありました。
それの本当の力は、それをどのように設定するかにあります。 ServiceManifest.xmlのサービス自体を介して行われます。これにより、新しいサービスを展開し、すぐにルーティングできるようになります-ルーティングテーブルなどを更新する必要はありません。
例
<StatelessServiceType ServiceTypeName="WebServiceType">
<Extensions>
<Extension Name="Traefik">
<Labels xmlns="http://schemas.Microsoft.com/2015/03/fabact-no-schema">
<Label Key="traefik.frontend.rule.example">PathPrefixStrip: /a/path/to/service</Label>
<Label Key="traefik.enable">true</Label>
<Label Key="traefik.frontend.passHostHeader">true</Label>
</Labels>
</Extension>
</Extensions>
</StatelessServiceType>
強くお勧めします！
Azure Service Fabricを使用すると、このシナリオの標準アーキテクチャ（クライアントが接続するフロントエンドとしてのゲートウェイサービスと、フロントエンドゲートウェイと通信するすべてのNバックエンドサービス）を簡単に実装できます。 Service Fabricの一部として利用可能ないくつかの通信APIスタックがあり、クライアントからサービスへ、およびサービス自体内で簡単に通信できます。 Service Fabricが提供する通信APIスタックは、接続の検出、接続、再試行の詳細を隠し、実際の情報交換に集中できるようにします。 Service Fabric通信APIを使用する場合、サービス自体の作成の一部として通常の手順を除いて、サービスは名前とエンドポイントを特定のルーティングサービスに登録するメカニズムを実装する必要はありません。通信APIはサービスURIとパーティションキーを受け取り、自動的に解決して適切なサービスインスタンスに接続します。 この記事 は、Reliable ActorsまたはReliable Servicesを使用しているか、HTTPなどのプロトコルを使用しているかによって、特定のケースに最適な通信APIを決定するのに役立つ良い出発点を提供しますまたはWCF、またはサービスが記述されているプログラミング言語の選択。記事の最後に、さまざまな通信APIの詳細な記事とチュートリアルへのリンクがあります。 Web APIサービスでの通信に関するチュートリアルについては、 this を参照してください。
サービスが開始されると、そのエンドポイントがファブリックネームサービスに登録されます。 FabricクライアントAPIを使用して、登録済みのサービス名に関連付けられた登録済みエンドポイントをファブリックに要求できます。
そのため、ケースを説明したように、接続用の着信URIを受け入れるゲートウェイがあり、そのパス情報をサービス名ルックアップとして使用して、着信要求と実際の内部接続の間にプロキシ接続を作成します。エンドポイントの場所。
これを行う方法を示すサンプルを投稿したチームのように見えます： https://github.com/Azure/servicefabric-samples/tree/master/samples/Services/VS2015/WordCount
N +サービスでRestを公開する代わりに、サービスファブリック内のすべての場所でデフォルトの通信スタックを使用します（または内部的にシンプルにするためにできる限り）。 REST=ファブリックへのEdgeエントリポイントでのみ。サービスおよびアクターのファブリックプロキシをラップするstdステートレスWeb 2.x APIを使用し、および/またはファブリックを使用します。同じように残りを公開するサービス前方向きの残りのサービスで必要に応じてAPIを集約します名前付けリダイレクトのためのアグリゲーターの追加オーバーヘッドの必要性をまだ見ていません（多分私は考えを逃しています）。目的のネームスペース（ファサードパターンなど）を使用して、残りのエンドポイントを整理（およびセキュリティ保護）するだけの演習に思えます。
SFは、ゲートウェイパターンとゲートウェイの背後にある約13のサービスで使用しています。 SFが提供する組み込みDNSサービスを使用します。 https://docs.Microsoft.com/en-us/Azure/service-fabric/service-fabric-dnsservice を参照してください。内部サービスへのゲートウェイサービスを含む、既知の（SF内部の）DNS名を持つサービスツーサービスコール。使用する有名なasp.netコアゲートウェイ（Ocelot、ProxyKit）がいくつかありますが、私たちは独自にロールバックしました。 SFの複数のゲートウェイインスタンスにルーティングする外部ロードバランサーがあります。