I.概要
API Gatewayは、オブジェクト指向の設計パターンFacadeパターンの定義と同様であるよりインテリジェントなアプリケーションサーバであり、その存在は、システムの全体ファサードマイクロサービスアーキテクチャと同じであり、すべての外部のクライアントアクセスは、それを通過する必要がありますスケジュールし、ろ過を行います。要求ルーティング、負荷分散、フィルタリング、キャリブレーションよりも、それを達成することに加えて、あなたは、このようなガバナンスのフレームワーク、リクエスト、重合および高度な機能とサービスの一連の転送のヒューズメカニズムなどのサービスと組み合わせてより多くの容量が必要です。
春クラウド内のゲートウェイ構成要素にZuul春クラウドZuulを実現ixにAPIベースネットFLを提供します。
第二に、準備フェーズ
SpringBootのバージョン番号：2.1.6.RELEASE
SpringCloudバージョン：Greenwich.RELEASE
pom.xml
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-zuul</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
</dependencies>application.yml
server:
port: 5555
spring:
application:
name: cloud-zuul
eureka:
client:
service-url:
defaultZone: http://user:password@localhost:1111/eureka/ZuulApplication.java
// 开启 Zuul 的Api 网关服务功能
@EnableZuulProxy
@EnableDiscoveryClient
@SpringBootApplication
public class ZuulApplication {
public static void main(String[] args) {
SpringApplication.run(ZuulApplication.class, args);
}
}第三に、要求が転送され、
春の雲春の雲ユーレカとの統合によりZuul、ユーレカガバナンスにおけるサービスアプリケーションとして自身を登録し、中ユーレカからマイクロサービスの他のすべての例のための情報へのアクセス。そのような情報の例は非常に巧妙に保守作業を自動的にインスタンスガバナンスのフレームワークを提供するために引き渡されるように、手動の介入が必要とされない、それらの使用を維持するために、サービス管理システムを設計しています。ルーティングルールの整備については、デフォルトでZuulは名前として機能するようになります
のcontextPathの道のルートマップを作成します。例えば、上記の構成、春クラウドZuulが自動的に各サービスユーレカのデフォルトのルーティングルールを作成し、パスが要求プレフィックスとして設定をServiceIDデフォルトルールのサービス名を使用します- /「をServiceID」/ **リクエストについてそれは、サービス処理をServiceIDに転送されます。
各サービスは、自動的にルーティングルールを作成しないように設定することができますか？
zuul:
# Zuul 将对所有的服务都不自动创建路由规则
ignored-services: "*"我々は、手動でルーティングを設定した場合、それは何ですか？次のように推奨：
zuul:
routes:
client-2:
path: /client-2/**
serviceId: cloud-eureka-client
# zuul.routes.<serviceid> = <path>
cloud-eureka-client: /client-3/**
client-4:
path: /client-4/**
# 请求转发 —— 仅限转发到本地接口
url: forward:/localその中でも、？：シングルマッチ、任意の数の文字が; *：より多くの任意の数の文字に一致します。**：任意の数の文字、複数のマルチレベルのディレクトリにマッチします。
URLはHystrixはとてもそのような要求を梱包しないと、糸の単離および回路ブレーカの保護コマンドを使用せずに、HttpClientを直接によって、要求パケットをルートを設定する方法が推奨されていません。
私たちは、URLの一部をフィルタリングしたい場合は、それはルールで歩いていないのですか？
zuul:
# 对某些 url 设置不经过路由选择
ignored-patterns: {"/**/world/**","/**/zuul/**"}春の雲「/ zuul」のZuulパス訪問のDispatcherServletをバイパスしますが、主に大容量ファイルのアップロードを処理する場合に対処するために使用され、ZuulServlet処理です。
zuul:
servlet-path: /zuul第四に、要求フィルター
春クラウドZuulは、開発者がZuulを使用して、さまざまな検証フィルタを作成し、チェックするだけで、特定経由でルーティングされるように、要求の検証ロジックを実行する必要のあるルールを指定することができ、フィルタ機構を提供しますマイクロサービスインタフェース、それ以外の場合はエラーメッセージを返します。
フィルタ機構Zuulを達成するためにも非常に簡単です、あなただけはZuulFilterクラスを継承する必要がありますすることができます。次に、我々は、トークンパラメータインターフェイスパラメータが存在するかどうかを確認、フィルタTokenFilterを記述する必要があります。
@Component
public class TokenFilter extends ZuulFilter {
private Logger logger = LoggerFactory.getLogger(TokenFilter.class);
/**
* 过滤器的类型，它决定过滤器在请求的哪个生命周期中执行。这里定义为 pre, 代表会在请求被路由之前执行。路由类型有下面几种：
* <p>
* - pre: 可以在请求被路由之前调用。
* - routing: 在路由请求时被调用。
* - post: 在 routing 和 error 过滤器之后被调用。
* - error: 处理请求时发生错误时被调用。
*
* @return
*/
@Override
public String filterType() {
return FilterConstants.PRE_TYPE;
}
/**
* 过滤器的执行顺序。当请求在一个阶段中存在多个过滤器时，需要根据该方法返回的值来依次执行，数值越小，优先级越高。
*
* @return
*/
@Override
public int filterOrder() {
return 0;
}
/**
* 判断该过滤器是否需要被执行。这里我们直接返回了true, 因此该过滤器对所有请求都会生效。实际运用中我们可以利用该函数来指定过滤器的有效范围。
*
* @return
*/
@Override
public boolean shouldFilter() {
return true;
}
/**
* 过滤器的具体执行逻辑
*
* @return
* @throws ZuulException
*/
@Override
public Object run() throws ZuulException {
RequestContext ctx = RequestContext.getCurrentContext();
HttpServletRequest request = ctx.getRequest();
logger.info("send {} request to {}", request.getMethod(), request.getRequestURL().toString());
String token = request.getParameter("token");
if (StringUtils.isEmpty(token)) {
logger.warn("token is empty");
// 令 zuul 过滤该请求，不对其进行路由
ctx.setSendZuulResponse(false);
// 设置返回的错误码
ctx.setResponseStatusCode(401);
// 设置返回的 body
ctx.setResponseBody("");
return null;
}
logger.info("access token is ok");
return null;
}
}確かに、実際の運転では、上述したZuulルーティング機能は、それが要求を転送し、ルーティングマップは、いくつかの異なるフィルタが完成しています。したがって、フィルタは、APIゲートウェイ機能Zuul最もコア部材を実装するということができ、各HTTPリクエストは、リクエスト応答処理チェーンを与える一連のフィルターを通してZuulを入力し、クライアントに返されます。フィルタ伝達HTTPリクエストの方法の異なる種類の間でAPIゲートウェイに到達した後に詳細にプロセスを説明要求のライフサイクルに示した下部公式ウィキZuulから図。
外部HTTP APIゲートウェイサービス要求が到着すると、それは最初にそれはフィルタの前のタイプによって処理される第一段階の前に、入力しますが、このタイプのフィルタの主な目的は、いくつかを行う前に、ルーティング要求の前に行われますこのような電流制限、確認を要求するよう、処理を設定します。転送が経路要求位相が前記前の前型のフィルタ処理が終了した後、第二段階に入るための要求をルーティングする、つまり、要求は、ルーティング型フィルタ処理されます。具体的な処理はここで、外部サービス・インスタンスの特定のプロセスの最大要求を転送、要求結果を返すサービスインスタンスは、ルーティングフェーズは、第三段階のポストを入力する要求を完了する。要求は、フィルタのポストタイプを処理されます。この時点では、これらのフィルタは、処理の際に情報を要求するために得ることができるだけでなく、サービスのインスタンスを取得するために、ポスト内のフィルタ情報、種類を返し、我々は対処することができます他のいくつかの処理または変換内容についての結果。また、特殊な位相誤差があり、それが最終的な結果が返されますポストを通じてフィルタリングする必要があるため、唯一の例外は、これら三つの段階で発生する位相がトリガされますが、それは最終的に流れたり、フィルタの種類を投稿します要求元のクライアントに。
Zuulデフォルトのフィルターの実装：
| タイプ | オーダー | フィルタ | 機能 |
|---|---|---|---|
| 前 | -3 | ServletDetectionFilter | マーキングプロセスのサーブレットタイプ |
| 前 | -2 | Servlet30WrapperFilter | HttpServletRequestのリクエストをパッキング |
| 前 | -1 | FormBodyWrapperFilter | パッキングリクエストボディ |
| ルート | 1 | DebugFilter | マーク・デバッグ・フラグ |
| ルート | 5 | PreDecorationFilter | その後の使用のための処理要求コンテキスト |
| ルート | 10 | RibbonRoutingFilter | サービスID |
| ルート | 100 | SimpleHostRoutingFilter | URL要求の転送 |
| ルート | 500 | SendForwardFilter | 転送するように要求を転送 |
| 役職 | 0 | エラーフィルタを送信 | エラー処理要求応答 |
| 役職 | 1000年 | SendResponseFilter | 通常の処理要求応答 |
私たちは、設定ファイルに、フィルタを無効にするかを選択することができます。
zuul:
# 禁用某个过滤器 zuul.<SimpleClassName>.<filterTye>.disable=true
TokenFilter:
pre:
disable: trueいくつかは、多くの場合、このようなaccessToken、看板、クッキーなどとして、我々はサービスに浸透したくないヘッダ情報を要求します。それとも我々はそれを構成する方法を、一貫性のあるホスト情報要求になりたいですか？
zuul:
routes:
client-2:
path: /client-2/**
serviceId: cloud-eureka-client
# 敏感头信息设置为空，表示不过滤敏感头信息，允许敏感头信息渗透到下游服务器（针对单个服务的敏感头部信息配置，下面两个配置项选其一即可）
sensitiveHeaders: ""
customSensitiveHeaders: true
# Spring Cloud Zuul在请求路由时，会过滤掉 HTTP 请求头（Cookie、Set-Cookie、Authorization）信息中的一些敏感信息，
sensitive-headers: {"Cookie", "Set-Cookie", "Authorization"}
# 网关在进行路由转发时为请求设置 Host 头信息（保持在路由转发过程中 host 头信息不变）
add-host-header: true
# 请求转发时加上 X-Forwarded-*头域
add-proxy-headers: true五、Hystrixとリボンのサポート
# 该参数可以用来设置 API 网关中路由转发请求的 HystrixCommand 执行超时时间，单位为毫秒。
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutinMilliseconds: 5000
ribbon:
# 该参数用来设置路由转发请求的时候，创建请求连接的超时时间。
ConnectTimeout: 500
# 该参数用来设置路由转发请求的超时时间。
ReadTimeout: 2000
# 最大自动重试次数
MaxAutoRetries: 1
# 最大自动重试下一个服务的次数
MaxAutoRetriesNextServer: 1これは、Hystrixの設定パラメータがでHystrixCommandProperties.javaで見つけることができます。
これは、リボンの設定パラメータがでCommonClientConfigKey.javaで見つけることができます。
また、要求する必要がtrueにzuul.retryableセットを再試行していることに注意してください。