[Spring Cloud] Nacos 登録センター、サービスの登録と検出、サービス階層化モデル、負荷分散戦略、マイクロサービスの重み設定、および環境分離の原則の詳細な調査

---

序文

マイクロサービス アーキテクチャでは、サービス登録センターはシステム全体の重要なコンポーネントの 1 つです。サービスの登録、検出、管理を担当し、マイクロサービス間の通信のためのインフラストラクチャを提供します。この点において、Nacos (Namespace Aware Clustered Object Storage) は、サービス検出および構成管理システムとして、マイクロサービス アーキテクチャにおけるサービスの登録、構成管理、およびサービス メタデータの処理を簡素化するように設計された豊富な機能を提供します。

1. Nacos 登録センターの最初の紹介

1.1 ナコスとは

Nacos (Namespace Aware Clustered Object Storage) は、オープンソースで構成が簡単な、多機能のサービス検出および構成管理システムです。Alibaba によって開発され、マイクロサービス アーキテクチャにおけるサービス検出、動的構成、サービス メタデータを簡素化するソリューションを提供します。

Nacos には次の主な機能があります。

• サービスの検出とヘルス チェック: Nacos は、マイクロサービス インスタンスを簡単に管理できるサービスの登録と検出機能を提供します。また、サービスのヘルスチェックもサポートしており、利用できないインスタンスをタイムリーに検出します。

• 動的な構成管理: Nacos では、構成情報をサーバーに保存し、動的に更新される構成をサポートし、構成の一元管理を実現します。

• ダイナミック DNS サービス: Nacos は組み込みの DNS サービスを提供しており、Nacos に登録されているサービス インスタンス情報は DNS クエリを通じて取得できます。

• 複数の環境と名前空間: Nacos は、複数の環境 (開発、テスト、実稼働など) と名前空間の管理をサポートし、構成情報のより柔軟な編成と管理を可能にします。

1.2 Nacos のインストール、設定、起動

1. インストール

1. インストールパッケージをダウンロードする

Nacos の GitHub ページには、コンパイルされた Nacos サーバーまたはソース コードをダウンロードするためのダウンロード リンクが提供されています。

GitHub ホームページ: https://github.com/alibaba/nacos

GitHub のリリース ダウンロード ページ: https://github.com/alibaba/nacos/releases

図に示すように:

2. 右側のラベルをクリックして、Tagsより直感的に過去のバージョンを選択します。ここでは、Nacos 1.4.1 を例に挙げます。

3. Windows 環境を選択しzip、Linux の場合はtar.gz圧縮パッケージを選択します。ここでは Windows 環境を例として取り上げます。

4. ダウンロード完了後、漢字の入っていないパスに解凍するとインストールは完了です。

5. Nacosのディレクトリ構造

カタログの説明:

• bin: Nacos を起動するためのスクリプト ファイル。
• conf: Nacos 設定ファイル。

2. 構成

Nacos のデフォルト ポートは 8848 です。コンピュータ上の他のプロセスがポート 8848 を占有している場合は、最初にプロセスを閉じてみてください。

ポート 8848 を占有しているプロセスを閉じることができない場合は、Nacos の conf ディレクトリに入り、構成ファイル内のポートを変更することもできます。
内容を変更します。

ポートを変更します:

3.スタート

Nacos の起動は非常に簡単です。bin ディレクトリに入ります。構造は次のとおりです。

次に、次のコマンドを実行します。

startup.cmd -m standalone

実行後の効果は以下の通りです。

起動ログに記載されているアドレスにアクセスするか、ブラウザにアドレスを入力してhttp://127.0.0.1:8848/nacosNacos コンソールにアクセスします。

デフォルトのアカウントとパスワードは nacos です。入力後:

2. サービスの登録と検出

Nacos のサービス登録は非常に簡単で、Spring Cloud では共通のインターフェース仕様を提供しているため、異なる登録センターを利用する場合でも、コードを変更することなく設定を変更するだけで登録センターの切り替えが完了します。たとえば、Eureka を Nacos に切り替えると次のように動作します。

1. cloud-demo親プロジェクトにspring-cloud-alilbaba管理依存関係を追加します。

<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>

2. 元の Eureka の依存関係をコメント アウトしorder-service、user-serviceNacos クライアントの依存関係を追加します。

<!-- Nacos 客户端依赖 -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

3. ファイルを変更しapplication.yml、Eureka 関連の設定をコメント アウトし、Nacos 関連の設定を追加します。

spring:
  cloud:
    nacos:
	  server-addr: localhost:8848 # Nacos 服务地址

4. 上記の変更手順に従って、2 つのマイクロサービスの構成を同時に変更しuser-service、order-service2 つのマイクロサービスをそれぞれ開始します。

order-serviceこの時点で、1 つのサービス インスタンスと 3 つのuser-serviceサービス インスタンスが起動されます。

5. 開始後、Nacos コンソールのサービス リストに登録されているすべてのサービスを表示できます。

サービスの詳細を確認できます。

上記の手順により、サービス登録センターを Eureka から Nacos に切り替えることができ、サービスの登録と検出が実現しました。Nacos は強力なサービス管理機能を提供し、クラウド ネイティブ アプリケーションの優れたサービス センターです。

3. Nacos サービス階層化モデル

3.1 Nacos のサービス階層型ストレージ モデル

Nacos のサービス階層ストレージ モデルは、その設計アーキテクチャの重要な部分であり、サービス情報をより適切に管理および整理するのに役立ちます。このモデルは、サービス、クラスター、インスタンスの 3 つのレベルに分かれています。

たとえば、Nacos のサービス階層型ストレージ モデルを次の図に示します。

このモデルは 3 つのレベルに分かれています。

1. Service : Service は Nacos の最高レベルであり、抽象的なサービス エンティティを表し、通常は userservice などのサービスの名前によって識別されます。サービスには 1 つ以上のクラスターを含めることができます。

2. クラスター: クラスターはサービスの次のレベルであり、同じサービスの複数のインスタンスのグループ化を表すために使用されます。サービスはさまざまなクラスターに分散でき、各クラスターには 1 つ以上のインスタンスを含めることができます。地理的な場所や展開環境を例に挙げると、サービスには杭州クラスター、上海クラスターなどの複数のクラスターを含めることができます。

3. インスタンス: インスタンスはサービスの最低レベルであり、特定のサービス インスタンスを表し、通常は実行中のサービス ノードに対応します。各クラスターには 1 つ以上のインスタンスを含めることができ、各インスタンスは一意の IP アドレスとポート番号を持ち、サービスのアクセス アドレスを提供します。

このモデルの設計により、Nacos は、特に複数の地理的場所および複数の環境に展開されるシナリオにおいて、サービス情報をより適切に管理および整理できるようになります。サービスは、地理的な場所、展開環境などに基づいて分割できます。各クラスターには複数のインスタンスが含まれており、高可用性と負荷分散の特性を備えています。この構造は、マイクロサービス アーキテクチャにおけるサービス システムの理解と管理にも役立ち、サービスの登録、検出、管理がより直観的かつ制御可能になります。

3.2 クラスタ間のサービス呼び出しの問題

マイクロサービス アーキテクチャでは、通常、サービスは異なるクラスターに分散され、サービス間の呼び出しにはクラスター間の状況が含まれる場合があります。Nacos では、クラスター間でサービスを呼び出すときに考慮する必要がある問題がいくつかあり、重要な問題の 1 つは遅延です。

サービスを呼び出すときの一般原則は、ローカル呼び出しの待ち時間が通常低いため、できる限りローカル クラスター内のサービスを選択することです。クラスタ間の呼び出しは、ローカル クラスタのサービスにアクセスできない場合にのみ考慮されます。

例を挙げて説明しましょう:

2 つのクラスターがあり、1 つは杭州クラスター、もう 1 つは上海クラスターであるとします。杭州クラスターにはサービスがありorder-service、user-service上海クラスターにも同じサービスがあります。order-serviceこのマイクロサービスを呼び出す必要がある場合user-service、最初にローカル クラスター、つまり杭州クラスターのサービスの呼び出しを試みますuser-service。杭州クラスターのサービスにアクセスできない場合にのみ、クラスター間呼び出しが上海クラスターにアクセスするとみなされますuser-service。

通常、ローカル呼び出しはクラスター間呼び出しよりも高速であるため、このような設計により、サービス呼び出しの遅延を効果的に短縮できます。同時に、システムの安定性も向上し、特定のクラスターが使用できない場合にシステム全体が正常に動作しなくなる状況を回避します。

3.3 サービスクラスタの属性設定

Nacos コンソールで特定のサービスの詳細を表示すると、現在のサービスが存在するクラスターが見つかります。DEFAULTこの

時点で、サービスが属するクラスターを変更したい場合は、application.yml次のように変更して構成できます。ファイル：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848 # nacos 服务地址
      discovery:
        cluster-name: name # 集群名称

たとえば、user-serviceサービスの 1 つのインスタンスを杭州クラスターに設定し、他の 2 つのインスタンスを上海クラスターに設定し、再起動した後、Nacos コンソールを再度確認します。

この時点で、サービスのクラスター プロパティは正常に構成されていますuser-service。ただし、order-service最も近いクラスターを呼び出したい場合は、order-serviceサービスのクラスター属性も構成する必要があります。

たとえば、杭州クラスターに構成します。

構成が完了すると、order-serviceポート 8081 とポート 8081 はuser-service同じクラスター内になり、ポート 8082 と 8083 はuser-service上海クラスター内になります。

3.4 負荷分散戦略をクラスター戦略に変更する

order-serviceサービスを再起動し、複数のクエリ順序操作を実行して、user-serviceサービスの呼び出し状況を観察します。

このとき、どうやら同一クラスタへの優先アクセスのポリシーは採用されておらず、ラウンドロビン方式の負荷分散方式が採用されていることが判明しました。もちろん、現在order-service設定されているのはランダムに選択された負荷分散戦略であるため、このアプローチを採用する必要があります。

同じクラスターにアクセスするポリシーを優先する場合は、ファイルを変更し、負荷分散を に設定する必要がありますorder-service。application.ymlこのIRuleルールcom.alibaba.cloud.nacos.ribbon.NacosRuleは、最初にそれ自体と同じクラスター内のサービスを検索します。

# 修改 Ribbon 负载均衡策略
userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 集群优先负载均衡规则

order-serviceサービスを再度再起動し、順序クエリ操作を複数回実行して、user-service呼び出し状況を観察します。

現時点では、ポート 8081 にアクセスしているすべてのインスタンスがuser-service他の 2 つのインスタンスにサービスを提供していないことがわかります。これは、user-serviceポート 8081 上のサービスがorder-service同じクラスター内にあるためです。

この時点で8081user-serviceサービスが停止した場合、再度アクセスするとどうなりますか? 例えば：

現時点では、ポート 8083 上のサービスはクラスター全体でアクセスされますuser-service。

さらに、order-serviceサービス ログにも次の警告が表示されました。

これは、クラスタ間呼び出しが行われることを意味します。つまり、order-serviceサービスを提供したいクラスタは杭州クラスタですが、実際には上海クラスタにアクセスされます。

4. サービスの重みに基づく負荷分散

実際のデプロイメントでは、サーバー デバイスのパフォーマンスが異なる場合があり、パフォーマンスの高いマシンに配置されているインスタンスもあれば、パフォーマンスの低いマシンに配置されているインスタンスもあります。リソースを合理的に使用するために、パフォーマンスの高いマシンがより多くのユーザー要求に耐えられることを期待しています。Nacosでは重み設定機能を提供しており、重みを設定することでアクセス頻度を制御することができ、重みが大きいほど選択される確率が高くなります。

以下は、Nacos コンソールでサービス インスタンスの重みを設定する方法を示しています。

1. Nacos コンソールで、対応するインスタンスを選択し、編集ボタンをクリックして重み設定項目を見つけます。
   

2. インスタンスの重みを設定します。たとえば、ポート 8081 上のサービスの重みを 0.1 に設定します。
   

重みを設定した後、複数のアクセスを実行してuser-serviceサービスの呼び出しを観察します。

user-service複数の訪問の後、ポート 8081 に対応する訪問数が比較的少なく、重み設定が有効であることがわかります。この方法ではリソースを効果的に利用できるため、パフォーマンスの高いマシンがより多くのユーザー要求を処理し、負荷分散を実現できます。

知らせ：

• 重みが 0 に設定されている場合、このサービスは提供されません。
• 実際の運用環境では、サービスをアップグレードする必要がある場合、アップグレード中のインスタンスにトラフィックが誘導されてユーザー エクスペリエンスに影響を与えることを避けるために、サービスの重みを 0 に設定できます。アップグレードの完了後、重みを通常に戻すことができます。価値。
• 同時に、この設定は障害処理にも適しており、障害が発生したサービス インスタンスの重みを 0 に設定することで、インスタンスが一時的にブロックされ、サービス全体の可用性が確保されます。

5. Nacos環境の隔離

5.1 Nacos 環境分離 (名前空間) とは

上記のことから、Nacos は登録センターであることがわかりますが、同時にデータ センターでもあります。したがって、サービスとデータを管理するために、Nacos は環境分離のサポートも提供します。Nacos のサービス ストレージとデータ ストレージの最外層は とnamespace呼ばれるもので、最外部の分離に使用されます。

以下に示すように:

Nacos の外側から内側への階層関係は次のとおりです。

1. 名前空間:最も外側の分離ユニットです。ネームスペースは分離された環境に対応し、独立したサービスと構成情報が含まれます。各名前空間には、一意の名前空間 ID と名前があります。

2. グループ:名前空間の下で、サービスと構成をグループに従って分割できます。異なるグループには、同じサービス名 (Service) または構成名 (Data) の異なるバージョンを含めることができます。グループの役割は、名前空間内でサービスと構成をより詳細に分割することです。

3. サービス/データ (サービス/構成):名前空間とグループの最も基本的な単位です。Service はサービスを表し、Data は構成を表します。サービス名と構成名は、名前空間とグループ内で一意です。

この層構造により、Nacos は非常に柔軟で独立したものになります。名前空間は最大範囲の分離を提供し、グループは分離をさらに改良し、サービスとデータは特定のサービスと構成単位です。

5.2 環境隔離が必要な理由

環境分離は、分散システムおよびマイクロサービス アーキテクチャにおける重要な実践です。Nacos にとって、環境分離を導入する主な理由は次のとおりです。

1. 複数環境のサポート:ソフトウェアの開発および運用保守のプロセスでは、通常、開発環境、テスト環境、本番環境などの複数の環境が存在します。ネームスペースを使用して環境を分離すると、異なる環境のサービスと構成情報を相互に干渉することなく独立して管理できます。

2. チームのコラボレーション:大規模なプロジェクトでは、複数の開発チームが同時にサービスを開発および保守することがあります。各チームは、独自の名前空間でサービスと構成を個別に管理し、相互に分離することができます。

3. バージョン管理:ビジネスが発展するにつれて、サービスと構成には複数のバージョンが存在する場合があります。グループと名前空間の構造を使用すると、バージョン管理をより適切に実行でき、同じ名前空間内のグループを通じてサービスと構成の異なるバージョンを区別できます。

4. 分離リスク:マイクロサービス アーキテクチャでは、サービスは互いに独立しています。環境を分離しないと、1 つのサービスでのエラーが他のサービスに広がり、システム全体に問題が発生する可能性があります。このリスクは、名前空間を使用して環境を分離することで最小限に抑えることができます。

一般に、Nacos の環境分離機能は、複数の環境、複数のチーム、および複数のバージョンを含む複雑なシナリオに柔軟なソリューションを提供し、サービスと構成の管理をより明確かつ制御しやすくします。

5.3 Nacos の環境分離をセットアップする

Nacos コンソールの「名前空間」を見ると、デフォルトの名前空間が提供されていることがわかりますpublic。

現時点では、すべてのサービスもこの名前空間にあります。

Nacos 環境分離の設定は、Nacos コンソールおよび関連する設定ファイルを変更することで完了できます。具体的な手順は次のとおりです。

1. 異なる環境を分離するには、Nacos コンソールで使用できる「名前空間」に名前空間を作成します。
   
   この時点で、dev開発環境用の名前空間を作成します。名前空間 ID もあります。この ID は入力することも、入力しないこともできます。入力しない場合は、UUID を使用して一意の ID が自動的に生成されます。

2. dev[確認] をクリックすると、次の名前空間 ID が自動的に生成されることがわかります。
   

dev現時点ではサービス リストに追加の名前空間がありますが、そこにはサービスが登録されていません。

3. 新しく作成した名前空間を変更しorder-serviceて追加します。application.yml

spring:
  cloud:
    nacos:
      server-addr: localhost:8848 # nacos 服务地址
      discovery:
        namespace: ID # 命名空间 ID

この ID は Nacos の名前空間 ID と一致している必要があることに注意してください。

たとえば、dev名前空間の ID に設定します。

5.4 order-service サービスの再起動

サービス名前空間を設定した後order-service、再起動してコンソール サービス リストを表示します。

devこの時点で、サービスがネームスペースに正常に登録されたことがわかりますorder-service。

このとき再度注文情報にアクセスするとアクセスは成功するでしょうか？

使用可能なインスタンスがないため、結果はエラーであることがわかりましたがuser-service、現在は明らかに 3 つのインスタンスが開始されていますuser-service。

3 つのインスタンスは名前空間内にuser-service存在し、名前空間内に存在することがわかります。名前空間は分離されているため、他の名前空間のサービスにアクセスすることはできません。publicorder-servicedevuser-service

user-serviceこの時点で、サービスも同じ方法でdev名前空間に登録されます。

サービスを再起動し、Nacos コンソールを表示します。

すべてのサービスが名前空間にあることがわかりdev、注文情報が再び提供されると、通常どおりにアクセスできるようになります。

6. Nacos登録センターの原則の分析

6.1 Nacos登録センターの実行プロセス

Nacos (Naming and Configuration Service) は、マイクロサービス アーキテクチャの構築と管理に使用されるオープンソースのサービス検出および構成管理プラットフォームです。マイクロサービス アーキテクチャでは、サービスの登録と検出が重要であり、Nacos はサービス登録センターとしてこの重要なタスクを引き受けます。以下では、Nacos 登録センターの実行プロセスを詳細に分析し、その背後にある原則を詳細に説明します。

Nacos 登録センターの実行プロセスの概要:

上図のプロセスの詳細な説明:

1. サービスプロバイダーの登録:サービスプロバイダーは、開始時にサービス情報を Nacos 登録センターに登録します。これには、サービス名、IP アドレス、ポート番号などの重要な情報が含まれます。登録されたインスタンスは一時インスタンスまたは非一時インスタンスにすることができ、実際のニーズに応じて登録タイプを選択します。

2. 健康診断：

   • 一時的なインスタンスの場合、Nacos はハートビート検出メカニズムを使用します。登録された一時インスタンスは、正常に実行されていることを証明するために、定期的にハートビート パケットを Nacos 登録センターに送信します。ハートビート パケットが時間どおりに到着しない場合、Nacos はインスタンスを削除して、登録センターに正常なサービス インスタンスのみが存在するようにします。
   • 一時的ではないインスタンスの場合、Nacos はインスタンスに積極的にクエリを実行して、その健全性ステータスを確認します。異常が見つかった場合、Nacos はインスタンスの健全性ステータスを更新し、インスタンスが正常に戻った後にステータスを復元します。

3. サービス利用者は、定期的に Nacos 登録センターから最新のサービス リストを取得します。このサービス リストには、利用可能なサービス インスタンスの情報が含まれており、消費者は現在利用可能なサービスを理解できます。

4. 例外処理とサービス プッシュ: Nacos 登録センターには例外処理メカニズムがあります。登録センターは、例外が発生したり動作を停止したりすると、更新されたサービス情報をサービス利用者に積極的にプッシュします。このようにして、消費者は登録センターのステータスの変化を即座に認識し、システムの安定性を確保するために対応する調整を行うことができます。

5. 負荷分散:サービス コンシューマはサービス リストを取得した後、キャッシュされたサービス リストに対して負荷分散を実行します。これにより、リクエストをさまざまなサービス インスタンスに均等に分散できるようになり、単一障害点が回避されます。

6.2 一時インスタンスと非一時インスタンスの設定

Nacos コンソールでインスタンスの詳細を確認します。

以前に登録されたインスタンスがデフォルトで一時インスタンスであることがわかります。

一時的ではないインスタンスに変更する場合は、application.ymlファイルを変更して設定できます。

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

たとえば、order-serviceサービスを一時的ではないインスタンスになるように変更します。

サービスを再起動し、Nacos コンソールを再度表示します。

この時点で、サービスはorder-service一時的ではないインスタンスに正常に設定されます。

この時点でサービスを停止するとorder-service、健全性ステータスが変化することがわかりますfalseが、サービス リストからは削除されません。

サービスを再度再起動するorder-serviceと、健全性ステータスが次のように変化していることがわかりますtrue。

まとめ：ナコスとエウレカの違い

Nacos と Eureka は、2 つの一般的なサービス登録および検出ツールですが、いくつかの違いがあり、主に次の点に反映されます。

1. データ保存方法：

   • Nacos: Nacos はサービス登録センターであるだけでなく、構成管理をサポートするプラットフォームでもあります。データベースのような方法を使用してサービスと構成情報を保存し、名前空間、グループ、サービス、インスタンスなどのマルチレベルのストレージ構造を提供し、よりきめ細かい管理をサポートします。
   • Eureka: Eureka は主に単純なサービスの登録および検出システムであり、そのサービス情報は比較的単純で簡単なグローバル レジストリに保存されます。

2. 複数環境の分離:

   • Nacos: Nacos は、名前空間とグループの概念を提供し、複数の環境、複数のチーム、および複数のバージョンの分離と管理をサポートします。
   • Eureka: Eureka は複数環境の分離の概念を直接サポートしていないため、他の手段を通じて実装する必要があります。

3. 構成管理:

   • Nacos: Nacos は構成センターとして、動的構成、構成バージョン管理、構成変更の監視などの機能をサポートします。
   • Eureka: Eureka は主にサービスの登録と検出に焦点を当てており、明示的な構成管理機能はありません。

4. サービスの重みとフロー制御:

   • Nacos: Nacos は重み設定によるフロー制御をサポートしており、サービスのパフォーマンスに応じて異なる重みを設定できます。
   • Eureka: Eureka は、ネイティブ形式ではウェイト設定と同様の機能を提供しないため、他のコンポーネント (リボンなど) を利用して実装する必要があります。

5. 互換性:

   • Nacos: Nacos は Spring Cloud のネイティブ サポートを提供し、Spring Cloud アプリケーションとより適切に統合します。
   • Eureka: Eureka は Netflix によって開発され、Spring Cloud とも自然に統合されています。

全体として、Nacos は Eureka よりも包括的で、より多くの機能をサポートし、特に構成管理と複数環境の分離の点でより柔軟です。どちらを使用するかは、特定のニーズとシナリオによって異なります。