通过JMeter压测结果来分析Eureka多种服务下线机制后的服务感知情况

文章目录

- 前言
- 1. Eureka-Server的设计
- 2. Eureka+Ribbon感知下线服务机制
- 3.服务调用接口压测模型
- 4.Eureka几种服务下线的方式
- - 4.1强制下线
  - - 压测
  - 4.2 发送delete（）请求
  - - 压测
  - 4.3 调用DiscoveryManager
  - - 压测
  - 4. 三方工具Actuator
- 总结

前言

上文末尾讲到了Eureka对于下线服务的感知不是很敏锐，会把已经下线的服务加载到可用的服务列表里。当轮询到该服务实例来处理请求就会出现“调用请求已经发送出去，但是接口却TimeOut、404、500…错误”，本文会使用多种服务下线方式并结合JMeter压测来具体分析

1. Eureka-Server的设计

Eurkeka中设计了三级缓存：一级缓存（registry注册表）——二级缓存（readWriteCacheMap读写缓存）——三级缓存（readOnlyCacheMap只读缓存）。作为经典的AP模型，读写分离，牺牲了一致性保证了高可用。（以后会分析源码）

2. Eureka+Ribbon感知下线服务机制

当客户端的服务实例正常下线，会发送心跳向Eureka服务端中的一级缓存更新信息（30S）——一级缓存会向二级缓存同步信息（立刻）——二级缓存向三级缓存同步信息（30S）——客户端从三级缓存中同步信息（30S）——Ribbon会向客户端同步缓存，更新服务列表upList（30S）,可见如果是在极端情况下，感知到一个服务下线是需要120S的。（注意这并不是串行化执行，30S均为默认时间）
在这里插入图片描述
下面基于这个流程，采用多种下线的方式结合JMeter压测报告来研究Eureka服务下线感知情况

3.服务调用接口压测模型

采用Jmeter（100个线程—3S内请求）对服务下线后的服务调用接口进行压测，来观察接口执行情况，以及结合日志来体现Ribbon的负载均衡情况：
在这里插入图片描述

通过观察线程组执行完后响应的异常率，来判断已经下线的服务是否没有被Eureka、Ribbon及时更新（也就是服务的感知情况），从而使调用方调用到了不可用的服务。
服务被调用方现有8081、8083、8084三个端口的实例，本次实验统一下线其中两个服务实例，并且Ribbon负载均衡的策略都为默认

4.Eureka几种服务下线的方式

4.1强制下线

直接关闭进程，类似于在服务器上通过kill-9的方式。通过下面的案例可以看到，当我强制下线了服务下的两个服务实例之后，此时立即进行服务间的远程调用（由于Eureka的缓存机制，已经下线的服务还会在缓存的服务列表中没来得及更新，但是列表里已经被下线的实例已经无法再处理请求），调用方会报出connect refused的错误，就像这样：
在控制台中，调用方直接无法建立连接，请求已经到达目标服务，但目标服务主动拒绝了连接。
在这里插入图片描述
在postman中发起调用的接口则是直接报出了500错误，显示服务端存在内部问题：

PS：这样下线会存在很多风险，比如进程中还有请求在处理，不建议使用

压测

15S，使用Jmeter压测模型进行压测，发现异常率高达51%
在这里插入图片描述
30S，使用Jmeter压测模型进行压测，发现异常率为0%

4.2 发送delete（）请求

向Eureka服务端发送http请求，来删除注册表的服务信息，也就是一级缓存中的数据

@GetMapping("/service-down")
public String shutDown(@RequestParam List<Integer> portParams,@RequestParam String vipAddress) {
    List<Integer> successList = new ArrayList<>();
    //获取到服务名下的所有服务实例
    List<InstanceInfo> instances = eurekaClient.getInstancesByVipAddress(vipAddress, false);
    //map<端口-实例id>
    instances.forEach(temp -> {
        String instanceId = temp.getInstanceId();
        String appName = temp.getAppName();
        int port = temp.getPort();
        //"http://eureka-server-url/eureka/apps/" + appName + "/" + instanceId;
        sourceMap.put(port, appName +"/"+instanceId);
    });
    //创建请求体
    OkHttpClient client = new OkHttpClient();

    if (ObjectUtils.isEmpty(portParams)){
      return "端口为空"; //todo 完善自定义异常
    }
    portParams.forEach(temp->{
        //处理服务信息
        String serviceInfo = sourceMap.get(temp);
        //创建请求去删除服务
        Request request = new Request.Builder()
                .url("http://"+eurekaServer+"/eureka/apps/" + serviceInfo)
                .delete()
                .build();
        log.debug(request.url().toString());
        try {
            Response response = client.newCall(request).execute();
            if (response.code() == 200) {
                log.debug(serviceInfo+"服务下线成功");
                successList.add(temp);
            } else {
                log.debug(serviceInfo+"服务下线失败");
            }
        } catch (IOException e) {
            log.error(e.toString());
        }
    });
    return "goodbye service"+successList;
}

使用这种方法，就是越过了client向一级缓存发送心跳的步骤，直接清除了一级缓存相当节省了极端情况的30S。其实这也是不可取的，因为此时我只是相当于告诉了eureka-Serve，该服务下线了，但是服务进程在没有被关闭的条件下还是会发送心跳向eureka-server的一级缓存同步信息的。
就会导致这样一种情况发生：
在这里插入图片描述

时间过了大约十几秒之后，下线的服务又被注册了回来：
在刚执行完下线服务的接口之后，立即进行远程调用，就出现了异常情况，接口响应时长太长太长：

我的理解：由于调用了下线服务的接口，Eureka-Server中的一级缓存信息被清除了，但是三级缓存以及Ribbon中的缓存并没有被清除（也就是更新）。恰巧负载均衡轮询到了已下线但未更新的服务实例，负载均衡使得调用方成功发送了请求，也就是给了调用方一个假象。值得注意的是，直到此时客户端的服务在物理层面上是没有下线的，他还在向Eureka-server的一级缓存发送心跳并同步到三级缓存来保证服务可用。而这段时间（续约服务）就是接口响应时间过长的原因所在。

压测

15S，使用Jmeter压测模型进行压测，发现接口异常率为0%
在这里插入图片描述
30S，使用Jmeter压测模型进行压测，发现接口异常率为0%

为什么这样的方式在上述的两个时间节点都不会出现问题，这是因为15S，30S后下线的服务已经续约上了，跨服务调用的接口请求还是被负载均衡到了三个服务实例上。
可以想象：当Eureka-Server中的二级缓存去同步一级缓存时，下线的服务已经通过心跳续约到了一级缓存（注册表）中，下线的服务已经重新注册，三级缓存同步二级缓存时，服务都是在线的状态，不存在什么调用到下线的服务。

4.3 调用DiscoveryManager

客户端主动下线，调用DiscoveryManager的API来下线服务（不会关闭进程）。可以通过接口来发送http请求的方式：

@GetMapping(value = "/service-down")
public void offLine(){
    DiscoveryManager.getInstance().shutdownComponent();
}

为了方便下线指定端口，我是这样写的（发请求通过接口调接口）：

 /**
     * DiscoveryManager下线服务
     * @param portParams 下线端口列表
     */
    @GetMapping(value = "/service-down-list")
    public String offLine(@RequestParam List<Integer> portParams) {
        List<Integer> successList = new ArrayList<>();
        //得到服务信息
        List<InstanceInfo> instances = eurekaClient.getInstancesByVipAddress(appName, false);
        List<Integer> servicePorts = instances.stream().map(InstanceInfo::getPort).collect(Collectors.toList());

        //去服务列表里挨个下线
        OkHttpClient client = new OkHttpClient();
        portParams.forEach(temp -> {
            if (servicePorts.contains(temp)) {
                Request request = new Request.Builder()
                        .url("http://" + ipAddress + ":" + temp + "/control/service-down")
                        .build();
                try {
                    Response response = client.newCall(request).execute();
                    if (response.code() == 200) {
                        log.debug(temp + "服务下线成功");
                        successList.add(temp);
                    } else {
                        log.debug(temp + "服务下线失败");
                    }
                } catch (IOException e) {
                    log.error(e.toString());
                }
            }
        });
        return successList + "优雅下线成功";
    }

这样下线之后，客户端服务不会向eureka-server发送心跳，并且在一级缓存中的服务信息也会被立即清除。
理想状态：如果我们通过这样的方式，来下线服务，并且更新Ribbon同步缓存的时间，二级缓存同步三级缓存的时间，客户端同步三级缓存的时间，这样轮询到下线服务的概率是不是会大大减小？（当然更新这个时间应该只是针对原生的Eureka，对于SpringCloudEureka是不适用的）

压测

15S，异常率为0%，但是一级缓存中不存在的服务信息还是会被调用
在这里插入图片描述
30S，一级缓存中不存在的服务信息还是会被调用。

虽然上述两个时间节点的异常率都为0%，但是会负载均衡到刚刚通过api调用后已经下线的服务实例上：

只有在40-50S的时间段才会不调用下线的服务，这段时间主要是在进行Eureka本地缓存的同步（二级同步三级，客户端同步三级，Ribbon同步客户端）

4. 三方工具Actuator

使用第三方工具，actuator来关闭服务，网上发现听说这种方式会让服务把当前请求处理完在关闭，并且会立即停止接受请求（关闭进程），实现起来比较简单只需要引入actuator依赖并且发送指定端口的post请求即可，就像这样：
在这里插入图片描述

/**
     * actuator下线服务列表
     * @param portParams 端口集合
     * @return 优雅
     */
    @GetMapping(value = "/service-down-ports")
    public String downServiceByPorts(@RequestParam List<Integer> portParams) {
        if (ObjectUtils.isEmpty(portParams)) {
            return "端口为空";
        }
        //成功下线列表
        List<Integer> successList = new ArrayList<>();
        OkHttpClient client = new OkHttpClient();
        portParams.forEach(temp -> {
            Request request = new Request.Builder()
                    .url("http://" + ipAddress + ":" + temp + "/actuator/shutdown")
                    .post(RequestBody.create(null, new byte[0]))
                    .build();
            try {
                Response response = client.newCall(request).execute();
                if (response.code() == 200) {
                    log.debug(temp + "服务下线成功");
                    successList.add(temp);
                } else {
                    log.debug(temp + "服务下线失败");
                }
            } catch (IOException e) {
                log.error(e.toString());
            }
        });
        return successList + "优雅下线成功";
    }

服务会被下线，并且Eureka里一级缓存的数据立即会被清除，搭配起更改缓存同步的时间应该也是一个不错的选择（这也是针对原生的Eureka）
15S，异常率高达50%
在这里插入图片描述
30S，异常率为0%

看下来，后两种方案可以直接清理一级缓存，并且服务不会续约。但是由于三级缓存不是实时更新的，所以还是会有调用下线服务导致接口报错的风险。

总结

接口报错的前提是发生了服务调用，发生服务调用的前提是负载均衡，负载均衡的前提是拉取同步信息到Ribbon缓存，而问题就出在这里，即Ribbon加载到了已经下线的服务。想到去清理Ribbon缓存（强制更新）这样做可以减少刷新服务的时间但不能根本解决问题，因为他是从客户端同步的缓存，而客户端又是从三级缓存同步的缓存，所以归根结底在于三级缓存同步二级缓存也就相当于是一级缓存（这个过程时间非常短）。但是springcloudeureka是不能强制更新三级缓存的
好像只能通过缩短感应时间来降低错误发生的概率，不能完全避免错误
对于SpringCloudEureka而言，上面的方式还有很多优化的手段来缩短感知时间，我们下次再来talk about~