第三の物品の春クラウド列で、2つの記事の内容を理解しておくこの記事では、より良い資料の後半の理解に貢献します：

A、ユーレカレジストリHAクラスタの概要

1-1、伝統的な建築

それは一つのノードのみを持っている場合、このような分散型システムのマイクロサービスアーキテクチャでは、我々は完全にレジストリユーレカ自体がサービスであるため、各マイクロの高可用性サービスコンポーネントの問題は、単一障害点を持つことができません考慮する必要があり、それが可能です我々は、クエリサービスに登録することはできませんので、失敗は、私たちが必要とするので、 - 必要な可用性の高いサービスレジストリは、クラスタ・レジストリによって対処されます。ユーレカサービスレジストリ自体がサービスであり、それはプロバイダとしても見ることができるが、また、我々のレジストリが自分自身を登録しないことのconfigure eureka.client.register-と-ユーレカ= falseのように前に、消費者として見ることができますしかし、我々は、他のレジストリに自身を登録することができます。

ユーレカサーバーの高可用性は、実際に他のサービスレジストリを自分に自身をサービスとして登録され、これは、登録センターAの登録サービスに、相互の同期サービスのリストを実現するように、お互いに登録されているサービス・レジストリのグループを形成しますクエリが登録されたサービスへの任意の1件の登録センターから得ることができるので、同期は、高可用性を実現するように、レジストリBにコピーすることができます。

二つは、ユーレカ登録センターは、高可用性クラスタを設定します

ユーレカ高可用性クラスタレジストリは、各登録センターお互いに登録されています

1は、我々はアプリケーション・eureka8701.yml、アプリケーション-eureka8702.ymlとしてapplication.ymlのユーレカ・サーバ（springcloud-ユーレカ・サーバー）をコピーし、私たちはお互いにユーレカサービス8701および8702の登録をしましょう。

構成アプリケーション-eureka8701.ymlは、次の変更：

春：
  ファイルアプリケーション：
    名前：springcloud -eureka- サーバー
サーバー：
  ポート： 8701 
IPを指定のサービス・センターの＃セットのホスト名、インスタンス名が重複することはできません
ユーレカを：
  インスタンス：
    ホスト名：eureka8701の
  クライアント：
    登録 -with-ユーレカ：trueに
    FETCH -レジストリ：trueに
    -サービスは - URL：
      defaultzone：HTTP：// eureka8702：8702 /ユーレカは

    、ファイル、アプリケーションを修正 - 対応eureka8701.yml以下の構成

の春：
  ファイルアプリケーション：
    名前：springcloud -eureka- サーバー
サーバー：
  ポート：8702 
サービスセンターのホスト名、指定されたIP、インスタンス名を複製することはできません＃セット
ユーレカを：
  インスタンス：
    ホスト名：eureka8702の
  クライアント：
    登録 -with-ユーレカ：trueに
    FETCH -registry：trueに
    サービス - URL：
      defaultzone：HTTP：// eureka8701： 8701 /ユーレカ

2、起動SpringcloudEurekaServerApplicationクラスはSpringcloudEureka8701ServerApplication、SpringcloudEureka8702ServerApplication、図の選択起動クラスの右のマウスと命名されたコピー

しかし、起動クラスSpringcloudEureka8701ServerApplicationを添加-Dspring.profiles.active = eureka8701

同様に、クラス開始動作8702が同じで、ここでは省略されています。

hostsファイル\ \ System32に\ Windowsの下のドライバ\ etcディレクトリ：あなたがお互いを訪問することができない場合3は、eureka8701とeureka8702が同期データに正しく相互訪問することができようにするために、データユーレカサービスは、私たちがCに必要な、共有を同期することはできません次のように、コンフィギュレーションの2行を追加します。

127.0.0.1 eureka8701
127.0.0.1 eureka8702

4、启动两个SpringcloudEureka8701ServerApplication，SpringcloudEureka8702ServerApplication服务我们可以看到注册成功了。

Eureka8702也是如此，到此Eureka服务集群搭建完毕

三、Eureka详解

1、服务消费者模式

1-1、获取服务

消费者启动的时候，使用服务别名，会发送一个rest请求到服务注册中心获取对应的服务信息，然后会缓存到本地jvm客户端中，同时客户端每隔30秒从服务器上更新一次。

可以通过eureka.client.registry-fetch-interval-seconds=30参数进行修改，该配置默认值为30，单位为秒。

1-2、服务下线

在系统运行过程中必然会面临关闭或重启服务的某个实例的情况，在服务关闭期间我们自然不希望客户端会继续调用关闭了的实例。所以在客户端程序中，当服务实例正常的关闭操作时，它会触发一个服务下线的REST请求给Eureka Server, 告诉服务中心:“我要下线了”。服务端在接收到请求之后，将该服务状态置为下线(DOWN)，并将该下线事件传播出去。

2、服务注册模式

2-1、失效剔除

有些时候，我们的服务实例并不一定会正常下线，可能由于内存溢出、网络故障原因使得服务不能正常工作，而服务注册中心并未收到“服务下线”的请求。为了从服务表中将这些无法提供服务的实例剔除，Eureka Server 在启动的时候会创建一个定时任务默认每隔一段时间(默认为60秒eureka.server.eviction-interval-timer-in-ms=6000L)将当前清单中超时(默认为90秒eureka.instance.lease-expiration-duration-in-seconds= 90)没有续约的服务踢除出去

2-2、Eureka服务注册中心自我保护机制

当我们在本地调试基于Eureka的程序时，基本上都会碰到这样一个问题，在服务主中心的信息面板中出现类似下面的红色警告信息，在开发测试时，需要频繁地重启微服务实例，但是我们很少会把eureka server一起重启（因为在开发过程中不会修改eureka注册中心），当一分钟内收到的心跳数大量减少时，会触发该保护机制。可以在eureka管理界面看到Renews threshold和Renews(last min)，当后者（最后一分钟收到的心跳数）小于前者（心跳阈值）的时候，触发保护机制，会出现红色的警告：

实际上，该警告就是触发了Eureka Server的自我保护机制，服务注册到Eureka Server之后，会维护个心跳连接，告诉Eureka Server自己还活着。Eureka Server在运行期间，会统计客户端节点的心跳失败的比例在15分钟之内是否低于85%如果出现低于的情况，如果低于85%，那就触发自我保护机制，单机调试的时候很容易满足，实际在生产环境上通常是由于网络不稳定导致)，Eureka Server会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。但是，在这段保护期间内实例若出现问题，那么客户端很容易拿到实际已经不存服务实例，会出现调用失败的情况，所以客户端必须要有容错机制，比如可以使用请使用重试、断路器等机制。

在没有Eureka自我保护的情况下,如果 Eureka Server在一定时间内没有接收到某个微服务实例的心跳, Eureka Server将会注销该实例,但是当发生网络分区故障时,那么微服务与 Eureka Server之间将无法正常通信,以上行为可能变非常危险了，因为微服务本身其实是正常的,此时不应该注销这个微服务，如果没有自我保护机制，那么Eureka Server就会将此服务注销掉。

Eureka通过“自我保护模式”来解决这个问题——当 Eureka Server节点在短时间内丢失过多客户端时(可能发生了网络分区故障),那么就会把这个微服务节点进行保护。一旦进入自我保护模式, Eureka server就会保护服务注册表中的信息,不删除服务注册表中的数据(也就是不会注销任何微服务)。当网络故障恢复后,该 Eureka Server节点会再自动退出自我保护模式。所以,自我保护模式是一种应对网络异常的安全保护措施,它的架构哲学是宁可同时保留所有微服务(健康的微服务和不健康的微服务都会保留),也不盲目注销任何健康的微服务,使用自我保护模式,可以让Eureka集群更加的健壮、稳定当然也可以使用配置项: eureka.server.enable-self-preservation=fase禁用自我保护模式。

但是Eureka Server自我保护模式也会给我们带来一些困扰,如果在保护期内某个服务提供者刚好非正常下线了,此时服务消费者就会拿到一个无效的服务实例,此时会调用失败,对于这个问题需要服务消费者端具有一些容错机制,如重试,断路器等。

Eureka的自我保护模式是有意义的,该模式被激活后,它不会从注册列表中剔除因长时间没收到心跳导致注册过期的服务,而是等待修复,直到心跳恢复正常之后,它自动退出自我保护模式。这种模式旨在避免因网络分区故障导致服务不可用的问题。

例如,两个微服务客户端实例A和B之间有调用的关系,A是消费者,B是提供者,但是由于网络故障,B未能及时向Eureka发送心跳续约,这时候 Eureka不能简单的将B从注册表中剔除,因为如果剔除了,A就无法从Eureka服务器中获取B注册的服务,但是这时候B服务是可用的;所以, Eureka的自我保护模式最好还是开启它。

2-3、关闭自我保护的相关配置如下

服务端配置

ユーレカ：
  サーバー：
    有効 -self-保存を：falseに
    、すなわち#eureka Serverノード非アクティブクリーンアップの時間間隔、デフォルト60000ミリ秒、60秒
    立ち退き -intervalタイマーを-に-MS：＃60000ミリ秒

クライアントの構成

＃ハートビート検出と更新時間、小さく設定テストの値、タイムリーなサービス登録センターを確保するためには、サービスを追い出さ閉じ
ユーレカ：
  インスタンス：
    1秒の＃間隔は、生きている「まだ自分自身を証明するために、サーバーにハートビートを送信します「
    リース -renewal・イン・秒間隔ザ・：1つの
    私はあなたに心を与えていない場合＃は、私に代わって、2S内、サーバーに伝える」」死んだ、私は蹴って下さい
    リース -expiration-DURATIONイン秒：2

次のように閉じる自己保護モードユーレカサーバが表示されます。

ケース送信元アドレス：https://gitee.com/coding-farmer/spirngcloud-learn

春の雲第III部では、|ユーレカ登録センターは、高可用性を設定しました