如何打造应对超大流量的高性能负载均衡？(2)

Tengine在应用过程中也遇到了各种问题，最严重的就是性能问题，我们发现随着CPU数量越来越多，QPS值并没有线性提升;Nginx本身是多worker模型，每个worker是单进程模式，多worker架构做CPU亲和，内部基于事件驱动的模型，其本身已经提供了很高的性能，单核Nginx可以跑到1W5～2W QPS。Nginx往下第一层是socket API，socket 往下有一层VFS，再往下是TCP、IP，socket层比较薄，经过量化的分析和评估，性能开销较大的是TCP协议栈和VFS部分，因为同步开销大，我们发现横向扩展不行，对此，我们做了一些优化。

七层反向代理的路径更长，处理更复杂，所以它的性能比LVS低很多，我们比较关注单机和集群的性能，集群性能可以靠堆设备去解决，单机如果不提升，成本会一直增加，从性能角度来看，有以下的优化思路和方向：

基于Kernel做开发，比如优化协议栈;

基于Aliscoket的优化，Alisocket是阿里研发的高性能TCP协议栈平台，底层是DPDK，它将资源做了局部化处理，报文分发不同核处理，性能非常出色;

HTTPS业务越来越多，流量逐步递增，我们采用硬件加速卡方式做一些加解密的性能提升，还有HTTPS的会话复用;

基于Web传输层的性能优化。

从弹性角度看，比如一些公司的应用和用户热点有关，当发生一个社会网络热点后，访问量会急剧变高，我们固有的基于物理机器实现的负载均衡模型在弹性扩展方面是有限制的，对此，我们可以使用VM去做，把反向代理功能放在VM去跑，我们会监控实例负载情况，根据实时需求做弹性扩容缩容;

除了VM，还有调度单元，我们可以在不同调度单元做平滑切换，根据不同的水位情况，通过切换可以把负载均衡实例调度到不同的单元中去，改善使容量上管理。Tengine本身也做了集群化部署，我们在一个region里有不同的机房，不同的调度单元，每个调度单元有多组设备;LVS到Tengine也有健康检查，如果一台Tengine有问题，可以通过健康检查方式摘除，不会影响用户转发能力;

Tengine具备灵活的调度能力，可以帮助我们应对更多的复杂情况;另外，Tengine也有很多高级的特性，比如基于cookie的会话保持、基于域名/URL的转发规则、HTTP2、Websocket等功能;目前，我们7层单VIP可以支撑10W规格的HTTPS QPS。

高可用

1、Group

高可用是整个产品很重要的一部分，图为集群内的高可用架构图，可以看到，在网络路径上是全冗余无单点的。具体情况如下：

双路服务器，每节点双网口上联不同交换机，增加带宽，避免跨节点收包

VIP路由两边发不同的优先级，不同的VIP，高优先级路由在不同的交换机上

单机160G转发能力，单VIP 80G带宽，单流 40G带宽

网卡故障不影响转发，上下游路由自动切换

ECMP，VIP路由发两边，通过优先级控制从入口

集群640G转发能力，单vip 320G带宽

会话同步，多播、包触发同步、定时同步

单机故障不影响转发

交换机故障不影响转发，路由秒级切换

用户无感知的升级变更，部分未及时同步的连接重连即可

2、AZ

每个机房连接两个不同路由器，当一个AZ出现故障之后，我们可以无缝切换到另外一个机房，具体情况如下：

VIP在不同的AZ发不同优先级的路由(秒级切换、自动切换)

VIP区分主备AZ，不同的VIP主备AZ不同

多个AZ的负载通过控制系统分配

缺省提供VIP多AZ的容灾能力

不支持跨AZ的session同步，跨AZ切换后，所有连接都需要重连

3、Region

当用户访问域名时，通过DNS解析，可以设定DNS解析到多个regionVIP地址，下沉到某一个Region来看，如果一个机房出现故障，流量可以切换到另一个可用区继续转发，如果流量进到机房发现一台LVS转发设备出现故障后，我们可以切换到另外一台LVS作处理，如果LVS后面挂载的RS出现问题，通过健康检查也可以快速摘掉设备，将流量转换到健康的设备上去。我们从多个维度实现高可用，较大限度地满足用户的需求。

总结

目前，高性能负载均衡应用主要在几个方面：

作为公有云基础组件，为公有云网站、游戏客户、APP提供负载均衡功能，也针对政府、金融等安全性高的客户提供专有云支持;

为阿里云内部云产品RDS、OSS、高防等提供了负载均衡的功能;

负载均衡作为电商平台入口，向淘宝、天猫、1688提供VIP统一接入功能;

交易平台的流量入口也在负载均衡设备上，如支付宝、网上银行。

（编辑：ASP站长网）