▲ 图 1 MeterSphere Cloud 部署架构
作为一款一站式的开源持续测试平台，MeterSphere（https://github.com/metersphereGPL）遵循 v3 开源许可协议，涵盖测试跟踪、接口测试、UI 测试和性能测试等功能，全面兼容 JMeter、Selenium 等主流开源标准，有效助力开发和测试团队充分利用云的弹性进行高度可扩展的自动化测试，加速高质量的软件交付。目前，MeterSphere 开源持续测试平台项目在软件托管平台 GitHub 上的 Star 数量已经超过 9,900 个，累计安装部署次数超过 175,000 次。
MeterSphere 一站式开源持续测试平台除了离线部署的开源版和企业版外，还有 Cloud 版本（也就是在线的 SaaS 版本）。本文根据《MeterSphere 开源版、企业版和 Cloud 版选型攻略》直播内容整理而成，呈现 MeterSphere 各版本的基本情况和主要差异，为广大测试行业用户提供 MeterSphere 开源版、企业版和 Cloud 版的选型策略参考。
一、MeterSphere 版本概览
MeterSphere 是一款一站式的开源持续测试平台，遵循 GPL v3 开源许可协议，涵盖测试管理、接口测试、UI 测试和性能测试等功能，全面兼容 JMeter、Selenium 等主流开源标准，有效助力开发和测试团队充分利用云弹性进行高度可扩展的自动化测试，加速高质量的软件交付。
2023年5月25日，MeterSphere 一站式开源持续测试平台发布 v2.10 LTS 版本。这是继 2022 年 5 月发布 v1.20 LTS 版本后，MeterSphere 开源项目发布的第三个 LTS（Long Term Support）版本。MeterSphere 开源项目组将对 MeterSphere v2.10 LTS 版本用户提供长期支持，每两周发布小版本，持续进行问题修复更新并针对部分功能进行优化。
MeterSphere v2.10 LTS 版本在测试能力、用户体验、系统架构、系统安全四大方面进行了关键性的升级与优化，为用户带来全面升级的使用体验。
MeterSphere 企业版由 X-Pack 功能增强包和原厂企业级支持服务构成。
■ X-Pack 功能增强包
系统管理层面，用户可以自定义系统的 Logo 以及主题配色等；
功能用例相关方面，平台提供了多版本管理以及不同版本之间进行用例对比的功能，以及公共用例库的功能；
接口测试方面，平台主要是通过插件的方式来支持更多的接口测试协议，然后提供了 “误报库” 进行误报管理的功能，以及接口与 Case 之间变化的联动。当接口发生变化时，可以把该接口下的用例进行对应的更新；
测试执行层面，平台提供了自定义消息通知模板的功能，用户可以内置一些变量来构造自己的消息通知格式以及模板。平台可以支持使用 Kubernetes 集群来提供测试资源，比如用户去跑一个接口测试或 UI 测试、性能测试的时候，都可以把这些任务执行在指定的 Kubernetes 集群中；
性能测试方面，平台针对大规模的性能测试进行了多方面的优化；
系统集成方面，用户可以通过各种各样的标准协议去跟单点登录系统进行对接，包括 CAS、OIDC 等这些常见的协议都是支持的。另外，就是可以跟 Jira、TAPD、禅道等平台进行缺陷的双向同步，如果用户已经用了这些平台来管理缺陷，只需进行一些简单的配置就可以把已有的缺陷同步到 MeterSphere 平台的缺陷管理模块之上。
此外，UI 测试功能也包含在 X-Pack 功能增强包当中。MeterSphere 官网展示了平台的功能列表，如果对此感兴趣可以的用户进行详细的阅读了解：https://metersphere.io/features.html。
■ 原厂企业级支持服务
除了 X-Pack 增强包中的功能增强之外，MeterSphere 企业版还有对应的服务增强。其中，测试专家服务主要针对性能测试，包括对测试需求进行分析、对压测模型进行设计、对压测环境进行搭建和管理，以及后续测试结果的分析和优化。另外，针对 MeterSphere 平台的安装部署、使用、数据迁移等具体操作，MeterSphere 企业版也提供了专业服务解决用户使用过程中会遇到的各种各样问题。
MeterSphere 专业测试云，即 MeterSphere Cloud 版，在功能上与 MeterSphere 企业版是一致的，都是在 MeterSphere 开源版功能的基础上增加了 X-Pack 增强包中的增强功能。但是因为 MeterSphere Cloud 版是 SaaS 模式，用户无需部署并维护 MeterSphere 的环境，直接访问 Cloud 版的官网 (metersphere.com)，直接注册购买账号即可开始使用。与 MeterSphere 企业版类似，MeterSphere Cloud 版同样提供了更加专业、更加细致的技术支持服务。
我们看到，在功能层面，MeterSphere Cloud 版和 MeterSphere 企业版是一样的，但是在产品的背后，比如部署架构层面，MeterSphere Cloud 项目组针对 Cloud 应用场景进行了很多额外的处理和优化。整体上，MeterSphere Cloud 项目组希望能够充分利用公有云还有 Kubernetes 的一些技术优势给大家提供一个安全、稳定、可靠并且可以规模化扩展，同时成本又相对可控的 MeterSphere 版本。
■ MeterSphere Cloud 部署架构
MeterSphere Cloud 环境目前都是运行在公有云上的，在最底层使用了比较多的公有云托管服务，比如托管的 MySQL、Kafka、Redis 等。这些托管服务的稳定性比较有保障，像扩/缩容、被测恢复都可以直接使用，不需要额外去处理。
▲ 图 1 MeterSphere Cloud 部署架构
如图 1 所示，托管的 MySQL、Kafka、Redis 等应用负载都运行在 Kubernetes 集群中。Kubernetes Worker 节点大体上可以分成两类，一类是包年/包月或者竞价实例的固定节点，通过提前购买云服务器，然后将其添加到 Kubernetes 集群中作为一个 Worker 节点来使用。
另外，还有一种就是超级节点或者虚拟节点，这种类型的节点只是一个虚拟的逻辑概念，不需要提前额外购买服务器，它会根据运行在虚拟节点上的容器的维度来进行计费。在 MeterSphere Cloud 的使用场景里，这种类型的节点很适合去跑像性能测试以及 UI 自动化的测试。当有需要的时候去启动一个容器，跑完之后它就会被回收掉，不会再计费。
在这些 Worker 节点之上，MeterSphere Cloud 的工作负载大概又分成两类。图 1 的左侧是一些公共的管理服务，包括大家访问 metersphere.com 看到的门户网站，还有大家注册登录之后进入到了 “个人中心” 页面。在 “个人中心” 页面中，用户可以去管理 MeterSphere 的订阅、管理成员及工单等这些通用功能。
图 1 的右侧，就是整个 MeterSphere 完整的应用，整体也是通过 Kubernetes 的方式跑起来的。这里进行了一个设计，就是 “个人中心” 页面和门户背后，可以去关联绑定多个 MeterSphere 环境。
这样一来，虽然在一个 MeterSphere 环境的 Kubernetes 集群里，每一个组件都可以去横向的扩容。但是它能够支持的用户规模毕竟还是有限的，所以在这种情况下，比如说当用户规模在进一步增长的时候，可以通过增加新的 MeterSphere 环境来扩展整个 MeterSphere Cloud 环境的规模。
有的用户对 MeterSphere 的环境要求特别高，希望有一套单独的环境来使用，也可以通过这样的方式单独部署一个 MeterSphere 环境，然后添加到 “个人中心” 页面，将这一部分用户的路由跳转到单独部署的 MeterSphere 环境之上。
■ 性能测试执行时的资源调度
前面提到在整个 MeterSphere 环境 Kubernetes 集群的 Worker 节点使用到了 “超级节点” 或者 “虚拟节点” 的概念，这种类型的节点特别适合用来运行性能测试还有 UI 自动化测试，具体的使用方法如下。
▲ 图 2 性能测试执行时的资源调度
大家都知道跑性能测试其实是比较耗费资源的，使用 MeterSphere 去跑性能测试的时候，Cloud 版本都是使用 Kubernetes 集群来跑性能测试，MeterSphere 就会调用 Kubernetes 的接口去创建出对应的性能测试的 Job。在这背后，可能是一个或者多个 JMeter 的 Pod 来执行的脚本。
具体有多少个 Pod 取决于并发数有多少。比方说，一个配置设定每一个 Pod 承载 500 个并发的测试，那么跑 1,000 并发的时候，就需要两个 Pod。在这些 Pod 运行起来之后，它会把结果传输到指定的 Kafka Topic 当中。MeterSphere 就从这个 Kafka 对列中获取到性能测试的报告并且进行处理，并展示到性能测试报告的页面上。
在这一过程中，如果是私有化部署的方式，用户什么时候跑性能测试、跑多少规模的性能测试，都是一定程度上可以提前预知或者提前规划的。但是在 Cloud 模式下，无法预知有多少用户在什么时候会跑多少个并发数的性能测试，这样对 MeterSphere 整体的资源调度就有一个比较高的要求。比方说，当有很多个用户总共需要去跑 1,000 个性能测试的时候，那么产品端就至少需要去启动 1,000 个 JMeter 的容器，来运行这个性能测试。
■ 基于云平台能力的动态调度
那么，要运行这么多容器平台需要多少个 Kubernetes 节点呢？一种比较容易解决这个问题的方法是，通过 “节点池 + 弹性伸缩” 的方式。根据一个节点池的 CPU、内存、网络流量以及 Pod 数量等监控指标，来动态地伸缩 Kubernetes 的 Worker 节点数量。当用户有更多的性能测试需要去跑的时候，就创建出更多的 Kubernetes 节点出来。当没有那么多性能测试要跑的时候，就缩减这个节点的数量。
▲ 图 3 基于云平台能力的动态调度
但这种方式存在两个比较明显的问题：
① 伸缩指标的配置与调试比较繁琐。比方说如果根据 CPU 内存来配置的话，可能不一定能很好地触发伸缩策略；
② 扩缩容存在一定的滞后性。因为通过这种方式的话，在公有云上创建节点需要时间，节点的初始化需要时间，节点加入到 Kubernetes 里也需要时间，加入到 Kubernetes 之后，在该节点上把 JMeter 的容器跑起来也需要时间。整个时间会拉得比较长，有可能造成的情况就是用户运行一个性能测试，需要等待一段比较长的时间，可能得几分钟才能真正的把这个性能测试任务给跑起来。
这对用户来说体验不够友好，MeterSphere Cloud 版本没有采用这种方案，而是使用到了 “超级节点” 或者叫 “虚拟节点” 来调度性能测试的 Job。
“超级节点” 就不需要事先去创建出对应的云服务器，并且把它加到 Kubernetes 集群里了。只需要在创建这个性能测试任务的时候，给它打上特定的节点选择标签，公有云就会自动地把这个节点调度到其背后的一个资源池上。具体调度在什么地方，对 MeterSphere Cloud 产品端是透明的。这些性能测试任务会启动在对应的 “虚拟节点” 上。在启动它时，只会在该性能测试任务运行期间对产品端进行计费，整体费用可控，响应时间也比较快。
这种方式比起刚才提到的弹性伸缩方式，有几个比较明显的优点：
① 配置很简单，用户只需要在创建任务的时候，添加一个额外的 Node Selector 标签，就可以完成这个任务；
② 底层调度是由云厂商完成的，可靠性和响应速度都有比较好的保障；
③ 从用户/产品研发方面来讲，这个方案的成本更优，因为只有在 Pod 运行的时候才会对产品端进行计费，不需要准备大量的闲置节点在整个 MeterSphere 环境中。
■ MeterSphere UI 自动化执行过程
UI 测试方面其实跟性能测试比较类似，它可能没有性能测试那么耗资源，但当用户去跑一个性能测试与跑一个 UI 测试的时候，都需要一个单独的浏览器来执行 UI 测试。所以，相比于接口测试其实也是比较消耗资源的。
UI 测试的执行方式可能跟性能测试也比较接近，当用户去执行一个 UI 测试的时候，MeterSphere 会把 UI 的脚本包装成一个 JMeter 的脚本。在 JMeter 的脚本里，就会指定一个 Selenium Grid 来提供各种各样不同的浏览器节点，比如 Chrome 或者 Firefox。在执行的过程中，也是通过 JMeter 把这个结果发送到 Kafka 当中以及 MeterSphere 平台等，再从 Kafka 中取到结果来进行解析。
与性能测试类似，产品端不知道什么时候会有多少用户运行多少个 UI 自动化测试，那就不能很确切地来评估整个 Selenium Grid 的规模，需要准备多少个浏览器节点在这个 Grid 当中。
▲ 图 4 MeterSphere UI 自动化执行过程
所以，最好的情况就是整个 Selenium Grid 是可以动态扩展的。当用户有新的 UI 测试任务时，它的浏览器节点就多一些。没有那么多新的测试任务的时候，它的浏览器节点就少一些。
MeterSphere Cloud 项目组所采用的方案整体上可以分成两个环节：
■ 浏览器节点的动态扩缩容
▲ 图 5 浏览器节点的动态扩容
① 如图 5 所示，上层的 Selenium Grid 扩缩容环节，产品端使用了一个名为 “KEDA” 的第三方组件，它是来做 Kubernetes 集群中应用的弹性扩缩容的。KEDA 的弹性扩缩容可以很方便地使用到一些业务指标。具体到产品端的场景，KEDA 可以根据 Selenium Grid 中处于等待队列的会话数量来进行弹性的扩缩容。比方说，在 Selenium Grid 等待队列中有一个会话，需要一个 Chrome 浏览器去执行，KEDA 就会监控到这个信息，去创建出一个新的 Chrome 节点出来。这个会话就可以调度到新的 Chrome 节点上，完成 UI 自动化测试。
② 在下层的资源层面，也是用到了刚才提到的 “超级节点” 或者 “虚拟节点” 概念，通过 KEDA 新创建出来的浏览器节点，也会被调度到指定的 “超级节点” 上。相应的也是在浏览器存在，在 UI 自动化测试执行的这段时间可能会进行费用的计算，除此之外就没有额外的资源消耗了。
二、MeterSphere 各版本之间的差异
基于前面的介绍，相信大家应该对 MeterSphere 的开源版、企业版和 Cloud 版有了基本的了解。接下来，我们从三个版本的部署方式、软件价格、功能、技术支持、服务以及成本构成这五个方面，再跟大家来进一步对比一下三个版本之间的差异性。
▲ 图 6 MeterSphere 开源版、企业版和 Cloud 版对比
首先，从部署方式上来看，MeterSphere 的开源版和企业版都是采用私有化部署的方式，需要用户自己准备服务器资源，需要用户自行下载 MeterSphere 安装包，执行 MeterSphere 安装脚本实现部署安装。MeterSphere 的 Cloud 版采用云端托管的模式，也就是 SaaS 的模式，大家直接在 MeterSphere Cloud 的网站上注册账号，就可以开始使用到 MeterSphere 平台的全部功能。
软件价格层面，开源版是免费的，大家直接在 MeterSphere 官网上下载安装包或者运行一键安装脚本，就可以完成开源版的部署操作，开始使用开源版提供的所有功能。MeterSphere 企业版和 Cloud 版采用的是按人按年订阅的模式，用户所在团队有多少人需要去使用 MeterSphere，支付每人每年订阅的费用。
功能层面，开源版提供了测试跟踪、接口测试、性能测试几大核心功能模块，大家如果有 UI 测试的相关需求，就需要使用 MeterSphere 企业版。MeterSphere 的企业版和 Cloud 版就是在开源版的核心功能之上，增加了前面提到的 X-Pack 功能增强包中的相关功能。
技术支持及服务方面，前文介绍到了 MeterSphere 企业版以及 Cloud 版有更专业、更细致、更及时、更全面的技术支持服务。那么 MeterSphere 的开源版也不是说没有技术支持服务，是相比较而言是比较有限、粗放的技术支持服务。大家可以通过 MeterSphere 的 GitHub 仓库、用户交流群、论坛等，来给 MeterSphere 项目组反馈问题、提出需求。MeterSphere 项目组也会尽可能地提供比较及时、比较专业的帮助。但是因为在社区交流群等场景下提问的用户可能比较多，大家的问题可能会被很快刷走，问题的解决有时会有滞后。
最后是成本构成方面，刚才提到了 MeterSphere 开源版是免费的，大家不需要为这个软件付费。但是这也不意味着用户使用 MeterSphere 开源版就是没有成本的，比如刚才提到了开源版是要私有化部署的，大家在私有化部署的过程中，就需要去准备服务器资源。部署完成后使用的过程中，也会碰到各种各样的运营上的问题。比方说网络异常、CPU 内存或者某个资源遇到瓶颈、存储占满需要去备份以及需要恢复等。所以说，MeterSphere 开源版的成本构成主要是用户自己的服务器资源成本，以及后期使用过程中的运维成本。
MeterSphere 企业版因为同样是私有化部署的模式，所以它的成本构成首先是也会包含服务器资源的成本以及运维成本，除此之外还要加上 MeterSphere 企业版的软件订阅成本。
MeterSphere Cloud 版的成本构成就很简单，只需要有一个软件订阅的成本。大家注册之后在 MeterSphere Cloud 版的网站完成付费之后，就可以正常的使用 MeterSphere 了，并不需要关注其背后的服务器资源、运维操作等问题。
因此，MeterSphere Cloud 版反而是成本最低的一个选择，这可能和大家的直觉有些不太匹配。举个具体的例子，根据 MeterSphere 官方的服务器配置（8 核 16GB），甚至更低一点的配置，用户自己在公有云上去买这一规格的服务器，大概需要 4,000 到 6,000 元每年。而这个价格就可以供十个人的团队去使用 MeterSphere Cloud 版一年的时间了。所以说如果不是出于监管、网络或者数据敏感性等方面对私有化部署的强要求，MeterSphere Cloud 版对大部分用户来而言是更好的选择。
MeterSphere Cloud 版的优势具体体现在几个方面：
首先，大家不需要去关心部署的问题，直接注册就可以使用，可以更快地使用 MeterSphere 并将平台的功能应用到测试流程当中；第二，相比于 MeterSphere 开源版，MeterSphere Cloud 版的功能会更加全面，因为它包含了 X-Pack 功能增强包中的功能，同时有更好的技术支持，大家使用起来的话也会更加省心，不用担心执行测试时服务器资源够不够用，会不会出现故障等问题。
MeterSphere Cloud 版整体来讲是成本最优的选择，无论是跟 MeterSphere 企业版相比来，还是跟 MeterSphere 开源版相比，当用户把服务器资源的成本以及运维成本都考虑进去的时候，MeterSphere Cloud 的实际成本都是最低的。
三、我适合使用什么版本的 MeterSphere?
以下是为大家总结的 MeterSphere 不同版本的选型策略。如果您的团队决定要使用 MeterSphere，可以参考图 7 进行实际选型。
▲ 图 7 MeterSphere 版本选型思路示意
第一个要考虑的问题就是有没有专门的运维团队。虽然 MeterSphere 已经把安装这个环节给大家进行了一个比较好的封装，提供了在线安装包、离线安装包，提供了 Kubernetes 的环境中使用的 Helm Chart ，基本上大家都可以很快速地完成 MeterSphere 的安装部署。
但是在部署完成后，随着用户使用的时间越来越长、使用的规模越来越大，MeterSphere 的后续运维就需要考虑各种各样的问题。比如存储空间可能会不够；CPU 内存去跑大批量的性能测试时资源是否足够；以及各种各样的中间件、数据库、Kafka 的性能是不是存在瓶颈，是不是能够支撑大规模使用等。
所以，如果大家没有专门的运维团队来保障 MeterSphere 的稳定使用，建议直接考虑使用 MeterSphere Cloud 版。作为用户直接使用 MeterSphere，不需要关心其背后复杂的运维问题。
如果有专门的运维团队可以保障整个 MeterSphere 环境的稳定，接下来就需要考虑功能层面的问题了，即是否需要 X-Pack 功能增强包中所提供的功能。比方说，用户的业务系统如果需要开展 UI 测试，那就需要使用到 X-Pack 功能增强包。是否需要与单点登录系统进行对接？是否需要对 MeterSphere 平台的主题色、Logo 进行定制？如果有这些需求就需要考虑 MeterSphere 企业版。
如果用户对 MeterSphere 的增强功能没有需求，是不是就可以直接使用开源版了呢？这里还有一个问题需要大家去考虑：是不是需要 MeterSphere 官方提供的专业技术支持服务？比如当用户对于某个功能的使用场景及使用方式可能不是特别明确，MeterSphere 官方就可以提供专门的上手服务，可以帮助大家更快地把 MeterSphere 的这些功能应用到实际测试工作当中。还有前文提到的针对性能测试的专家服务等。
如果大家对这方面的服务也没有需求，大家可以接受在 GitHub 或者通过技术交流群、论坛等方式来获取支持的话，或者说大家可以自己服务自己，就可以考虑使用 MeterSphere 开源版。
如果大家对私有化部署没有特别强烈的诉求的话，不妨直接考虑 MeterSphere Cloud 版。如果大家需要私有化部署，可以考虑 MeterSphere 企业版。
那么什么情况下会需要私有化部署呢？一般来说如果用户身处强监管的行业，或者说用户的被测系统是纯内网的环境，互联网上根本访问不到，也没有办法跟 MeterSphere Cloud 环境的网络进行打通，那么用户就要考虑使用 MeterSphere 企业版。或者说，用户特别在意数据安全相关的问题，担心使用 SaaS 服务后用例会被其他人看到。如果有这样的担心， 虽然说这种情况出现的可能性很小，但如果大家实在有这种担心也要考虑私有化部署，选择使用 MeterSphere 企业版。
