APIゲートウェイとリバースプロキシ

マイクロサービスアーキテクチャを処理するために、リバースプロキシ（nginxやapache httpdなど）と一緒に使用されることが多く、横断的な懸念のために APIゲートウェイパターンが使用されます。リバースプロキシがAPIゲートウェイの機能を実行する場合があります。
これら2つのアプローチの明確な違いを確認するとよいでしょう。APIゲートウェイの使用の潜在的な利点は、複数のマイクロサービスを呼び出して結果を集約することです。APIゲートウェイの他のすべての責任は、リバースプロキシを使用して実装できます。

• 認証（nginx LUAスクリプトを使用して行うことができます）;
• 輸送のセキュリティ。それ自体が逆プロキシタスクです。
• 負荷分散
• ....

したがって、これに基づいていくつかの質問があります：

1. APIゲートウェイとリバースプロキシを同時に使用することは理にかなっていますか（たとえば、リクエスト-> APIゲートウェイ->リバースプロキシ（nginx）->具体的なmictoservice）。どのような場合に？
2. APIゲートウェイを使用して実装でき、リバースプロキシで実装できない他の違いは何ですか？

それらが相互に排他的ではないことを理解すれば、それらについて考える方が簡単です。APIゲートウェイは、特定のタイプのリバースプロキシ実装と考えてください。

質問に関しては、APIゲートウェイが、負荷分散とヘルスチェックのためにリバースプロキシの背後にあるアプリケーション層として扱われる場合に、両方が一緒に使用されることは珍しくありません。例としては、WAFサンドイッチアーキテクチャのようなものがあります。Webアプリケーションファイアウォール/ APIゲートウェイは、リバースプロキシ層で挟まれており、1つはWAF自体用で、もう1つは、WAFが通信する個々のマイクロサービス用です。

違いについては、非常によく似ています。それは単に命名法です。基本的なリバースプロキシの設定を行い、認証、レート制限、動的構成更新、サービス検出などの要素を追加していくにつれて、人々はそのAPIゲートウェイを呼び出す可能性が高くなります。

私は、API GatewayはAPIを介して動的に構成できるリバースプロキシであり、潜在的にUIを介して構成できる一方で、従来のリバースプロキシ（Nginx、HAProxy、Apacheなど）は構成ファイルを介して構成され、構成が変更されたときに再起動する必要があると思います。したがって、ルーティングルールやその他の構成が頻繁に変更される場合は、API Gatewayを使用する必要があります。あなたの質問に：

1. このシーケンスのすべてのコンポーネントがその目的を果たす限り、理にかなっています。
2. 違いは機能リストではなく、構成変更の適用方法にあります。

また、APIゲートウェイは、多くの場合のように、SAASの形で提供されてApigeeまたはTYK例えば。

また、Node.jsを使用してシンプルなAPIゲートウェイを作成する方法に関する私のチュートリアルhttps://memz.co/api-gateway-microservices-docker-node-js/

それが役に立てば幸い。

APIゲートウェイは通常、L7構造として動作します。

APIゲートウェイは、通常のリバースプロキシと比較して追加の機能を提供します。あなたがそこにあるポータルのいくつかを検討すると、それらは提供することができます：

• ドキュメントを含む完全なAPIライフサイクル管理
• さまざまなクライアントアプリケーションの真の情報源として使用でき、クライアントガバナンス、レート制限などを提供できるポータル。
• canary / betaバージョンを含むAPIの異なるバージョンへのルーティング
• 使用パターンの検出、アプリの登録、クライアント資格情報の取得など。

ただし、Istioのようなサービスメッシュの出現により、ConsulのAPIゲートウェイの機能の多くはメッシュに組み込まれます。