LVS负载均衡配置虚拟引起微服务注册混乱

线上小程序突然报错，查看网关日志，访问下游微服务A时大量报错：

1）检查微服务是否未注册。登录eureka页面，发现三个节点均正常注册

三个微服务节点地址分别为：13.9.1.91:8080，13.9.1.92:8080和13.9.1.93:8080

2）查看详细日志，发现网关请求地址为13.9.1.121，也就是说虽然微服务节点正常注册，但请求数据并未分发到实际的微服务节点上。

3）继续排查，发现13.9.1.121为LVS上配置的负载均衡地址。回想起来，系统原来并未使用微服务架构，所以负载均衡采用LVS模式来实现，三个节点的集群配置的虚拟地址就是13.9.1.121，因为采用的DR模式，所以在三个节点上均配置了13.9.1.121，也及时说每个节点都配置了两个IP地址，一个是原来分配到eth0网卡的地址，一个配置在虚拟网卡的负载均衡的虚拟IP地址。所以怀疑是微服务虚拟网卡上的地址通过ARP发布出去，在网关保存（虚拟IP：节点MAC地址）的绑定关系，后继LVS服务器也通过ARP发布虚拟IP地址，从而在网关保存的（虚拟IP:节点MAC）被（虚拟IP：LVS MAC地址），所以网关把请求会转发到LVS，因为该LVS已不再使用，所以连接超时。登录13.9.1.90，检查配置，发现已经配置了ARP抑制（也就既不响应针对虚拟IP的ARP请求，也不广播本地所配置的虚拟IP）

4）到此判断应该是在Eureka中报错的注册信息错误，也就是说在Eureka保存的三个节点的地址均为13.9.1.121，所以网关请求Eureka拿到的地址是13.9.1.121，从而把请求分发到这个并未安装微服务的LVS节点。进一步分析微服务的注册过程，微服务注册时携带instance_id和本地IP地址， instantce_id是从微服务的application.yml中获取，并且显示在Eureka的监控页面上，但在Eureka页面并未显示实际的IP地址。那么实际上注册时的IP地址是什么呢？微服务注册时，遍历所有UP状态的网卡，找到第一个非环回IP地址（环回地址：对于IPV4来说，就是以127开头的地址）作为注册使用的IP地址。

5）问题找到了。在原理使用LVS做负载时，在主机eth0配置了虚拟IP，这样在eth0网卡绑定了两个地址，一个原来的真实IP地址，一个是虚拟IP地址，并且在Linux内核的IP地址列表中虚拟地址在前，真实IP地址在后，微服务注册时，获取到的第一个非环回地址正是虚拟IP地址，所以在Eureka保存的微服务的地址为虚拟IP地址，网关分发请求时，从Eureka获取到的是虚拟IP地址13.9.1.121，请求被分发到了原来的LVS服务，所以在网关报500错误。

6）进一步分析。为什么原来一切正常，突然出现这个问题？

问了一下运维人员，微服务节点虚机操作系统在晚上被重启了。根源找到了，因为节点上配置了两个地址（虽然不再使用原来的负载均衡，但原来为了负载均衡而配置的虚拟IP地址并未删除），但虚拟IP对应的虚拟网卡原来通过命令行DOWN掉了，所以注册时IP地址为物理IP地址，系统重启后，虚拟IP所在网卡自动进入UP状态，所以注册时获取的地址就是虚拟IP地址，从而导致流量分发目的地错误。

总结：

1）在主机上，没有的配置信息该删除的删除掉。比如当前问题主机上的虚拟网卡和虚拟IP地址

2）在微服务的配置文件中使用eureka.instance.ip-address 直接指定注册时使用的IP地址