本届挑战赛的评测环节完全使用了云上的产品和服务，是一场真正意义上的云端赛事。可能有人会说：这有什么了不起？其实不然，纵观每届挑战赛，这还是第一次完全抛弃了阿里集团内部的专有系统而完全拥抱公共云，这是具有里程碑意义的一次改变。
正因如此，本届比赛才得以用到更多云原生的产品和服务，选手能够在比赛中使用性能测试 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 的诸多“杀器”尚未体现，如 RPS模式支持、流量地域定制、定时压测、SLA（服务等级协议）等都是业界领先的功能。欢迎大家试用。
黑科技二：隐藏于无形的 Web+
与 PTS 不同，Web+ 对选手来说几乎不可见，却在每次提交代码以后为其默默准备评测环境。如果参加了去年挑战赛的选手们，尤其是动手搭建过评测环境甚至是阅读过搭建评测环境代码的开发者们，必定会了解，去年比赛的评测环境完全是通过 Python 与 Shell 脚本拉起的，有大量的代码用于构建 Docker 镜像、启动服务并实施压测等，这还不包括在代码外提前进行的环境资源申请与配置。
Web 应用托管服务（Web+）正如其名称所示意的，正是用来解决 Web 应用托管中遇到的一系列问题。这些问题包括但不限于：
- 云资源的申购与编排
- 软件运行时环境的安装与配置
- 应用程序的启停与维护等
- 部署环境配置模板的分发与应用
而本届挑战赛正是综合利用了以上的这些功能特性。
云端资源的申购与编排
所谓云端资源，就是我们通常所说的 ECS、VPC、SLB 和 RDS 等，而申购与编排，就是从申请和购买开始，将各种孤立的资源按照正确的方式排列组合，最终形成一套可用系统的过程。这并不是一个新颖的产品概念，与 HashiCorp 的 Terraform、AWS 的 Cloud Formation 和阿里云自家的 ROS 都是同类型的产品，这类产品有一个通用的术语叫做 Infrastructureas Code（基础设施即代码）。不难想象就是用代码来指代基础设施。当一整套基础设施环境都可以以代码的方式进行固化与重放，那么这份代码就与基础架构基本上等同了。如此所带来的好处就是代码易于阅读、可以被版本管理也便于分发和复制。Web+ 也是利用了同样的技术，通过配置描述文件（Wpfile）这份代码来映射和编排一整套完整的基础设施环境。
软件运行时环境的安装与配置
在基础设施搭建完成以后，距离用户的应用程序可以运行还有一个中间环节，即软件运行时的安装与配置。根据应用所使用的公共类库、语言、应用容器和框架的不同，这部分的操作将会有很大的差别。为了解决这部分差异，Web+ 引入了技术栈的概念——即操作系统、语言、容器和其他辅助软件的集合。根据一套标准的技术栈扩展体系，Web+ 可以非常容易的支持任意多种编程语言，不限于当前已经提供的这些。举个 Java 的例子，如果一个技术栈仅仅包含 Linux 与 OpenJDK，那么其将是一套最简单的基于 Linux 系统的 Java 运行时技术栈。而如果在此之上又增加了一个 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+ 产品经理，专注于应用托管类的产品设计和相关中间件技术。
