Tengine在软件层面已经有了深度的调试和优化经验，但是在硬件层面，通用处理器（CPU）已经进入了摩尔定律，有了瓶颈。而在业务量突飞猛进的当下，如何利用硬件来提升性能，承载双11等大型活动的洪峰流量，保障活动平稳度过呢？

本文作者：王发康，花名毅松，负责集团主站统一接入层Tengine的开发与维护。今天分享的主题是《阿里七层流量入口Tengine硬件加速探索之路》。

接入层系统介绍

接入层是2015年阿里巴巴全站HTTPS诞生的一个产品。作为一个电商网站，为了保护用户信息安全、账户、交易的安全，全站HTTPS是势在必行，如果淘宝、天猫、聚划算等各业务方在后端各自做接入层，机器成本高，而且证书管理复杂。为了解决问题，我们做了统一接入层，来做HTTPS卸载和流量分发等通用功能。

所有的阿里集团流量通过四层LVS，到达统一接入层，统一接入层根据不同的维度域名转发到对应的后端APP，并且提供智能的流量分发策略。因为抽象出一层，通用的安全防攻击、链路追踪等高级功能，都可以在这一层统一实现。

接入层是集团所有流量的入口，它的稳定性是非常重要的。同时，接入层提供了这么多高级功能，所以对其性能的挑战也非常大。业务驱动了技术创新，2017年接入层在硬件加速领域迈出了第一步。

性能瓶颈分析及解决

我们要对自己的系统做性能优化，首先我们要找到系统的瓶颈点，并且进行分析与调研。

主站接入层承载集团90%以上的入口流量，同时支持着很多高级功能，比如HTTPS卸载及加速、单元化、智能流量转发策略、灰度分流、限流、安全防攻击、流量镜像、链路追踪、页面打点等等，这一系列功能的背后是Tengine众多模块的支持。由于功能点比较多，所以这就导致Tengine的CPU消耗比较分散，消耗CPU比较大的来自两个处HTTPS和Gzip，这就是性能瓶颈之所在。

一、HTTPS卸载篇

虽然全站HTTPS已经是一个老生常谈的话题，但是国内为何能做到的网站却还是屈指可数？原因简单总结来说有两点，首先使用HTTPS后使得网站访问速度变“慢”，其次导致服务器CPU消耗变高、从而机器成本变“贵”。

软件优化方案：如Session复用、OCSP Stapling、False Start、dynamic record size、TLS1.3、HSTS等。但软件层面如何优化也无法满足流量日益增长的速度，加上CPU摩尔定律已入暮年，使得专用硬件卸载CPU密集型运算成为业界一个通用解决方案。

Tengine基于Intel QAT的异步加速方案总体架构

由三部分组成Tengine的ssl_async指令、OpenSSL + QAT Engine及QAT Driver。其中Tengine通过适配OpenSSL-1.1.0的异步接口，将私钥操作卸载至Intel提供的引擎(QAT engine)中，引擎通过 QAT驱动调用硬件完成非对称算法取回结果。

该方案在Tengine2.2.2中已经开源。

Tengine启用ssl_async QAT加速后的效果如何？

RSA套件提升3.8倍(8核时)
ECDHE-RSA提升2.65倍(8核时)
ECDHE-ECDSA(P-384) 提升2倍(16核时)
ECDHE-ECDSA(P-256) 8核达到QAT硬件处理峰值16k左右，只有23%的性能提升。

HTTPS卸载方案可以减少物理机数量，节省CPU资源，为公司带来价值。

二、Gzip卸载篇

当前接入层Gzip模块的CPU占比达到15-20%，如果我们能卸载掉Gzip的CPU消耗，让出来的CPU就可以用于处理更多请求和提升性能。

然而目前业内各大公司接入层针对于Gzip采用硬件加速还是一片空白，阿里在接入层结合硬件加速技术卸载Gzip调研了几套方案：

方案一是和Intel合作的QAT卡的加速方案，直接把相关软件算法固化到硬件中去，链路会更精简。
方案二智能网卡方案，需要把Tengine一部分业务逻辑抽取到网卡中做，其成本及风险高，而且只是对zlib进行软件卸载，相对于QAT并不具有加速作用。
方案三是FPGA卡方案，相对来说开发成本较高，且相关资源匮乏。

综上评估，选择方案一对Gzip进行卸载及加速。

Tengine Gzip 硬件加速方案实践

左边的图是软件方案，请求进来后，在软件层面做一些压缩，全部是用CPU在做。右边是通过QAT卡来加速，把红色那部分全部卸载到QAT卡里，通过改造Tengine中的Gzip这个模块，让它去调用QAT的驱动，通过硬件做压缩，最终送回Tengine传输给用户。

在这个过程中，我们也遇到了非常多的坑。

使用的第一版驱动Intel-Qat 2.6.0-60，当QPS为1k左右时，从上图可以看出，横坐标是时间，纵坐标是CPU消耗百分比，跑到第五秒左右，CPU很快打满，这相当于根本跑不起来。

针对这个问题，我们使用strace进行相关系统热点函数统计发现，其CPU主要消耗在ioctl系统函数上，如下所示：

ioctl主要是做上层应用程序和底层通讯的，并且CPU消耗中90%以上都是消耗在内核态。因为最初的每个压缩请求都要送到硬件中去，buffer需要开辟连续的物理内存，系统跑久了，一旦遇到连续内存分配不成功的情况，就会需要ioctl去分配内存，出现频繁调用 compact_zone进行内碎片整理，其调用热的高达88.096%，如果分配失败了，就会触发内存去做碎片整理，所以就会出现sys态CPU持续上升的情况。

这个问题解决后，也并没有那么顺利，我们遇到了下面的问题。

在日常压测时，我们发现CPU用了Gzip卸载方案后，节省效果上并没有明显的提升。user态CPU降低了10%左右，但是sys态CPU相对于软件版的CPU提升了10%。所以，节省效果不明显。

经分析，我们发现使用QAT后，部分系统函数CPU占比变高，如下图所示(注:左边的是使用QAT后各系统热点函数，右边是软件版原生tengine的各系统热点函数)open、ioctl、futex执行时间占比高达8.95(注:3.91 + 2.68 + 2.36)，而未使用版本对应占比时间才0.44(注:0.24 + 0.14 + 0.06)。

open和ioctl是由于Zlib Shim适配层处理逻辑有一些问题，通过优化改造后open、ioctl调用频率明显减少。但是其futex系统调用频度却没有减少，还是导致内核态的CPU占比较高，通过strace跟踪发现一个http压缩请求后会多次调用futex，Zlib Shim采用多线程方式，其futex操作来自zlib shim等待QAT压缩或解压缩数据返回的逻辑，由于Tengine是多进程单线程、采用epoll异步IO事件模式，联调Intel的研发同学对Zlib Shim进行改造（去线程），最终futex系统调用也明显减少。

一路走来，通过无数次的性能优化、功能测试，我们与Intel研发同学一起探讨之后，才使得QAT在功能、性能、架构方面等众多问题得以快速解决。

运维与监控

问题解决后，接下来我们进行上线前的准备。

一、压测和演练，这里主要关注高流量、压缩与解压缩流量混跑等情况下的性能提升情况，同时关注数据完整性校验。
二、容灾保护，在运行过程中，当硬件资源缺乏导致Gzip执行失败，会自动切换软件版本，硬件资源恢复后自动切回。
三、监控，对硬件加速相关的资源指标进行实时监控和报警，防患于未然。
四、部署与发布，因为存在硬件和软件两个版本，所以采用单rpm软件包、双二进制模式，从而降低软件版与硬件加速版之间的耦合度，自动识别部署机器是否开启QAT，并选择正确的二进制执行。