在第三章（服务治理）的服务治理机制一节（p55）
书中提到:
服务注册到Eureka Server之后，会维持一个心跳连接，告诉Eureka Server自己还活着。Eureka Server在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%，如果出现低于的情况（在单机调试的时候很容易满足，实际在生产环境上通常是由于网络不稳定导致），Eureka会将这些实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。
这里“会统计心跳失败的比例在15分钟之内是否低于85%”很难理解。我在google上一番搜索，找到netflix eureka的github repository，上面有个issue。说：
If any time, the heartbeat from all clients, a.k.a renewals falls below a percentage which by default configured to 85% in 15min, the server stops expiring instances. This will happen usually by either kill -9on client or network unreachable.
For example, there are 50 endpoints, and eureka expects 100 heartbeats per min.
If due to some reason, the heartbeats drops to 80 which is below 85, and eureka will disable expiration, so there are 10 endpoints (should be 20 heartbeats) unavailable.
But what if this is a permanent state? People just kill -9 on the 10 endpoints to make them offline? Eureka server will hold these unavailable endpoints for as long as possible because expiration is disabled. Is this case make sense?
翻译过来可能是：
无论何时，如果所有客户端的心跳发送成功的比例降到一定水准（默认是15分钟内85%），服务器会不在移除过期实例。这通常在对客户端kill -9或网络不可用时发生。
例如，有50个endpoints，并且eureka正常时每分钟接收100个心跳。
如果，因为某些原因，心跳降到80（低于85），eureka会不在移除过期实例，所以有10个endpoints不可用。
但如果这是一个永恒持续性的状态怎么办？有人就是用在10个endpoints上用kill -9使他们断线。那么，因为服务器不再移除过期实例了，Eureka服务器会尽可能的久地保持这些
不可用的endpoints。这么说能理解吗？
这样好理解多了，我的理解是Eureka服务器会智能判断如果有大规模的群体故障发生，那么也许不是程序崩溃或者简单的内存不足，可能是因为短暂性的网络延迟，所以它会智能地保存住已有的节点信息，不去移除过期的节点，而等待他们恢复。