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

高并发优化系列文章(持续更新补充)

1. 垂直性能提升
   1.1. 架构优化：集群部署，负载均衡
   1.2. 本篇内容：万亿流量下负载均衡的实现

上篇基本把负载均衡涉及到的基础都罗列了，那么到了实际场景下，特别是万亿流量场景下，真实的负载均衡方案又是怎么做的呢。
本篇分别就淘宝双11、春运12306、微信红包和抖音春晚红包等场景在负载均衡方面的运用进行一些介绍和讨论。

阿里双11流量下的负载均衡^[1]

双十一流量特点请求量巨大，脉冲式的。是对阿里生态链路上所有服务的考验对负载均衡器的要求：

• 性能优良：应对双11当晚脉冲式的流量冲击
• 服务稳定：可用性高，以应对设备和网络的抖动
• 业务无感：顺滑的自身升级和容灾切换

实现原理

1）优良性能依赖DPDK

阿里的新一代负载均衡器是基于DPDK^[2]来实现的。其优势总结如下*^[3]正是由于这些专门针对数据包的高性能支持，才得以实现性能优良的负载均衡器来支撑多年双11场景下的脉冲流量的压力。

2）应对ECMP重选导致的连接中断

ECPM(Equal-CostMultipathRouting) 是一种最大限度利用最短路径的等价多路径路由算法。

<<< 左右滑动见更多 >>>

如上图，SLB采用水平扩展的集群部署，多台服务器发布相同路由，在交换机处形成ECPM路由。以达到高可用的目的。但，在连接没有同步之前，遇到服务器硬件或网络异常，会使该服务器不可用，ECPM重选路由，会使连接到达其他服务器，导致已有连接中断，造成用户访问异常。SLB使用了会话同步的机制来解决了升级与容灾场景下长连接中断的问题。用组播技术解决会话同步机制中的机器上下线问题。详细解释参见文献[1]。

铁路12306的负载均衡^[4]

12306大名鼎鼎，无需多介绍。其中很多的场景和技术都可以给我们做一些很好的参考。但只找到了16年发表的论文，没有能了解到最新的架构部署。

12306的业务难点

• 动态库存，余票可以按站点拆分
• 事务强一致，下单交易性质
• 多维度数据一致性，线上线下售票渠道
• 流量洪峰，遇节假日有流量洪峰

这里对前几个问题就暂不讨论，单说负载均衡在应对流量洪峰时的作用。

12306架构的发展历程如下：

<<< 左右滑动见更多 >>>

由上图可以看到，第一次优化之前，几乎全链路服务都出现了性能瓶颈，因为并发查询导致查询系统负载过高，用户重试引发AS过载；AS阻塞导致响应增加，引发WEB负载问题，线上压力导致整个票务系统异常，进而影响了线下购票渠道正常运转，直至链路雪崩。

第一次优化后，引入排队系统，不同车次使用不同队列，已达到请求分流；且排队系统采用了动态流量控制，根据各铁路局客票中心处理速度，进行控速请求下发；并进行了客票网服务拆分，根据不同规则，使流量负载均衡。此次优化让12306顺利度过了13年春运。但随着互联网的高速发展，网上订票人数不断增加，目前的架构已经达到了带宽、性能、稳定性的瓶颈。因此第二次优化如下：本篇重点还是看负载均衡在业务场景下的实际作用，因此，其他优化点就不做讨论了。正是因为多维度，多层次的负载均衡，才使得12306能够承载更高的流量冲击（如果哪些同学有12306最新的部署架构，希望能私信交流学习~）

微信红包背后的负载均衡^[5]

2017年正月，微信公布用户在除夕当天收发微信红包的数量——142亿个，收发峰值已达到76万每秒。

百亿红包业务特点：

• 不同于普通电商场景，一个群红包就相当于一个秒杀活动，并发要求更高
• 金融属性，不允许数据出现一致性，安全级别要求更高。

那么微信的红包方案是怎么设计的

垂直SET化，分而治之

如果采用普通的服务拆分和部署方式，由于需要锁库存来防止超发，海量的锁竞争将对DB造成不可估量的压力。及时是使用外部存储的分布式锁进行前置压力缓解，只是对压力的转移，而无法减少。

采用SET化部署的好处，就是同一个红包只会被路由到同一个的SET内，相当于对庞大的洪流，进行了reduce似的细小拆分，不同的SET之间互不影响，极大的减少了不同SET之间的资源压力。(其实和阿里的RGCzone单元化部署原理差不多)

server层请求排队

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

<<< 左右滑动见更多 >>>

首先，通过IDhash确保同一红包的请求被分配到同一台Server，然后再进行单机红包排队，这样，就可以保证同一红包的请求顺序的达到DB，从而减少DB抢锁并发。

双维度库表设计

因为红包数量巨大，单表数据达到一定程度就会出现性能问题；因此除了按红包ID分库分表，还按天进行冷热数据拆分，在保障数据可以优雅迁移的前提下，保证了当天的DB性能。而在查询时，通过数据库中间件，进行库表路由。

总结

从负载均衡的角度看红包的架构设计，可以看到，整个架构设计可以理解为使用了三层负载均衡，首先是入口层，将流量进行set拆分，达到整体SET集群的负载均衡；然后是server层，对红包ID进行业务逻辑Hash ,ID穿行的同时，达到server集群内部的负载均衡；再有是DB层，通过双维度库表设计，在保障DB性能的同时达到数据访问的负载均衡。

抖音春晚红包背后的负载均衡^[6][7]

前几部分分别从网络层、架构层、内部设计等角度阐述了负载均衡的实际运用。而这里会着重介绍下抖音架构中涉及到的下一代微服务技术Service Mesh在负载均衡上的优势。

什么是Service Mesh^[8]

为了解决端到端的字节码通信问题，TCP协议诞生，让多机通信变得简单可靠；微服务时代，Service Mesh诞生，屏蔽了分布式系统的诸多复杂性，让开发者可以回归业务。

<<< 左右滑动见更多 >>>

Service Mesh下Istio的负载均衡^[9]

Istio 服务网格在逻辑上分为控制平面和数据平面两部分。其中，数据平面由一组以Sidecar方式部署的智能代理(Envoy)组成，这些代理可以调节和控制微服务及Mixer之间所有的网络通信。Envoy 代理可以发出很多指标和遥测数据，这些遥测数据发送到何处，取决于 Envoy 的配置.

Envoy作为代理，在网络体系中扮演着中介的角色，可以为网络中的流量管理添加额外的功能，包括提供安全性、隐私保护或负载策略等。在服务间调用的场景中，代理可以为客户端隐藏服务后端的拓扑细节，简化交互的复杂性，并保护后端服务不会过载。并能发现集群中的所有成员，然后通过主动健康检查来确定集群成员的健康状态，并根据健康状态，通过负载均衡策略决定将请求路由到哪个集群成员。

结束语

本篇从实践的角度出发，挑选了四个最典型的案例，分别从网络层、架构层、微服务发展等方面阐述了负载均衡的实际运用，希望能对大家的工作和学医有所帮助~ 欢迎关注私信交流~

Reference