前言：笔者曾经有18年的硬件研发经验，从（1）51单片机到（2）FPGA到（3）嵌入式ARM(ARM9到CORTEX A9)全都研发设计过，产品从（1）B超的整机研发到（2）智能家居系统到（3）无线电监测机到（4）平板电脑研发到（5）路灯智能控制到（5）工业电脑均有涉及，从（1）普通的电子技术工程师到（2）副总工程师到（3）副总经理到（4）事业部总经理。。。目前已经步入不惑之年的我对于物联网技术的热衷，决定从硬件开始全面转到物联技术框架之一的spring cloud技术，把我的整个学习经历和大家一起分享，也期待在之后有更多机会和大家一起合作，探讨。
今天是：2018年4月10日 研究主题：euerka server的“剔除任务”和“服务续约”
一、在注册完服务后，服务提供者会维护一个心跳用来持续告诉Eureka Server：“我还活着”，以防止Eureka Server的“剔除任务”将该服务实例从服务列表中排除出去，我们称该操作为服务续约。
1、关于服务续约有两个重要属性，如下：
eureka.instance.lease-renewal-interval-in-seconds=30 eureka.instance.lease-expiration-duration-in-seconds=90
其中：eureka.instance.lease-renewal-interval-in-seconds表示定义服务续约任务的调用间隔时间，默认为30秒；eureka.instance.lease-expiration-duration-in-seconds表示定义服务失效的时间，默认为90秒。
2、自我保护：
当我们在本地调试基于Eureka的程序是，基本上都会碰到这样一个问题，在服务注册中心的信息面板中出现类似下面的红色警告信息：
实际上，该警告就是触发了Eureka Server的自我保护机制。由于服务注册到Eureka Server之后，会维护一个心跳连接，告诉Eureka Server自己还活着。Eureka Serverz哎运行期间，会统计心跳失败的比例在15分钟之内是否低于85%，如果出现低于的情况（在单机调试的时候很容易满足，实际在生产环境上通常是由于网络不稳定导致），Eureka Server会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。但是，在这段保护期间内实例若出现问题，那么客户端很容易拿到实际已经不存在的服务实例，会出现调用失败的情况，所以客户端必须要有容错机制，比如可以使用请求重试、断路器等机制。
由于本地调试很容易触发注册中心的保护机制，这会使得注册中心维护的服务实例不那么准确。所以，我们在本地进行开发的时候，可以使用eureka.server.enable-self-preservation=false参数来关闭保护机制，以确保注册中心可以将不可用的实例正确剔除。
以上文字太多，看起来头痛，但主要我记录下来便于后期可以查找，因为这个保护机制经常出现，之前一直不知道根本原因，记录下来了后期可以随时查询。