问题背景
2017 年中, 我参与了一个亚太地区互联网公司并购的项目, 客户收购了亚太地区 7 个国家的同行业互联网企业和产品. 我作为其中的 DevOps 咨询师和 DevOps 工程师, 和客户一起完成并购后的产品迁移和技术能力提升的设计, 实施和培训.
客户希望采用新的统一产品, 并根据不同地区的业务特色进行一些定制, 与此同时, 需要进行数据迁移以保证业务可以继续运行. 其中一个很关键的步骤是把原系统的 URL 通过重定向的方式到新的产品中, 因为有很多的第三方链接和搜索引擎依然保留了原系统中的链接.
初步统计了一下, 将近有 3000 多个 URL 需要重定向, 光是规则和正则表达式就写了 400 多条(没有统一规则的 URL 害死人啊), 这就引发了一个问题: 我该如何验证这些规则和覆盖这些 URL ? 此外, 大量的重定向不光对用户来讲不是很好的体验, 如果我要优化这些规则, 我如何保证我当前的转发规则不被破坏?
解决方案
最早, 我们写了一个 Shell 脚本, 用 curl 命令来验证这些 URL, 最初只需要验证 200 条就可以满足需求, 时间也不到两分钟. 后来, 我们采用了一个 Excel 文件来跟踪这些 URL, 产品经理只需要把新的重定向 URL 补充到上面, 我们就依据这些 URL 来开发 nginx 的重定向规则.
这让我想到了 TDD 的红绿模式: 先写出一个自动化测试用例, 然后修复这个自动化测试用例. 更好的是, 有了自动化的测试做保护, 你可以放心和安全的对代码 (Nginx) 进行重构.
此外, 随着更多的 URL 需要重定向, 这个数字在不断的增加. 原先的 Shell 脚本执行的时间也从最初的 2 分钟增长到了 15 分钟.
现有的工具满足不了要求, 一怒之下, 我决定开发一个自己的工具. 它必须具备以下特点:
可以通过文件读取规则, 进行大批量验证.
多线程并发执行, 可以提升效率.
很容易和 CI 集成.
能帮我做一定程度的重定向优化分析.
于是, 我在一个周末的时间用 Python 写下了 vivian: 一个多线程的批量自动化重定向验证工具.
它把原先的 15 分钟的验证时间缩短到了 17 秒, 效率提升了 5294 % !!
后来, 我把测试用例集成到了代码库里. 并把 vivian 提交到了 pipy, 这样我就可以通过 pip 在初始化 CI 上安装了. 也减少了代码库中减少了一个需要维护的脚本.
选择 Python 的原因主要是因为相较于 Ruby, Go, Java, NodeJS 来说. Python 的语言环境比较稳定, 几乎每种 Linux 都包含 Python 的运行环境, 且容易安装和集成.
如果你对该工具感兴趣, 欢迎在 github 上围观: https://github.com/wizardbyron/vivian
安装使用 Vivian
安装:
pip install vivian
使用:
vivian -f example.csv
test.csv 非常简单, 第一列是源 URL, 第二列是目标 URL. 例如:
- http://www.github.com, https://github.com/
- http://www.facebook.com, https://facebook.com/
采用 csv 文件的目的主要是方便使用 Excel 和文本工具编辑.
之后会得出下列结果:
- vivian -f example.csv
- load test case from example.csv
- 2 cases loaded running in 2 threads
- verifying http://www.github.com to https://github.com/
- verifying http://www.facebook.com to https://facebook.com/
- Failed cases:
- ============================================================
- line: 2
- origin: http://www.facebook.com
- dist: https://www.facebook.com/
- expect: https://facebook.com/
- status: 200
- redirect_count:1
- ------------------------------------------------------------
- 1/2 PASS in 5.8494720458984375 seconds
第一行输出提示测试用例文件的路径.
第二行输出提示测试用例数量和线程数量. 你也可以通过增加 -n 来指定线程的数量, 默认线程数量等于 CSV 文件记录行数. 如果文件过大, 请限制线程数量, 否则线程创建开销会影响测试机性能. 此外, 过多的并发访问也会发起应用的流量保护机制. 没有流量保护的应用则会 Crash.
第三行到第四行列出了需要验证的 URL.
第五行开始就是失败的测试用例信息:
失败用例的第一行就是测试用例所在的文件行号.
失败用例的第二行是测试用例测试的源 URL.
失败用例的第三行是访问测试的 URL 的实际目标 URL.
失败用例的第四行是期望得到的 URL.
失败用例的第五行是访问测试用例源 URL 最后得到的 HTTP 状态.
失败用例的第六行是访问测试用例源 URL 到最后结果之间的 重定向次数, 有了这个数字我们可以优化 URL.
最后一行表明有多少个用例通过了测试, 同时统计了完成这些测试的总时间.
最佳实践
以下是我总结的使用 vivian 的最佳实践场景, 希望能对你的 web 服务器维护工作起到帮助.
作为冒烟 / 回归测试集成在持续部署流水线里
Vivan 是用 Python 编写的, 这意味着你可以在自己的 CI 服务器上 (大多是 Linux) 很容易的安装 vivian, 在部署完成后用 vivian 执行代码中的测试用例, 这相当是对 Nginx 规则开发的回归测试 -- 不会影响到以前的 URL 重定向. 于此同时也是一种冒烟测试, 如果测试失败, Nginx Server 是有问题的. 这样可以避免一些修改破坏当前的生产环境.
重构 nginx 转发规则
在这种模式下, 你需要先把需要重定向的案例写到文件里, 这时候运行 vivian 肯定会失败. 之后你就可以根据案例编写重定向规则. 甚至可以优化合并一些正则表达式, 因为有自动化测试保护. 你可以放心的将验证过的 nginx 部署到生产环境中.
用 Dev 的方式处理 Ops 的工作, 也算一种 DevOps 吧!?
减少重定向
我们知道, 每一次重定向都会给客户端带来额外的访问开销, 这对用户体验是一种灾难. redirect_count 记录了重定向的次数, 并且给出了最初和最终的 URL, 我们可以利用这些信息构造更加简单和直接的规则, 优化重定向.
来源: http://www.jianshu.com/p/dbe62da30eb4