基于Eureka的微服务心跳监控

设计原因

    为什么要基于Eureka再做一个监控微服务连通性监控？ Eureka本身不是已经有监控吗？
    原因在于，微服务会假死，实际请求都已经超时失败了。有了连通性的监控，可以第一时间的发现问题，早修复，减少用户影响。

    如上图，由于有一个服务假死了但是还在注册中心中正常注册着，最终导致技术小哥没有及时发现这个问题进行修复，而用户小王在页面上久久没有得到想要的返回结果，小王很生气，要退款。
    退款是不可能的，但是对这个问题进行及时的吸收修复，确保后面大幅度减少这个问题对用户的波及，这个可以有，经过安抚，小王愿意再给我们一次机会。由此，一个监控微服务连通性的心跳监控，马上被提上了日程。
    那么为了实现连通性的监控，具体要实现以下几点：

• 扫描Eureka中注册的结点。
• 通过注册服务的info请求（模拟业务请求，也可以是约定好的其他请求）的返回状态和响应时间来校验服务的请求是否还能存活，是否有异常风险。
• 发现问题时，通过送钉钉消息发送警告，并@到相关人员。

设计思路

    基于上图的流程，我们还需要将它绑定定时任务进行定时请求。由此，一个简单的基于Eureka的微服务心跳监控可以继续下一步实现。

实操

框架选型

    对于这个监控，我们比较容易可以提炼出这么几个关键字：请求，解析，断言。看到这里，做过接口测试或者是对接口测试有了解的小伙伴是不是觉得这几个关键字极为眼熟？
    是的，我们首先需要有一个请求的框架，当然基于HttpClient和其他一些框架都能很好的实现我们的需求，但是我最终选用的是rest-assured，因为它集请求，解析，断言为一体，从实现上可以大大减少投入的时间成本。由下面的代码块可见，请求，断言，获取返回值非常的简单。

	// 请求Eureka，断言返回状态为200，相