Rest微服务构建案例工程模块
Lombok：https://blog.csdn.net/motui/article/details/79012846
*此处版本选用cloud_Dalston.SR1 boot_1.5.9RELEASE 可根据需求修改
*RestTemplate提供了多种便捷访问远程HTTP服务的方法，是一种简单便捷的访问restful服务模板类，是Spring提供的用于访问Rest服务的客户端模板工具集
Eureka：
*是Netflix的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移。服务注册于发现对于微服务架构来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了。功能类似于dubbo的注册中心，比如Zookeeper。
原理：
*采用C-S的设计架构。Eureka Server 作为服务注册功能的服务器，它是服务注册中心。
*而系统的其他微服务，使用Eureka的客户端连接到Eureka Server并维持心跳连接。这样系统的维护人员就可以通过Eureka Server 来监控系统中各个微服务是否正常运行。SpringCloud的一些其他模块(比如Zuul)就可以通过Eureka Server来发现系统中的其他微服务，并执行相关的逻辑。
*两大组件：
*Eureka Server
*提供服务注册服务
*各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以再界面中直观的看到
*Eureka Client
*Java客户端
*用于简化EurekaServer的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向EurekaServer发送心跳（默认周期为30秒）。如果EurekaServer在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除（默认90秒）
*actuator
Netflix在设计Eureka时遵守的是AP原则
*Eureka的自我保护机制
*好死不如赖活着
*某时刻，某一个微服务不可用了，eureka不会立刻清理，依旧会对该微服务信息进行保存
*导致原因：
*默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险了---因为微服务本身其实是健康的，此时本不该注销这个微服务。Eureka通过"自我保护模式"来解决这个问题----当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该EurekaServer节点会自动退出自我保护模式。
*在自我保护模式中，EurekaServer会保护服务注册表中的信息，不再注销任何服务实例。当它收到心跳书重新恢复到阈值以上时，该EurekaServer节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。
*综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定。
*在SpringCloud中，可以使用eureka,server,enable-self-preservation = false 金庸自我保护模式
服务发现（Discovery）
*Eureka集群：
*配置Eureka集群（高可用）
microservicecloud-eureka-7002
*新建microservicecloud-eureka-7002，microservicecloud-eureka-7003
*以7001为模板，修改pom
*修改02.03主启动类
*修改本机映射配置
*进入C:\Windows\System32\drivers，修改Hosts
*127.0.0.1 eureka7001.com
*127.0.0.1 eureka7002.com
*127.0.0.1 eureka7003.com
*修改3台eureka服务器的yml配置
*将8001发布到三台Eureka集群机器上
*修改yml文件
