那些年,想和你一起认识的SpringCloud Eureka

2019年8月9日 184次阅读

　　前几天鲁班LB跟我说：你玩把游戏都要半个钟啦，为何不用这时间来看看书，如果涨工资还可以帮我买个皮肤。

　　面对如此合理的这需求，但我不以为然，事实上并不是我不想学习，而是 ↓

　　《那些年,想和你一起认识的SpringCloud Eureka》

　　实力不允许呀~

　　直到有一天，突然被叫到会议室，心里疙瘩一下，这难道？项目出严重Bug了，冷静的我思索片刻后，很快就会否定了这种想法，结果巴拉巴拉2小时后，结论竟然是说:“现在我们这个项目要求重构，需用使用微服务架构，所以不了解相关技术的同事请利用这段时间学习复习一下，下个月要开始进入开发阶段。

　　呵呵，会议上，总是有人把微服务吹的很厉害似的，我笑而不语，于是

　　《那些年,想和你一起认识的SpringCloud Eureka》

　　一周后

　　《那些年,想和你一起认识的SpringCloud Eureka》

　　以下是我的笔记，我一般是带着问题去学习，有了需求，或者说是好奇心，因为这样学习的效率会更高

　　当看到我们架构中有Eureka，我的第一个问题自然就是：做微服务为什么要使用Eureka，或者Eureka能够帮助我们解决什么样的问题？

　　对于微服务的概念有经验的开发人员的一般都听说过吧，无非就是把大应用拆分为小应用，然后处理好服务的相互通讯即可，但是如果光启动微服务时，不启动eureka，其他微服务也是可以通过Nginx反向代理，用rest的方式从不同服务后台获取到数据（HTTP直怼），那多个eureka服务岂不是多此一举吗？细想一下其实并不是的，我觉得原因有如下：

　　其一：

　　如果后端微服务之间，有互相通信，那么在负载均衡时，相同的服务肯定会启动多个，而且使用不同的端口，这个时候，服务之间就可以通过注册在eureka中的名称来找到对方，而不是根据IP+端口号去找对方。反之如果后端微服务之间相互通信，都要知道具体的IP和端口，那开发起来十分麻烦，而IP地址也并不是固定不变的，除非使用域名封装，所以无论是测试还是开发还是上线都存在问题。

　　其二：

　　Eureka注册中心的作用很大的程度是作用于服务发现和服务心跳，在多个注册中心的时候,依赖于zuul的负载均衡,保证异常的服务停止,正常的服务加载,保证服务的稳定性。

　　新手可能不理解这说的是什么意思，没关系，请往下看，首先我们先说说什么是SpringCloud

　　SpringCloud是一系列框架的有序集合。它利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、熔断器、数据监控等，都可以用SpringBoot的开发风格做到一键启动和部署。是一套简单易懂、易部署和易维护的分布式系统开发工具包。

　　主要组成如下：

　　服务发现——Netflix Eureka 服务调用——Netflix Feign
　　熔断器——Netflix Hystrix 服务网关——Netflix Zuul
　　分布式配置——Spring Cloud Config 消息总线 —— Spring Cloud Bus

　　本文主要介绍Eureka注册中心

　　组成原理：

　　Eureka包含两个组件： Eureka Server和Eureka Client：

　　Eureka Server提供服务注册服务，各个Client节点启动后，会在Eureka Server中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。

　　Eureka Client是一个java客户端，用于简化与Eureka Server的交互，客户端有一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳,默认周期为30秒，如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除(默认90 秒)。如果Eureka Server做了集群，Eureka Server之间通过复制的方式完成数据的同步，同时Eureka还提供了客户端缓存机制，即使所有的Eureka Server都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API。

　　综上，Eureka能够通过心跳检查、客户端缓存等机制，确保了系统的高可用性。

　　问题：同为注册中心，Eureka要比Zookeeper好在哪，或者说为什么Cloud为什么不集成Zookeeper，在CAP理论中说道，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。我们从需求出发考虑，当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，对于服务注册功能对可用性的要求要高于一致性。

　　Eureka不会出现这种问题，Zookeeper则会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

　　而在此Zookeeper保证的是CP, 而Eureka则是AP，显然Eureka更加合适。

　　但在默认配置中，Eureka Server在默认90s没有得到客户端的心跳，则注销该实例，但是往往因为微服务跨进程调用，网络通信往往会面临着各种问题，比如微服务状态正常，但是因为网络分区故障时，Eureka Server注销服务实例则会让大部分微服务不可用，这很危险，因为服务明明没有问题。为了解决这个问题，Eureka 有自我保护机制，通过在Eureka Server配置参数，可启动保护机制它的工作原理是：当Eureka Server节点在短时间内丢失过多的客户端时（可能发送了网络故障），那么这个节点将进入自我保护模式，不再注销任何微服务，当网络故障回复后，该节点会自动退出自我保护模式。

　　实战：

　　Eureka服务端开发（非常简单的3步完成）

　　1.从官网下载脚手架项目https://start.spring.io/

　　2.修改一下配置文件

　　3.启动，本质上也是一个SpringBoot项目

　　《那些年,想和你一起认识的SpringCloud Eureka》

　　把下载好的Demo导入编译器，打开application.properties或 .yml配置文件

#配置端口
server:
    port: 8761  #服务端口
#配置服务名称
spring:
　　application:
　　　　name: service-name
 #是否将自己注册到Eureka服务中，本身就是服务端，所以无需注册
 #是否从Eureka中获取注册信息
 #客户端和服务端交互地址
eureka:
    client:
        registerWithEureka: false 
        fetchRegistry: false
        serviceUrl:
            defaultZone: http://127.0.0.1:${server.port}/eureka/

　　配置启动类

@SpringBootApplication
//加入注解，声明为服务端
@EnableEurekaServer  
public class EurekaServer {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServer.class, args);
    }
}

《那些年,想和你一起认识的SpringCloud Eureka》

　　上图为Eureka服务端启动成功，可视化界面，Application表示当前并无客户端用户注册进来，这里说的客户端就是我们开发的微服务应用

　　Eureka客户端开发（其实就是我们真正业务微服务应用）

　　1.从官网下载脚手架项目https://start.spring.io/

　　2.修改一下配置文件

#配置端口
server:
　　port:1111
#配置服务名称
spring:
　　application:
　　　　name : client-name
#配置服务器路径
eureka:
    client:
        service‐url:
            defaultZone: http://localhost:8761/eureka
    instance:
         prefer‐ip‐address: true

　　启动类配置

//加入注解，声明为微服务客户端，项目启动后自动向服务端注册
@EnableDiscoveryClient
@SpringBootApplication
public class ServiceProviderApplication {

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

　　启动后就能在服务端可视化界面看见客户端的注册信息，我们现在就将所有的微服务都注册到Eureka中，这样所有的微服务之间都可以互相调用，服务的调用将在下一篇文章详细讲解

　　《那些年,想和你一起认识的SpringCloud Eureka》

　　但是有时候会出现下面的文字

　　《那些年,想和你一起认识的SpringCloud Eureka》

　　说明Eureka已经进入了保护模式：

　　Eureka Server在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%，如果出现低于的情况（在生产环境上通常是由于网络不稳定导致），Eureka Server会将当前的实例注册信息保护起来，同时提示这个警告。保护模式主要用于一组客户端和Eureka Server之间存在网络分区场景下的保护。一旦进入保护模式，Eureka Server将会尝试保护其服务注册表中的信息，不会注销任何微服务。

　　关于Eureka Server集群的介绍

　　Eureka注册中心只部署在一台机器上，一旦出现问题，会导致整个服务调用系统的崩溃，针对这种情况，我们需要部署两台Eureka注册中心，彼此相互注册，组成一个高可用的的Eureka集群。这样一来，每台服务器都包含着对方的服务注册信息，相当于双机热备，同时，服务提供者只需向其中的一个注册服务。

　　在生产环境中，一般是把两个相互注册的服务器安装在两台服务器上，现在我们在一台机器上模拟双服务器的场景，具体的实现步骤如下:

　　到C:\WINDOWS\system32\drivers\etc目录里，找到hosts文件，在其中加入两个机器名（其实都是指向本机），代码如下。修改后，需要重启机器。

127.0.0.1 erueka-server

127.0.0.1 erueka-server2

　　配置如下

Eureka service

server:
        port: 8761 #端口号
spring:
　　application:
　　　　name: eureka-server #应用名

eureka:
        instance:
              hostname: hostname1
         client:
            register-with-eureka: true
            fetch-registry: true
            service-url:
                defaultZone: http://hostname1:8761/eureka/,http://hostname2:8762/eureka/

Eureka service2

server:
        port: 8762 #端口号
spring:
　　application:
　　　　name: eureka-server2 #应用名

eureka:
        instance:
              hostname: hostname2
         client:
            register-with-eureka: true
            fetch-registry: true
            service-url:
                defaultZone: http://hostname1:8761/eureka/,http://hostname2:8762/eureka/

　　这样下来，就算有一台机器死机了，然后可让服务正常工作。