阿里七层流量入口 Tengine硬件加速探索之路

摘要： Tengine在软件层面已经有了深度的调试和优化经验，可是在硬件层面，通用处理器（CPU）已经进入了摩尔定律，有了瓶颈。而在业务量日新月异的当下，如何利用硬件来提高性能，承载双11等大型活动的洪峰流量，保障活动平稳度过呢？本文做者：王发康，花名毅松，负责集团主站统一接入层Tengine的开发与维护。

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

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

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

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

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

性能瓶颈分析及解决
咱们要对本身的系统作性能优化，首先咱们要找到系统的瓶颈点，而且进行分析与调研。

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

1、HTTPS卸载篇
虽然全站HTTPS已是一个老生常谈的话题，可是国内为什么能作到的网站却仍是屈指可数？缘由简单总结来讲有两点，首先使用HTTPS后使得网站访问速度变“慢”，其次致使服务器CPU消耗变高、从而机器成本变“贵”。

软件优化方案：如Session复用、OCSP Stapling、False Start、dynamic record size、TLS1.三、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资源，为公司带来价值。

2、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在功能、性能、架构方面等众多问题得以快速解决。

运维与监控
问题解决后，接下来咱们进行上线前的准备。

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

硬件加速效果
上线后咱们得到了一些加速效果的数据。当QPS为10k左右时，Tengine Gzip使用QAT加速后，CPU节省在15%左右，且Gzip基本上彻底卸载，随着其占比变高，优化效果将愈来愈好。在2017年双11零点流量峰值附近，Tengine加速机器相比普通机器性能提高 21%。

展望及总结
Tengine首次采用硬件加速技术卸载Gzip，不只带来性能上的提高，并且使得接入层在硬件加速领域再次打下了坚实的基础，对业界在此领域的发展也有重大影响意义。在将来，Tengine会在软件和硬件层面继续探索，为集团和用户提供更加高可用、高性能、低成本、安全、运维自动化的系统。

原文连接