重庆建网站优化,网站运营是做什么的怎么样,长沙网警,网站建设需要哪些职位本文整理自美团点评技术沙龙第14期#xff1a;美团背后的故事#xff0d;你不知道的美团云。 美团点评技术沙龙由美团点评技术团队主办#xff0c;每月一期。每期沙龙邀请美团点评及其他互联网公司的技术专家分享来自一线的实践经验#xff0c;覆盖各主要技术领域。 目前沙… 本文整理自美团点评技术沙龙第14期美团背后的故事你不知道的美团云。 美团点评技术沙龙由美团点评技术团队主办每月一期。每期沙龙邀请美团点评及其他互联网公司的技术专家分享来自一线的实践经验覆盖各主要技术领域。 目前沙龙会分别在北京、上海和厦门等地举行要参加下一次最新沙龙活动赶快关注微信公众号“美团点评技术团队”。 本期沙龙包括三场讲座美团云Docker平台、美团云对象存储系统、美团四层负载均衡网关MGW。其他几场讲座的图文实录会陆续发表请继续关注。 在高速发展的移动互联网时代负载均衡有着举足轻重的地位它是应用流量的入口对应用的可靠性和性能起着决定性的作用因此负载均衡需要满足高性能、高可靠两个特点。MGW是美团点评自研的一款四层负载均衡主要用于替代原有环境的四层负载均衡LVS目前处理着美团点评数十 Gbps的流量、上千万的并发连接。本文主要介绍MGW是如何实现高性能、高可靠的。 互联网早期业务流量比较小并且业务逻辑比较简单单台服务器便可以满足基本的需求但随着互联网的发展业务流量越来越大并且业务逻辑也越来越复杂单台机器的性能问题以及单点问题凸显了出来因此需要多台机器来进行性能的水平扩展以及避免单点故障。但是要如何将不同的用户的流量分发到不同的服务器上面呢 早期的方法是使用DNS做负载通过给客户端解析不同的IP地址让客户端的流量直接到达各个服务器。但是这种方法有一个很大的缺点就是延时性问题在做出调度策略改变以后由于DNS各级节点的缓存并不会及时的在客户端生效而且DNS负载的调度策略比较简单无法满足业务需求因此就出现了负载均衡。 客户端的流量首先会到达负载均衡服务器由负载均衡服务器通过一定的调度算法将流量分发到不同的应用服务器上面同时负载均衡服务器也会对应用服务器做周期性的健康检查当发现故障节点时便动态的将节点从应用服务器集群中剔除以此来保证应用的高可用。 负载均衡又分为四层负载均衡和七层负载均衡。四层负载均衡工作在OSI模型的传输层主要工作是转发它在接收到客户端的流量以后通过修改数据包的地址信息将流量转发到应用服务器。 七层负载均衡工作在OSI模型的应用层因为它需要解析应用层流量所以七层负载均衡在接到客户端的流量以后还需要一个完整的TCP/IP协议栈。七层负载均衡会与客户端建立一条完整的连接并将应用层的请求流量解析出来再按照调度算法选择一个应用服务器并与应用服务器建立另外一条连接将请求发送过去因此七层负载均衡的主要工作就是代理。 既然四层负载均衡做的主要工作是转发那就存在一个转发模式的问题目前主要有四层转发模式DR模式、NAT模式、TUNNEL模式、FULLNAT模式。 DR模式也叫作三角传输通过修改数据包的目的MAC地址来让流量经过二层转发到达应用服务器这样应用服务器就可以直接将应答发给应用服务器性能比较好。由于这种模式需要依赖二层转发因此它要求负载均衡服务器和应用服务器必须在一个二层可达的环境内并且需要在应用服务器上配置VIP。 NAT模式通过修改数据包的目的IP地址让流量到达应用服务器这样做的好处是数据包的目的IP就是应用服务器的IP因此不需要再在应用服务器上配置VIP了。缺点是由于这种模式修改了目的IP地址这样如果应用服务器直接将应答包发给客户端的话其源IP是应用服务器的IP客户端就不会正常接收这个应答因此我们需要让流量继续回到负载均衡负载均衡将应答包的源IP改回VIP再发到客户端这样才可以保证正常通信所以NAT模式要求负载均衡需要以网关的形式存在于网络中。 TUNNEL模式的优缺点和DR是一样的并且TUNNEL模式要求应用服务器必须支持TUNNEL功能。 FULLNAT模式是在NAT模式的基础上做一次源地址转换即SNAT做SNAT的好处是可以让应答流量经过正常的三层路由回到负载均衡上这样负载均衡就不需要以网关的形式存在于网络中了对网络环境要求比较低缺点是由于做了SNAT应用服务器会丢失客户端的真实IP地址。 下面详细介绍一下FULLNAT模式。首先负载均衡上需要存在一个localip池在做SNAT时的源IP就是从localip池中选择的。当客户端流量到达负载均衡设备以后负载均衡会根据调度策略在应用服务器池中选择一个应用服务器然后将数据包的目的IP改为应用服务器的IP。同时从localip池中选择一个localip将数据包的源IP改为localip这样应用服务器在应答时目的IP是localip而localip是真实存在于负载均衡上的IP地址因此可以经过正常的三层路由到达负载均衡。由于FULLNAT比NAT模式多做了一次SNAT并且SNAT中有选端口的操作因此其性能要逊色于NAT模式但是由于其较强的网络环境适应性我们选择了FULLNAT作为MGW的转发模式。 选择自研四层负载均衡的原因主要有两个第一个是考虑到硬件负载均衡成本比较高第二个随着美团点评业务流量越来越大LVS出现了性能瓶颈以及运维成本的上升问题。 硬件负载均衡成本问题 硬件成本中低端硬件负载均衡价格在数十万高端的上百万价格非常昂贵。当我们需要组成一个高可用集群时需要数台机器成本异常高。人力成本硬件负载均衡功能比较强大配置比较灵活这也导致在维护上我们需要一些经过专业培训的人员就增加了人力成本。时间成本当使用的过程中遇到bug或者新需求需要厂商提供新版本的时候我们需要经过繁琐的流程向厂商上报然后厂商再发布新版本供我们升级时间周期非常长在高速发展的互联网行业这种周期是无法接受的。LVS的性能问题 最初美团点评使用的是LVSNginx组成的负载均衡结构LVS做四层负载均衡Nginx做七层负载均衡但是随着美团点评流量的高速增长几个月内无论新建连接数还是吞吐量都有三倍的增长LVS故障频发性能上出现瓶颈因此我们自研了一款高性能、高可靠的四层负载均衡MGW来替换LVS。 下面通过对比LVS的一些性能瓶颈来介绍MGW是如何实现高性能的。 中断问题以及协议栈路径性能过长问题 中断是影响LVS性能最重要的一个因素假如我们一秒需要处理600万的数据包每6个数据包产生一个硬件中断的话那一秒就会产生100万个硬件中断每一次产生硬件中断都会打断正在进行密集计算的负载均衡程序中间产生大量的cache miss对性能的影响异常大。 同时由于LVS是基于内核netfilter开发的一个应用程序而netfilter是运行在内核协议栈的一个钩子框架。这就意味着当数据包到达LVS时已经经过了一段很长的协议栈处理但是这段处理对于LVS来说都不是必需的这也造成了一部分不必要的性能损耗。 针对这两个问题解决方法是使用轮询模式的驱动以及做kernel bypass而DPDK提供的用户态PMD驱动恰好可以解决这两个问题。DPDK在设计时使用了大量硬件相关特性比如numa、 memory channel、 DDIO等对性能优化非常大同时提供了比较多网络方面的库可以大大减小开发难度提高开发效率。因此选择DPDK作为MGW的开发框架。 锁 由于内核是一个比较通用的应用程序因此它并没有对一些特定场景做一些定制设计这就导致一些公共的数据结构需要锁的保护。下面介绍一下出现锁的原因和MGW的解决方法。 首先介绍一下RSSReceive Side ScalingRSS是一个通过数据包的元组信息将数据包散列到不同网卡队列的功能这时候不同的CPU再去对应的网卡队列读取数据进行处理就可以充分利用CPU资源。之前介绍MGW使用FULLNAT的模式FULLNAT会将数据包的元组信息全部改变这样同一个连接请求和应答方向的数据包有可能会被RSS散列到不同的网卡队列中在不同的网卡队列也就意味着在被不同的CPU进行处理这时候在访问session结构的时候就需要对这个结构进行加锁保护。 解决这个问题的方法有两种一种就是在做SNAT选端口的时候通过选择一个端口lport0让RSS(cip0, cport0, vip0, vport0) RSS(dip0, dport0, lip0, lport0)相等另外一种方法就是我们为每个CPU分配一个localip在做SNAT选IP的时候不同的CPU选择自己的localip等应答回来以后再通过lip和CPU的映射关系将指定目的IP的数据包送到指定队列上。 由于第二种方法恰好可以被网卡的flow director特性支持因此我们选择了第二种方法来去掉session结构的锁。 flow director可以根据一定策略将指定的数据包送到指定网卡队列其在网卡中的优先级要比RSS高因此我们在做初始化的时候就为每个CPU分配一个localip比如为cpu0分配lip0为cpu1分配lip1为cpu2分配lip2为cpu3分配lip3。 当一个请求包cip0, cport0, vip0, vport0到达负载均衡后被RSS散列到了队列0上这时这个包被cpu0处理。cpu0在对其做fullnat时选择cpu0自己的localip lip0然后将数据包lip0, lport0, dip0, dport0发到应用服务器在应用服务器应答后应答数据包dip0, dport0, lip0, lport0被发到了负载均衡服务器。此时我们就可以在flow director下一条将目的IP为lip0的数据包送到队列0的规则这样应答数据包就会被送到队列0让cpu0处理。这时候CPU在对同一个连接两个方向的数据包进行处理的时候就是完全串行的一个操作也就不要再对session结构进行加锁保护了。 上下文切换 在设计时希望控制平面与数据平面完全分离数据平面专心做自己的处理不被任事件打断。因此将CPU分成两组一组用作数据平面一组用做控制平面。同时对数据平面的CPU进行CPU隔离这样控制平面的进程就不会调度到数据平面的这组CPU上面了对数据平面的线程进行CPU绑定这样就可以让每个数据线程独占一个CPU。 其他的控制平面的程序比如Linux kernel、 SSH等都跑在控制平面的这组CPU上。 下面从MGW集群、MGW单机以及应用服务器层这三个层介绍MGW如何在每一层实现高可靠。 集群的高可靠 MGW使用OSPFECMP的模式组成集群通过ECMP将数据包散列到集群中各个节点上再通过OSPF保证单台机器故障以后将这台机器的路由动态的剔除出去这样ecmp就不会再给这台机器分发流量也就做到了动态的failover。 传统的ecmp算法有一个很严重的问题当集群中节点数量发生变化以后会导致大部分流量的路径发生改变发生改变的流量到达其他MGW节点上时是找不到自己的session结构的这就会导致大量的连接出现异常对业务影响很大并且当我们在对集群做升级操作时会将每个节点都进行一次下线操作这样就加重了这个问题的影响。 一种解决方式是使用支持一致性hash的交换机这样在节点发生变化的时候只有发生变化的节点上面的连接会有影响其他连接都会保持正常但是支持这种算法的交换机比较少并且也没有完全实现高可用因此我们做了集群间的session同步功能。 集群中每个节点都会全量的将自己的session同步出去使集群中每个节点都维护一份全局的session表因此无论节点变化以后流量的路径以任何形式改变这些流量都可以找到自己的session结构也就是说可以被正常的转发这样就可以在集群中节点数量发生变化时保证所有连接正常。 在设计的过程中主要考虑了两个问题第一个是故障切换第二个是故障恢复以及扩容。 故障切换 在故障切换的问题上我们希望在机器故障以后交换机可以立刻将流量切到其他机器上因为流量不切走意味着到达这台机器流量会被全部丢掉产生大量丢包。经过调研测试发现当交换机侧全部使用物理接口并且服务器侧对接口进行断电时交换机会瞬间将流量切换到其他机器上。通过一个100ms发两个包的测试客户端和服务端各发一个这种操作方法是0丢包的。 由于故障切换主要依赖于交换机的感知当服务器上出现一些异常交换机感知不到时交换机就无法进行故障切换操作因此需要一个健康自检程序每半秒进行一次健康自检当发现服务器存在异常时就对服务器执行网口断电操作从而让流量立刻切走。 故障切换主要依赖于网口断电操作并且网卡驱动是跑在主程序里面的当主程序挂掉以后就无法再对网口执行断电操作了因此为了解决这个问题主进程会捕获异常信号当发现异常时就对网卡进行断电操作在断电操作结束以后再继续将信号发给系统进行处理。 经过以上设计MGW可以做到升级操作0丢包主程序故障0丢包其他异常网线等会有一个最长500ms的丢包因为这种异常需要靠自检程序去检测而自检程序的周期是500ms。 故障恢复与扩容 无论是在进行故障恢复还是扩容操作都会导致集群节点数量发生变化这样也就会导致流量路径发生变化。当变化的流量到达集群中原有的节点时因为原有节点都维护着一个全局的session表因此这些流量是可以被正常转发的但是如果流量到达了新机器上这个机器是没有全局session表的那么这部分流量就会全部被丢弃。为了解决这个问题MGW在上线以后会经历一个预上线的中间状态在这个状态上MGW不会让交换机感知到自己上线了这样交换机也就不会把流量切过来。首先MGW会对集群中其他节点发送一个批量同步的请求其他节点收到请求以后会将自己的session全量的同步到新上线的节点上新上线节点在收到全部session以后才会让交换机感知到自己上线这时交换机再将流量切过来就可以正常被转发出去了。 在这个过程中主要存在两点问题。 第一个问题是由于集群中并没有一个主控节点来维护一个全局的状态如果request报丢失或者session同步的数据丢失的话那新上线节点就没办法维护一个全局的session状态。但是考虑到所有节点都维护着一个全局的session表因此所有节点拥有的session数量都是相同的那么就可以在所有节点每次做完批量同步以后发送一个finish消息finish消息中带着自己拥有的session数量。当新上线节点收到finish消息以后便会以自己的session数量与finish中的数量做对比。当达到数量要求以后新上线节点就控制自己进行上线操作。否则在等待一定的超时时间以后重新进行一次批量同步操作直到达到要求为止。 另外一个问题是在进行批量同步操作时如果出现了新建连接那么新建连接就不会通过批量同步同步到新上线的机器上。如果新建连接特别多就会导致新上线机器一直达不到要求。因此需要保证处于预上线状态的机器能接收到增量同步数据因为新建连接可以通过增量同步同步出来。通过增量同步和批量同步就可以保证新上线机器可以最终获得一个全局的session表。 单机高可靠 在单机高可靠方面MGW做了一个自动化测试平台自动化平台通过连通性和配置的正确性来判断一个测试用例是否执行成功失败的测试用例平台可以通过邮件通知测试人员。在每次新功能迭代结束以后都会将新功能的测试用例加到自动化平台里面这样在每次上线之前都进行一次自动化测试可以大大避免改动引发的问题。 在之前每次上线之前都需要进行一次手动的回归测试回归测试非常耗时并且很容易遗漏用例但是为了避免改动引发新问题又不得不做有了自动化测试平台以后大大提高了回归测试的效率和可靠性。 RS可靠性 节点平滑下线 在RS可靠性方面MGW提供了节点平滑下线功能主要是为了解决当用户需要对RS进行升级操作时如果直接将需要升级的RS下线那这个RS上存在的所有连接都会失败影响到业务。此时如果调用MGW的平滑下线功能MGW就可以保证此RS已有连接正常工作但不会往上面调度新的连接。当所有已有连接结束以后MGW会上报一个结束的状态用户就可以根据这个结束的状态对RS进行升级操作升级后再调用上线接口让这个RS器进行正常的服务。如果用户平台支持自动化应用部署那就可以通过接入云平台使用平滑下线功能实现完全自动化且对业务无影响的升级操作。 一致性源IP Hash调度器 源IP Hash调度器主要是保证相同的客户端的连接被调度到相同应用服务器上也就是说建立一个客户端与应用服务器一对一的映射关系。普通的源IP Hash调度器在应用服务器发生变化以后会导致映射关系发生改变会对业务造成影响。 因此我们开发了一致性源IP Hash调度器保证在应用服务器集群发生变化时只有发生变化的应用服务器与客户端的映射关系发生改变其他都是不变的。 为了保证流量的均衡首先在hash环上分配固定数量的虚拟节点然后将虚拟机节点均衡的重分布到物理节点上重分布算法需要保证两点 在物理节点发生变化时只有少数虚拟节点映射关系发生变化也就是要保证一致性Hash的基本原则。因为MGW是以集群的形式存在的当多个应用服务器发生上线下线操作时反馈到不同的MGW节点上就有可能会出现顺序不一致的问题因此无论不同的MGW节点产生何种应用服务器上下线顺序都需要保证最终的映射关系一致因为如果不一致就导致相同客户端的连接会被不同的MGW节点调度到不同的应用服务器上也就违背了源IP Hash调度器的原则。综合以上两点Google Maglev负载均衡的一致性Hash算法是一个很好的例子在paper中有详细的介绍这里就不过多讨论了。 经过美团点评以及美团云的流量验证MGW无论在传统网络环境还是overlay的大二层环境下都有出色的性能和稳定性表现。在业务场景方面涵盖数据库业务千万级别的长连接业务嵌入式业务存储业务以及酒店、外卖、团购等Web应用业务。在业务需求快速变化的环境下MGW在不断完善自身功能在各种业务场景下都有良好的表现。 在未来的一段时间内MGW除了会完善四层的功能需求外也会考虑向七层方向发展。 DPDK.LVS.Eisenbud D E, Yi C, Contavalli C, et al. Maglev: A Fast and Reliable Software Network Load Balancer.
