图11、VGW业务模型图
4.5 VGW的冗余保障
为了提高可用性，那么考虑哪些风险？大家自然而然的考虑到服务器故障、进程故障等场景。但VGW场景需要考虑更多，因为VGW整个系统包括了链路、网络设备、服务器、进程等。而且还不能只考虑设备宕机这种简单的场景，实际上，上述任何设备出现不宕机但转发异常的情况才是最麻烦的。
所以监控VGW服务转发是不是正常是第一步，我们通过布放在不同机房和地区的探测节点定期和VIP建立连接，通过建立连接的失败比列来作为衡量VGW是不是正常的标准。实际上，该监控相当于检测了整个涉及VGW的所有环节的链路和转发是不是良好的。
上面的监控覆盖到的是集群级别的探测，当然我们也建立了其他更细粒度的监控来发现具体问题点。
在有监控一手数据之后，我们就能提供服务器级别故障处理和集群级别的故障处理能力。
- 所有设备级别的直接宕机，VGW做到自动隔离；
- 所有链路级别的异常，一部分能自动隔离；
- 所有进程级别的异常，能达到自动隔离；
- 其他非完全故障的异常，人工介入隔离。
服务器级别故障隔离是将某一些VGW服务器通过路由调整将取消VIP的发布，从而达到隔离目的；
集群级别故障隔离是将整个VGW集群的VIP取消发布，让流量自动被备用集群牵引，由备用集群接管所有业务流量。
图12、服务器、链路级别故障隔离
图13、集群级别的故障隔离
4.6 如何提高VGW性能
随着业务量级越来越大，VGW单机要接收近百万的QPS请求，同时要达到500W/s以上的包处理能力。显然一般服务器根本无法达到这么大量的请求和包处理速度，主要原因在于Linux的网络处理机制。网络数据包都必须经过Linux内核，网卡收到数据包后都要发送中断给CPU，由CPU在内核处理，然后再拷贝一份副本给应用程序。发送数据也要经过内核进行处理一遍。频繁的中断、用户空间和内核空间之间不断的拷贝数据，导致CPU时长严重被消耗在了网络数据处理上，包速率越大，性能越差。当然还有其他诸如Cache Miss，跨CPU的数据拷贝消耗等等问题。
这里会很容易想到，能不能把上面CPU*这些脏活累活扔网卡去干了，CPU就纯粹处理业务数据就行。目前很多方案就是根据这个想法来的，硬件方案有智能网卡，纯软件方案当前用的较多的是DPDK（Intel Data Plane Development Kit）。显然智能网卡的成本会偏高，而且还在发展阶段，应用有一定成本。而DPDK纯软件来说在成本和可控方面要好得多，我们选择了DPDK作为底层的包转发组件（实际上是基于爱奇艺开源的DPVS的二次开发）。
DPDK主要是拦截了内核的包处理流程，将用户数据包直接上送至应用程序中，而不是由内核进行处理。同时摈弃了依靠网卡中断的方式处理数据的行为，转而采用轮询的方式从网卡中读取数据，从达到降低CPU中断的目的。当然还利用了CPU亲和性，使用固定的CPU处理网卡数据，减少进程的切换消耗。另外还有很多关于Cache、内存等方面的优化技术。总体上能够将服务器网卡包处理速度达到千万PPS，极大提升网卡的包处理能力，进而能提升服务器的CPS（每秒新建连接数目）。当前我们在100G网卡下，能够达到 100w 的CPS和1200w PPS的业务处理量（有限条件下的测试结果，非理论值）。
图14、VGW使用的底层工具DPVS（DPDK LVS）对比几种现有的负载均衡方案性能
五、总结
通过上述讲解，我们逐步从一个业务可靠性的需求推演出一套可行的负载均衡方案，同时结合vivo的实际需求，落地了我们的VGW负载均衡接入平台。当然，当前的负载均衡方案都是大量取舍后的结果，不可能做到完美。同时我们未来还面临着新的业务协议支持的问题，以及数据中心去中心化的业务模型对负载均衡的集中式控制之间冲突的问题。但技术一直在进步，但总会找到合适的方案的！
作者：vivo 互联网运维团队- Duan Chengping
来源:微信公众号:vivo互联网技术
出处:https://mp.weixin.qq.com/s/hPB3STR39MuoSAJkf1pYmg
