なぜゲートウェイが必要なのですか？
サービス自体を入力したいことはわかっていますが、特に良い方法がないことは明らかです。 IPアドレス +ポート番号を直接入力します。このアプローチは非常に悪いことを知っています。このアプローチには大きな問題があります。まず、物理マシンのIPアドレスを公開します。他の人があなたのIPアドレスを見ると、彼らはサービスがどこに展開されているかを知っており、他の人が非常に便利に攻撃操作を行うことができます。
第二に、私たちは非常に多くのサービスを持っています、私たちはそれらを1つずつ呼び出す必要がありますか？許可認証を行ったと仮定し、各顧客はさまざまなマシンで実行されているさまざまなJVMでサービスプログラムにアクセスします。各サービスにはサービス認証が必要です。これは迷惑ですか？それは明らかに非常に迷惑です。
それから、私たちはこの時点でこれら2つとそれらの一般的な問題に直面しており、それらを解決する方法が必要です。まず第一に、IPアドレスの露出と、死亡後に書くIPアドレスによって引き起こされる単一点の問題を見てみましょう。また、このようなサービス自体のサービスのリストを動的に維持する必要がありますか？私はこのサービス自体を呼び出す必要があります、私も負荷分散するものが必要ですか？
IPアドレスの露出についてもあります。 Nginxの逆プロキシのようなプロキシである必要がありますか？また、すべてのポータルの許可確認など、このことに関するパブリックモジュールを展開するものもあります。そのため、Zuul APIゲートウェイが必要になりました。上記の問題を解決します。特定のサービスを呼び出したい場合は、マップしてサービスのIPアドレスをマップします。
パスに入ると、それが一致し、サービスにアクセスします。リクエスト転送プロセスがあります。 Service Machineインスタンスの特定の強度であるNginxと同様に、IPに直接アクセスすることはなく、Eureka登録センターに移動してService Instance ID、つまりサービス名を取得します。クライアントのロードバランシングリボンを使用して、サービスインスタンスの1つに再びアクセスしました。
APIゲートウェイは、主にサービス自体による外部呼び出しの問題を解決し、許可確認の問題を解決するために使用されます。 Shiro、Springsecurityなどの統合など、一連のフィルターをここに統合して呼び出すことができます。
Zuulは、動的フィルタリングメカニズムをロードして、次の機能を実現できます。
1.検証とセキュリティ：さまざまなリソースの検証要件を特定し、要件と一致しないリクエストを拒否します。
2。レビューと監視：意味のあるデータと統計結果をエッジの場所で追跡し、生産状況に関する正確な結論をもたらします。
3.動的ルーティング：必要に応じて、異なるバックエンドクラスターへのルートリクエストは動的に動的にリクエストします。
4。ストレステスト：クラスターへの負荷の流れを徐々に増やして、パフォーマンスレベルを計算します。
5。負荷割り当て：各負荷タイプに対応する容量を割り当て、制限値を超える要求を非難します。
6.静的応答処理：エッジの位置で部分的な応答を直接作成して、内部クラスターに流れないようにします。
7.マルチリージョンの弾力性：AWS地域全体のルーティングを要求すると、多様な肘の使用を実現し、ユーザーにエッジの場所ができるだけ近いことを確認するように設計されています。
次に、小さなデモに移動します
最初のステップは、元のプロジェクトの下で新しいZuulモジュールを構築し、依存関係を導入することです。コードは次のとおりです。
<Dependency> groupId> org.springframework.cloud </groupid> <artifactid> spring-cloud-starter-eureka </artifactid> <バージョン> 1.3.5. release </version> </dependency> <depency> <groupid> org.springframework.cloud < <バージョン> 1.3.5.Release </version> </Dependency>
次に、スタートアップクラスに@EnableZuulProxyアノテーションを入力します。コードは次のとおりです。
サーバー：ポート：5000spring：アプリケーション：名前：api-getewayzuul：ルート：#sidentive redify your serviceは、ここで自分で定義できます。一般的に言えば、便利さと仕様は、サービスの名前と同じです。hello-service：＃このパスを通じて、サービスマッピングのパスは、外部からサービスにアクセスできます。目的は、マシンのIPとサービス指向のルートの公開を避け、利用可能なルートを選択することです。 #Here、Zuulは自動的にHystrixとリボンに依存しますが、スタンドアロンパスではありません： /Hello-Service /**＃これはEureka登録センターのサービスの名前でなければなりません。したがって、ServiceIDはEurekaと組み合わされるため、ここで構成されています。 Zuulを単独で使用する場合は、マシンのIPを作成する必要があります。 #such as url：http：// localhost：8080/これは、ip deadを書くのに十分ではありません。このIPが失敗し、これが高可用性である場合、サービス登録セットは使用されません。 ServiceID：hello-serviceeureka：#client：#register Centerアドレスサービス-url：defaultzone：http：// localhost：8888/eureka/、http：// localhost：8889/eureka/
次に、前の記事でレジストリセンターと2つのハローサービスサービスプロバイダーを開始します。次に、それを実行し、その要求転送機能を見て、2つのサービスに投票するかどうかを確認します。
localhost：5000/hello-service/hello、次のように入力してください。
その後、もう一度更新：
Zuulがそれを配布することを要求していることがわかります。サービス名Hello-Servieに基づいて特定のマシンにマッピングされます。これは逆プロキシの機能ではありませんか？
Zuulはリクエストフィルタリングを実行することもできるため、トークン検証を実行して実証しましょう。まず、Zuflilterクラスを継承して4つのインターフェイスを実装するために、新しいtokenfilterクラスを作成する必要があります。コードは次のとおりです。
パッケージhjc.zuul; import com.netflix.zuul.zuflilter; Import com.netflix.zuul.context.requestContext; Import javax.servlet.http.httpservletrequest;/*** 2018/5/18でコングによって作成されました。 */public class tokenfilterはzuflilterを拡張します{// 4つのタイプ：pre、ルーティング、エラー、post // pre：主にルーティングマッピング段階で使用され、ルーティングマッピングテーブル//ルーティング：特定のルーティング転送フィルターはルーティングルーターにあります。特定の要求を転送すると、//エラーが呼び出されます：前のフィルターエラーが発生したら、エラーフィルターが呼び出されます。 //投稿：このフィルターはルーティング後に呼び出され、エラーが完了します。 @Override public String filterType（）{return "pre"; } //フィルターの実行順序をカスタマイズします。値が大きいほど、実行が遅くなります。値が小さいほど、最初に実行されます。 @Override public int filterOrder（）{return 0; } //フィルターを制御して有効かどうか。 @Override public boolean sextfilter（）{return true; } // filter logic @override public object run（）{requestcontext context = requestcontext.getCurrentContext（）; httpservletrequest request = context.getRequest（）; string token = request.getParameter（ "token"）; if（token == null）{context.setsendzuulResponse（false）; Context.SetResponsESTATUSCODE（401）; context.setResponseBody（ "Unauthrized"）; nullを返します。 } nullを返します。 }}FilterType：フィルターのタイプを表す文字列を返します。次のように、Zuulでは、ライフサイクルが異なる4つのフィルタータイプが定義されています。
pre ：リクエストがルーティングされる前に呼び出すことができます。ルーティングマッピング段階でルーティングマッピングテーブルを見つけるために使用されます。
2.route ：ルーティングリクエスト中に呼び出されます。ルーターの特定の要求転送をルーティングするときに、特定のルーティング転送フィルターが呼び出されます。
3。 error ：リクエストの処理中にエラーが発生したときに呼び出されます
4。 post ：ルーティング後にフィルターが呼び出されず、エラーが完了します。これは最後の段階にあります。
ここでは、Zuulフィルターがネットワーク要求を実行したときに発生する例外を宣言します。 Try-Catchによってキャッチされた例外は、フィルター内のページに直接スローすることはできません。キャッチ内のContext.set（）メソッドを使用して、アプリケーションによってスローされる例外をページに返すことができます。次のように：
try {business logic ...} catch（例外e）{requestContext context = requestContext.getCurrentContext（）; context.set（ "error.status_code"、401）; context.set（ "error.exception"、e）; context.set（ "error.message"、 "sfdfsdf"）;}次に、このフィルターをスプリングに追加し、春に管理させる必要があります。コードは次のとおりです。
パッケージhjc; Import hjc.zuul.tokenfilter; import org.springframework.boot.springApplication; Import org.springframework.boot.autoconfigure.springbootapplication; Import org.springframework.cloud.netflix.zuul.zuul.zuul.zuulproxy org.springframework.context.annotation.bean;@springbootapplication@enablezuulproxypublic class zuulapplication {public static void main（string [] args）{springapplication.run（zuulapplication.class、args）; } //フィルターをspring管理@bean public tokenfilter tokenfilter（）{return new tokenfilter（）; }}次に、次のように、トークンなしでスタートアップクラスと最初のアクセスを開始しましょう。
許可なしにメッセージが返されることがわかります。ここで、トークンは通常、リクエストヘッダーに配置されていると言いたいです。ここでは、デモンストレーションの目的でそれを行っていません。
次に、トークンを取り、次のようにアクセスしてください。
私たちの要求が送信されたことがわかります。
ここでは、デフォルトのルートとは何かについて説明し、次のようにZuul構成を削除します。
サーバー：ポート：5000Spring：アプリケーション：名前：API-Getewayeureka：#Client Client：#register Centerアドレスサービス-URL：http：// localhost：8888/eureka/、http：// localhost：8889/eureka/
次に、次のようにアクセスを再起動して継続します。
、
あなたは私たちがまだアクセスし続けることができることを見ることができます。私たちには何もすることはありませんが、それでもアクセスできます。それは、デフォルトでは、サービス名のHello-Serviceで自動的に宣言されるためです。
したがって、自分のために自動的に宣言したくない場合、自分で定義したい場合は、YML構成ファイルでZuu.ignored-Servicesを使用して、次のようにフィルタリングのようにフィルタリングすることができます。
Zuul：#if if readored-services：*すべてのデフォルトルートが期限切れになっていることを意味します。それらを1つずつ一致させる必要があります。奇妙なビジネスに遭遇しない限り、誰もそんなに犯されることはありません。
たとえば、マッピングルールについて説明しましょう
Zuul：ルート：＃サービスの名前を識別してください。ここで自分で定義できます。一般的に言えば、便利さと仕様は、サービスの名前と同じハローサービスです。目的は、マシンのIPの公開を避けることであり、サービス指向のルートはあなたのためです。 #Here Zuulは自動的にHystrixとリボンに依存しますが、スタンドアロンのパスではありません。 Zuulを単独で使用する場合は、#such、url：http：// localhost：8080/これは悪いことです。それはip deadを書くことを意味します。このIPが失敗し、高可用性が発生した場合、サービス登録セットは使用されませんserversid：hello-servicezuul：routes：hello-service：/hello-service/ext/** serviceid：hello-service
ここの2つのZuul構成マッピングパスには /hello-service /があります。 /hello-service/** include/hello-service/ext/**を確認できます。これらの2つのパスを一致させるとき、競合はありますか？それに対処する方法は？誰が最初に一致しますか？
YMLで一致するように定義されている順序は次のとおりです。 Application.Properties形式の構成ファイルの場合、この注文は保証できません。 YML形式の構成ファイルは順番にあり、保証できます。ここでこれに注意してください。
一致するルールを定義したい場合はどうなりますか？次に、次のようにルートを決定するスタートアップクラスで豆を定義する必要があります。
ここではデモを行いません。必要なときは、情報をゆっくりと検索してください。
Ingrore-Patternsもあります：次のように：
Zuul：ルート：＃サービスの名前を識別してください。ここで自分で定義できます。一般的に言えば、便利さと仕様は、サービスの名前と同じハローサービスです。目的は、マシンのIPの公開を避けることであり、サービス指向のルートはあなたのためです。 #Here Zuulは自動的にHystrixとリボンに依存しますが、スタンドアロンのパスではありません。 Zuulを単独で使用する場合は、#such、url：http：// localhost：8080/これは悪いことです。それは死んだIPを書くことを意味します。このIPが失敗し、高可用性が発生した場合、サービス登録セットは使用されませんserviceid：hello-service naidored-patterns： /hello /**
Ingrore-Patterns： /hello /**のパスがブロックされていることを示します。あなたが/hello-service/hello/**が不可能であっても、あなたはそれをブロックします。この構成をさらに絞り込むことができます。たとえば、 /helloインターフェイスをルーティングしたくない場合は、上記のように構成できます。
サービスのプレフィックスを構成したい場合はどうなりますか？コードは次のとおりです。
Zuul：ルート：＃サービスの名前を識別してください。ここで自分で定義できます。一般的に言えば、便利さと仕様は、サービスの名前と同じハローサービスです。目的は、マシンのIPの公開を避けることであり、サービス指向のルートはあなたのためです。 #Here Zuulは自動的にHystrixとリボンに依存しますが、スタンドアロンのパスではありません。 Zuulを単独で使用する場合は、#such、url：http：// localhost：8080/これは、死んだIPを書くには十分ではありません。このIPが失敗し、高可用性が発生した場合、サービス登録セットは使用されませんserverid：hello-service prefix： /api /**
訪問するサービスは、/api/hello-service/**などの/api/をプレフィックスする必要があることがわかります。
パスアクセスを行いたい場合、地元にジャンプしたい場合はどうすればよいですか？
ユーザーが /ローカルにアクセスするときに自動的にこの方法にジャンプできることを願っています。したがって、現時点では、Zuulのローカルジャンプを使用する必要があり、構成方法は次のとおりです。
Zuul：プレフィックス：/api無視-patterns：/**/hello/**ルート：ローカル：path：/hello-service/** url：forward：/local
スプリングセキュリティまたは一部のサードパーティコンポーネントに接続する一般的に使用されるものの一部は、クッキー情報の一部を取得します。そのため、Zuul Gatewayはセキュリティ上の理由ですべてのCookie情報を殺しており、Cookieを作る方法はありません。デフォルトで殺されます。
ここで、ZuulはZuul.Sensitive-Headersを提供して、これらのCookieとヘッダーを作成し、これらの情報をフィルタリングしません。機密情報を制御します。
デフォルトでは、敏感なヘッダー情報をAPIゲートウェイに渡すことはできません。次の構成を通過できるようにすることができます。
Zuul：ルート：Hello-Service：Path： /Hello-Service /** ServiceID：Hello-Service Sensitive-Headers：Cookie、Headerなど
前述のように、Hystrixの詳細な構成でも使用できます。ここでは話しません
上記はこの記事のすべての内容です。みんなの学習に役立つことを願っています。誰もがwulin.comをもっとサポートすることを願っています。