MeterSphere的定位为一个“一站式的开源持续测试平台”。它主要涵盖测试跟踪、接口测试、性能测试、团队协作等功能，同时兼容JMeter等主流的开源标准，可以有效地助力开发和测试团队充分利用云的弹性，进行高度可扩展的自动化测试。由于自己干性能测试的，所以比较关注性能测试这块的实现。以下是官方描述的架构：
可以看出来，这个平台是基于Docker的集群部署架构，而且通过NodeController实现了分布式压测部署，性能测试任务会被下发到NodeController，一个NodeController就是一个资源池（界面上能看到这么个概念）。
NodeController在接收到测试任务后，就会创建一个Docker的Jmeter引擎，这个jmeter实例并不是我们通常所理解的slave或jmeter-server进程，而就是独立的jmeter（master），所以它们之间不存在端口1099的冲突问题，这样就可以无限创建多个Docker引擎，比如在多个宿主机上分别创建NodeController，如下：
而一个NodeController下，可以创建多个jmeter-docker实例（一个任务起一个实例，压测完后，自动回收），如下：
每个jmeter-docker实例（多任务）压测完后，都会保留独立的测试报告（相当于是多个jmeter独立并行测试）：
所以这个平台非常适合多任务并行测试，同时方便实现在云端上的部署扩展（基于docker的优势） ，最关键人家还是开源的，所以这个平台的亮点很多。
虽然支持多个jmeter节点（多任务性）独立开展测试，但初看没发现有单任务多节点分布式压测及测试数据汇聚报告的功能（而从VincentWzhen所提供的文档链接中https://metersphere.io/docs/faq/#q中能看到这个功能），毕竟传统的jmeter压测思路，是将一个测试任务分发到分布式节点（jmeter-slave），最后汇聚测试报告；而这个平台则是通过资源池的概念来关联多节点（而由每个NodeController按照任务启动独立的jmeter docker实例），并引入Kafka作为测试结果的缓存组件，从官方文档中可以看明白分布式压测的支持方式：
MeterSphere 通过在测试资源池中添加多个测试执行节点的方式来支持分布式的性能测试。在我们向一个测试资源池中添加节点时，除了节点的 IP、端口信息外，还需要根据该节点的机器规格，配置该节点可以支持的最大并发数。当我们在执行性能测试的过程中选择了某个测试资源池时，MeterSphere 会将本次性能测试定义的并发用户数，按照所选测试资源池的节点支持的最大并发数进行按比例拆分（目前发现有个BUG，就是各个NodeController并发启动时，对应的jmeter-docker是以任务ID?testId 命名的，这在容器集群中可能因为同名而启动失败，希望后续版本可以避免），在测试开始执行后，每个测试执行节点会将测试结果、测试日志等信息输送到执行的 Kafka 队列中，MeterSphere 中的 data-streaming 组件会从 Kafka 中收集这些信息并进行汇总处理（按测试任务所对应UUID键来汇聚报告）。
针对平台的性能测试部分，根据自己的理解所绘制的各个组件关系架构图，如下：
根据对资源池概念的进一步理解，我把上面的关系图再加一层，变成如下所示：
新的关系架构图说明了，这个平台不仅支持多任务并行测试（通过NodeControlle启动多个Jmeter Docker实例，启动的jmeter实例都不依赖于端口），也支持分布式并发测试（通过资源池调度多个NodeControlle一起压测）。这么一来，这个平台的整个关系就比较清晰了，它很好的避免了传统Jmeter分布式压测平台在多任务运行时的Jmeter-slave争用情况（大家都知道，一个jmeter-slave独占一个1099端口，根本无法多任务并行调用），又能满足按任务分布式并发测试的要求。
说明：Jmeter把测试结果发送给Kafka的方式也很简单，就是使用了第三方后端监听器?jmeter-backend-listener-kafka?，将Jmeter的实时监听数据发送给kafka，利用kafka能够处理高吞吐量和分布式的流量数据特性，以实现Jmeter集群的高并发测试结果数据汇聚能力。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
