负载均衡续：万亿流量场景下的负载均衡实践

负载均衡续：万亿流量场景下的负载均衡实践垂直性能提升架构优化：集群部署，负载均衡本篇内容：万亿流量下负载均衡的实现上篇基本把负载均衡涉及到的基础都罗列了，那么到了实际场景下，特别是万亿流量场景下，真实的负载均衡方案又是怎么做的呢。本篇分别就淘宝双11、春运12306、微信红包和抖音春晚红包等场景在负载均衡方面的运用进行一些介绍和讨论。阿里双11流量下的负载均衡[1]双十一流量特点请求量巨大，脉冲式的。是对阿里生态链路双十一流量特点请求量巨大，脉冲式的。是对阿里生态链路上所有服务的考验对负载均衡器的要求:性能优良：应对双11当晚脉冲式的流量冲击服务稳定：可用性高，以应对设备和网络的抖动业务无感：顺滑的自身升级和容灾切换实现原理1）优良性能依赖DPDK

阿里的新一代负载均衡器是基于DPDK[2]来实现的。其优势总结如下 *⑶昼通过UIO技朮将报文拷贝到应用空间处理‘规避干必要的内存拷贝和系址调用，便于怏速迭代优仏吳通过大页内存HUGEPAGE,KUcachemiss｛访存幵销)，利用内存劣通道交错访问提高内存访问有效带宽，即提高命中率，进而提高epu访问速度样呈通过CPU亲稻性郭定赵卡和线程到固定的8理讖少匚凹任务切换口特定任务可以被指定只在某个核上工作，避免堆程在不同核间频繁切棘保证M^feache命中。呈通过无锁趴列，减少资淋竞争"cache行对齐’预取数据,势元数抵批量操年。. 了匚刖廿的技律之銘1通过轮询可在包处理时谨免中断上下文切隸的开销。 "正是由于这些专门针对数据包的高性能支持，才得以实现性能优良的负载均衡器来支撑多年双11场景下的脉冲流量的压力。2)应对ECMP重选导致的连接中断ECPM(Equal-CostMultipathRouting)是一种最大限度利用最短路径的等价多路径路由算法。无感容灾与升级——连接断开问题③无感容灾与升级——连接断开问题③DPDK转题彌n转题彌n问题-单抽腊时，ECMF更癥路鬧丸衆5^中瓯■单冋卡或者链路城備时，ECMP重新说蹈导5!旌接中新-交换机弼时，切换交换机r造路不叵鲁致逬接中匪*JE群通过轮潮柵版仙」导甦EGdPHi新选宿导雜连摆中断影响-交易直接下跌・用户访问超时,异常•会话同步・同_组转炭服务器加入同一个组播组•利用组播解决机器的上线与下线•高性能；•会话同步・同_组转炭服务器加入同一个组播组•利用组播解决机器的上线与下线•高性能；发送T分‘组播复制叢份•转发面简单、高效1GJWF转发确器TIconnsSconnsSconnsLconn±交m-iLconnsSconnsSU埶播住话同歩示危图三「心二<7•二之12VVV左右滑动见更多>>>如上图，SLB采用水平扩展的集群部署，多台服务器发布相同路由,在交换机处形成ECPM路由。以达到高可用的目的。但，在连接没有同步之前，遇到服务器硬件或网络异常，会使该服务器不可用，ECPM重选路由，会使连接到达其他服务器，导致已有连接中断，造成用户访问异常。SLB使用了会话同步的机制来解决了升级与容灾场景下长连接中断的问题。用组播技术解决会话同步机制中的机器上下线问题。详细解释参见文献［1］。铁路12306的负载均衡⑷12306大名鼎鼎，无需多介绍。其中很多的场景和技术都可以给我们做一些很好的参考。但只找到了16年发表的论文，没有能了解到最新的架构部署。12306的业务难点动态库存，余票可以按站点拆分事务强一致，下单交易性质多维度数据一致性，线上线下售票渠道流量洪峰，遇节假日有流量洪峰这里对前几个问题就暂不讨论，单说负载均衡在应对流量洪峰时的作用。12306架构的发展历程如下：由上图可以看到，第一次优化之前，几乎全链路服务都出现了性能瓶颈，因为并发查询导致查询系统负载过高，用户重试引发AS过载；AS阻塞导致响应增加，引发WEB负载问题，线上压力导致整个票务系统异常，进而影响了线下购票渠道正常运转，直至链路雪朋。第一次优化后，引入排队系统，不同车次使用不同队列，已达到请求分流；且排队系统采用了动态流量控制，根据各铁路局客票中心处理速度，进行控速请求下发；并进行了客票网服务拆分，根据不同规则，使流量负载均衡。此次优化让12306顺利度过了13年春运。但随着互联网的高速发展，网上订票人数不断增加，目前的架构已经达到了带宽、性能、稳定性的瓶颈。因此第二次优化如下:本篇重点还是看负载均衡在业务场景下的实际作用，因此，其

他优化点就不做讨论了。正是因为多维度，多层次的负载均衡，才使得12306能够承载更咼的流量冲击（如果哪些同学有12306最新的部署架构，希望能私信交流学习~）微信红包背后的负载均衡 ⑸2017年正月，微信公布用户在除夕当天收发微信红包的数量142亿个，收发峰值已达到76万每秒。百亿红包业务特点：不同于普通电商场景，一个群红包就相当于一个秒杀活动，并发要求更高金融属性，不允许数据出现一致性，安全级别要求更高。那么微信的红包方案是怎么设计的SET化，分而治之SET化，分而治之如果采用普通的服务拆分和部署方式，由于需要锁库存来防止超发，海量的锁竞争将对DB造成不可估量的压力。及时是使用外部存储的分布式锁进行前置压力缓解，只是对压力的转移，而无法减少。采用SET化部署的好处，就是同一个红包只会被路由到同一个的SET内，相当于对庞大的洪流，进行了reduce似的细小拆分，不同的SET之间互不影响，极大的减少了不同SET之间的资源压力。（其实和阿里的RGCzone单元化部署原理差不多）server层请求排队

产生并发抢锁的原因,是因为到达DB的请求可能是并发,如果可以保证到达DB的请求穿行，那就不存在并发了。

队DB按£'旧Cedar的技世之路接收请求队DB按£'旧Cedar的技世之路接收请求worker进程组lYiemcahcedvvv左右滑动见更多>>>首先,通过IDhash确保同一红包的请求被分配到同一台Server,然后再进行单机红包排队，这样，就可以保证同一红包的请求顺序的达到DB，从而减少DB抢锁并发。双维度库表设计因为红包数量巨大，单表数据达到一定程度就会出现性能问题；因此除了按红包ID分库分表，还按天进行冷热数据拆分，在保障数据可以优雅迁移的前提下，保证了当天的DB性能。而在查询时，通过数据库中间件，进行库表路由。总结从负载均衡的角度看红包的架构设计，可以看到，整个架构设计可以理解为使用了三层负载均衡，首先是入口层，将流量进行set拆分，达到整体SET集群的负载均衡；然后是server层，对红包ID进行业务逻辑Hash,ID穿行的同时，达到server集群内部的负载均衡；再有是DB层，通过双维度库表设计，在保障DB性能的同时达到数据访问的负载均衡。抖音春晚红包背后的负载均衡 [6][7]前几部分分别从网络层、架构层、内部设计等角度阐述了负载均衡的实际运用。而这里会着重介绍下抖音架构中涉及到的下一代微服务技术ServiceMesh在负载均衡上的优势。什么是ServiceMesh[8]为了解决端到端的字节码通信问题，TCP协议诞生，让多机通信变得简单可靠；微服务时代，ServiceMesh诞生，屏蔽了分布式系统的诸多复杂性，让开发者可以回归业务。

ServiceAEnvnyf-^ServiceAknv-oyR理ServiceAEnvnyf-^ServiceAknv-oyR理HTTP；1.1.HTTP/；,

gKlFCcwTCF・・

with,urwithout

ntri-gFnlicychecks,

tckm&tr^__AdapterMixrrAdapterCunfijpjurian.fCunfijpjurian.“acfatalflproxies:cfatalflproxies:C-onfi^M^riixi:JlLtlL■J'LScerlifiriilrh*

toproxies.GalleyCitadelIstio服务网格在逻辑上分为控制平面和数据平面两部分。其中,数据平面由一组以Sidecar方式部署的智能代理（Envoy）组成，这些代理可以调节和控制微服务及Mixer之间所有的网络通信。Envoy代理可以发出很多指标和遥测数据，这些遥测数据发送到何处，取决于Envoy的配置.Envoy作为代理，在网络体系中扮演着中介的角色，可以为网络中的流量管理添加额外的功能，包括提供安全性、隐私保护或负载策略等。在服务间调用的场景中，代