【.com原稿】负载均衡是实现网络就近访问的核心技术之一。将流量相对均匀地分配给能够完成相同任务的N个网络节点或服务器，避免出现负载压力不均的情况。负载均衡作为应用流量的入口，直接影响应用的性能和可靠性。近日，以“TechNeo”为主题的第十五期技术沙龙在北京举行。本次沙龙邀请到了美团云负载均衡网关MGW产品研发负责人王伟。多年负载均衡系统一线实施经验，主导和推动MGW（美团四层负载均衡）的技术选型和性能优化。在这篇文章中，我们可以了解到承载美团点评数十Gbps流量、千万级并发连接数的MGW，如何做到高性能、高可靠，以及详细的优化过程。负载均衡和分类的作用互联网早期，业务逻辑简单，流量不大，单台服务器即可满足日常需求。随着互联网的发展，业务流量不仅会呈爆炸式增长，逻辑也会越来越复杂，对可靠性的需求也会逐渐增加。这时候就需要多台服务器来应对单台服务器在性能和单点方面突出的问题，进行性能的横向扩展和容灾。但是客户端流量如何顺利访问这么多不同的服务器是个问题。对于这个问题，可以选择使用DNS作为负载来解析客户端的不同IP地址，让流量直达不同的应用服务器。但是这种调度策略比较简单，并不能很好的满足业务需求。当调度方案发生变化时，各级DNS节点的缓存不能及时在客户端生效，会造成严重的延迟问题。这时候可以选择使用负载均衡，如下图：到不同应用程序服务器的流量。同时，负载均衡服务器定期对应用服务器进行健康检查。一旦检测到故障节点，将直接淘汰，保证应用的高可用。负载均衡分为四层和七层两种，如下图所示：四层负载均衡的核心是转发。收到客户端流量后，修改数据包的地址信息，转发给应用服务器。整个过程在OSI模型的传输层完成。七层复合平衡的核心是代理，它在收到来自客户端的流量后，通过完整的TCP/IP协议栈对应用层流量进行分析。然后根据调度算法选择合适的应用服务器，与应用服务器建立连接发送请求。整个过程在OSI模型的应用层完成。四层负载均衡的转发方式转发是四层负载均衡的主要工作。目前主要有四种转发模式：DR模式、NAT模式、TUNNEL模式和FULLNAT模式。下面是四种转发模式的优缺点对比图：从图中可以直观的看出四种转发模式的优缺点。DR模式（三角传输）的实现是修改数据包的目的MAC地址；NAT模式的实现方法是修改数据包的目的IP地址；TUNNEL模式的实现方法与DR相同，但应用服务器必须支持TUNNEL功能。美团点评最终选择了FULLNAT作为MGW的转发模式，在NAT模式的基础上进行源地址转换（SNAT）。这种模式的好处是响应流量可以通过正常的三层路由返回到负载均衡器，负载均衡器不需要以网管的形式存在于网络中，从而降低了对网络的要求环境。缺点是在做SNAT时，应用服务器会丢失客户端的真实IP地址。下图是FULLNAT转发模式的具体实现过程：如图所示，负载均衡器上部署了一个localip池，SNAT过程中从中获取源IP。当客户端流量到达负载均衡设备时，负载均衡根据调度策略在应用服务器池中选择一个应用服务器，并将数据包的目的IP修改为该应用服务器IP。同时从localip池中选择一个localip，将数据包的源IP改为localip，这样应用服务器响应时，目的IP为localip，localip为负载上实际存在的IP地址balancer，所以可以通过正常的三层路由到达负载均衡器。与NAT模式相比，FULLNAT模式会多执行一次SNAT，过程中还有一个端口选择的操作，在性能上略弱于NAT模式，但FULLNAT模式在网络适应性上有优势。采用高性能高可靠四层负载均衡的原因美团点评为何选择自研四层负载均衡？主要原因有两个：业务流量越来越大，LVS性能瓶颈和运维成本越来越高。使用硬件负载平衡，成本是门槛。在LVS方面，美团点评最初的做法是用LVS做四层负载均衡，用Nginx做七层负载均衡。如上图所示，流量高速增长，LVS性能出现瓶颈，故障率增加。在硬件负载均衡方面，存在三个突出问题：异常高的硬件成本、人力成本和时间成本。基于这两个原因，美团点评决定自研四层负载均衡MGW来替代LVS。MGW需要满足高性能和高可靠性两大特点。那么如何实现高性能和高可靠性呢？MGW实现高性能的四大问题及解决方案通过对比LVS的一些性能瓶颈，我们可以直观的了解到MGW实现高性能的解决方案。这主要涉及到LVS遇到的四大问题：中断、协议栈路径长、锁、上下文切换。MGW针对这些问题的解决方案是PMD驱动、Kernelbypass、无锁设计、CPU绑定和隔离。中断LVS是在内核中完成的，内核设计时要考虑到通用性，所以采用中断的方式来感知流量的接收。中断对LVS性能影响很大。如果每秒处理500万个数据包，每5个数据包产生一个硬件中断，那么一秒内就会产生100万个硬件中断，每产生一个硬件中断就会打断正在进行的进程。计算密集的负载均衡程序会产生大量的缓存未命中，对性能影响很大。协议栈路径太长是因为LVS是基于内核netfilter开发的应用，而netfilter是运行在内核协议栈上的hook框架。当一个数据包到达LVS时，要经过一个漫长的协议栈过程。实际情况是负载均衡器收到流量后，只需要修改MAC、IP、端口就可以发送出去，不需要这个处理增加额外的消耗。解决中断和协议栈路径过长这两个问题的方法是使用DPDK提供的用户态PMD驱动，做Kernelbypass。DPDK在设计过程中大量使用了硬件特性，如numa、内存通道、DDIO等，极大地提高了性能。同时提供网络库，降低开发难度，提高开发效率。这些都是美团点评选择DPDK作为MGW开发框架的因素。锁内核是一个比较通用的应用程序。为了兼顾不同的硬件，在设计过程中会加入一些锁。而自主研发只需要针对一些特定场景进行定制化设计，无需考虑很多硬件，然后通过一些方法解除锁定，达到完全无锁状态，方便后续扩展。我们先来看看锁需要设计什么。首先介绍一下RSS（ReceiveSideScaling）。RSS是通过数据包的元组信息，将数据包散列到不同网卡队列的功能。这时候不同的CPU去对应的网卡队列中读取数据进行处理。充分利用CPU资源。MGW采用FULLNAT方式，会改变数据包的所有元组信息。这样对于同一个连接，request和response方向的数据包可能会被RSS散列到不同的网卡队列中，而在不同的网卡队列中就意味着它们被不同的CPU处理。这时候在访问session结构的时候，就是需要用锁来保护这个结构。解决这个问题一般有两种方案：在做SNAT端口选择时，通过选择端口lport0使RSS(cip0,cport0,vip0,vport0)=RSS(dip0,dport0,lip0,lport0)相等。为每个CPU分配一个localip。在做SNAT选择IP的时候，不同的CPU选择自己的localips。当response返回时，通过lip和cpu的映射关系将指定目的IP的数据包发送到指定队列。由于第二种方式刚好是网卡的flowdirector特性支持的，所以MCW选择第二种方式解除session结构的锁。Flowdirector可以按照一定的策略将指定的数据包发送到指定的网卡队列中。它在网卡中的优先级高于RSS，所以在初始化时为每个CPU分配了一个localip：比如分配lip0给cpu0，分配lip1给cpu1，lip2给cpu2，lip3给cpu3。当一个请求数据包（cip0，cport0，vip0，vport0）到达负载均衡器时，它被RSS散列到队列0，并由cpu0处理该数据包。cpu0对其进行fullnat时，会选择cpu0自己的localiplip0，然后将数据包（lip0，lport0，dip0，dport0）发送给应用服务器。应用服务器响应后，将响应数据包（dip0，dport0，lip0，lport0）发送给负载均衡服务器。这样就可以在flowdirector下设置将目的IP为lip0的数据包发送到queue0的规则，这样响应的数据包就会被发送到queue0，让cpu0处理。此时CPU处理同一个连接的两个方向的数据包时，完全是串行操作，不需要对session结构进行加锁和保护。上下文切换MGW为了解决上下文切换的问题，设计了对CPU进行分组，实现控制平面和数据平面完全分离的状态，可以很好的避免数据平面处理的中断，如下图所示：同时，隔离数据平面的CPU，使得控制平面进程不去调度数据平面的CPU；数据面线程的CPU必然要实现每个数据线程独占一个CPU。控制平面的程序运行在控制平面的CPU上，如Linux内核、SSH等。MGW实现高可靠性的方案这里主要介绍MGW集群、MGW单机和应用服务器三层实现高可靠性的方法。MGW集群的高可靠主要涉及三个部分：会话同步、故障转移、故障转移和扩容。如下图，MGW采用ECMP+OSPF的模式组成集群：ECMP的作用是将数据包hash到集群中的各个节点，然后使用OSPF保证本机的路由是正确的单机故障后动态移除。这样ECMP就不会再给本机分发流量了，实现了动态failover。会话同步传统的ECMP算法存在严重的问题。当复杂平衡集群中的节点数量发生变化时，大部分流量的路径都会发生变化。变化的流量到达其他MGW节点，找不到自己的会话结构，会造成大量连接异常，对业务影响很大，而且集群升级时，每个节点都会下线一次，加剧了这个问题的影响。传统的解决方案是使用支持一致性哈希的交换机，如下图所示。传统的解决方案是使用支持一致性哈希的交换机。当一个节点发生变化时，只会影响变化节点上的连接，其他连接保持正常，但是支持该算法的交换机比较少，没有完全实现高可用，所以需要集群间的session同步，如下图所示：集群中的每个节点都会完全同步自己的会话，从而使集群中的每个节点都维护一个全局会话表。这样，当节点发生变化，流量路径发生任何形式的变化时，流量都能找到自己的会话结构。其次，failover、failover和扩容是整个集群间session同步过程中首要考虑的两个问题。Failover针对的是failover的问题。当一台机器出现故障时，交换机可以立即将流量切换到其他机器上，避免大量丢包。MGW经过研究测试，采用下图所示的操作方式，可以做到升级操作0丢包，主程序故障0丢包，其他异常（网线等）都会有一个包loss高达500ms，因为这个异常需要依赖自检程序来检测，而自检程序的周期是500ms。具体包括以下四个方面：交换机侧不使用虚接口。当所有物理接口都用完，服务器端接口断电时，交换机会瞬间将流量切换到其他机器上。通过100ms发送两个包的测试（客户端和服务端各发送一个），表明这种操作方式可以做到零丢包。机器健康状况每半秒自检一次。故障转移主要取决于交换机的感知。当服务器出现异常而交换机检测不到时，交换机就无法进行failover操作。所以需要一个健康自检程序，每半秒进行一次健康自检。当发现服务器存在异常时，对服务器进行网口断电操作，立即切断流量。当检测到故障时，网口自动断电。Failover主要依靠网口的断电操作，网卡驱动运行在主程序中。当主程序挂掉时，无法进行网口断电操作。主进程将捕获异常信号。鉴于主程序挂掉后，网口无法断电。主进程会捕获异常信号。当发现异常时，网卡将被断电。系统的进程。故障恢复和扩容当系统进行故障恢复和扩容操作时，集群节点的数量会发生变化，进而导致流量路径发生变化。因为当变化的流量到达集群中的原节点时，原节点维护了一个全局会话表，所以这些流量可以正常转发；但是当流量到达新机器时，由于新机器没有全局会话表，所有流量都会被丢弃。为了解决这个问题，MGW在上线后会经过pre-online这个中间状态。在这种状态下，MGW不会让交换机感知到自己在线，所以交换机不会进行流量切换。实现过程是MGW先向集群中的其他节点发送批量同步请求。其他节点收到请求后，会将自己的所有会话同步到新上线的节点上。新上线的节点在收到所有会话后才会让交换机感知到它。当你上线时，交换机再次切入流量，可以正常转发。这里需要提醒两点：第一：由于集群中没有主控节点维护一个全局状态，如果request上报的数据丢失或者session同步的数据丢失，那么新上线节点无法维护全局会话状态。但是考虑到所有的节点都维护一个全局的会话表，所以所有的节点都有相同的会话数，那么可以在所有节点的每一次批量同步之后发送一个finish消息，这个finish消息携带自己拥有的会话数。当新的在线节点收到完成消息时，它会将自己的会话数与完成数进行比较。当达到数量要求时，新上线的节点会控制自己上线。否则，等待一定的超时时间后，再次进行批量同步操作，直至满足要求。第二：在批量同步操作过程中，如果有新连接，新连接不会通过批量同步同步到新上线的机器上。如果新连接太多，新上线的机器将无法满足要求。所以需要保证在线前状态的机器能够接收到增量同步数据，因为新的连接可以通过增量同步来同步。增量同步和批量同步可以保证新上线的机器最终能得到一张全局的会话表。MGW单机自动化测试平台单机高可靠性，MGW开发自动化测试平台，通过连接和配置的正确性来判断测试用例是否执行成功，失败的测试用例平台可以邮件通知测试人员。每次新功能迭代后，都会将新功能的测试用例添加到自动化平台，这样每次上线前都会进行自动化测试，可以大大避免变更带来的问题。在此之前，每次上线前都需要进行人工回归测试。回归测试非常耗时，而且很容易遗漏用例，但为了避免变更带来新的问题，又不得不做。借助自动化测试平台，回归可以提高测试效率和可靠性。应用服务器在应用服务器可靠性方面，MGW部署了两个功能：平滑节点下线和一致源IPHash调度器。节点平滑下线节点功能主要是解决当用户需要升级RS时，如果需要升级的RS直接下线，这个RS上存在的所有连接都会失效，影响业务。此时如果调用MGW的平滑下线功能，则MGW可以保证该RS已有的连接正常工作，但不会为其调度新的连接。当所有现有连接结束后，MGW会上报结束状态，用户可以根据结束状态对RS进行升级，升级完成后，调用在线接口让RS进行正常的业务。如果用户平台支持应用自动化部署，您可以通过连接云平台使用平滑离线功能，实现对业务无影响的全自动化升级操作。ConsistentSourceIPHashScheduler源IPHash调度器主要是保证同一个客户端的连接被调度到同一个应用服务器上，也就是在客户端和应用之间建立一对一的映射关系服务器。同源IPHash调度器会在应用服务器发生变化后改变映射关系，影响业务。一致的源IPHash调度器保证当应用服务器集群发生变化时，只有变化的应用服务器与客户端的映射关系发生变化，其他不变。为了保证流量的均衡，首先在哈希环上分配固定数量的虚拟节点，然后再均衡地将虚拟机节点重新分配给物理节点。重分配算法需要保证：当物理节点发生变化时，只有少数虚拟节点的映射关系发生变化，这是保证Hash一致的基本原则。由于MGW以集群的形式存在，当多个应用服务器上线或下线时，反馈给不同的MGW节点可能会造成顺序不一致。因此，无论是什么应用，都需要保证最终的映射关系在服务器上线和下线的顺序上是一致的，因为如果不一致，同一个客户端的连接会被不同的调度到不同的应用服务器上MGW节点，违反了源IPHash调度器的原则。技术展望未来，美团点评将主要围绕这三个方面展开：升级自动化、集中配置管理、降低运维成本。升级自动化。最初，自研MGW是为了解决LVS的性能问题。这些问题解决后，随着业务的快速发展，IDC规模不断扩大，负载集群越来越多。例如，一个新的IDC上线，通常会推出两套。集群分别用于IDC入口和内部业务。在这种情况下，更大的问题出现了。比如一个新功能发布的时候，周期会很长，所以需要实现自动升级。当然，还需要同步完善监测异常的监测措施。集中配置管理。目前业务配置已经实现了集中配置，希望以后也能实现机器配置。降低运营和维护成本。实现自动化升级，集中配置最根本的目的是降低运维成本。【嘉宾介绍】王伟，美团云技术专家。2015年加入美团云，现任美团云负载均衡网关MGW产品开发负责人。拥有多年负载均衡系统一线实施经验，主导并推动了MGW的技术选型和性能优化。沙龙其他文章深入剖析CDN痛点，互联网老手说说CDN那些事！每天数亿视频播放量，秒拍播放链接优化实践10月28日/北京，第16届“TechNeo”沙龙，主题：“自动化运维与DevOps”，点击图片立即报名。【原创稿件，合作网站转载请注明原作者和出处为.com】
