网站推广营销案例,龙井建设局网站,wordpress积分主题,手机搭建平台网站线上小程序突然报错#xff0c;查看网关日志#xff0c;访问下游微服务A时大量报错#xff1a; 1#xff09;检查微服务是否未注册。登录eureka页面#xff0c;发现三个节点均正常注册
三个微服务节点地址分别为#xff1a;13.9.1.91:8080#xff0c;13.9.1.92:8080和1…线上小程序突然报错查看网关日志访问下游微服务A时大量报错 1检查微服务是否未注册。登录eureka页面发现三个节点均正常注册
三个微服务节点地址分别为13.9.1.91:808013.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被虚拟IPLVS 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地址
