クラウドネイティブ時代のゲートウェイとリバースプロキシ

  [[375497]]

導入

• ゲートウェイは主にマイクロサービス/API を提供し、R&D 担当者向けに設計されています。
• リバースプロキシは主に従来の静的Webアプリケーションを対象としており、運用と保守に重点を置いています。
• 今後のトレンドはDevOps+ゲートウェイとリバースプロキシの統合です

開発の歴史

WEB1.0/2.0 時代は、フロントエンドにリバースプロキシが使用され、運用保守は nginx が担当し、リバースプロキシと負荷分散、セキュリティ認証、電流制限、キャッシュ機能などを行っていました。ウェブサイトのアップグレードの頻度は低く、リバース プロキシでは主に静的構成が使用されます。

マイクロサービス時代では、API サービスは頻繁にアップグレードされます。従来の nginx は動的構成が不十分で、運用と保守の効率が低いという欠点があります。したがって、独立した構成の開発を容易にするために、動的に構成されたゲートウェイ サービスを使用する必要があります。

クラウド ネイティブ時代には要件が厳しくなり、グレースケール リリースのサポートも必要になります。ゲートウェイは動的に構成可能であるだけでなく、動的にプログラム可能であることも求められるため、ゲートウェイとリバース プロキシを統合する傾向があり、Envoy や Traefik などの代表的な製品があります。

クラウドネイティブ時代のプログラム可能なゲートウェイ

k8s では、ゲートウェイに相当する概念は Ingress と呼ばれます。 kong/envoy/traefik などのプログラム可能なゲートウェイはすべて Ingress への接続をサポートしています。

iOS、Android、H5、Web など、さまざまな端末を分離するかどうかは、ビジネスとチームの規模によって異なります。たとえば、Ctrip にはさまざまな端末用のゲートウェイが 10 セット以上あり、ゲートウェイ クラスターの合計サイズは 100 ユニットを超えます。複数のチームを持つ大企業の場合、ゲートウェイが十分に分割されていないと、異なるチーム間で争いが発生する可能性があります。マイクロサービスでも同様です。サービスがどの程度詳細に分割されるかは、主にチームの量と規模によって異なります。少人数のチームであれば分割しなくても大丈夫です。

セキュリティ認証の要件は部門によって異なる場合があります。たとえば、支払い部門にはより厳しい要件があるため、個別にカスタマイズして展開することができます。

つまり、nginx はより運用とメンテナンス指向であり、一方、spring gateway は中国の Java プログラマーにとってより使いやすいのです。

2つの概念を区別する

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

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

違いに関して言えば、非常に似ています。それは単なる用語です。基本的なリバース プロキシ設定があり、認証、レート制限、動的な構成更新、サービス検出などの機能を使い始めると、その API ゲートウェイを呼び出す可能性が高くなります。

リバースプロキシ + ゲートウェイの展開アーキテクチャ

アーキテクチャの進化に関する歴史的な理由により、多くの企業ではリバース プロキシとゲートウェイが共存するアーキテクチャを採用しています。

つまり、2 つのシステムを維持する必要があり、これは間違いなくより複雑になるため、これらを組み合わせるのが最適です。

参照する

https://stackoverflow.com/questions/35756663/api-gateway-vs-reverse-proxy

この記事はWeChatの公開アカウント「JavaEdge」から転載したものです。下のQRコードからフォローできます。この記事を転載する場合は、JavaEdge 公式アカウントまでご連絡ください。