属于一个线上的问题，就大概介绍下处理

背景

一个需要需要进行内外网流量的切分（基于dns）外部dns 解析到一个公网ip，然后公网ip 映射到内网的lvs vip 
为了部署简单，内网流量以及外网流量使用了一套keepalived（dr 模式，够用了），不同业务流量的请求到vip 
然后vip 转发到实际提供服务的服务器节点

现象

在进行测试阶段，配置好keepavlied 之后，测试lb 都是正常的（包括内网网的处理，但是外网的是基于内部vip的） 
在基本的测试都没问题之后，添加了外网ip到内网的映射（基于F5），同时修改了dns A记录（以前外网的ip还可用，这样业务影响很小） 
dns 切换完成之后，观测外网服务节点的流量很比较正常（基于prometheus+node exporter），然后晚上突然收到报警服务 
有异常，因为在路上，只能手机测试下（没有问题，应该不是100%问题），后边过了20分钟，收到短信通知服务恢 
复（实际上系统负载小了，系统自动恢复可用了）

排查

到家之后，查看系统配置(通过vpn)，以及lvs 状态，发现一个很怪异的问题，lvs 外网流量只有一个节点可处理请求，其他节点基本就是空闲状态 
自然怀疑lvs 是不是故障了，但是内网流量很正常，lvs real server 的配置也没问题，一句话系统的负载均衡有问题，因为排查很晚了，还没解决 
就休息了（临时调整了一些服务器参数，保障业务处理会好点）

找到问题原因

第二天到公司，查看服务的请求日志发现了一个比较怪异的问题，理论上我是要内外网流量切换的，但是提供服务的机器，获取到的一直是同一个ip 
（F5入口的），这个就比较怪异了，而且也不应该的，因为我们系统需要回话的处理，keepalived 配置了回话保持，基于lvs的策略，负载当然就不均 
衡了（之前还尝试过修改lvs 的负载均衡算法，按照实际的请求都是一个ip，修改也没用），之后联系开通外网ip的同事，调整f5提供ip 的模式，让 
用户端ip可以透传到lvs 的vip 请求数据包中，通过ipvsadmn -ln 观测master 的链接请求，负载均衡立马正常，各real server 都可以提供服务了，系统 
响应以及状态也都慢慢正常了

说明

以上是一个关于lvs的问题，很多时候我们可能只关注了一点，同时只测试了系统的部分链路，这样可能就会有风险，同时我们在搞方案设计的时候 
应该对于整个请求的链路以及环节都应该清楚点，至少解决问题会快很多，不会那么盲目，还有就是多看看源码，了解系统的工作原理也是很重要的