APIゲートウェイを使用したマイクロサービス
新しいプロジェクトでは、Micro Services with Api Gatewayを使用する必要があります。そこで、マイクロサービスに関する詳細情報を収集しましたが、Apiゲートウェイの部分が明確ではありません。
私の質問は、
- Api Gatewayでリクエストルーティング部分がどのように行われるかを知っている人はいますか？
- それは単純なif条件[擬似コード：if（keyword == "product "）then route（" product service "）]？
- それともそれを行うためのより良い方法ですか？
私はC＃.Netを使用してApiを開発しています。
Api Gatewayに関する情報を https://www.nginx.com/blog/building-microservices-using-an-api-gateway/ から入手しました
あなたはほとんど3つの質問をしましたが、それらはすべてある程度関連しているので、3つすべてに一緒に取り組むために最善を尽くします。
1つは、APIゲートウェイでのリクエストルーティングは単なるプロキシではなく、実装には、ダウンストリームサービスに送信する前にリクエストを検査する条件が含まれていません。 APIゲートウェイは、サービスへの唯一のエントリポイントである可能性が高く、レイヤーで認証も処理され、リクエストにダウンストリームサービスに移動する権限があることを確認します。認証は、それ自体が別のサービスである可能性があります。 APIゲートウェイの高レベルの実装は、すべてのダウンストリームサービスのすべてではないにしてもほとんどのエンドポイントを統合する可能性があります。
商品の一覧表示、商品の検索、ショッピングカートのサービスを含むeコマースアプリケーションなどの小さな例を見てみましょう。 APIゲートウェイにもこれらの同じエンドポイントがあり、リクエストを担当するサービスにリクエストをさらに委任します。この例のAPIには/productsすべての製品を一覧表示するには、/products?query=...製品を検索し、最後に/carts/:id/productsショッピングカート内の商品を一覧表示します。これがあなたの質問に答えることを願っています。
それとは別に、新しいプロジェクト用だとおっしゃっていましたが、チームが非常に小さいためにチームが本当に小さい場合、これは新しいプロジェクトに使用するのに最適なアーキテクチャではない可能性があることを2セントで伝えたいと思います運用上のオーバーヘッド。標準化、展開の自動化、統合などを必要とするオーバーヘッド。従来のMVCアーキテクチャから始めて、プロジェクトが開始されたらゆっくりとマイクロサービスに進化させるのがおそらく最善です。
アーキテクチャによっては、Weave with CoreOS（ https://github.com/weaveworks/weave ）のような非常に優れたソフトウェアを使用できます。 Dockerを使用してアプリケーションをCoreOSノードに配布し、内部DNSはWeaveによって処理されます。
これは本当に素晴らしいことです。ポートを使用してアプリケーション名にリクエストを転送するだけで、すぐに離れることができるからです。
たとえば、ユーザーがapplication.com/api/apiName/request/pathをリクエストします
ゲートウェイはNode.jsで実装されており、/ apiの後にapiNameを使用してそのAPIにルーティングし、次にURLの次のパスを使用して呼び出し自体に追加します。
したがって、ゲートウェイからのリクエストは、内部でapiName：8080/request/pathとしてプロキシされます。その点で、パスはリクエストから動的に作成されるため、新しいサービスが起動したときにAPIを変更する必要はありません。
さまざまなAPIからのパスを追跡し、それらをどこかに保存することを心配する必要がないため、これは素晴らしいことです。
そうでない場合は、エンドポイントの（おそらく外部の）リストを維持して、簡単にする必要があります。これは、API自体からプログラムで実行できます。
ただし、要件が何であるかはわかりませんが、Willが回答したように、かなり大きなインフラストラクチャコストが発生します。ただし、複数のレイヤーでコードを変更することを心配する必要がないため、リリースは高速で簡単です。新しいAPIは、ゲートウェイのプロキシ、ロギング、認証を無料で利用できます。