[ダークホース プログラマー] - マイクロサービスの完全なセット - 実践パート 1

目次：

1. マイクロサービス テクノロジー スタックのチュートリアル 1
2. マイクロサービス テクノロジー スタックのチュートリアル 2
3. マイクロサービスとサービス アーキテクチャの進化を理解する
4. マイクロサービスを理解する - マイクロサービス テクノロジの比較
5. マイクロサービスを理解する - SpringCloud
6. サービス分割ケースのデモ
7. サービス分割 - サービスのリモート呼び出し
8. Eureka プロバイダーとコンシューマー
9. エウレカ-エウレカ原理分析
10. Eureka-エウレカサービスの構築
11. エウレカサービス登録
12. Eurekaサービスの発見
13. リボン負荷分散の原理
14. リボン負荷分散戦略
15. リボン - ハングリーロード
16. Nacos-Nacos の理解とインストール
17. Nacos-クイックスタート
18. Nacosサービスのマルチレベルストレージモデル
19. Nacos-NacosRule 負荷分散
20. サービスインスタンスのNacos-weight設定
21. ナコス-環境隔離
22. ナコス・ナコスとエウレカの比較

1. マイクロサービス テクノロジー スタックの概要 1

マイクロサービス フレームワークの知識を学ぶ必要があるのはなぜですか?

どのようなマイクロサービスの知識を学ぶ必要がありますか?

2. マイクロサービス テクノロジー スタック 2 の概要 

どのようなマイクロサービスの知識を学ぶ必要がありますか?

 

学習パス

3. マイクロサービスとサービス アーキテクチャの進化を理解する

モノリシック アーキテクチャ:開発のためのすべてのビジネス機能を 1 つのプロジェクトに集中させ、パッケージとして展開します。

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

• アドバンテージ：
  • シンプルなアーキテクチャ
  • 導入コストが低い
• 欠点:
  • 高度な結合 (維持とアップグレードが困難)

分散アーキテクチャ

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

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

アドバンテージ：

• サービス結合を減らす

• サービスのアップグレードと拡張に貢献

欠点:

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

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

• サービス分割の粒度を定義するにはどうすればよいですか?

• サービス間で通話するにはどうすればよいですか?

• サービス呼び出し関係を管理するにはどうすればよいですか?

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

マイクロサービス アーキテクチャ機能:

• 単一の責任: マイクロサービスはより小さな粒度に分割されており、各サービスは固有のビジネス機能に対応し、単一の責任を実現します。

• 自律性: 独立したチーム、独立したテクノロジー、独立したデータ、独立した展開と配信

• サービス指向: サービスは、言語やテクノロジーに依存しない、統一された標準インターフェイスを提供します。

• 強力な分離: 問題の連鎖を避けるために、サービス コールは分離され、耐障害性があり、ダウングレードされる必要があります。

 

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

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

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

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

要約:

• モノリシックアーキテクチャの特徴は何ですか?
  • シンプルで便利、高度に結合されているが拡張性が低く、小規模なプロジェクトに適しています。例: 学生管理システム
• 分散アーキテクチャの特徴は何ですか?
  • 疎結合でスケーラビリティに優れていますが、アーキテクチャが複雑で困難です。 JD.com、Taobao などの大規模なインターネット プロジェクトに適しています。
• マイクロサービス: 優れた分散アーキテクチャ ソリューション
  • 利点: 分割の粒度が小さく、サービスの独立性が高く、結合度が低い
  • 短所: アーキテクチャが非常に複雑であるため、運用、メンテナンス、監視、展開がより困難になります。

4. マイクロサービスを理解する - マイクロサービス テクノロジの比較

マイクロサービスの実装には技術的なフレームワークが必要です。世界中のインターネット企業が独自のマイクロサービス実装テクノロジを積極的に試しています。中国で最もよく知られているのは、SpringCloud と Alibaba の Dubbo です。

マイクロサービステクノロジーの比較:

ビジネスニーズ

5. マイクロサービス - SpringCloud を理解する

• SpringCloud は現在、中国で最も広く使用されているマイクロサービス フレームワークです。
• 公式サイトアドレス：https://spring.io/projects/spring-cloud
• SpringClaud は、さまざまなマイクロサービス機能コンポーネントを統合し、SpringBoot に基づいてこれらのコンポーネントの自動アセンブリを実装するため、すぐに使用できる優れたエクスペリエンスを提供します。

6. サービス分割ケースのデモ

サービスを分割する際の注意点

1. 単一の責任: 異なるマイクロサービス、同じビジネスを繰り返し開発しない
2. データの独立性: 他のマイクロサービスのデータベースにアクセスしません。
3. サービス指向: 他のマイクロサービスが呼び出すためのインターフェイスとしてビジネスを公開します。

サービス分割例

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

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

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

• user-service: ユーザー関連のビジネスを担当するユーザー マイクロサービス

必要とする：

• 注文マイクロサービスとユーザー マイクロサービスは両方とも独自のデータベースを持ち、互いに独立している必要があります。

• 注文サービスとユーザー サービスは両方とも、Restful インターフェイスを外部に公開します。

• オーダー サービスがユーザー情報をクエリする必要がある場合、ユーザー サービスの Restful インターフェイスのみを呼び出すことができ、ユーザー データベースにクエリを実行することはできません。

SQL ステートメントをインポートします。

まず、事前授業資料で提供される cloud-order.sql と cloud-user.sql を mysql にインポートします。  

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

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

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

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

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

7. サービス分割 - サービスのリモート呼び出し

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

ID に基づいて注文をクエリすると、図に示すように、戻り値は Order オブジェクトになります: (user は null です)

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

クエリ結果は次の図に示されています。

order-serviceのIDに基づく注文クエリ業務を変更する オーダークエリ時にオーダーに含まれるuserIdを元にユーザー情報をクエリし、まとめて返す必要があります。​  

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

一般的な手順は次のとおりです。

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

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

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

8.Eureka - プロバイダーとコンシューマー 

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

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

ただし、サービス プロバイダーとサービス利用者の役割は絶対的なものではなく、ビジネスに対して相対的なものです。サービス A がサービス B を呼び出し、サービス B がサービス C を呼び出す場合、サービス B の役割は何ですか?

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

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

要約:

サービス呼び出し関係

• サービス プロバイダー: 他のマイクロサービスが呼び出すためのインターフェイスを公開します。
• サービスコンシューマ: 他のマイクロサービスによって提供されるインターフェイスを呼び出します。
• プロバイダーとコンシューマーの役割は実際には相対的です
• サービスは、同時にサービスプロバイダーとサービスコンシューマーの両方になることができます

9.エウレカ-エウレカ原理分析

図に示すように、サービス プロバイダーのユーザー サービスが複数のインスタンスをデプロイする場合:

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

• order-service がリモート呼び出しを開始するとき、ユーザー サービス インスタンスの IP アドレスとポートをどのようにして知るのでしょうか?

• ユーザーサービスインスタンスのアドレスが複数ありますが、order-service を呼び出すときにどのように選択すればよいですか?

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

これらの問題は、Spring Cloud の登録センターを使用して解決する必要があります。最もよく知られている登録センターは 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 サーバーへのリクエストを開始し、ハートビートと呼ばれる独自のステータスを報告します。

• 一定期間ハートビートが送信されない場合、eureka-server はマイクロサービス インスタンスに障害があるとみなし、そのインスタンスをサービス リストから削除します。

• order-service がサービスをプルすると、障害のあるインスタンスを削除できます。

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

10.Eureka-エウレカサービスの構築

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

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

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

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

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

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

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

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

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

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

次の結果が表示されれば、成功したことがわかります。

11.エウレカサービス登録

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

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

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

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

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

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

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

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

ただし、最初のポートはポート 8081、2 番目のポートはポート 8082 です。 2 つのユーザー サービス インスタンスを開始します。

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

12.Eurekaサービスディスカバリー

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

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

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

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

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

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

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

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

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

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

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

13.リボン負荷分散原理

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

送信したリクエストは明らかにhttp://userservice/user/1 ですが、なぜhttp://localhost:8081?  

なぜサービス名を入力するだけでアクセスできるのでしょうか？また、事前に IP とポートを取得する必要があります。

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

私たちはソースコードの追跡を実施します。

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

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

ここの「this.loadBalancer」は「LoadBalancerClient」タイプです。引き続き追跡しましょう。

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

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

• getLoadBalancer(serviceId): サービス ID に基づいて ILoadBalancer を取得します。ILoadBalancer はサービス ID を取得して eureka からサービス リストを取得し、保存します。

• getServer(loadBalancer): 組み込みの負荷分散アルゴリズムを使用して、サービス リストから 1 つを選択します。この例では、ポート 8082 のサービスが取得されていることがわかります。

解放された後、再度アクセスして追跡したところ、8081 を取得していることがわかりました。

案の定、負荷分散は達成されました。

先ほどのコードでは、負荷分散のための「getServer」メソッドを通じてサービスが取得されていることがわかります。

引き続きフォローアップしてみましょう:

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

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

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

これが投票の意味ではないでしょうか？この時点で、負荷分散プロセス全体を明確に理解できました。

要約:

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 を取得して、実際のリクエストを開始します。

14.リボン負荷分散戦略 

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

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

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

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

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

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

15.リボンがいっぱいの読み込み

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

プロジェクトの開始時にハングリー ローディングが作成され、最初の訪問の時間が短縮されます。次の構成を通じてハングリー ローディングを有効にします。

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

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

[ダークホース プログラマー] - 完全なマイクロサービス - Nacos インストール ガイド - CSDN ブログ

17.Nacos-クイックスタート 

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

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

• 依存関係が違う

• サービスアドレスが異なります

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>

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

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

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

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

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

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

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

18.Nacosサービスの多層ストレージモデル

たとえば、Aサービスには複数のインスタンスを含めることができます。ユーザー サービスには次のものが含まれます。

• 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 は、同じコンピュータ ルーム内のインスタンスを クラスタに分割します。

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

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

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

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 コンソールを再度確認します。

19.Nacos-NacosRule 負荷分散

デフォルトの `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 # 负载均衡规则 

20.サービスインスタンスのNacos-weight設定

実際の展開では、次のシナリオが発生します。

• サーバー機器の性能にはばらつきがあり、インスタンスが配置されているマシンの性能が良いものもあれば、性能が悪いものもあり、性能の良いマシンにはより多くのユーザーのリクエストを受け入れられることが期待されます。
• ただし、デフォルトでは、NacosRule は同じクラスター内でランダムに選択され、マシンのパフォーマンスの問題は考慮されません。
• そこでNacosではアクセス頻度を制御するための重み設定を用意しており、重みが大きいほどアクセス頻度が高くなります。
• nacos コンソールで、user-service のインスタンス リストを見つけて、[編集] をクリックして重みを変更します。

ポップアップ編集ウィンドウで重みを変更します。

注: 重みを 0 に変更すると、インスタンスにはアクセスできなくなります。

21.ナコス - 環境隔離

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

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

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

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

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

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

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

たとえば、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 が見つからず、コンソールにエラーが報告されます。

22.ナコス・ナコスとエウレカの比較

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

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

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

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

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

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

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

  • どちらもサービスの登録とサービスのプルをサポートしています。

  • すべてのサービス プロバイダーの健全性検査のハートビート方式をサポートします。

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

  • Nacos は、サーバーがプロバイダーのステータスをアクティブに検出することをサポートします。一時インスタンスはハートビート モードを採用し、非一時インスタンスはアクティブ検出モードを採用します。

  • 異常なハートビートのある一時的なインスタンスは削除されますが、一時的ではないインスタンスは削除されません。

  • Nacos はサービス リスト変更のメッセージ プッシュ モードをサポートしており、サービス リストはよりタイムリーに更新されます。

  • Nacos クラスターはデフォルトで AP モードを使用します。クラスター内に非一時インスタンスがある場合は CP モードが使用され、Eureka は AP モードを使用します。