本届挑战赛的评测环节全部基于云上产品与服务完成，真正实现了一场完整的云端赛事。也许有人会觉得：这有什么特别？其实意义非常重大。回顾历届中间件性能挑战赛，这是第一次彻底摆脱阿里集团内部专有系统，全面采用公共云能力，堪称一次具有里程碑意义的升级。
也正因为如此，本届比赛才能更充分地使用云原生产品与服务。参赛选手不仅可以在比赛过程中使用性能测试 PTS，还能间接体验一个隐藏在挑战赛评测系统背后的全新产品——Web 应用托管服务（Web ）。
性能测试 PTS，访问这里。
Web 应用托管服务（Web ），访问这里。
黑科技一：阿里云性能测试 PTS
相信参加过去年比赛，或者曾在本地搭建过评测环境的选手，对 wrk 一定并不陌生。wrk 作为一款现代 HTTP 基准测试工具，能够在多核 CPU 环境下制造高强度负载，并结合 lua 脚本实现定制化压测统计。不过，wrk 在去年的评测过程中也暴露出一些明显问题，例如：
在 wrk 的施压过程中，评测机 CPU 负载过高，甚至会出现假死状态，运维人员连登录评测机进行问题排查都十分困难；在使用 wrk 时，选手通常只能拿到整个评测过程的“汇总结果”，难以动态观察程序在压测期间的 QPS、RT 等核心性能指标随时间变化的趋势，不利于定位性能瓶颈；wrk 无法向选手提供评测过程中的采样日志，遇到状态码异常或服务端报错时，问题排查难度很大；PTS 的“杀器”
为了给选手带来更好的性能评测体验，今年比赛选用了阿里云 PTS（性能测试服务平台）作为核心评测工具，它主要具备以下优势：
作为阿里云的云压测平台，PTS 在施压时能够充分利用分布式机器资源进行压力发起，显著解决单机 CPU 负载过高的问题；同时还提供请求成功率、峰值流量、平均流量、分位 RT 等关键指标统计，为选手输出更全面的性能压测数据，有效提升程序问题定位与性能优化效率；PTS 还可以提供采样日志，帮助选手分析并定位程序异常；评测完成后，系统还能生成详细压测报告，选手可通过报告更全面地了解整个评测过程中各项性能指标的秒级变化；总体来看，PTS 作为阿里云自研的性能压测平台，在本届比赛中不仅承担了压测工具的角色，更是选手分析系统表现、定位性能瓶颈的重要助手。受限于比赛题目的评测需求，PTS 其实还有许多“杀器”尚未完全展示，例如 RPS 模式支持、流量地域定制、定时压测、SLA（服务等级协议）等能力，均属于业界领先水平。欢迎大家进一步体验和试用。
黑科技二：隐藏于无形的 Web
与 PTS 不同，Web 对选手而言几乎是“看不见”的，但它会在每次提交代码后，默默完成评测环境的准备工作。如果你参加过去年的挑战赛，尤其是亲手搭建过评测环境，甚至研究过相关搭建代码，就会知道：去年的评测环境几乎完全依赖 Python 和 Shell 脚本拉起，包含大量用于构建 Docker 镜像、启动服务以及执行压测的代码，这还不包括在此之前手动完成的资源申请和环境配置工作。
Web 应用托管服务（Web ）顾名思义，正是为了解决 Web 应用托管过程中遇到的一系列复杂问题。这些问题包括但不限于：
云资源的申购与编排软件运行时环境的安装与配置应用程序的启停与维护等部署环境配置模板的分发与应用而本届挑战赛，正是综合运用了上述这些核心能力。
云端资源的申购与编排
所谓云端资源，就是大家熟悉的 ECS、VPC、SLB、RDS 等基础云资源；而申购与编排，则是从申请、购买开始，将原本独立的资源按照正确方式进行组合，最终构建成一套可实际运行的系统。这并不是一个全新的概念，HashiCorp 的 Terraform、AWS 的 Cloud Formation，以及阿里云自家的 ROS，都属于同类产品。这类产品通常有一个通用术语，叫做 Infrastructure as Code（基础设施即代码）。简单理解，就是用代码来描述和管理基础设施。当整套基础设施都能通过代码固化与重复部署时，这份代码在很大程度上就等同于基础架构本身。它带来的好处也非常明显：易于阅读、便于版本管理，也更容易分发与复制。Web 同样采用了这一思路，通过配置描述文件（Wpfile）来映射和编排完整的基础设施环境。
软件运行时环境的安装与配置
在基础设施搭建完成之后，距离应用程序真正运行起来，中间还隔着一个关键步骤，那就是软件运行时环境的安装与配置。由于应用所依赖的公共类库、编程语言、应用容器和框架各不相同，这部分操作往往差异很大。为了解决这种差异，Web 引入了技术栈的概念——也就是操作系统、语言、容器以及其他辅助软件的组合。基于一套标准化的技术栈扩展体系，Web 可以比较轻松地支持多种编程语言，而不局限于当前已经提供的几类。以 Ja va 为例，如果一个技术栈只包含 Linux 与 OpenJDK，那么它就是一套最基础的 Linux Ja va 运行时环境；如果在此基础上增加 Tomcat，就变成了可以将应用运行在 Tomcat 容器中的技术栈。同理，它还可以支持 Linux OpenJDK Jetty 的技术栈、Windows .netFramework IIS 的技术栈、Linux Node.js 的技术栈等多种应用部署场景。
应用程序的启停与维护
即便已经有了技术栈，也并不意味着应用程序一定能够顺利启动；而即便能够启动，也不代表一定可以稳定运行；就算运行正常，也未必处于最佳性能状态。这些问题，恰恰是应用托管服务需要解决的核心内容。除了依赖技术栈外，用户的应用还可能依赖某些特殊组件，这些组件必须在应用启动前完成安装与配置。即便无需额外组件，很多应用也需要先完成解压或安装操作（例如 Windows 系统中的程序），这些步骤都需要用户根据自身应用特点制定处理方式。Web 能提供的，是丰富的脚本挂载点，用户可借助这些挂载点完成各种自定义操作。然而，应用启动成功后，能否稳定运行还与整体系统架构密切相关。如果系统依赖一整套分布式环境，那么分布式配置就尤为关键。比如应用端口、健康检查、反向袋里、SLB 监听与转发策略等，都需要进行细致配置。Web 可以帮助用户尽量屏蔽复杂的配置细节，但某些关键设置仍然需要用户自行把控。最后，当应用正式运行后，还需要持续监控其运行状态与性能表现，这就需要监控和诊断能力。好在这些能力在 Web 中可以开箱即用，用户无需再单独搭建和维护，能够有效节省运维成本。
部署环境模板的分发与重放
最后，在本届挑战赛中最关键、也是使用频率最高的能力之一，就是部署环境模板的分发与重放。为此，我们提供了一套环境模板，能够一键拉起挑战赛完整评测环境。基于这套模板的重复使用，挑战赛执行脚本就可以轻松反复完成环境的创建与释放。放在过去的挑战赛中，这几乎是难以想象的——因为搭建一整套评测环境，向来都非常耗时耗力，环境一旦搭好，通常都希望在比赛结束前尽量不要再动它。但问题也正出在这里：只要环境需要调整配置，整个过程就会变得非常繁琐。不论是程序本身存在缺陷，还是需求临时变更，对整套评测环境进行配置修改，都会带来不小的工作量。
另外，由于这些环境在搭建之初就被固定下来，因此无论是否有选手实际使用，它们都必须持续运行，直到比赛结束。这显然不是一种合理的云资源分配方式。在用户提交高峰期，集群处理能力不足会导致排队；而在提交低谷期，这些资源又会被白白浪费。而基于环境模板的分发与重放能力，这些问题就能够被彻底解决。在预算允许、库存充足的前提下，理论上可以按需创建任意数量的评测环境，用完即释放。这样一来，如果没有用户提交评测，系统就不会浪费任何多余资源，实现更高效的弹性调度与云端部署。
盘他！
归根结底，PTS 和 Web 这两项“黑科技”，正是本届中间件性能挑战赛背后非常关键的底层能力支撑。Web 应用托管服务（Web ）也已于 2019 年 6 月 14 日，随着第五届中间件性能挑战赛评测正式开启，同步进入公测阶段。对于选手来说，它的使用门槛并不高，只需要注册一个阿里云账号并完成实名认证，就可以直接试用。开通 Web 后，在首页右下角还可以看到“ 一键创建第五届中间件性能挑战赛评测环境 ”的交互式教程。借助这套教程，选手能够快速搭建出一套与官方评测环境完全一致的测试环境。这样不仅可以省去大量环境搭建时间和精力，也能尽量避免因测试环境与官方评测环境不一致而产生的问题。
怎么样，就问你心动不心动？
点一下这里，一起来参与第五届中间件性能挑战赛吧！
本文作者：
殷成涛，花名风起，阿里云 PTS 开发工程师，专注于性能压测与高可用架构领域。
唐睿，花名奥陌，阿里云 EDAS 和 Web 产品经理，专注于应用托管类产品设计与相关中间件技术。
