以前の共有を通じて、マイクロサービスアーキテクチャのいくつかのコア設備について学びました。これらのコンポーネントを通じて、シンプルなマイクロサービスアーキテクチャシステムを構築できます。たとえば、Spring Cloud Eurekaを介して非常に利用可能なサービス登録センターを構築し、サービス登録と発見を実現します。
スプリングクラウドリボンまたはフェージを使用したバランスを積み込みます。障害の広がりを避けるために、スプリングクラウドヒスストリックスを使用したフォールトトレラント保護。マイクロサービスが構築された後、コール用の外部システムに統一されたRESTFUL APIサービスインターフェイスを間違いなく提供します。
しかし、外部システムがRestful APIを呼び出すとき、必要な特定の機能を提供するために必要なサービスをどのように決定しますか？これには、ルーティングルールとサービスインスタンスリストのメンテナンスが含まれます。
これにより、今日の主人公 - Spring Cloud Zuulが紹介されます。これは、Netflix Zuulの実装に基づいたAPIゲートウェイコンポーネントです。 2つの主要な問題を解決できます。
OK、このゲートウェイサービスの実装方法を見てみましょう。
1.ゲートウェイを構築し、ルーティングを構成します
ここでは、以前のHello-ServiceおよびFeign-Consumerサービスを使用する必要があります。私たちはFeign-Consumerをサービス消費者と見なしていましたが、Eurekaシステムでは、各サービスがサービスプロバイダーでありサービス消費者であることを忘れないでください。Feign-Consumerはサービスプロバイダーでもあり、http：// localhost：9001/feign-cusumerが提供するサービスです。
次に、次のようにコード構造を使用してゲートウェイサービスを構築します。
コード実装の手順：
新しいMaven Project Api-Gatewayを作成します
POMファイルを変更します
<Project XMLNS = "http://maven.apache.org/pom/4.0.0" xmlns：xsi = "http://www.w3.org/2001/xmlschema-instance" xsi：schemalocation = "http://maven.apach/4.0. http://maven.apache.org/xsd/maven-4.0.0.xsd "> <modelversion> 4.0.0 </modelversion> <groupid> com.sam </groupid> <artifactid> api-gateway </artifactid> <バージョン> 0.0.1-snapshot </version> <parent> <groupid> org.springframework.boot </groupid> <artifactid> spring-boot-boot-starter-parent </artifactid> <version> 1.5.1.release </version> </parent> <properties> <javaversion> 1.8 </javaversion> </properties> < <groupid> org.springframework.cloud </groupid> <artifactid> spring-cloud-dependencies </artifactid> <bersion> camden.sr6 </version> <type> pom </type> <scope>インポート</scope> </dependency> </dependency> </dependency> < Spring-boot-starter-actuator/spring-boot-starter-hystrix/spring-boot-starter-ribbon-> <dependency> <groupid> org.springframework.cloud </groupid> <artifactid> spring-cloud-starter-zuul </artifactid> </dentency> </despencies> </project>
新しいスタートアップクラスを作成します
/*** @ENABLEZUULPROXY ENABLE ZUULのAPIゲートウェイサービス機能**/@@enableZuulProxy@SpringCloudApplication Class GateWayApp {public static void main（String [] args）{springApplication.run（gatewaywapp.class、args）; }}新しいapplication.propertiesを作成します
server.port = 5555spring.application.name = api-gateway＃ルーティングルールの構成に追加＃zuul.routes。<route> .path and zuul.routes。<route> .url <route>はルートの名前であり、任意に指定できますが、パスとURLのセットのルート名は、次の例に示すものと同じ＃である必要があります。 http：// localhost：9001/helloによって提供されるマイクロサービスインターフェイスzuul.routes.api-a.path =/api-a/** zuul.routes.api-a.url = http：// localhost：9001zuul.routes.api-b.path =/api-b/** zuul.routes.api-b.url = http：// localhost：9090
テスト、Eureka、Hello-Service、Feign-Consumer、および新しく追加されたApi-Gatewayサービスを開始してから、http：// localhost：5555/api-a/feign-consumerにアクセスしてください
Feign-Consumerのサービスインターフェイスに正常にアクセスしました - Feign-Consonsumer。
上記の手順では、従来のルーティングの構成を実装します。この構成には大きな欠点があります。つまり、Application.Propertiesファイルのルーティングルールの手動構成が必要です。多くのサービスがある場合、メンテナンスワークロードは非常に大きくなります。メンテナンスコストを削減するために、別のルート - サービス指向ルートがあります。
2。サービス指向のルーティング
Spring Cloud ZuulとEureka Integrateでは、特定のURLをマッピングするのではなく、特定のサービスではなく、Eureka Service DiscoveryメカニズムによってサービスURLが自動的に維持されます。このタイプのルートは、サービス指向のルートです。特定のコード構成は次のとおりです。
POMファイルを変更し、Eureka依存関係を導入します
<！ - eureka依存関係の導入 - > <依存関係> <groupid> org.springframework.cloud </groupid> <artifactid> spring-cloud-starter-eureka </artifactid> </dependency>
Application.Properties構成ファイルを変更します
server.port = 5555spring.application.name = api-gatewayzuul.routes.api-a.path =/api-a/**＃ここでは、urlの代わりにserviceidを使用し、ip+ポート番号の代わりにサービス名を使用しますzuul.routes.api-a.serviceid = hello-serviceeureka.client.service-url.defaultzone = http：// localhost：1111/eureka
注：zuul.routes.api-a.url = hello-serviceも機能を実装できますが、通常の負荷分散と断層耐性保護を実行することはできません。
テスト、http：// localhost：5555/apia/helloにアクセスしてください
アクセスは成功しました。
3。サービスルーティングのデフォルトルール
サービス指向のルートでは、<route>名前は任意であるため、これは可能です。
zuul.routes.hello-service.path =/hello-service/** zuul.routes.hello-service.serviceid = hello-service
<route>名前はサービス名です。実際、実際のアプリケーションでは、このように名前を付けることがよくあります。そのようなルールがある場合、Zuulはデフォルトでそのような機能の実装を支援し、構成の問題をさらに節約できます。
実験を行い、構成ファイルを次のように変更しましょう。
server.port = 5555spring.application.name = api-gatewayeureka.client.service-url.defaultzone = http：// localhost：1111/eureka
次に、ページアクセス検証
アクセスは成功しました。
ただし、デフォルトでは、ユーレカのサービスはZuulによってデフォルトのマッピング関係を作成することによってルーティングされるため、外部世界に開かれたくないサービスにも外部からアクセスできます。現時点では、Zuul.ignored-Servicesによる自動ルーティング作成を必要としないルールを構成できます。 Zuul.ignored-Services =*の場合、すべてのサービスはルーティングルールを自動的に作成しません。現時点では、関連するルーティング構成を以前の構成を通じて実行する必要があります。
=================ゴージャスな分割線======================
以前に多くのことが言われていますが、すべての問題を中心に展開しています。ルーティングルールとサービスインスタンスのメンテナンスの問題です。では、2番目の問題を解決する方法（冗長性の問題を確認）？
4。フィルタリングを要求します
APIゲートウェイでクライアントリクエストを確認するために、フィルターを使用して要求を傍受およびフィルタリングできます。実装方法は比較的簡単です。 Zuflilterの抽象クラスを継承し、その4つの方法を実装するだけです。
Api-Gatewayを変更します：
フィルタークラスを追加しました
/*** ZuFiLterを継承し、リクエストフィルタリング用の4つのインターフェイスを実装**/public class accessFilter拡張zulfilter {logger logger = loggerfactory.getLogger（accessfilter.class）; / * *フィルターは、フィルターを実行する必要があるかどうかを判断します * *ここでtrueを返し、フィルターがすべてのリクエストに有効になることを示します。 *実際に使用すると、この関数を使用して、フィルターの有効範囲を指定できます*/ @Override public boolean sefsfilter（）{return true; } /**フィルターの特定のロジック**ここでは、Zuulにctx.setsendzuulResponse（false）を介してリクエストするように依頼し、それをルーティングしないでください*次に、ctx.setresponsestatuscode（401）*** / @Overrideパブリックオブジェクトrun（）{requestcontext.context.getext.currentcontexext（）; httpservletrequest request = context.getRequest（）; Object AccessToken = request.getParameter（ "AccessToken"）; logger.info（ "send {} request to {}"、request.getMethod（）、request.getRequesturl（）。toString（））; if（accessToken == null）{context.setsendzuulResponse（false）; Context.SetResponsESTATUSCODE（401）; } nullを返します。 } /* filterTypeフィルタータイプを返します*フィルターが実行されるライフサイクルを決定します。これはpreとして定義されます。つまり、リクエストはルーティングされる前に実行されます。 * *リクエストの実行前にフィルター実行 *ルート：リクエストとルートの処理 *投稿：リクエスト処理が完了した後に実行 *エラー：エラーが発生したときにフィルター実行 */ @Override public string filterType（）{return "pre"; } / * * filterOrderフィルターの実行の順序を返します * *要求に1つの段階に複数のフィルターがある場合、メソッドの返される値に基づいて1回実行する必要があります * * / @Override public int filterorder（）{return 0; }}スタートアップクラスを変更します
/*** @ENABLEZUULPROXY ENABLE ZUULのAPIゲートウェイサービス機能**/ @ @enableZuulProxy @SpringCloudApplication Class GateWayApp {// Beanが追加されて@Bean Public AccessFilter AccessFilter（）{return new AccessFilter（）; } public static void main（string [] args）{springApplication.run（gatewaypapp.class、args）; }}テスト
）http：// localhost：5555/hello-service/helloにアクセスしてください、アクセスは失敗しました
）http：// localhost：5555/hello-service/hello？accesstoken = token、通常はアクセスしてください
修正コード構造：
5。拡張して拡張します
実際、ルーティング機能が実際に実行されている場合、そのルーティングマッピングとリクエストの転送はすべていくつかの異なるフィルターによって行われます。
ルーティングマッピングは、主にPre-Typeフィルターを介して完了します。これは、リクエストパスを構成されたルーティングルールと一致させ、転送する必要があるターゲットアドレスを見つけます。
要求転送部品は、プレタイプフィルターによって取得されたルートアドレスを転送するルートフィルターによって完了します。
したがって、フィルターは、ZuulのAPIゲートウェイ関数の最もコアコンポーネントであると言えます。 Zuulに入る各HTTP要求は、一連のフィルター処理チェーンを介して応答され、クライアントに返されます。
要約します
上記は、Zuulを使用してSpring CloudにAPI Gatewayサービスを実装する問題です。私はそれが誰にでも役立つことを願っています。ご質問がある場合は、メッセージを残してください。編集者は、すべての人に時間内に返信します。 wulin.comのウェブサイトへのご支援ありがとうございます！