三、SpringCloud從看不懂到放棄，第二章

SpringCloud從看不懂到放棄，第二章

1、Eureka服務的註冊與發現

Eureka

Netflix在設計Eureka時遵照的就是AP原則

CAP原則又稱CAP定理，指的是在一個分佈式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可兼得

一、Eureka簡介

Eureka是Netflix的一個子模塊，是一個基於Rest的服務，用於服務定位，已實現雲端中間層服務發現和故障轉移。
	
	服務註冊與發現對於微服務架構來講是很是重要的，有了服務發現與註冊，只須要使用服務的標識符，就能夠訪問到服務，而不須要修改服務調用的配置文件了。

	功能相似於dubbo的註冊中心，好比zookeeper

Eureka基本架構

Spring Cloud 封裝了 Netflix 公司開發的 Eureka 模塊來實現服務註冊和發現(請對比Zookeeper)。

	Eureka 採用了 C-S 的設計架構。Eureka Server 做爲服務註冊功能的服務器，它是服務註冊中心。
 
	而系統中的其餘微服務，使用 Eureka 的客戶端鏈接到 Eureka Server並維持心跳鏈接。這樣系統的維護人員就能夠經過 Eureka Server 來監控系統中各個微服務是否正常運行。SpringCloud 的一些其餘模塊（好比Zuul）就能夠經過 Eureka Server 來發現系統中的其餘微服務，並執行相關的邏輯。

	Eureka包含兩個組件：Eureka Server和Eureka Client
	Eureka Server提供服務註冊服務
	各個節點啓動後，會在EurekaServer中進行註冊，這樣EurekaServer中的服務註冊表中將會存儲全部可用服務節點的信息，服務節點的信息能夠在界面中直觀的看到
 
	EurekaClient是一個Java客戶端，用於簡化Eureka Server的交互，客戶端同時也具有一個內置的、使用輪詢(round-robin)負載算法的負載均衡器。在應用啓動後，將會向Eureka Server發送心跳(默認週期爲30秒)。若是Eureka Server在多個心跳週期內沒有接收到某個節點的心跳，EurekaServer將會從服務註冊表中把這個服務節點移除（默認90秒）

三大結構

一、Eureka server提供服務註冊與發現
二、service provide將自身服務註冊到Eureka，從而使服務消費方可以找到
三、service consumer從Eureka獲取註冊服務列表，從而可以消費服務

二、構建項目

項目結構

總父工程
通用模塊API
服務提供者Provider
服務消費者Consumer
eureka服務註冊中心module

（1）、cloud-eureka-7001

POM

主要包含一個spring-cloud-starter-eureka-server

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <parent>
        <artifactId>cloud</artifactId>
        <groupId>com.lee</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>cloud-eureka-7001</artifactId>

    <dependencies>
        <!--eureka-server服務端 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>
        <!-- 修改後當即生效，熱部署 -->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>springloaded</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
        </dependency>
    </dependencies>


</project>

注意：

基本上咱們要引入cloud的一個新的技術組件，會有兩步

一、新增一個相關的maven座標
	<dependency>
		<groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-eureka-server</artifactId>
	</dependency>

二、在主啓動類上標註啓動該新組件的相關注解標籤
	@EnableEurekaServer 
	@EnableZuulProxy
	@EnableXXXXX
	...

APPLICATION.YML

主要暴露eureka端口和對外服務地址

server:
  port: 7001

eureka:
  instance:
    hostname: localhost #eureka服務端的實例名稱
  client:
    register-with-eureka: false #false表示不向註冊中心註冊本身。
    fetch-registry: false #false表示本身端就是註冊中心，個人職責就是維護服務實例，並不須要去檢索服務
    service-url:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ #設置與Eureka Server交互的地址查詢服務和註冊服務都須要依賴這個地址。

主啓動類

package com.lee.cloud;

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

//EurekaServer服務器端啓動類,接受其它微服務註冊進來
@EnableEurekaServer
@SpringBootApplication
public class EurekaServer7001_App {

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

測試

http://localhost:7001

（2）、將已有的部門微服務註冊進Eureka服務中心

修改cloud-provider-dept-8001

POM - 新增 eureka客戶端 config配置中心

<!-- 將微服務provider側註冊進eureka -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>

<!--注意：-->
<!--
	若是eureka下載不下來的話
	改爲這個
		<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
            <version>1.3.6.RELEASE</version>
        </dependency>

-->

YML - 新增 eureka服務地址

eureka:
  client: #客戶端註冊進eureka服務列表內
    service-url: 
      defaultZone: http://localhost:7001/eureka

主啓動類 - 新增 將本服務啓動後自動註冊進eureka服務中

@EnableEurekaClient //本服務啓動後會自動註冊進eureka服務中

測試：

一、啓動 cloud-eureka-7001
二、啓動 cloud-provider-dept-8001
三、http://localhost:7001

注意：暴露在eureka中的微服務名稱，即provider的yml中spring:application:name的名稱

若是找不到服務的話，大機率是應爲spring-cloud-starter-eureka和
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Dalston.SR1</version>

版本不一致致使的

（3）、actuator與註冊微服務信息完善---主機映射名稱修改

Eureka服務中的顯示

Application	AMIs	Availability Zones	Status
CLOUD-DEPT	n/a (1)	(1)	UP (1) - windows10.microdone.cn:cloud-dept:8001

目標：修改 windows10.microdone.cn:cloud-dept:8001的顯示

cloud-provider-dept-8001修改：

YML

eureka:
	instance:
    	instance-id: cloud-dept8001

結果：

Application	AMIs	Availability Zones	Status
CLOUD-DEPT	n/a (1)	(1)	UP (1) - cloud-dept8001

（4）、actuator與註冊微服務信息完善---主機IP信息提示

鼠標移動到上側超連接時，瀏覽器左下角的連接顯示

cloud-provider-dept-8001修改：

YML

eureka:
	instance:
		prefer-ip-address: true  #訪問路徑能夠顯示IP地址

（5）、actuator與註冊微服務信息完善---Info內容構建

cloud-dept8001超瞭解點擊後內容的構建

cloud-provider-dept-8001修改：

POM

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

YML

info:									#內容以info開頭下邊隨便寫
  app.name: cloud
  author.name: lee
  app.function: 部門服務提供者
  build.artifactId: $project.artifactId$
  build.version: $project.version$

CLOUD父工程POM

<build><!--構建-->
   <finalName>microservicecloud</finalName>
   <resources>	<!--能夠訪問src/main/resources下的文件-->
     <resource>
       <directory>src/main/resources</directory>
       <filtering>true</filtering>
     </resource>
   </resources>
   <plugins>
     <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-resources-plugin</artifactId>
       <configuration>
         <delimiters>
          <delimit>$</delimit>
         </delimiters>
       </configuration>
     </plugin>
   </plugins>
  </build>

結果：

訪問：http://192.168.101.39:8001/info
顯示：
{"app":
	{
		"name":"cloud",
		"function":"部門服務提供者"
	},
 "author":{"name":"lee"},
 "build":{
			"artifactId":"$project.artifactId$",
			"version":"$project.version$"
		  }
}

三、Eureka集羣配置

（1）、仿照cloud-eureka-7001建立cloud-eureka-7002和cloud-eureka-7003

（2）、修改 映射

c:\Windows\System32\drivers\etc下的host文件
添加以下:
	127.0.0.1   eureka7001.com
	127.0.0.1   eureka7002.com
	127.0.0.1   eureka7003.com

（3）、三臺eureka服務的yml配置

eureka:
   instance:
		hostname: eureka7001.com  ##eureka服務端的實例名稱,知識localhost換了個名而已

eureka:
	client:
		defaultZone: http://eureka7002.com:7002/eureka,http://eureka7003.com:7003/eureka
		##也能夠是http://localhost:7002/eureka,http://localhost:7003/eureka

（4）、cloud-provider-dept-8001 YML服務地址修改

eureka:
	client:
		service-url:
			defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka,http://eureka7003.com:7003/eureka

測試：

http://eureka7001.com:7001
http://eureka7002.com:7002
http://eureka7003.com:7003

四、Eureka自我保護機制

某時刻某一個微服務不可用了，或者長時間沒有被調用，eureka不會馬上清理，依舊會對該微服務的信息進行保存。（網絡擁堵或者調用超時）

	什麼是自我保護模式？
  
	默認狀況下，若是EurekaServer在必定時間內沒有接收到某個微服務實例的心跳，EurekaServer將會註銷該實例（默認90秒）。可是當網絡分區故障發生時，微服務與EurekaServer之間沒法正常通訊，以上行爲可能變得很是危險了——由於微服務自己實際上是健康的，此時本不該該註銷這個微服務。Eureka經過「自我保護模式」來解決這個問題——當EurekaServer節點在短期內丟失過多客戶端時（可能發生了網絡分區故障），那麼這個節點就會進入自我保護模式。一旦進入該模式，EurekaServer就會保護服務註冊表中的信息，再也不刪除服務註冊表中的數據（也就是不會註銷任何微服務）。當網絡故障恢復後，該Eureka Server節點會自動退出自我保護模式。
 
	在自我保護模式中，Eureka Server會保護服務註冊表中的信息，再也不註銷任何服務實例。當它收到的心跳數從新恢復到閾值以上時，該Eureka Server節點就會自動退出自我保護模式。它的設計哲學就是寧肯保留錯誤的服務註冊信息，也不盲目註銷任何可能健康的服務實例。一句話講解：好死不如賴活着
 
	綜上，自我保護模式是一種應對網絡異常的安全保護措施。它的架構哲學是寧肯同時保留全部微服務（健康的微服務和不健康的微服務都會保留），也不盲目註銷任何健康的微服務。使用自我保護模式，可讓Eureka集羣更加的健壯、穩定。

五、Eureka和Zookeeper對比

RDBS(mysql/oracle/sqlserver)---->ACID
NOSQL(redis/mongodb)----->CAP
---------------------------------------------------------
---------------------------------------------------------
ACID:   atomicity原子性、
		consistency一致性、
		isolation獨立性、
		durability持久性

CAP：	consistency強一致性、
		 availability高可用、
		 partition tolerance 分區容錯性
---------------------------------------------------------
---------------------------------------------------------
Eureka遵照AP  Zookeeper遵照CP

 
 	做爲服務註冊中心，Eureka比Zookeeper好在哪裏
著名的CAP理論指出，一個分佈式系統不可能同時知足C(一致性)、A(可用性)和P(分區容錯性)。因爲分區容錯性P在是分佈式系統中必需要保證的，所以咱們只能在A和C之間進行權衡。
所以
	Zookeeper保證的是CP,
	Eureka則是AP。
 
1. Zookeeper保證CP
	當向註冊中心查詢服務列表時，咱們能夠容忍註冊中心返回的是幾分鐘之前的註冊信息，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。可是zk會出現這樣一種狀況，當master節點由於網絡故障與其餘節點失去聯繫時，剩餘節點會從新進行leader選舉。問題在於，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集羣都是不可用的，這就致使在選舉期間註冊服務癱瘓。在雲部署的環境下，因網絡問題使得zk集羣失去master節點是較大機率會發生的事，雖然服務可以最終恢復，可是漫長的選舉時間致使的註冊長期不可用是不能容忍的。
 
2. Eureka保證AP
	Eureka看明白了這一點，所以在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工做，剩餘的節點依然能夠提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊或時若是發現鏈接失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。除此以外，Eureka還有一種自我保護機制，若是在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心出現了網絡故障，此時會出現如下幾種狀況： 

2.一、Eureka再也不從註冊列表中移除由於長時間沒收到心跳而應該過時的服務 
2.二、Eureka仍然可以接受新服務的註冊和查詢請求，可是不會被同步到其它節點上(即保證當前節點依然可用) 
2.三、當網絡穩定時，當前實例新的註冊信息會被同步到其它節點中
 
	所以， Eureka能夠很好的應對因網絡故障致使部分節點失去聯繫的狀況，而不會像zookeeper那樣使整個註冊服務癱瘓。

拓展知識

#服務發現

@AutoWire
private DiscoveryClient client;

List<String> serviceList = client.getServices();//列出Eureka中全部的服務
List<ServiceInstance> instanceList = client.getInstances("CLOUD-DEPT");//查找服務實例
 
instance.getServiceId();//實例ID
instance.getHost();//實例主機
instance.getPort();//實例端口
instance.getUri();//實例Uri
    
@EnableDiscoveryClient //主啓動類上+服務發現註解