服务自保-心法总决

服务自保

服务剔除，服务自保，这两套功法一邪一正，俨然就是失传多年的上乘心法的上卷和下卷。但是往往你施展了服务剔除便无法施展服务自保，而施展了服务自保，便无法施展服务剔除。也就是说，注册中心在同一时刻，只能施展一种心法，不可两种同时施展。

心法总决

服务剔除把服务节点果断剔除，即使你的续约请求晚了一步也毫不留情，招式凌厉，重在当断则断，忍痛割爱。心法总决简明扼要;

欲练此功，必先自宫

服务自保把当前所有节点保留，一个都不能少，绝不放弃任何队友。心法的指导思想是，即便主动删除，也许并不能解决问题，且放之任之，以不变应万变。心法总决引人深思:

宫了以后，未必成功
如果不宫，或可成功

在实际应用里，并不是所有无心跳的服务都不可用，也许因为短暂的网络抖动等原因，导致服务节点与注册中心之间续约不上，但服务节点之间的调用还是属于可用状态，这时如果强行剔除服务节点，可能会造成大范围的业务停滞。

由此可见，这两套心法都是各走极端，只有相互搭配使用才能中和。大家用心体会就好，至于心法还是不要去身体力行照着修炼了。

服务自保的触发机关

服务自保由两个开关进行控制

自动开关

看过我前面的文章，相信小伙伴们对注册中心的Portal已经很熟悉了，你们有没有注意到页面上出现了这么一行大红英文：

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INS TANCES ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSE R THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.

这就是服务自保开启后的警告，意思是说，挂掉的服务有可能会被错误的当做UP，(在一定时间内)续约成功的节点个数占已注册总服务的比值，已经低于限定值，因此所有节点都不会过期，服务自保开启。

这是一个服务自保的自动触发开关，简单来说，服务自保机制会检查过去15分钟以内，所有成功续约的节点，占所有注册节点的比例，如果低于一个限定值(比如85%)就开启服务自保模式。

服务自保模式往往是为了应对短暂的网络环境问题，在理想情况下服务节点的续约成功率应该接近100%，如果突然发生网络问题，比如一部分机房无法连接到注册中心，这时候续约成功率有可能大幅降低。但考虑到Eureka采用客户端的服务发现模式，客户端手里有所有节点的地址，如果服务节点只是因为网络原因无法续约但其自身服务是可用的，那么客户端仍然可以成功发起调用请求。这样就避免了被服务剔除给错杀。

手动开关

这是服务自保的总闸，以下配置将强制关闭服务自保，即便上面的自动开关被触发，也不能开启自保功能
eureka.server.enable-self-preservation=false

本文已收录至我的个人网站：程序员波特，主要记录Java相关技术系列教程，共享电子书、Java学习路线、视频教程、简历模板和面试题等学习资源，让想要学习的你，不再迷茫。