基本的なマイクロサービス SpringCloud 学習 Day01

春雲01

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

モノリシック アーキテクチャ: ビジネスのすべての機能が 1 つのプロジェクトで開発され、展開用に 1 つのパッケージにパッケージ化されます。

モノリシック アーキテクチャの長所と短所は次のとおりです。

アドバンテージ：

• シンプルな構造
• 導入コストが低い

欠点:

• 高度な結合 (維持とアップグレードが困難)

1.2. 分散アーキテクチャ

分散アーキテクチャ: システムはビジネス機能に応じて分割され、各ビジネス機能モジュールはサービスと呼ばれる独立したプロジェクトとして開発されます。

分散アーキテクチャの長所と短所:

アドバンテージ：

• サービス結合を減らす
• サービスのアップグレードと拡張に貢献

欠点:

• サービスコールの関係が複雑

分散アーキテクチャによりサービスの結合は軽減されますが、サービスを分割する際には考慮すべき問題がまだ多くあります。

• サービス分割の粒度を定義するにはどうすればよいですか?
• サービス間で通話するにはどうすればよいですか?
• サービス呼び出し関係を管理するにはどうすればよいですか?

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

1.3. マイクロサービス

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

• 単一の責任: マイクロサービス分割の粒度はより小さく、各サービスは単一の責任を達成するための固有のビジネス機能に対応します。
• 自律性: 独立したチーム、独立したテクノロジー、独立したデータ、独立した展開と配信
• サービス指向: サービスは、言語やテクノロジーに依存しない、統一された標準インターフェイスを提供します。
• 強力な分離: サービス コールは分離され、耐障害性があり、連鎖的な問題を回避するために機能が低下します。

マイクロサービスの上記の特性は、実際に分散アーキテクチャの標準を設定し、サービス間の結合をさらに軽減し、サービスの独立性と柔軟性を提供します。高い凝集性と低い結合性を実現します。

したがって、マイクロサービスは、適切に設計されたアーキテクチャを備えた分散アーキテクチャ ソリューションと考えることができます。

しかし、計画はどのように実行されるべきでしょうか? どのテクノロジースタックを選択すればよいでしょうか? 世界中のインターネット企業は、独自のマイクロサービス実装ソリューションを積極的に試しています。

中でもJava分野で最も注目を集めているのがSpring Cloudが提供するソリューションだ。

1.4.スプリングクラウド

SpringCloud は現在、中国で最も広く使用されているマイクロサービス フレームワークです。公式ウェブサイトのアドレス：https://spring.io/projects/spring-cloud。

Spring Cloud は、さまざまなマイクロサービス機能コンポーネントを統合し、SpringBoot に基づいてこれらのコンポーネントの自動アセンブリを実現するため、優れたすぐに使用できるエクスペリエンスを提供します。

共通のコンポーネントには次のものがあります。

また、SpringCloud の最下層は SpringBoot に依存しており、次のようなバージョン互換関係があります。

授業で学ぶバージョンは Hoxton.SR10 なので、対応する SpringBoot のバージョンはバージョン 2.3.x です。

1.5. 概要

• モノリシック アーキテクチャ: シンプルで便利、高度に結合されているが拡張性が低く、小規模プロジェクトに適しています。例: 学生管理システム

• 分散アーキテクチャ: 疎結合でスケーラブルですが、複雑で困難です。JD.com や Taobao などの大規模なインターネット プロジェクトに適しています

• マイクロサービス: 優れた分散アーキテクチャ ソリューション

  ①メリット：分割粒度が小さく、サービスの独立性が高く、結合度が低い

  ②デメリット：構造が非常に複雑で、運用保守、監視、導入の難易度が高くなる

• SpringCloud は、さまざまな優れたマイクロサービス機能コンポーネントを統合した、マイクロサービス アーキテクチャのワンストップ ソリューションです

2. サービス分割とリモート通話

分散アーキテクチャはサービスの分割と切り離すことができず、マイクロサービスについても同様です。

2.1. サービス分割の原則

ここでは、マイクロサービスを分割する際のいくつかの原則を要約します。

• 異なるマイクロサービス、同じビジネスを繰り返し開発しない
• マイクロサービス データは独立しており、他のマイクロサービスのデータベースにはアクセスしません
• マイクロサービスは、他のマイクロサービスが呼び出すためのインターフェイスとしてビジネスを公開できます。

2.2. サービス分割の例

事前授業資料のマイクロサービス クラウド デモを例に挙げると、その構造は次のとおりです。

Cloud-demo: 親プロジェクト、依存関係を管理する

• order-service: 注文マイクロサービス、注文関連のビジネスを担当します。
• user-service: ユーザー マイクロサービス。ユーザー関連のビジネスを担当します。

必須：

• 注文マイクロサービスとユーザー マイクロサービスの両方に、互いに独立した独自のデータベースが必要です
• 注文サービスとユーザー サービスの両方が、Restful インターフェイスを外部に公開します
• オーダー サービスがユーザー情報をクエリする必要がある場合、ユーザー サービスの Restful インターフェイスのみを呼び出すことができ、ユーザー データベースをクエリすることはできません。

2.2.1. SQL ステートメントのインポート

まず、事前授業資料によって提供されたcloud-order.sql合計をcloud-user.sqlmysql にインポートします。

クラウド ユーザー テーブルの初期データは次のとおりです。

クラウド順序テーブルの初期データは次のとおりです。

cloud-order テーブルは、cloud-user テーブルの id フィールドを保持します。

2.2.2. デモプロジェクトのインポート

IDEA を使用して、授業前の教材で提供されるデモをインポートします。

プロジェクトの構造は次のとおりです。

インポート後、IDEA の右下隅にポップアップ ウィンドウが表示されます。

ポップアップ ウィンドウをクリックし、以下に示すように選択します。

次のようなメニューが表示されます。

次のプロジェクトで使用される JDK を構成します。

2.3. リモート通話の場合を実現する

order-service サービスには、ID で注文をクエリするためのインターフェイスがあります。

ID に従って注文をクエリすると、図に示すように、戻り値は Order オブジェクトになります。

user が null の場合

user-service には、ID でユーザーをクエリするためのインターフェイスがあります。

クエリの結果を図に示します。

2.3.1. ケースの要件:

order-service 内の ID によって注文クエリ サービスを変更し、注文のクエリ中に注文に含まれる userId に従ってユーザー情報をクエリし、一緒に返すように要求します。

したがって、order-service で user-service への http リクエストを開始し、インターフェイス http://localhost:8081/user/{userId} を呼び出す必要があります。

おおよその手順は次のとおりです。

• RestTemplateのインスタンスをSpringコンテナに登録する
• order-service サービスの OrderService クラスの queryOrderById メソッドを変更し、Order オブジェクトの userId に従ってユーザーをクエリします。
• クエリされたユーザーを Order オブジェクトに入力し、一緒に返します

2.3.2. RestTemplateの登録

まず、order-service サービスの OrderApplication スタートアップ クラスに RestTemplate インスタンスを登録します。

package cn.itcast.order;

import org.mybatis.spring.annotation.MapperScan;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;

@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {
    
    

    public static void main(String[] args) {
    
    
        SpringApplication.run(OrderApplication.class, args);
    }

    @Bean
    public RestTemplate restTemplate() {
    
    
        return new RestTemplate();
    }
}

2.3.3. リモート通話を実現する

order-service サービスの cn.itcast.order.service パッケージにある OrderService クラスの queryOrderById メソッドを変更します。

2.4. プロバイダーとコンシューマー

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

サービスプロバイダー: ビジネス内の他のマイクロサービスによって呼び出されるサービス。(他のマイクロサービスへのインターフェースを提供します)

サービスコンシューマ: ビジネス内の他のマイクロサービスを呼び出すサービス。(他のマイクロサービスによって提供されるインターフェイスの呼び出し)

ただし、サービス プロバイダーとサービス利用者の役割は絶対的なものではなく、ビジネスに対して相対的なものです。

サービス A がサービス B を呼び出し、サービス B がサービス C を呼び出す場合、サービス B の役割は何ですか?

• A が B に電話をかけるビジネスの場合: A はサービス消費者、B はサービスプロバイダーです
• B が C に電話をかけるビジネスの場合: B はサービス コンシューマであり、C はサービス プロバイダーです。

したがって、サービス B はサービス プロバイダーとサービス コンシューマの両方になることができます。

3. エウレカ登録センター

図に示すように、サービス プロバイダーのユーザー サービスが複数のインスタンスをデプロイするとします。

いくつかの質問について考えてみましょう。

• order-service がリモート呼び出しを開始するとき、ユーザー サービス インスタンスの IP アドレスとポートをどのようにして知るのでしょうか?
• ユーザーサービスインスタンスのアドレスが複数ありますが、order-service を呼び出すときにどのように選択すればよいですか?
• order-service は、特定のユーザー サービス インスタンスがまだ正常であるかどうかをどのようにして知るのでしょうか?

3.1. エウレカの構造と機能

これらの問題は、SpringCloud の登録センターを使用して解決する必要があります。最もよく知られている登録センターは Eureka であり、その構造は次のとおりです。

前の質問に答えてください。

質問 1: order-service はどのようにして user-service インスタンスのアドレスを知るのでしょうか?

住所情報を取得する手順は次のとおりです。

• user-serviceサービスインスタンス起動後、eureka-server(エウレカサーバー)に自身の情報を登録します。これをサービス登録といいます
• eureka-server は、サービス名とサービス インスタンスのアドレス リスト間のマッピング関係を保存します。
• order-service は、サービス名に従ってインスタンスのアドレスリストを取得します。これはサービス ディスカバリまたはサービス プルと呼ばれます

質問 2: order-service は、複数の user-service インスタンスから特定のインスタンスをどのように選択しますか?

• order-service は、負荷分散アルゴリズムを使用してインスタンス リストからインスタンス アドレスを選択します。
• インスタンスアドレスへのリモート呼び出しを開始します。

質問 3: order-service は、特定のユーザー サービス インスタンスがまだ正常であるか、ダウンしているかをどのようにして知るのでしょうか?

• ユーザーサービスは、ハートビートと呼ばれる独自のステータスを報告するために、時々 (デフォルトは 30 秒) eureka-server へのリクエストを開始します。
• 一定期間以上ハートビートが送信されない場合、eureka-server はマイクロサービス インスタンスに障害があるとみなし、そのインスタンスをサービス リストから削除します。
• order-service がサービスをプルするときに、障害のあるインスタンスを除外できる

注: マイクロサービスはサービス プロバイダーとサービス コンシューマーの両方になることができるため、eureka はサービス登録やサービス検出などの機能を eureka-client にカプセル化します。

したがって、次の実践的なステップは次のとおりです。

3.2. eureka-serverの構築

まず、全員がセンター サーバー eureka-server を登録します。これは独立したマイクロサービスである必要があります。

3.2.1. eureka-server サービスの作成

Cloud-demo 親プロジェクトの下に、サブモジュールを作成します。

モジュール情報を入力します。

次に、サービス情報を入力します。

3.2.2. eureka 依存関係の導入

SpringCloud によって eureka に提供されるスターター依存関係を導入します。

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

3.2.3. スタートアップクラスの書き込み

eureka-server サービスの起動クラスを作成するには、必ず @EnableEurekaServer アノテーションを追加して、eureka の登録センター機能を有効にしてください。

package cn.itcast.eureka;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer
public class EurekaApplication {
    
    
    public static void main(String[] args) {
    
    
        SpringApplication.run(EurekaApplication.class, args);
    }
}

3.2.4. 設定ファイルの書き込み

次の内容を含む application.yml ファイルを作成します。

server:
  port: 10086
spring:
  application:
    name: eureka-server
eureka:
  client:
    service-url: 
      defaultZone: http://127.0.0.1:10086/eureka

3.2.5. サービスの開始

マイクロサービスを開始し、ブラウザーでアクセスします: http://127.0.0.1:10086

次の結果が成功することを確認してください。

3.3. サービス登録

次に、eureka-serverにuser-serviceを登録します。

1) 依存関係を導入する

user-service の pom ファイルに、次の eureka-client 依存関係を導入します。

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

2) 設定ファイル

user-service で、application.yml ファイルを変更し、サービス名と eureka アドレスを追加します。

spring:
  application:
    name: userservice
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

3) 複数のユーザーサービスインスタンスを開始する

サービスに複数のインスタンスがあるシナリオを示すために、SpringBoot スタートアップ構成を追加し、ユーザー サービスを開始します。

まず、元のユーザー サービスの起動設定をコピーします。

次に、ポップアップ ウィンドウで次の情報を入力します。

これで、2 つのユーザー サービスのスタートアップ構成が SpringBoot ウィンドウに表示されます。

[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-yGn9Scxc-1656849902621)(assets/image- .png)
]

ただし、1 つ目はポート 8081、2 つ目はポート 8082 です。

2 つのユーザー サービス インスタンスを開始します。

eureka-server 管理ページを表示します。

3.4. サービスディスカバリ

次に、order-service のロジックを変更します。eureka-server からユーザー サービス情報をプルして、サービス ディスカバリを実現します。

1) 依存関係を導入する

前に述べたように、サービス検出とサービス登録はすべて eureka-client 依存関係にカプセル化されているため、この手順はサービス登録と一致します。

order-service の pom ファイルに、次の eureka-client 依存関係を導入します。

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

2) 設定ファイル

サービス検出では、エウレカ アドレスも知る必要があるため、2 番目のステップはサービス登録と一致しており、エウレカ情報を構成します。

order-service で、application.yml ファイルを変更し、サービス名と eureka アドレスを追加します。

spring:
  application:
    name: orderservice
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

3) サービスプルとロードバランシング

最後に、eureka-server から user-service サービスのインスタンス リストを取得し、負荷分散を実装します。

ただし、これらのアクションを実行する必要はなく、いくつかの注釈を追加するだけで済みます。

order-service の OrderApplication で、 @LoadBalanced アノテーションを RestTemplate Bean に追加します。

order-service サービスの cn.itcast.order.service パッケージの下にある OrderService クラスの queryOrderById メソッドを変更します。アクセスする URL パスを変更し、IP とポートの代わりにサービス名を使用します。

Spring は、サービス名 userservice に従って eureka-server 側からインスタンス リストを取得し、負荷分散を完了するのに自動的に役立ちます。

4. リボンの負荷分散

前のセクションでは、負荷分散を実現するために @LoadBalanced アノテーションを追加しましたが、その原理は何ですか?

4.1. 負荷分散の原理

Spring Cloud の最下層は、実際にはリボンと呼ばれるコンポーネントを使用して負荷分散を実装します。

つまり、送信したリクエストは明らかに http://userservice/user/1 ですが、どのようにして http://localhost:8081 になったのでしょうか?

4.2. ソースコードの追跡

サービス名を入力するだけでアクセスできるのはなぜですか? 事前に IP とポートを取得する必要もあります。

明らかに、誰かがサービス名に基づいてサービス インスタンスの IP とポートを取得するのを手伝ってくれました。つまりLoadBalancerInterceptor、このクラスは RestTemplate リクエストをインターセプトし、サービス ID に従って Eureka からサービス リストを取得し、負荷分散アルゴリズムを使用して実際のサービス アドレス情報を取得し、サービス ID を置き換えます。

ソースコードの追跡を行います。

1）ロードバランサーインターセポート

ここでの intercept メソッドがユーザーの HttpRequest リクエストをインターセプトし、いくつかのことを実行することがわかります。

• request.getURI(): リクエスト URI を取得します。この場合は http://user-service/user/8 です。
• originalUri.getHost(): URI パスのホスト名を取得します。これは実際にはサービス ID です。user-service
• this.loadBalancer.execute(): サービス ID とユーザーのリクエストを処理します。

こちらthis.loadBalancerがLoadBalancerClientそのタイプで、引き続きフォローしていきます。

2）ロードバランサークライアント

引き続き実行メソッドに従います。

コードは次のようなものです:

• getLoadBalancer(serviceId): サービス ID に従って ILoadBalancer を取得します。ILoadBalancer はサービス ID を eureka に取り、サービス リストを取得して保存します。
• getServer(loadBalancer): 組み込みの負荷分散アルゴリズムを使用して、サービス リストから 1 つを選択します。この例では、ポート 8082 上のサービスが取得されたことがわかります。

リリース後、再度アクセスしてトレースすると、取得した値が 8081 であることがわかりました。

[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-5A3TheBS-1656849902627)(assets/ .png)
]

案の定、負荷分散は達成されています。

3) 負荷分散戦略 IRule

先ほどのコードでは、アクセス サービスが負荷分散を行うメソッドを使用していることがわかりますgetServer。

私たちはフォローアップを続けます:

ソース コードのchooseServer メソッドをトレースし続けると、次のようなコードが見つかりました。

このルールが誰であるかを見てみましょう:

[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-RdANZvrZ-1656849902629)(assets/ .png)
]

ここでのルールのデフォルト値は one ですRoundRobinRule。クラスの紹介を参照してください。

それが投票の意味ではないでしょうか。

この時点で、負荷分散プロセス全体が明らかになりました。

4) まとめ

SpringCloudRibbon の最下層はインターセプターを使用して、RestTemplate によって送信されたリクエストをインターセプトし、アドレスを変更します。画像でまとめるとこうなります。

基本的なプロセスは次のとおりです。

• RestTemplate リクエストをインターセプト http://userservice/user/1
• ibbonLoadBalancerClient は、リクエスト URL からサービス名を取得します。これは user-service です。
• DynamicServerListLoadBalancer は、ユーザーサービスに従って eureka からサービスリストを取得します。
• eureka はリスト、localhost:8081、localhost:8082 を返します。
• IRule は組み込みの負荷分散ルールを使用します。リストから 1 つを選択します (localhost:8081 など)。
• ibbonLoadBalancerClient はリクエスト アドレスを変更し、userservice を localhost:8081 に置き換え、http://localhost:8081/user/1 を取得して、実際のリクエストを開始します。

4.3. 負荷分散戦略

4.3.1. 負荷分散戦略

負荷分散のルールは IRule インターフェイスで定義され、IRule にはさまざまな実装クラスがあります。

さまざまなルールの意味は次のとおりです。

組み込みの負荷分散ルールクラス	ルールの説明
ラウンドロビンルール	サービスのリストをポーリングしてサーバーを選択するだけです。これは、リボンのデフォルトの負荷分散ルールです。
可用性フィルタリングルール	次の 2 つのサーバーは無視してください。 (1) デフォルトでは、このサーバーが 3 回接続に失敗すると、このサーバーは「短絡」状態に設定されます。短絡状態は 30 秒間続き、再び接続に失敗すると、短絡の継続時間は幾何級数的に増加します。(2) 同時実行性が高すぎるサーバー。サーバーの同時接続数が多すぎる場合、AvailabilityFilteringRule ルールで構成されたクライアントもそれを無視します。同時接続数の上限は、クライアントの ..ActiveConnectionsLimit プロパティによって構成できます。
WeightedResponseTimeRule	各サーバーに重み値を割り当てます。サーバーの応答時間が長いほど、このサーバーの重みは低くなります。このルールはサーバーをランダムに選択し、この重み値はサーバーの選択に影響します。
ゾーン回避ルール	サーバーの選択は、その地域で利用可能なサーバーに基づいて行われます。ゾーンを使用してサーバーを分類します。このゾーンは、コンピューター室、ラックなどとして理解できます。次に、ゾーン内の複数のサービスをポーリングします。
BestAvailableルール	短絡しているサーバーを無視し、同時実行性の低いサーバーを選択します。
ランダムルール	利用可能なサーバーをランダムに選択します。
再試行ルール	再試行メカニズムの選択ロジック

デフォルトの実装は、ポーリング スキームである ZoneAvoidanceRule です。

4.3.2. カスタム負荷分散戦略

負荷分散ルールは、IRule 実装を定義することで変更できます。方法は 2 つあります。

1. コード メソッド: order-service の OrderApplication クラスで、新しい IRule を定義します。

@Bean
public IRule randomRule(){
    
    
    return new RandomRule();
}

2. 構成ファイルによる方法: order-service の application.yml ファイルで、新しい構成を追加すると、ルールを変更することもできます。

userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则 

通常、デフォルトの負荷分散ルールは変更せずに使用されることに注意してください。

4.4. スターベーションローディング

リボンはデフォルトで遅延読み込みを使用します。つまり、LoadBalanceClient は最初にアクセスされたときにのみ作成され、要求時間は非常に長くなります。

ハンガー ロードは、最初の訪問にかかる時間を短縮するために、プロジェクトの開始時に作成されます。次の構成を通じてハンガー ロードを有効にします。

ribbon:
  eager-load:
    enabled: true
    clients: userservice

5. ナコス登録センター

国内企業は一般に登録センターなどアリババの技術を尊重しており、Spring Cloud アリババも Nacos と呼ばれる登録センターを立ち上げた。

5.1. Nacos の理解とインストール

Nacosは Alibaba の製品であり、現在SpringCloudのコンポーネントです。Eurekaに比べて機能が豊富で、中国での人気が高いです。

インストール方法については、事前授業資料「Nacosインストールガイド.md」を参照してください。

5.2. nacosへのサービス登録

Nacos は SpringCloudAlibaba のコンポーネントであり、SpringCloudAlibaba も SpringCloud で定義されたサービス登録およびサービス検出の仕様に従います。したがって、マイクロサービスに Nacos を使用する場合と Eureka を使用する場合に大きな違いはありません。

主な違いは次のとおりです。

• さまざまなものに依存します
• サービスアドレスが異なります

1) 依存関係を導入する

Cloud-demo 親プロジェクトの pom ファイル<dependencyManagement>に SpringCloudAlibaba の依存関係を導入します。

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
    <version>2.2.6.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

次に、user-service と order-service の pom ファイルに nacos-discovery 依存関係を導入します。

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

注: eureka の依存関係をコメントアウトすることを忘れないでください。

2) nacosアドレスの設定

user-service と order-service の application.yml に nacos アドレスを追加します。

spring:
  cloud:
    nacos:
      server-addr: localhost:8848

注: eureka のアドレスをコメントアウトすることを忘れないでください。

3) 再起動

マイクロサービスを再起動した後、nacos 管理ページにログインすると、マイクロサービスの情報を確認できます。

5.3. サービス階層型ストレージモデル

サービスは複数のインスタンスを持つことができます (ユーザー サービスなど)。

• 127.0.0.1:8081
• 127.0.0.1:8082
• 127.0.0.1:8083

たとえば、これらのインスタンスが全国のさまざまなコンピューター室に分散されている場合は、次のようになります。

• 127.0.0.1:8081、上海コンピュータ室
• 127.0.0.1:8082、上海コンピューター室
• 127.0.0.1:8083、杭州コンピューター室

Nacos は、同じコンピュータ ルーム内のインスタンスを 1 つのクラスタに分割します。

つまり、ユーザー サービスはサービスです。サービスには、杭州や上海などの複数のクラスターを含めることができます。各クラスターには複数のインスタンスを含めることができ、図に示すように階層モデルを形成できます。

マイクロサービスが相互にアクセスする場合は、ローカル アクセスの方が高速であるため、できる限り同じクラスター インスタンスにアクセスする必要があります。他のクラスターにアクセスできるのは、クラスターが使用できない場合のみです。例えば：

杭州のコンピューター ルームのオーダー サービスは、同じコンピューター ルームのユーザー サービスへのアクセスを優先する必要があります。

5.3.1. ユーザーサービス用のクラスターの設定

user-service の application.yml ファイルを変更し、クラスター構成を追加します。

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名称

2 つのユーザー サービス インスタンスを再起動すると、nacos コンソールに次の結果が表示されます。

ユーザーサービスの起動設定を再度コピーし、プロパティを追加します。

-Dserver.port=8083 -Dspring.cloud.nacos.discovery.cluster-name=SH

構成を次の図に示します。

UserApplication3 を起動した後、nacos コンソールを再度確認します。

5.3.2. 同じクラスター優先度でのロードバランシング

デフォルトでは、ZoneAvoidanceRule同じクラスターの優先順位に基づいて負荷分散を実現することはできません。

そこでNacosでは、NacosRule同一クラスタ内のインスタンスを優先的に選択できる実装を提供します。

1) order-service のクラスター情報を構成する

order-service の application.yml ファイルを変更し、クラスター構成を追加します。

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名称

2) 負荷分散ルールを変更する

order-service の application.yml ファイルを変更し、負荷分散ルールを変更します。

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则 

5.4. ウェイト設定

実際の展開では、次のようなシナリオが表示されます。

サーバー機器のパフォーマンスは異なります。パフォーマンスが優れているインスタンスもあれば、パフォーマンスが低いインスタンスもあります。パフォーマンスが高いマシンがより多くのユーザーのリクエストを処理できることを期待しています。

ただし、デフォルトでは、NacosRule はマシンのパフォーマンスを考慮せずに、同じクラスター内でランダムに選択されます。

そこでNacosではアクセス頻度を制御するためのウェイト設定を用意しており、ウェイトが大きいほどアクセス頻度が高くなります。

nacos コンソールで、user-service のインスタンス リストを見つけ、[編集] をクリックして重みを変更します。

表示される編集ウィンドウで、重みを変更します。

注: 重みが 0 に変更されると、インスタンスは決して訪問されなくなります。

5.5. 環境隔離

Nacos は、環境分離を実装するための名前空間を提供します。

• nacos には複数の名前空間が存在する可能性があります
• 名前空間の下にグループ、サービスなどを含めることができます。
• 異なる名前空間は相互に分離されます。たとえば、異なる名前空間内のサービスは相互に認識されません。

5.5.1. ネームスペースの作成

デフォルトでは、すべてのサービス、データ、グループは public という名前の同じ名前空間にあります。

ページ上の「追加」ボタンをクリックして名前空間を追加できます。

次に、フォームに記入します。

ページ上に新しい名前空間が表示されます。

5.5.2. マイクロサービスの名前空間の設定

マイクロサービスの名前空間の構成は、構成を変更することによってのみ実現できます。

たとえば、order-service の application.yml ファイルを変更します。

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ
        namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空间，填ID

order-service を再起動した後、コンソールにアクセスすると、次の結果が表示されます。

この時点で、order-service にアクセスすると、名前空間が異なるため、userservice が見つからず、コンソールにエラーが報告されます。

5.6. ナコスとエウレカの違い

Nacos サービス インスタンスは 2 つのタイプに分類されます。

• 一時インスタンス: インスタンスが一定期間以上停止している場合、デフォルトのタイプであるサービス リストから削除されます。

• 非一時インスタンス: インスタンスがダウンしてもサービス リストから削除されず、永続インスタンスと呼ぶこともできます。

サービス インスタンスを永続インスタンスとして構成します。

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为非临时实例

Nacos と Eureka の全体的な構造は、サービス登録、サービス プル、ハートビート待機など似ていますが、いくつかの違いがあります。

• ナコスとエウレカの共通点

  • サービス登録とサービスプルの両方をサポートします
  • どちらもサービス プロバイダーの健全性検出のためのハートビート方式をサポートしています

• ナコスとエウレカの違い

  • Nacos は、サーバーがプロバイダーのステータスをアクティブに検出することをサポートします。一時インスタンスはハートビート モードを採用し、非一時インスタンスはアクティブ検出モードを採用します。
  • 異常なハートビートのある一時的なインスタンスは削除されますが、一時的ではないインスタンスは削除されません
  • Nacos はサービス リスト変更のメッセージ プッシュ モードをサポートし、サービス リストはよりタイムリーに更新されます。
  • Nacos クラスターはデフォルトで AP モードを採用します。クラスター内に非一時インスタンスがある場合は CP モードが採用され、Eureka は AP モードを採用します。

マイクロサービスの名前空間の構成は、構成を変更することによってのみ実現できます。

たとえば、order-service の application.yml ファイルを変更します。

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ
        namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空间，填ID

order-service を再起動した後、コンソールにアクセスすると、次の結果が表示されます。

5.6. ナコスとエウレカの違い

Nacos サービス インスタンスは 2 つのタイプに分類されます。

• 一時インスタンス: インスタンスが一定期間以上停止している場合、デフォルトのタイプであるサービス リストから削除されます。

• 非一時インスタンス: インスタンスがダウンしてもサービス リストから削除されず、永続インスタンスと呼ぶこともできます。

サービス インスタンスを永続インスタンスとして構成します。

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为非临时实例

Nacos と Eureka の全体的な構造は、サービス登録、サービス プル、ハートビート待機など似ていますが、いくつかの違いがあります。

• ナコスとエウレカの共通点

  • サービス登録とサービスプルの両方をサポートします
  • どちらもサービス プロバイダーの健全性検出のためのハートビート方式をサポートしています

• ナコスとエウレカの違い

  • Nacos は、サーバーがプロバイダーのステータスをアクティブに検出することをサポートします。一時インスタンスはハートビート モードを採用し、非一時インスタンスはアクティブ検出モードを採用します。
  • 異常なハートビートのある一時的なインスタンスは削除されますが、一時的ではないインスタンスは削除されません
  • Nacos はサービス リスト変更のメッセージ プッシュ モードをサポートし、サービス リストはよりタイムリーに更新されます。
  • Nacos クラスターはデフォルトで AP モードを採用します。クラスター内に非一時インスタンスがある場合は CP モードが採用され、Eureka は AP モードを採用します。