企业官网建设流程全解析

• 示例工程

本文是 52-technologies-in-2016 项目第 19 周（19-bees/README.md）的技术专题：以beeswithmachineguns为工具，讲解如何"召唤一群蜜蜂"——批量启动微型 EC2 实例——对一个 Web 应用发起分布式负载测试。读完本文，你将掌握该工具从安装、AWS 凭证配置到up/attack/down/report四命令全生命周期的使用流程，并理解其底层基于 boto、paramiko 与 Apache Benchmark 的工作原理，从而在自有服务器上复现一次完整的 EC2 分布式压测。

beeswithmachineguns 是什么

beeswithmachineguns是一个 Python 命令行工具，它的设计目标非常直接：通过启动大量微型 EC2 实例（"蜜蜂"），对目标 Web 应用（"靶子"）发起分布式负载测试（"攻击"）。与在单机上用多线程模拟并发不同，它把压力源分布到多台真实的云服务器上，从而在接近真实网络环境的前提下产生大规模请求流量。

工具本身提供的命令集非常精简，运行bees -h即可看到它的全部能力，共四个子命令：

Usage: bees COMMAND [options] Bees with Machine Guns A utility for arming (creating) many bees (small EC2 instances) to attack (load test) targets (web applications). commands: up Start a batch of load testing servers. attack Begin the attack on a specific url. down Shutdown and deactivate the load testing servers. report Report the status of the load testing servers.

这四个命令恰好构成一次完整压测的生命周期：

• up：创建（"武装"）一批 EC2 压测实例；
• report：查看当前压测集群的状态与公网地址；
• attack：对指定 URL 发起并发请求；
• down：压测结束后关闭并注销这批实例。

值得一提的是，本项目第 10 周曾介绍过另一款压测工具 Gatling（见 10-gatling/README.md）。Gatling 偏向"单机、代码化、异步模拟用户"的压测范式，而beeswithmachineguns走的是"云上弹性集群、命令行一键分发"的路线，二者思路互补，可对照学习。

使用前提：先读懂官方的严重警告

在动手之前，原文档引用项目官方主页特别强调了一个不可忽视的前提：

如果你决定使用 Bees，请牢记以下重要警告：它在某种程度上就是"一个包装精美的分布式拒绝服务攻击（DDoS）工具"。因此，如果你把它指向任何不属于你自己的服务器，你将：行为不道德、导致你的 Amazon Web Services 账户被锁定，并对你造成的任何停机事故承担法律责任。

这一点必须严肃对待：beeswithmachineguns的"分布式"能力本身是中性的，但把它用于未经授权的目标，性质就等同于发起 DDoS。本文所有操作仅适用于你自己拥有、且明确授权进行压测的服务器，例如自己的应用站点或临时搭建的测试环境。这也是整个系列文档在使用该工具前反复强调的伦理底线。

安装 beeswithmachineguns

原文档撰写于 2016 年，安装步骤基于 Python 2.7 的虚拟环境。建议先创建一个独立的virtualenv，避免污染系统 Python：

$ virtualenv venv --python=python2.7 $ source venv/bin/activate

激活虚拟环境后，可以运行which python确认当前python已指向虚拟环境内的解释器，再执行安装：

$ pip install beeswithmachineguns

该工具依赖两个关键 Python 包，理解它们有助于后续排查问题：

• boto：AWS 官方 Python 客户端库，用于与 Amazon EC2 交互，负责实例的创建、状态查询与销毁；
• paramiko：SSH v2 协议的 Python 实现，beeswithmachineguns用它建立到压测实例的 SSH 连接，从而在远端执行压测命令。

安装完成后，验证命令是否可用：

$ bees -h

若能正常输出前文展示的四个子命令帮助信息，说明安装成功。

环境前提说明：上述安装流程是 2016 年原文档的实际步骤，基于当时主流的 Python 2.7。Python 2 官方维护已于 2020 年终止，若在今天的运行环境中安装，需要留意beeswithmachineguns及其依赖（boto、paramiko）对 Python 版本的兼容性，必要时在 Python 2.7 兼容环境或容器中运行。压测目标站点也应确保对压测流量有充分预期与放行策略。

配置 AWS 凭证与默认区域

beeswithmachineguns需要通过 boto 调用 EC2 API，因此在执行任何命令之前，必须先配置 AWS 访问凭证。原文档推荐的配置方式是把凭证写入~/.aws/credentials文件：

[default] aws_access_key_id = <YOUR_AWS_ACCESS_KEY> aws_secret_access_key = <YOUR_AWS_ACCESS_SECRET>

同时可以在~/.aws/config文件中设置默认区域，例如us-east-1：

[default] region=us-east-1

配置完成后，bees才会知道该用哪组密钥、在哪个区域启动实例。区域配置直接影响后续up命令中实例的落点——默认区域是us-east-1时，实例默认在该可用区启动，也可通过--zone参数指定其他可用区。

完整压测实战：一次"蜂群"生命周期

1.bees up：武装蜂群

up命令用于启动一批压测服务器。原文档给出的最小示例是一次启动 1 台实例：

$ bees up --servers 1 --group default --key my-ssh-key

各参数含义如下：

执行后，终端输出大致如下：

New bees will use the "default" EC2 security group. Please note that port 22 (SSH) is not normally open on this group. You will need to use to the EC2 tools to open it before you will be able to attack. Connecting to the hive. Attempting to call up 1 bees. Waiting for bees to load their machine guns... . . . . Bee i-b8581a3f is ready for the attack. The swarm has assembled 1 bees.

这段输出包含两个关键信息，值得细读：

1. 安全组警告：默认安全组通常不开放 22 端口（SSH）。由于attack阶段需要通过 SSH 进入实例执行压测，你必须在启动实例前用 EC2 管理工具为安全组开放 22 端口入站规则，否则后续无法发起攻击。这是新手最容易踩的坑。
2. 实例就绪：i-b8581a3f是 AWS 为这台实例分配的资源 ID，输出表明它已进入可压测状态，蜂群集结完毕。

2.bees report：查看蜂群状态

在发起压测前，可以用report命令确认实例的运行状态与公网地址：

$ bees report

输出示例：

Read 1 bees from the roster. Bee i-b8581a3f: running @ 54.100.99.121

这里读取的是"花名册（roster）"——即本地记录的已启动实例清单，显示实例i-b8581a3f正在运行，公网地址为54.100.99.121。

3.bees attack：对目标发起压测

attack命令是压测的核心，原文档示例如下：

$ bees attack -n 1000 -c 25 -u https://my-website.com/

这条命令会通过 SSH 在所有已启动的实例上同时发起请求，其中：

• -n 1000：请求总数（total connections），本示例共 1000 次连接；
• -c 25：并发连接数，即同一时刻保持 25 个并发请求；
• -u：压测目标 URL。

也就是说，每个压测实例都会按-n/-c的参数组合对目标 URL 施加负载，最终汇聚成分布式的请求洪流。压测结束后，bees会收集各实例上压测工具的返回结果并汇总回传给用户。

4.bees down：解散蜂群

压测完成后，务必用down命令关闭并注销所有压测实例，避免 EC2 持续计费：

$ bees down

输出示例：

Read 1 bees from the roster. Connecting to the hive. Calling off the swarm. Stood down 1 bees.

至此，一次完整的"召唤蜂群 → 确认状态 → 发起攻击 → 解散蜂群"压测闭环就完成了。建议把down视作压测流程的强制收尾动作：压测实例本质上是临时资源，及时回收既是成本控制，也是避免空闲实例被误用或遗忘的必要操作。

原理剖析：up 与 attack 命令底层做了什么

原文档最后一节专门讲解了工具的内部机制，这里结合其描述展开说明。

up命令：boto 启动实例 + 轮询等待就绪

up命令做的事情其实非常简单：调用 boto 的 API 启动指定数量的 EC2 实例。关键在于"确保实例真正运行起来"这一步——up命令会进入一个while循环，反复查询实例的当前状态，直到实例进入running状态才返回。原因在于：

• 实例从创建到进入running状态通常需要一两分钟；
• 只有处于running状态的实例才允许 SSH 接入；
• attack阶段依赖 SSH，因此up必须保证返回时实例已可连接。

前文输出中的Waiting for bees to load their machine guns...以及逐行的.，正是这个轮询等待过程的直观体现。

attack命令：paramiko SSH + Apache Benchmark（ab）

attack命令的执行链路分三步：

1. 建立 SSH 连接：使用up命令中指定的.pem密钥（存放在~/.ssh目录），通过 paramiko 的 API 与每个压测实例建立 SSH v2 连接；
2. 远程执行压测：连接建立后，在实例上调用Apache Benchmark（ab）工具对目标 Web 站点施加负载——你在attack命令中传入的-n、-c、-u等参数会被直接透传给ab；
3. 汇总结果：收集各实例上ab的执行结果，返回给用户查看。

这正是"分布式"的由来：每一台 EC2 实例都是独立的压测执行者，通过 SSH 统一调度，最后把多台机器的压测结果合并汇总。理解这条链路，也就理解了前文为什么强调安全组必须开放 22 端口——attack的一切都建立在 SSH 可达的前提之上。

小结

beeswithmachineguns用极简的命令行接口，把"云上分布式压测"这件事压缩成了up、report、attack、down四个动作：boto 负责资源编排，paramiko 负责远程调度，Apache Benchmark 负责实际施压。对于需要评估应用在突发高并发下表现的场景，它是一种成本可控、弹性灵活的压测方案。不过请始终牢记官方警告：这些"蜜蜂"只会忠实地执行你的命令，把枪口对准谁，是你的选择与责任——压测请务必限定在你自己拥有的服务器上。

本文为 52-technologies-in-2016 系列第 19 周内容的深度整理，原始教程见 19-bees/README.md，系列索引见 README.md。文中的命令与配置均以该文档所述环境（Python 2.7 时代、AWS EC2）为前提，实际使用时请结合当前环境与 AWS 控制台配置做相应适配。

• 示例工程