モノリシックアーキテクチャ#

ビジネスのすべての機能を1つのプロジェクトに集中して開発し、1つのパッケージとしてデプロイする。

利点：

• アーキテクチャが単純
• デプロイコストが低い

欠点：

• 結合度が高い（保守が難しい、アップグレードが難しい）

分散アーキテクチャ#

ビジネス機能に基づいてシステムを分割し、各ビジネス機能モジュールを独立したプロジェクトとして開発します。これを1つのサービスと呼ぶ。

利点：

• サービス間の結合を低減
• サービスのアップグレードと拡張に有利

欠点：

• サービス呼び出し関係が複雑になる

分散アーキテクチャは確かにサービスの結合を低減しますが、サービスを分割する際には考えるべき問題が多くあります：

• サービス分割の粒度をどう定義するか？
• サービス間はどう呼び出すのか？
• サービスの呼び出し関係をどう管理するのか？

人々は分散アーキテクチャを制約するための実効的な標準を制定する必要があります。

マイクロサービス#

マイクロサービスのアーキテクチャの特徴：

• 単一責務：マイクロサービスは粒度がより小さく、各サービスが唯一のビジネス能力を持ち、単一責務を実現します
• 自治：チーム独立、技術独立、データ独立、独立デプロイとデリバリー
• サービス指向：サービスは統一された標準インターフェースを提供し、言語や技術に依存しない
• 隔離性が高い：サービス呼び出しは隔離・フォールトトレランス・降格を適切に実施し、連鎖的な問題を回避

上述の特性は、分散アーキテクチャに対して標準を設定し、サービス間の結合をさらに低減し、サービスの独立性と柔軟性を提供することを目的としています。高い内聚、低い結合を実現します。

したがって、マイクロサービスは、良好なアーキテクチャ設計を経た、分散アーキテクチャのソリューションとみなすことができます。

SpringCloud#

SpringCloudは現在国内で最も広く使われているマイクロサービスフレームワークです。公式サイト：https://spring.io/projects/spring-cloud。

SpringCloudはさまざまなマイクロサービス機能コンポーネントを統合し、SpringBootを基盤としてこれらのコンポーネントの自動設定を実現することで、良好な「箱から出してすぐ使える」体験を提供します。

コンポーネントには：

• サービス登録・発見：Eureka、Nacos、Consul
• サービスリモート呼び出し：OpenFeign、Dubbo
• サービストレースモニタリング：Zipkin、Sleuth
• 統一設定管理：SpringCloudConfig、Nacos
• 統一ゲートウェイルーティング：SpringCloudGateway、Zuul
• レート制御、降格、保護：Hystix、Sentinel

サービス間の遠隔呼び出し#

RestTemplateを呼び出して実現します

1. 起動時にRestTemplateのインスタンスを登録する

   1
   @Bean
   2
   public RestTemplate restTemplate() {
   3
       return new RestTemplate();
   4
   }

2. サービス側の呼び出し

   1
   @Autowired
   2
   private RestTemplate restTemplate;
   3
   
   4
   public Order queryOrderById(Long orderId) {
   5
       // 1.注文を取得
   6
       Order order = orderMapper.findById(orderId);
   7
       // 2. ユーザーをリモート照会
   8
       String url = "<http://localhost:8081/user/>" + order.getUserId();
   9
       User user = restTemplate.getForObject(url, User.class);
   10
       // 3. orderに格納
   11
       order.setUser(user);
   12
       // 4. 返却
   13
       return order;
   14
   }

提供者と消費者#

サービス呼び出し関係には2つの異なる役割があります：

サービス提供者：他のマイクロサービスから呼び出されるサービス。（他のマイクロサービスへ接口を提供）

サービス消費者：他のマイクロサービスを呼び出すサービス。（他のマイクロサービスが提供するインターフェースを呼び出す）

Eurekaの構成と役割#

登録センターは、消費者がリモート呼び出しを行う際、複数のインスタンスとして実行されているサービス提供者を解決するために使用します。

• 問題1：order-serviceはuser-serviceのインスタンスアドレスをどう知るのか？
  • user-serviceのインスタンスが起動すると、自分の情報をeureka-server（Eurekaサーバ）に登録します。これをサービス登録と呼ぶ
  • eureka-serverはサービス名とサービスインスタンスアドレスのリストの対応を保持します
  • order-serviceはサービス名に基づいてインスタンスアドレスリストを取得します。これをサービス発見またはサービスプルと呼ぶ
• 問題2：order-serviceは複数のuser-serviceインスタンスのうちどの具体的なインスタンスを選ぶのか？
  • order-serviceはインスタンスリストからロードバランシングアルゴリズムを用いて1つのインスタンスアドレスを選ぶ
  • そのインスタンスアドレスに対してリモート呼び出しを行う
• 問題3：order-serviceはあるuser-serviceインスタンスが依然として健全か、落ちていないかをどう知るのか？
  • user-serviceは一定の間隔（デフォルト30秒）でeureka-serverに心拍を送信して自分の状態を報告する
  • 心拍が一定時間受信されない場合、eureka-serverはマイクロサービスインスタンスを故障とみなし、サービスリストから除外する
  • サービスを取得する際、故障したインスタンスは除外される

Eureka-Serverの構築#

1. Eureka-Serverサービスを作成

親プロジェクトの下にサブモジュールを作成し、Mavenプロジェクトとする

1. Eureka依存を導入 - server

1
<dependency>
2
    <groupId>org.springframework.cloud</groupId>
3
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
4
</dependency>

1. 起動クラスを作成

@EnableEurekaServerアノテーションを付与して、Eureka登録センター機能を有効化する

1
@SpringBootApplication
2
@EnableEurekaServer
3
public class EurekaApplication {
4
    public static void main(String[] args) {
5
        SpringApplication.run(EurekaApplication.class, args);
6
    }
7
}

1. 設定ファイルを作成

1
server:
2
  port: 10086
3
spring:
4
  application:
5
    name: eureka-server
6
eureka:
7
  client:
8
    service-url:
9
      defaultZone: <http://127.0.0.1:10086/eureka>

1. サービスを起動

設定したEurekaサービスパスにアクセス

サービス登録#

1. 依存導入 - client

1
<dependency>
2
    <groupId>org.springframework.cloud</groupId>
3
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
4
</dependency>

1. 設定ファイル

1
spring:
2
  application:
3
    name: userservice
4
eureka:
5
  client:
6
    service-url:
7
      defaultZone: <http://127.0.0.1:10086/eureka>

1. 複数のサービスインスタンスを起動

SpringBootの起動設定を複製し、VMオプションで-Dserver.port=8082を設定

サービス発見#

消費者であるorder-serviceの前述2点は提供者と同様です。

1. サービス取得とロードバランシング

ロードバランシング：restTemplateのBeanに@LoadBalancedアノテーションを追加すればよい

1
@Bean
2
@LoadBalanced
3
public RestTemplate restTemplate(){
4
    return new RestTemplate();
5
}

取得するサービス：

1
public Order queryOrderById(Long orderId) {
2
    // 1.注文を取得
3
    Order order = orderMapper.findById(orderId);
4
    // 2. 远程查询User
5
//        String url = "<http://localhost:8081/user/>" + order.getUserId();
6
    String url = "<http://userservice/user/>" + order.getUserId();
7
    User user = restTemplate.getForObject(url, User.class);
8
    // 3. 存入order
9
    order.setUser(user);
10
    // 4.返回
11
    return order;
12
}

springは自動的にeureka-server端からuserserviceというサービス名のインスタンスリストを取得し、その後ロードバランシングを実行します。

Ribbonロードバランシング#

1
@Bean
2
public IRule randomRule(){
3
    return new RandomRule();
4
}

1
userservice: # 負荷均衡規則を設定するマイクロサービス、この場合はuserservice
2
  ribbon:
3
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # ロードバランス規則

1
ribbon:
2
  eager-load:
3
    enabled: true
4
    clients: userservice

Nacosへのサービス登録#

1
<dependency>
2
    <groupId>com.alibaba.cloud</groupId>
3
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
4
    <version>2.2.6.RELEASE</version>
5
    <type>pom</type>
6
    <scope>import</scope>
7
</dependency>

1
<dependency>
2
    <groupId>com.alibaba.cloud</groupId>
3
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
4
</dependency>

1
spring:
2
  cloud:
3
    nacos:
4
      server-addr: localhost:8848

サービス分級ストレージモデル#

1つのサービスには複数のインスタンスがあり、これらのインスタンスが全国各地の異なるデータセンターに分布している場合、Nacosは同一データセンター内のインスタンスを1つのクラスターとして区分します。

マイクロサービス同士のアクセスは、可能な限り同じクラスターのインスタンスへアクセスするべきです。なぜならローカルアクセスの方が速いためです。もし同一クラスター内で利用不能になった場合にのみ、他のクラスターへアクセスします。

• 設定

application.ymlファイルを修正し、クラスター設定を追加します：

1
spring:
2
  cloud:
3
    nacos:
4
      server-addr: localhost:8848
5
      discovery:
6
        cluster-name: HZ # クラスター名

Nacosには同一クラスターからインスタンスを優先的に選ぶNacosRuleの実装が用意されています。

1
userservice:
2
  ribbon:
3
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # ロードバランス規則

• ウェイト設定

実際のデプロイでは、サーバ機器の性能差などがあり、性能の良い機械がより多くのユーザーリクエストを処理することを望みます。

ただしデフォルトではNacosRuleは同一クラスター内でランダムに選択され、機械の性能を考慮しません。

したがって、Nacosはアクセス頻度を制御するウェイト設定を提供します。ウェイトが大きいほどアクセス頻度が高くなります。

• 環境分離

  Nacosはnamespaceを使って環境分離を実現します。

  • Nacosには複数のnamespaceを持つことができます
  • namespaceにはgroup、serviceなどを含むことができます
  • 異なるnamespace同士は互いに見えません

• サービスインスタンス

  Nacosのサービスインスタンスは2種類のタイプに分かれます：

  • 一時インスタンス：インスタンスが停止して一定時間経過するとサービスリストから除外されます（デフォルトのタイプ）。
  • 永続インスタンス：インスタンスが停止してもサービスリストから除外されません（永久インスタンスとも呼ばれます）。

  サービスインスタンスを永久インスタンスとして設定する：

1
spring:
2
  cloud:
3
    nacos:
4
      discovery:
5
        ephemeral: false # 非一時インスタンスに設定

NacosとEurekaの違い#

NacosとEurekaの全体的な構造は概要としては似ており、サービス登録、サービス取得、心拍待機といった点は共通です。

• NacosとEurekaの共通点
  • サービス登録とサービス取得をサポート
  • サービス提供者の心拍を用いた健全性検知をサポート
• NacosとEurekaの違い
  • Nacosはサーバ側が提供者の状態をアクティブに検出します：一時インスタンスは心拍モード、非一時インスタンスは能動的検出モードを採用
  • 一時インスタンスの心拍が異常だと除外されるが、非一時は除外されない
  • Nacosはサービスリスト変更のプッシュ通知モードを提供し、サービスリストの更新がよりタイムリー
  • NacosクラスターはデフォルトでAPモードを採用します。クラスター内に非一時インスタンスが存在する場合はCPモードを採用します。EurekaはAPモード

マイクロサービスから設定を取得#

マイクロサービスはNacosで管理されている設定を取得し、ローカルのapplication.yml設定とマージしてプロジェクト開始を完了します。

ただし application.yml をまだ読んでいない場合、どうやってNacosアドレスを知ることができるのでしょうか？

そこでSpringは新しい設定ファイル bootstrap.yaml を導入します。これは application.yml の前に読み込まれます。

1. nacos-config依存を導入

1
<!--nacos設定管理依存-->
2
<dependency>
3
    <groupId>com.alibaba.cloud</groupId>
4
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
5
</dependency>

1. bootstrap.ymlを追加

1
spring:
2
  application:
3
    name: userservice # サービス名
4
  profiles:
5
    active: dev #開発環境、ここはdev
6
  cloud:
7
    nacos:
8
      server-addr: localhost:8848 # Nacosアドレス
9
      config:
10
        file-extension: yaml # ファイル拡張子

ここでは spring.cloud.nacos.server-addr からNacosアドレスを取得し、${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension} をファイルIDとして設定を読み込みます。

1. Nacos設定を読み取る

1
@Value("${pattern.dateformat}")
2
private String dateformat;
3

4
@GetMapping("now")
5
public String now(){
6
    return LocalDateTime.now().format(DateTimeFormatter.ofPattern(dateformat));
7
}

設定のホット更新#

Nacosの設定を変更しても、マイクロサービスを再起動せずに設定を有効にできる、つまり設定のホット更新です。

• 方法1：@RefreshScope を追加

• 方法2

  @Value の代わりに @ConfigurationProperties を使います。

  1. user-service に、patterrn.dateformat 属性を読み取るクラスを追加：

1
package cn.itcast.user.config;
2

3
import lombok.Data;
4
import org.springframework.boot.context.properties.ConfigurationProperties;
5
import org.springframework.stereotype.Component;
6

7
@Component
8
@Data
9
@ConfigurationProperties(prefix = "pattern")
10
public class PatternProperties {
11
    private String dateformat;
12
}

1
1. `UserController` でこのクラスを `@Value` の代わりに使う：

1
@Autowired
2
private PatternProperties patternProperties;
3

4
@GetMapping("now")
5
public String now(){
6
    return LocalDateTime.now().format(DateTimeFormatter.ofPattern(patternProperties.getDateformat()));
7
}

設定の共有#

実際には、マイクロサービス起動時にはNacosから複数の設定ファイルを読み込みます。例えば：

• [spring.application.name]-[spring.profiles.active].yaml、例：userservice-dev.yaml
• [spring.application.name].yaml、例：userservice.yaml

[spring.application.name].yamlは環境情報を含まないため、複数の環境間で共有できます。

設定の共有の優先順位：

Nacosとサービスローカルの両方に同じ属性がある場合、優先順位には違いがあります：

Nacosクラスタ#

Nginxで複数のNacosサーバをロードバランシングする

Nacosのconfにあるcluster.confを設定し、Nacosクラスタのアドレスを追加します。

FeignをRestTemplateの代替として#

1. 依存関係を導入

1
<dependency>
2
    <groupId>org.springframework.cloud</groupId>
3
    <artifactId>spring-cloud-starter-openfeign</artifactId>
4
</dependency>

2. アノテーションを追加

起動クラスに@EnableFeignClientsを追加

3. Feignクライアントを作成

サービス内にインターフェースを新規作成：

1
@FeignClient("userservice")
2
public interface UserClient {
3
    @GetMapping("/user/{id}")
4
    User findById(@PathVariable("id") Long id);
5
}

このクライアントは、サービス名：userservice、リクエスト方法：GET、リクエストパス：/user/{id}、リクエストパラメータ：Long id、戻り値タイプ：User など、SpringMVCのアノテーションを用いてリモート呼出情報を宣言します。こうしてFeignは、RestTemplateを使わずにHTTPリクエストを送信するのを支援します。

4. 呼出

サービスクラスからこのメソッドを呼び出します：

1
@Autowired
2
private UserClient userClient;
3

4
public Order queryOrderById(Long orderId) {
5
    // 1.注文を取得
6
    Order order = orderMapper.findById(orderId);
7
    // 2. 远程查询User
8
    User user = userClient.findById(order.getUserId());
9
    // 3. 存入order
10
    order.setUser(user);
11
    // 4.返回
12
    return order;
13
}

カスタム設定#

Feignには多くのカスタム設定があり、以下の表のとおりです：

一般的にはデフォルト値で十分なことが多いですが、カスタム時には@Beanを作成してデフォルトBeanを上書きするだけで済みます。

1
feign:
2
  client:
3
    config:
4
      userservice: # 特定のマイクロサービスに対する設定
5
        loggerLevel: FULL #  ログレベル

1
feign:
2
  client:
3
    config:
4
      default: # ここに書くとグローバル設定、サービス名を指定すれば特定のマイクロサービス向け
5
        loggerLevel: FULL #  ログレベル

1
public class DefaultFeignConfiguration  {
2
    @Bean
3
    public Logger.Level feignLogLevel(){
4
        return Logger.Level.BASIC; // ログレベルはBASIC
5
    }
6
}

1
@EnableFeignClients(defaultConfiguration = DefaultFeignConfiguration .class)

1
@FeignClient(value = "userservice", configuration = DefaultFeignConfiguration .class)

Feignの利用最適化#

FeignはHTTPリクエストを発行する下位層が他のフレームワークに依存します。その下位クライアント実装には以下のものがあります：

• URLConnection：デフォルト実装、接続プールをサポートしません
• Apache HttpClient：接続プールをサポート
• OKHttp：接続プールをサポート

したがって、Feignの性能を向上させる主な手段は、デフォルトのURLConnectionの代わりに接続プールを使用することです。

ここではApacheのHttpClientを用いて説明します。

1. 依存関係を導入

order-serviceのpomにApacheのHttpClient依存を導入します：

1
<!--httpClientの依存 -->
2
<dependency>
3
    <groupId>io.github.openfeign</groupId>
4
    <artifactId>feign-httpclient</artifactId>
5
</dependency>

1. 接続プールを設定

order-serviceのapplication.ymlに設定を追加します：

1
feign:
2
  client:
3
    config:
4
      default: # defaultはグローバル設定
5
        loggerLevel: BASIC # ログレベル、BASICは基本的なリクエストとレスポンス情報
6
  httpclient:
7
    enabled: true # FeignによるHttpClientのサポートを有効化
8
    max-connections: 200 # 最大コネクション数
9
    max-connections-per-route: 50 # ルートごとの最大コネクション数

要約すると、Feignの最適化は以下の点です。

1. ログレベルはできるだけBASICを用いる
2. HttpClientまたはOKHttpを用いてURLConnectionを置換する
   • feign-httpClient依存を導入
   • 設定ファイルでhttpClient機能を有効化し、コネクションプールのパラメータを設定

最適な実装#

Feignのクライアントとサービス提供者のコントローラのコードは非常に似ており、このような重複したコードを簡略化する方法は以下のとおりです。

1
<dependency>
2
    <groupId>cn.itcast.demo</groupId>
3
    <artifactId>feign-api</artifactId>
4
    <version>1.0</version>
5
</dependency>

1
@EnableFeignClients(basePackages = "cn.itcast.feign.clients")

1
@EnableFeignClients(clients = {UserClient.class})

なぜゲートウェイが必要か#

Gatewayは私たちのサービスの守護神で、すべてのマイクロサービスの統一エントリポイントです。

ゲートウェイのコア機能特性：

• 認可制御：ゲートウェイはマイクロサービスの入口として、リクエスト許可があるかを検証します。なければ遮断します。
• ルーティングとロードバランシング：すべてのリクエストはゲートウェイを経由しますが、ゲートウェイはビジネスを処理せず、何らかのルールに基づいてリクエストを特定のマイクロサービスへ転送します。この過程をルーティングと呼びます。ルーティング先サービスが複数ある場合は、ロードバランシングが必要です。
• レート制御：リクエストの流量が多すぎる場合、ゲートウェイは下位のマイクロサービスが処理できる速度に応じてリクエストを通すように制御します。

SpringCloudにはゲートウェイの実装として2つがあります：

• gateway
• zuul

ZuulはServletベースの実装で、ブロッキング型です。一方、SpringCloudGatewayはSpring5が提供するWebFluxをベースとしたリアクティブ実装で、より高いパフォーマンスを実現します。

入門#

1. SpringBootプロジェクトgatewayを作成し、ゲートウェイの依存関係を導入

1
<!--网关-->
2
<dependency>
3
    <groupId>org.springframework.cloud</groupId>
4
    <artifactId>spring-cloud-starter-gateway</artifactId>
5
</dependency>
6
<!--nacosサービス发现依存-->
7
<dependency>
8
    <groupId>com.alibaba.cloud</groupId>
9
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
10
</dependency>

2. 起動クラスを作成

1
@SpringBootApplication
2
public class GatewayApplication {
3

4
  public static void main(String[] args) {
5
    SpringApplication.run(GatewayApplication.class, args);
6
  }
7
}

3. 基礎設定とルーティング規則を作成

ルーティング設定には以下が含まれます：

1. ルートID：ルートの一意識別子
2. ルーティング先（uri）：ルーティングのターゲット先。httpは固定アドレス、lbはサービス名に基づくロードバランシング
3. ルート述語（predicates）：ルートの条件
4. ルーティングフィルター（filters）：リクエストやレスポンスを処理する

1
server:
2
  port: 10010 # ゲートウェイポート
3
spring:
4
  application:
5
    name: gateway # サービス名
6
  cloud:
7
    nacos:
8
      server-addr: localhost:8848 # nacosアドレス
9
    gateway:
10
      routes: # ゲートウェイルーティング設定
11
        - id: user-service # ルートID、任意で唯一であればOK
12
          uri: lb://userservice # ルーティング先、lbはロードバランシング、後にサービス名を続ける
13
          predicates: # ルーティング述語、ルーティングルールの条件
14
            - Path=/user/** # パスに従ったマッチング、/user/で始まる場合に一致

4. ゲートウェイサービスを起動してテスト

ゲートウェイを再起動し、http://localhost:10010/user/1 にアクセスすると、/user/**ルールに一致し、リクエストは uri: http://userservice/user/1 に転送され、結果を得られます。

断言ファクトリ#

設定ファイルに書かれた断言ルールは文字列として扱われ、Predicate Factoryによって読み取られ、ルート判断の条件に変換されます。

例：Path=/user/** はパス照合であり、このルールはorg.springframework.cloud.gateway.handler.predicate.PathRoutePredicateFactoryクラスが処理します。SpringCloudGatewayにはこのような断言ファクトリが他にも十数種類あります：

フィルター・ファクトリ#

GatewayFilterはゲートウェイに提供されるフィルターで、ゲートウェイに入るリクエストとマイクロサービスから返ってくるレスポンスを処理します

• ルートのリクエストやレスポンスを加工して、例えばリクエストヘッダを追加する
• ルート下のフィルター設定は、そのルートのリクエストにのみ有効

1
spring:
2
  cloud:
3
    gateway:
4
      routes:
5
      - id: user-service
6
        uri: lb://userservice
7
        predicates:
8
        - Path=/user/**
9
        filters: # フィルター部
10
        - AddRequestHeader=Truth, dreaife is freaking awesome! # リクエストヘッダを追加

1
spring:
2
  cloud:
3
    gateway:
4
      routes:
5
      - id: user-service
6
        uri: lb://userservice
7
        predicates:
8
        - Path=/user/**
9
      default-filters: # デフォルトのフィルター項目
10
      - AddRequestHeader=Truth, dreaife is freaking awesome!

グローバルフィルター#

1
public interface GlobalFilter {
2
    /**
3
     *  現在のリクエストを処理する。必要に応じて`{@link GatewayFilterChain}` を使ってリクエストを次のフィルターへ渡します
4
     *
5
     * @param exchange リクエストのコンテキスト。Request、Responseなどの情報を取得可能
6
     * @param chain リクエストを次のフィルターへ委譲するためのチェーン
7
     * @return {@code Mono<Void>} 現在のフィルターの処理を終了することを示す
8
     */
9
    Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
10
}

1
package cn.itcast.gateway.filters;
2

3
import org.springframework.cloud.gateway.filter.GatewayFilterChain;
4
import org.springframework.cloud.gateway.filter.GlobalFilter;
5
import org.springframework.core.annotation.Order;
6
import org.springframework.http.HttpStatus;
7
import org.springframework.stereotype.Component;
8
import org.springframework.web.server.ServerWebExchange;
9
import reactor.core.publisher.Mono;
10

11
@Order(-1)
12
@Component
13
public class AuthorizeFilter implements GlobalFilter {
14
    @Override
15
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
16
        // 1.リクエストパラメータ取得
17
        MultiValueMap<String, String> params = exchange.getRequest().getQueryParams();
18
        // 2. authorizationパラメータを取得
19
        String auth = params.getFirst("authorization");
20
        // 3.検証
21
        if ("admin".equals(auth)) {
22
            // 通過
23
            return chain.filter(exchange);
24
        }
25
        // 4.遮断
26
        // 4.1.アクセス禁止、ステータスコードを設定
27
        exchange.getResponse().setStatusCode(HttpStatus.FORBIDDEN);
28
        // 4.2.処理を終了
29
        return exchange.getResponse().setComplete();
30
    }
31
}

クロスオリジン問題#

クロスオリジン：ドメイン名が異なる場合を指します。主に以下を含みます：

• 異なるドメイン名： www.taobao.com、www.taobao.org、www.jd.com、miaosha.jd.com
• 同一ドメイン、ポートが異なる場合：localhost<8080> と localhost<8081>

クロスオリジン問題は、ブラウザがサービスへ送るクロスドメインのAjaxリクエストを禁止することで、リクエストがブラウザでブロックされる問題です。

解決策：CORS

gatewayサービスのapplication.ymlに以下の設定を追加します：

1
spring:
2
  cloud:
3
    gateway:
4
      globalcors: # グローバルのクロスオリジン処理
5
        add-to-simple-url-handler-mapping: true # optionsリクエストのブロックを回避
6
        corsConfigurations:
7
          '[/**]':
8
            allowedOrigins: # 許可するクロスオリジンリクエスト先サイト
9
              - "<http://localhost:8090>"
10
            allowedMethods: # 許可するクロスオリジンのAjaxリクエスト方式
11
              - "GET"
12
              - "POST"
13
              - "DELETE"
14
              - "PUT"
15
              - "OPTIONS"
16
            allowedHeaders: "*" # リクエストで許可されるヘッダ情報
17
            allowCredentials: true # クッキーの送受を許可するか
18
            maxAge: 360000 # このクロスオリジン検出の有効期限