ユーレカの最初の理解

ユーレカとは？

NetflixがEurekaを設計したとき、それはAPの原則に従いました（CAPの記事で後述）。

Eurekaは、Netflixのサブモジュールであり、コアモジュールの1つです。Eurekaは、クラウド中間層サービスの検出とフェイルオーバーを実現するためにサービスを見つけるために使用されるRESTベースのサービスです。サービスの登録と検出はマイクロサービスにとって非常に重要です。サービスの検出と登録では、サービスを使用するだけで済みます。識別子。サービスによって呼び出される構成ファイルを変更せずにサービスにアクセスできます。機能は、ZookeeperなどのDubboの登録センターに似ています。

ユーレカの原理の紹介

ユーレカの基本的なアーキテクチャ

SpringCloudは、サービスの登録と検出を実装するためにNetFlixによって開発されたEurekaモジュールをカプセル化します（Zookeeperと比較して）。
EurekaはCSアーキテクチャ設計を採用し、EurekaServerはサービス登録機能のサーバーとして機能し、サービス登録センターです。
およびシステム内の他のマイクロサービス。Eurekaを使用しているクライアントはEurekaServerに接続し、ハートビート接続を維持します。このようにして、システムメンテナはEurekaServerを使用して、システム内の各マイクロサービスが正常に実行されているかどうかを監視できます。SpringCloudの他のモジュール（Zuulなど）は、EurekaServerを使用して、システム内の他のマイクロサービスを検出し、関連するロジックを実行できます。
Dubboアーキテクチャとの比較：
Dubbo構造図：

Eurekaアーキテクチャ図：

Eurekaには、EurekaサーバーとEurekaクライアントの2つのコンポーネントが含まれています。
Eureka Serverは、サービス登録サービスを提供します。各ノードが起動すると、EurekaServerに登録されます。これにより、Eureka Serverのサービスレジストリは、利用可能なすべてのサービスノードの情報を登録し、サービスノードの情報をインターフェイスで直感的に確認できます。

重要なポイントは次
のとおりです。Eurekaクライアントは、EurekaServerの対話を簡素化するために使用されるJavaクライアントです。クライアントには、ポーリングロードアルゴリズムを使用するロードバランサーも組み込まれています。アプリケーションの起動後、ハートビートがEurekaServerに送信されます（デフォルトの期間は30秒です）。Eureka Serverが複数のハートビートサイクル内にノードのハートビートを受信しない場合、EurekaServerはサービスレジストリからサービスノードを削除します（デフォルトのサイクルは90秒です）。

ユーレカのサービス登録と発見

一般化する

フロントエンドとバックエンドが分離されているアーキテクチャでは、サービスレイヤーが複数のマイクロサービスに分割され、マイクロサービスの情報を管理する必要があるため、SpringCloudはこの情報を管理するためのサービスレジストリを提供します。

それで問題は、なぜマイクロサービスにレジストリが必要なのかということです。

マイクロサービスの数が多いため、リモート呼び出しを行うにはサーバーのIPアドレスとポート番号を知る必要があり、レジストリはこれらのサーバーのポートとIPの管理に役立ちます。
マイクロサービスは、ステータスをリアルタイムで報告する必要があります。これらのステータスはレジストリによって一律に管理され、問題のあるサービスはサービスリストから削除されるため、クライアントは呼び出し可能なサービスを取得できます。

ユーレカサーバーの構築

1.Mavenプロジェクトを作成しますspringcloud-eureka-7001

パッケージ構造は次のとおりです。com.olodou.springcloud
これはEurekaのサーバーです。

2.Pom依存関係を追加します

			<!--SpringCloud的依赖-->
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>Hoxton.SR8</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
		    <!--eureka服务依赖-->
		    <dependency>
		        <groupId>org.springframework.cloud</groupId>
		        <artifactId>spring-cloud-starter-eureka-server</artifactId>
		        <version>1.4.6.RELEASE</version>
		    </dependency>

yml構成ファイルでの構成

server:
  port: 7001 # 服务端口

#Eureka的配置
eureka:
  instance:
    hostname: localhost   #Eureka服务端的实例名称
  client:
    register-with-eureka: false   #表示是否向Eureka注册中心注册自己
    fetch-registry: false   # fetch-registry如果为false,则表示自己为注册中心
    server-url:  # 监控页面
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

register-with-eureka：他のサービスから呼び出された場合、Eurekaに登録する必要があることを示します
fetch-registry：Eurekaから呼び出されるターゲットサービスを検索するときは、trueに設定する必要があります
server-url.defaultZone：Eurekaサービスアドレスの高可用性ステータスを構成および報告して、相手のアドレスを構成し、スタンドアロン状態で構成します。

クラスを開始

//启动之后访问: http://localhost:7001/
@SpringBootApplication
@EnableEurekaServer //EnableEurekaServer服务端的启动类,可以接受别人的注册类
public class EurekaServer_7001 {
    
    
    public static void main(String[] args) {
    
    
        SpringApplication.run(EurekaServer_7001.class,args);
    }
}

@EnableEurekaServerは、このサービスをEurekaサービスとして識別するために、スタートアップクラスで@EnableEurekaServerを使用する必要があります。

EurekaServerを起動してアクセスします。http：// localhost：7001 /
ここに写真の説明を挿入
しばらくすると、次のメッセージがページに表示されます。

これはEurekaの自己保護メカニズムです。このメカニズムを紹介します。

ユーレカの自己防衛メカニズム

一文の要約：特定の瞬間に特定のマイクロサービスが利用できなくなった場合、eurekaはすぐにはクリーンアップせず、マイクロサービスの情報を保存します。

デフォルトでは、EurekaServerが特定の期間内にマイクロサービスインスタンスのハートビートを受信しない場合、EurekaServerはインスタンスからログオフします（默认90秒)。ただし、ネットワークパーティションに障害が発生すると、マイクロサービスとユーレカは正常に通信できなくなります。マイクロサービス自体は実際には正常であり、現時点ではサービスをログオフしないため、上記の動作は非常に危険になる可能性があります。Eurekaは、自己保護メカニズムによってこの問題を解決します。EurekaServerノードが短期間に多くのクライアントを失うと（ネットワークパーティション障害が発生する可能性があります）、ノードは自己保護モードになります。このモードになると、EurekaServerはサービスレジストリ内の情報を保護し、サービスレジストリ内のデータを削除しなくなります（つまり、マイクロサービスからログアウトしません）。ネットワーク障害が回復すると、EurekaServerノードは自動的に自己保護モードを終了します。
自己保護モードでは、EurekaServerはサービスレジストリ内の情報を保護し、サービスインスタンスをログアウトしなくなります。受信したハートビートの数が(5s检测一次)しきい値を超えると、EurekaServerノードは自動的に自己保護モードを終了します。その設計哲学は、正常である可能性のあるサービスインスタンスを盲目的にキャンセルするのではなく、間違ったサービス登録情報を保持することです。一言で言えば：生きるよりも死ぬ方が良い
要約すると、自己保護モードは、ネットワークの異常に対処するための安全保護手段です。そのアーキテクチャ哲学は、健全なマイクロサービスを盲目的にログオフするのではなく、すべてのマイクロサービスを同時に保持することを好むことです（正常なマイクロサービスと不健全なマイクロサービスの両方が保持されます）。自己保護モードを使用すると、Eurekaクラスターをより堅牢で安定させることができます
SpringCloudでは、eureka.server.enable-self-preservation = false無効化された自己保護モードを使用できます[自己保護メカニズムをオフにすることはお勧めしません]

自己保護メカニズムの出力情報：
ここに写真の説明を挿入

ユーレカのサービス登録

ステップ1：次のEureka依存関係と監視依存関係をサービスプロバイダープロバイダーのpomファイルに追加する必要があります。

<!--引入eureka的依赖-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
    <version>1.4.6.RELEASE</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

ステップ2：サービスプロバイダーのyml構成ファイルを同時に構成します

# Eureka的配置  配置服务注册到哪里
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka/
  instance:
    instance-id: springcloud-provider-dept-8001   # 修改eureka上的默认描述信息

service-url.defaultZone：登録センターの住所を示します
instance.instance-id：以下に示すように、アクセスしたEurekaページのステータス名：

ステップ3：サービスプロバイダーのスタートアップクラスでEurekaを有効にするための注釈を追加します

@SpringBootApplication
@EnableEurekaClient  //在服务启动后自动注册到Eureka中。
public class DeptProvider_8001 {
    
    
    public static void main(String[] args) {
    
    
        SpringApplication.run(DeptProvider_8001.class,args);
    }
}

@EnableEurekaClient：サービスの開始後に自動的にEurekaに登録します。

ステップ4：テスト。最初にEureka7001を起動してから、サービスプロバイダーを起動します。この時点で、Eurekaページに登録情報が表示されます。
ここに写真の説明を挿入

ユーレカのサービスの発見

Eurekaページでステータスを確認できます。つまり、上の図にハイパーリンクがありますが、過去には何もなかったため、サービスプロバイダーで次のように構成する必要があります。
ステップ1：パッケージをインポートし、監視情報のパッケージをインポートします。

<!--actuator完善监控信息-->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

ステップ2：yml構成ファイルに情報構成を追加する

# Eureka的配置  配置服务注册到哪里
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka/
  instance:
    instance-id: springcloud-provider-dept-8001   # 修改eureka上的默认描述信息

#info配置
info:
  app.name: Oldou's SpringCloud
  company.name: https://mp.csdn.net/console/home

app.name：自分で設定したプロジェクト名
company.name：会社名

ステップ3：コントローラーに出力情報メソッドを追加します

//提供Restful服务
@RestController
public class DeptController {
    
    

    //获取一些配置的信息,得到具体的微服务
    @Autowired
    private DiscoveryClient client;
		.....中间其他方法我省略了....
    //注册进来的微服务~ 获取一些消息
    @GetMapping("/dept/discovery")
    public Object discovery(){
    
    
        //获取微服务列表的清单
        List<String> services = client.getServices();
        System.out.println("discovery----->service:-->"+services);

        //得到一个具体的微服务信息，通过具体的微服务id，applicationName
        List<ServiceInstance> instances = client.getInstances("SPRINGCLOUD-PROVIDER-DEPT");
        for (ServiceInstance instance : instances) {
    
    
            System.out.println(
            		//获取主机名
                    instance.getHost()+"\t"+
                    //获取端口
                    instance.getPort()+"\t"+
                    //获取完整的IP
                    instance.getUri()+"\t"+
                    //获取服务名
                    instance.getServiceId()
            );
        }
        return this.client;
    }
}

ステップ4：次に、スタートアップクラスに@EnableDiscpveryClient注釈を追加して、サービスディスカバリーを開始し、プロジェクトを開始できるようにする必要があります。サービスが登録された後、登録http://localhost:8001/dept/discovery可能なマイクロサービス情報にアクセスし、Eurekaページの[ステータス]の下のリンクをクリックすると、出力されます。構成ファイルで構成された情報。

同時に、コンソールは次の情報を出力します。
ここに写真の説明を挿入
上記は、登録済みのIPアドレス、ポート番号、完全なURIアドレス、および登録が必要なサービスの名前です。

高可用性環境の構築

Eureka Serverの高可用性環境では、相互に登録する2つのEurekaサーバーを展開する必要があります。このマシンで3つのEurekaを起動する場合は、設定が異なる3つのEurekaサーバーポートに注意する必要があります。ここでは、ポート7001〜7003を使用し、次の図に従ってクラスターモデルを構築し、
ここに写真の説明を挿入
新しいspringcloud-eureka-7002、springcloud-eureka-7003を作成します。Mavenの依存関係のコピーを作成します。
次に、application.ymlファイルを個別にコピーし、サーバーポート
を変更し、メインの起動クラスをコピーして名前を変更する必要があります。次に、これがクラスターであるように見せやすくするために、ローカルコンピューターに移動して、ドメイン名のマッピングを変更します（ C：\ Windows \ System32 \ drivers \ etc \ hosts）、このファイルは特に重要であるため、このファイルを簡単に削除しないでください。ここで、実際にはlocalhostである3つのドメインマッピングを追加しました。
ここに写真の説明を挿入
次に、各Eurekaサーバーに移動して、構成ファイルを変更します。
例：7001サービスservice-url.defaultZoneは7002および7003サービスを登録する必要があります

server:
  port: 7001

#Eureka的配置
eureka:
  instance:
    hostname: eureka7001.com #Eureka服务端的实例名称
  client:
    register-with-eureka: false  #表示是否向Eureka注册中心注册自己
    fetch-registry: false  # fetch-registry如果为false,则表示自己为注册中心
    service-url: # 监控页面 http://${eureka.instance.hostname}:${server.port}/eureka/
      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
      #单机配置：http://${eureka.instance.hostname}:${server.port}/eureka/
      #集群配置：需要将另外两个注册中心的地址也关联进来，如上所示

7002サービスservice-url.defaultZoneを登録する必要があります7001および7003サービス
7003サービスservice-url.defaultZoneを登録する必要があります7001および7002サービス

設定が完了したら、1つずつ起動します。最初にレジストリを起動してから、プロバイダーを起動します。
！[ここに画像の説明を挿入]（https://img-blog.csdnimg.cn/20200929000301516.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNz80xMdIFF_color_center=70FF_ ここに写真の説明を挿入
まとめ
1.実際の使用では、Eurekaサーバーは高可用性を実現するために少なくとも2つのサーバー（ここでは3つ作成）を展開します
。2。2つのEurekaサーバーは相互に登録します（つまり、service-url.defaultZoneに他の2つの登録を追加します）サービスアドレス）
3。マイクロサービスは登録するために2つのEurekaサーバーに接続する必要があり、1つのEurekaが停止しても、サービスの登録と検出には影響しません
。4。マイクロサービスは定期的にEurekaサーバーにハートビートを送信します（5秒ごとに送信））、自身のステータスを報告します
。5。マイクロサービスはレジストリからサービスアドレスを取得し、RESTfulな方法でリモートコールを開始します。

Eurekaのクラスターの利点を以下に説明します。

ユーレカのCAP原理とZookeeperとの比較

CAPの原則

CAP定理としても知られるCAPの原則は、分散システムでは、一貫性（一貫性）、可用性（可用性）、およびパーティションの許容範囲（パーティションの許容範囲）に互換性がないという事実を指します。

一貫性（C）：分散システム内のすべてのデータバックアップが同時に同じ値を持つかどうか。（最新データの同じコピーにアクセスするすべてのノードに相当）
可用性（A）：クラスター内の一部のノードに障害が発生した後、クラスター全体がクライアントの読み取りおよび書き込み要求に応答できるかどうか。（データ更新の高い可用性）
パーティションフォールトトレランス（P）：実際の効果では、パーティションは通信の制限時間に相当します。システムが制限時間内にデータの整合性を達成できない場合は、パーティションが発生したことを意味し、現在の操作はCとAの間で選択する必要があります。

RDBMS（Mysql、Oracle、sqlServer）リレーショナルデータベース--------> ACID

NoSQL（Redis、Mongodb）非リレーショナルデータベース----------> CAP

酸

A（アトミシティ）：アトミック性、
C（一貫性）：一貫性
I（分離）：分離
D（耐久性）：耐久性

レジストリとして、EurekaはZookeeperよりどのように優れていますか？

分散システムではパーティションの障害許容度Pを保証する必要があるため、AとCの間でのみトレードオフを行うことができます。

ZookeeperはCPを保証します。
ユーレカはAPを保証します。

動物園の飼育係はCPを保証します

レジストリからサービスリストを照会する場合、レジストリが数分前に登録情報を返すことは許容できますが、サービスがダウンしているときにサービスが直接利用できないことを受け入れることはできません。つまり、サービス登録機能には一貫性よりも多くの可用性が必要です。。しかし、Zookeeperはそのような状況になり、ネットワーク障害のためにマスターノードが他のノードとの接続を失うと、残りのノードがリーダーを再選します。問題は、リーダーの選出に時間がかかりすぎ（30〜120秒）、選出期間が長くなることです。動物園飼育係の統合は利用できず、選挙期間中の登録サービスの麻痺につながります。クラウド展開環境では、ネットワーク上の理由によるZKクラスター内のマスターノードの喪失は比較的大きなイベントです。サービスは最終的には返信できますが、登録が長期間利用できなくなるような長期的な選挙イベントは耐えられません。

ユーレカはAPを保証します

Eurekaはこの問題を理解しているため、設計時には使いやすさを優先します。Eurekaの各ノードは同じです。複数のノードに障害が発生しても、通常のノードの動作には影響しません。残りのノードは引き続き登録およびクエリサービスを提供できます。Eurekaクライアントが特定のEurekaに登録するときに、接続が見つかった場合失敗した場合、自動的に別のノードに切り替わります。ユーレカが残っている限り、登録サービスの可用性は維持できますが、見つかった情報は最新のデータではない可能性があります。また、ユーレカには自己保護メカニズムがあります。ノードの85％以上が（5秒ごとにチェック）15分以内に正常な心拍を持っていない場合は、ユーレカは、クライアントとレジストリの間でネットワーク障害があると思いますし、次のような状況が発生します。
（ 1）Eurekaは、長い間ハートビートを受信していないために期限切れになるはずのサービスを登録リストから削除しなくなりました。
（2）Eurekaは、新しいサービス登録とクエリ要求を引き続き受け入れることができますが、他のノードと同期されません（つまり、保証されます）。現在のノードは引き続き使用可能です）;
（3）ネットワークが安定すると、現在のインスタンスの新しい登録情報が他のノードに同期されます。

したがって、Eurekaは、Zookeeperのような登録サービス全体を麻痺させることなく、ネットワーク障害のために一部のノードが接続を失う状況に対処できます。

ZookeeperとEurekaの違いのまとめ[キーポイント]：

動物園の飼育係はcp（一貫性）を保証します。
eurekaはap（可用性）を保証します。
動物園の飼育係の登録サービスは、リーダーの選挙中に麻痺し、期間中は利用できませんでした。
eurekaの各ノードは同等の関係にあります。1つある限り、サービスは保証され、照会されたデータは最新ではない可能性があります。これにより、ネットワーク障害による一部のノードの損失に十分に対処できます。
Zookeeperには、リーダー、フォロワー、オブザーバーの3つの役割がありますが、eurekaノードは同じです。
Zookeeperは（脳の分裂を避けるために）半減期の原則を採用し、eurekaはパーティションの問題を解決するために自己保護メカニズムを採用しています。
Eurekaは本質的にプロジェクトです。Zookeeperは単なるプロセスです。ZooKeeperはCPに基づいており、高い可用性を保証しません。zookeeperがマスターを選択している場合、またはZookeeperクラスター内のマシンの半分以上が使用できない場合、データは使用できません。EurekaはAPに基づいており、すべてのマシンがハングアップしている場合でも、ローカルにキャッシュされたデータを取得できるため、高い可用性を保証できます。登録センターとして、構成は頻繁に変更されることはなく、リリース（新しいバージョンがリリースされる）とマシンのみが失敗します。頻繁に変更されない構成の場合、CPは適切ではなく、APは一貫性を犠牲にして、古いデータを返すこととデータをキャッシュすることの両方で問題が発生したときに可用性を確保できます。したがって、理論的には、Eurekaは登録センターとしてより適しています。実際の環境では、クラスターが十分に大きくなく、レジストリとして使用されるマシンの半分以上がダウンしている場合は基本的にないため、ほとんどのプロジェクトでZooKeeperを使用できます。したがって、実際には大きな問題はありません。

これは私が最初にユーレカを学んだときに得た知識です。それがあなたに役立つなら、それを好きでサポートすることを忘れないでください。記事に修正が必要な何か不適切なものがあれば、私を訂正してください。どうもありがとうございます！

参考記事：https：//www.jianshu.com/p/e2e3ded1f54a

Eurekaの最初の理解[サービスの登録と発見、高可用性クラスター、自己保護メカニズム、Zookeeperとの比較]