Eureka Client是通过Jersey Client基于Http协议与Eureka Server交互来注册服务、续约服务、取消服务、服务查询等。同时，Server端还会维护一份服务实例清单，并每隔90s对未续约的实例进行失效剔除。
Eureka Server有一个自我保护机制，当网络发生故障时，客户端与服务端不通，这是需要启动Eureka Server的自我保护机制，这样不会剔除服务，当网络恢复时，退出自我保护。自我保护有两个参数，最后一分钟收到的心跳数（Renews (last min)）、期望收到的心跳数（Renews threshold），当Renews threshold > Renews (last min) 时，进入自我保护模式。
Renews (last min) = 实例数 * 2 #实例数算上Eureka Server自注册服务
Renews threshold = Renews (last min) * 0.85 # 0.85可配置
下图的注册中有10个实例：
推荐多个Eureka Server部署时，开启自我保护
eureka.client.register-with-eureka = true 1.3、分布式注册中心了解了注册中心的工作原理，下面开始研究分布式服务，多注册中心、多服务实例的情况。
当微服务仅向一台注册中心注册时，当这个注册中心发生故障时，新服务无法继续注册上去，旧服务的注册信息，缓存在其他注册中心和客户端中，依旧可以使用，当重启之后，无法向注册中心注册，也是无法使用的。
因此构建高可用的注册中心时，需要交叉注册，每个注册中心既当服务端，又当客户端，向其他注册中心注册自己，同时微服务需要向每个注册中心进行注册，由注册中心自己过滤互备，防止单个注册中心故障而导致只往它上面注册微服务重启后不可用。示意图如下所示。
目前注册中心与配置中心集中在一起，可拆可不拆，对整体影响不大，拆分是为了注册中心和配置中心相互间不影响。gitlab部署在某一台机器上，所有config共用，由于gitlab的原因，导致config的分布式存在单点故障的隐患。每个config分别用独立的gitlab，又给运维带来极大的不便。后期采用apollo，用数据库存储配置，利用数据库的分布式优势替代gitlab，来解决单点故障的问题。
1.4、注册中心压测根据压测调研，8核4G的Eureka Server在处理1000个服务实例时，没有任何压力，在默认情况下，可以处理7000个实例，超出的会超时报错，在修改tomcat的配置之后，最多可以承载8000实例，此时CPU基本满载。
升级注意事项：
1、Eureka Server之间相互注册，Eureka Client需要在每个Server上都注册一边
2、Eureka Server开启自我保护
3、Eureka Client的实例数不超过1000个
参考：[1] https://www.jianshu.com/p/ae4f0c8b8135
[2] https://www.cnblogs.com/xishuai/p/spring-cloud-eureka-safe.html