Eureka注册中心

介绍

eureka 是 netflix 开发的一款服务发现（service discovery）工具，它是 spring cloud netflix 微服务套件的一部分。服务发现是微服务架构中的关键组件之一，允许服务实例在启动时向 eureka 服务器注册自己的信息（如ip地址和端口），并定期发送心跳来更新状态。

1 eureka注册中心

假如我们的服务提供者user-service部署了多个实例，如图：

大家思考几个问题：

• order-service在发起远程调用的时候，该如何得知user-service实例的ip地址和端口？
• 有多个user-service实例地址，order-service调用时该如何选择？
• order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？

1.1.eureka的结构和作用

这些问题都需要利用springcloud中的注册中心来解决，其中最广为人知的注册中心就是eureka，其结构如下：

回答之前的各个问题。

问题1：order-service如何得知user-service实例地址？

获取地址信息的流程如下：

• user-service服务实例启动后，将自己的信息注册到eureka-server（eureka服务端）。这个叫服务注册
• eureka-server保存服务名称到服务实例地址列表的映射关系
• order-service根据服务名称，拉取实例地址列表。这个叫服务发现或服务拉取

问题2：order-service如何从多个user-service实例中选择具体的实例？

• order-service从实例列表中利用负载均衡算法选中一个实例地址
• 向该实例地址发起远程调用

问题3：order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？

• user-service会每隔一段时间（默认30秒）向eureka-server发起请求，报告自己状态，称为心跳
• 当超过一定时间没有发送心跳时，eureka-server会认为微服务实例故障，将该实例从服务列表中剔除
• order-service拉取服务时，就能将故障实例排除了

因此，接下来我们动手实践的步骤包括：

1.2.搭建eureka-server

首先大家注册中心服务端：eureka-server，这必须是一个独立的微服务

1.创建eureka-server服务

在cloud-demo父工程下，创建一个子模块：

2.引入eureka依赖

引入springcloud为eureka提供的starter依赖：

<dependency>
    <groupid>org.springframework.cloud</groupid>
    <artifactid>spring-cloud-starter-netflix-eureka-server</artifactid>
</dependency>

3.编写启动类

给eureka-server服务编写一个启动类，一定要添加一个@enableeurekaserver注解，开启eureka的注册中心功能：

package cn.shen.eureka;

import org.springframework.boot.springapplication;
import org.springframework.boot.autoconfigure.springbootapplication;
import org.springframework.cloud.netflix.eureka.server.enableeurekaserver;

@springbootapplication
@enableeurekaserver
public class eurekaapplication {
    public static void main(string[] args) {
        springapplication.run(eurekaapplication.class, args);
    }
}

4.编写配置文件

编写一个application.yml文件，内容如下：

server:
  port: 10086
spring:
  application:
    name: eureka-server
eureka:
  client:
    service-url: 
      defaultzone: http://127.0.0.1:10086/eureka
    register-with-eureka: false # false表示不向注册中心注册自己。
    fetch-registry: false # false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务      

5.启动服务

启动微服务，然后在浏览器访问：http://127.0.0.1:10086

看到下面结果应该是成功了：

1.3.服务注册

下面，我们将user-service注册到eureka-server中去。

1）引入依赖

在user-service的pom文件中，引入下面的eureka-client依赖：

<dependency>
    <groupid>org.springframework.cloud</groupid>
    <artifactid>spring-cloud-starter-netflix-eureka-client</artifactid>
</dependency>

2）配置文件

在user-service中，修改application.yml文件，添加服务名称、eureka地址：

spring:
  application:
    name: userservice
eureka:
  client:
    service-url:
      defaultzone: http://127.0.0.1:10086/eureka

3）启动多个user-service实例

为了演示一个服务有多个实例的场景，我们添加一个springboot的启动配置，再启动一个user-service。

查看eureka-server管理页面：

1.4.服务发现

下面，我们将order-service的逻辑修改：向eureka-server拉取user-service的信息，实现服务发现。

1）引入依赖

之前说过，服务发现、服务注册统一都封装在eureka-client依赖，因此这一步与服务注册时一致。

在order-service的pom文件中，引入下面的eureka-client依赖：

<dependency>
    <groupid>org.springframework.cloud</groupid>
    <artifactid>spring-cloud-starter-netflix-eureka-client</artifactid>
</dependency>

2）配置文件

服务发现也需要知道eureka地址，因此第二步与服务注册一致，都是配置eureka信息：

在order-service中，修改application.yml文件，添加服务名称、eureka地址：

spring:
  application:
    name: orderservice
eureka:
  client:
    service-url:
      defaultzone: http://127.0.0.1:10086/eureka

3）服务拉取和负载均衡

最后，我们要去eureka-server中拉取user-service服务的实例列表，并且实现负载均衡。

不过这些动作不用我们去做，只需要添加一些注解即可。

在order-service的orderapplication中，给resttemplate这个bean添加一个@loadbalanced注解：

修改order-service服务中的cn.shen.order.service包下的orderservice类中的queryorderbyid方法。修改访问的url路径，用服务名代替ip、端口：

@restcontroller
@requestmapping("order")
public class ordercontroller {
   @autowired
   private orderservice orderservice;
   @autowired
   private resttemplate resttemplate;
    @getmapping("{orderid}")
    public order queryorderbyuserid(@pathvariable("orderid") long orderid) {
        // 根据id查询订单并返回
        order order = orderservice.queryorderbyid(orderid);
        // 根据订单关联的用户id远程查询用户信息
        long userid = order.getuserid();                  // 服务名称
        user user = resttemplate.getforobject("http://userservice/user/" + userid, user.class);
        order.setuser(user);
        return order;
    }
}

spring会自动帮助我们从eureka-server端，根据userservice这个服务名称，获取实例列表，而后完成负载均衡。

2 ribbon负载均衡

上面示例中，我们添加了@loadbalanced注解，即可实现负载均衡功能，这是什么原理呢？

2.1.负载均衡原理

springcloud底层其实是利用了一个名为 ribbon 的组件(无需引入依赖，euraka依赖内部已经内嵌了)，来实现负载均衡功能的。

那么我们发出的请求明明是 http://userservice/user/1，怎么变成了http://localhost:8081的呢？

2.2.源码跟踪

为什么我们只输入了service名称就可以访问了呢？之前还要获取ip和端口。

显然有人帮我们根据service名称，获取到了服务实例的ip和端口。它就是loadbalancerinterceptor，这个类会在对resttemplate的请求进行拦截，然后从eureka根据服务id获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务id。

我们进行源码跟踪：

1）loadbalancerintercepor

可以看到这里的intercept方法，拦截了用户的httprequest请求，然后做了几件事：

• request.geturi()：获取请求uri，本例中就是 http://user-service/user/8
• originaluri.gethost()：获取uri路径的主机名，其实就是服务id，user-service
• this.loadbalancer.execute()：处理服务id，和用户请求。

这里的this.loadbalancer是loadbalancerclient类型，我们继续跟入。

2）loadbalancerclient

继续跟入execute方法：

代码是这样的：

• getloadbalancer(serviceid)：根据服务id获取iloadbalancer，而iloadbalancer会拿着服务id去eureka中获取服务列表并保存起来。
• getserver(loadbalancer)：利用内置的负载均衡算法，从服务列表中选择一个。本例中，可以看到获取了8082端口的服务

放行后，再次访问并跟踪，发现获取的是8081：

果然实现了负载均衡。

3）负载均衡策略irule

在刚才的代码中，可以看到获取服务使通过一个getserver方法来做负载均衡:

我们继续跟入：

继续跟踪源码 chooseserver 方法，发现这么一段代码：

我们看看这个rule是谁：

这里的rule默认值是一个roundrobinrule，看类的介绍：

这不就是轮询的意思嘛。

到这里，整个负载均衡的流程我们就清楚了。

4）总结

springcloudribbon的底层采用了一个拦截器，拦截了resttemplate发出的请求，对地址做了修改。用一幅图来总结一下：

基本流程如下：

• 拦截我们的 resttemplate 请求http://userservice/user/1
• ribbonloadbalancerclient 会从请求url中获取服务名称，也就是user-service
• dynamicserverlistloadbalancer 根据 user-service 到 eureka 拉取服务列表
• eureka 返回列表，localhost:8081、localhost:8082
• irule 利用内置负载均衡规则，从列表中选择一个，例如 localhost:8081
• ribbonloadbalancerclient 修改请求地址，用 localhost:8081 替代 userservice ，得到 http://localhost:8081/user/1，发起真实请求

2.3.负载均衡策略

负载均衡策略

负载均衡的规则都定义在irule接口中，而irule有很多不同的实现类：

不同规则的含义如下：

内置负载均衡规则类	规则描述
roundrobinrule	简单轮询服务列表来选择服务器。
availabilityfilteringrule	对以下两种服务器进行忽略： （1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。 （2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了availabilityfilteringrule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的<clientname>.<clientconfignamespace>.activeconnectionslimit属性进行配置。
weightedresponsetimerule	为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。
zoneavoidancerule	以区域可用的服务器为基础进行服务器的选择。使用zone对服务器进行分类，这个zone可以理解为一个机房、一个机架等。而后再对zone内的多个服务做轮询。
bestavailablerule	忽略那些短路的服务器，并选择并发数较低的服务器。
randomrule	随机选择一个可用的服务器。
retryrule	重试机制的选择逻辑

默认的实现就是zoneavoidancerule，是一种轮询方案

自定义负载均衡策略

通过定义irule实现可以修改负载均衡规则，有两种方式：

1. 代码方式：在order-service中的orderapplication类中，定义一个新的irule：

@bean
public irule randomrule(){
    return new randomrule();
}

2. 配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：

userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
  ribbon:
    nfloadbalancerruleclassname: com.netflix.loadbalancer.randomrule # 负载均衡规则 

2.4.饥饿加载

ribbon默认是采用懒加载，即第一次访问时才会去创建loadbalanceclient，请求时间会很长。

而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：

ribbon:
  eager-load:
    enabled: true #开启饥饿加载
    clients: userservice # 指定被调用微服务饥渴加载,多个服务使用 - 的方式。