Filebeat Log input核心配置详解

Filebeat运行过程

说到实时查看日志，最常用得莫过于 tail -f 命令，基于此可以自己实现一个简单的日志采集工具，https://github.com/iyaozhen/filebeat.py/blob/master/filebeat.py#L237

但这太简陋了，无法保证不丢不重。我们看看 Filebeat 是怎么实现的，官方说明：https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-overview.html

简单来说 Filebeat 有两大部分，inputs 和 harvesters，inputs 负责找文件（类似 find 命令）和管理 harvesters，一个 harvester 则和一个文件一一对应，一行行读然后发送给 output（类似tail -f）。

当然还有很多细节问题，我们结合配置文件一一详解。

Log input配置详解

官方配置说明：https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-log.html

先看一个基本例子（下面所述基于7.x版本，6.x版本也基本适用）

1
2
3
4
5
6
7
8
9
10
11
filebeat.inputs:
- type: log
  paths:
    - /var/log/system.log
    - /var/log/wifi.log
- type: log
  paths:
    - "/var/log/apache2/*"
  fields:
    apache: true
  fields_under_root: true

inputs 可以配置多块（block），就是相同类型的放一块，这个也很好理解。paths 可以配置多个文件，文件路径和文件名都支持通配。

ignore_older 和 scan_frequency

这就有两个细节问题了，一是路径下的历史文件可能很多，比如配置了按天分割，显然旧文件我们一般是不需要的。二是扫描频率如何控制，通配设置复杂的话频繁扫文件也是很大的开销。

问题一则是通过 ignore_older 参数解决，意思就是多久前的旧文件就不管了。比如设置为 1h，表示文件时间在 1h 之前的日志都不会被 input 模块搜集，直到有新日志产生。

问题二则是通过 scan_frequency 参数控制，表示多久扫描一次是否有新文件产生。比如设置 10s（默认），一个新文件产生 10s 后会被发现，或者一个旧文件（上面 ignore_older）新产生了一行日志 10s 才发现这个文件。有人说我需要实时性，是不是这个值设置的越小越好，其实是错误的，前面我们介绍了 Filebeat 架构，input 模块只是负责发现新文件，新文件是相对已经被 harvester 获取的文件，第一次发现之后就已经在被 harvester 一行行实时读取了，所以这里基本上只影响日志切分时的实时性（这种场景下的短暂延迟是可以接受的）。

close_* 和 clean_*

那么被 harvester 获取的文件就一直拿着不放吗？文件重命名或者被删除后怎么办呢？这里重点介绍这两组配置。 Continue Reading...

Nginx+Tomcat偶现502分析

问题

业务为了负载均衡，前面放了个 Nginx，但最近 502 报警有点频繁，影响了 SLA，因此对这个问题做了较深入的研究。

502 Bad Gateway

简单来说就是 Nginx 找不到一个可用的 upstream，可能的原因有：

  1. 压根是配置错误
  2. 连接 upstream server 发生错误/超时
  3. upstream server 到了处理瓶颈

还有一个重点是轮询了 upstream server 后任然没有一个可用的。但是不管什么原因，都能在 Nginx 的 error log 中找到报错详情。

upstream prematurely closed connection

在 Nginx 中找到错误日志（开了 debug）：

1
2
3
4
5
6
7
8
9
10
11
[debug] 46093#46093: *606728052 http upstream process header
[debug] 46093#46093: *606728052 malloc: 00007FB65E3834E0:4096
[debug] 46093#46093: *606728052 posix_memalign: 00007FB65C783D60:4096 @16
[debug] 46093#46093: *606728052 recv: eof:1, avail:1
[debug] 46093#46093: *606728052 recv: fd:65 0 of 4096
[error] 46093#46093: *606728052 upstream prematurely closed connection while reading response header from upstream, client: xxx
[debug] 46093#46093: *606728052 http next upstream, 2
[debug] 46093#46093: *606728052 free keepalive peer
[debug] 46093#46093: *606728052 free rr peer 4 4
[debug] 46093#46093: *606728052 free rr peer failed: 00007FB65C704F50 1
[debug] 46093#46093: *606728052 finalize http upstream request: 502

看了下 Nginx 代码，发现是 c->recv(); 读到的内容为 0，日志中也有显示 recv: fd:65 0 of 4096，说明没有获取到 response

同时也查了 Tomcat access 日志，请求还没到 Tomcat。看情况就像日志里面说的，连接被断掉了。

一开始怀疑是网络原因导致连接断掉了，但出现较频繁，期间内网也无网络故障，应该和网络无关。

再看日志发现报错前后有很多 keepalive 信息，尝试关掉 keepalive，502 就没了，但这会对性能有一定影响，感觉有点因噎废食了，还得继续研究。

keepalive

HTTP 持久连接（HTTP persistent connection，也称作 HTTP keep-alive 或 HTTP connection reuse）是使用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，而不是为每一个新的请求/应答打开新的连接的方法。

一般 Nginx 会配置 keepalive 以提高性能：

1
2
3
4
5
6
upstream servers_test {
    server 127.0.0.1:5001 max_fails=1 fail_timeout=10s weight=1;
    server 127.0.0.1:5002 max_fails=1 fail_timeout=10s weight=1;
    keepalive 10;
}

Syntax: keepalive connections;

Activates the cache for connections to upstream servers.

The connections parameter sets the maximum number of idle keepalive connections to upstream servers that are preserved in the cache of each worker process. When this number is exceeded, the least recently used connections are closed.

可以配置每个 worker 对 upstream servers 最大长连接数量。同时这个长连接受 keepalive_requests（默认100） 和 keepalive_timeout（默认60s）配置的影响。

但 keepalive 也有缺陷，会加重 webserver 的负担，因为需要绑定一定数量的线程或者进程来维持长链接。注意 keepalive 并没有连接复用（即同一时间窗口不能处理多个请求，这个在 HTTP/2 中才实现），仅节省了新建/关闭连接的开销，类似连接池了。所以 webserver 一般都有类似 nginx 的 keepalive_requests、keepalive_timeout 配置，让空闲的连接断掉。

查看了 upstream(tomcat) 配置的 timeout 是20s，lighttpd 的 requests 是16，timeout 是 5s，都远小于 nginx 的配置。

原因就清楚了，upstream servers 先断了 keepalive 的长连接，但 nginx 仍使用了这个已经断掉的连接。

至于 nginx 为什么不主动检测一下连接是否可用呢？猜测应该是性能原因，一直检查连接池中的连接是否可用没必要，keepalive 协议本身也没业务心跳啥的。PS：商业版的 ngx_http_upstream_hc_module 可以主动监测（世界加钱可及）。

proxy_next_upstream

那么 Nginx 如何保证高可用呢？答案是重试。这就涉及另一个重要配置 proxy_next_upstream，在什么情况下进行重试，默认为 error timeout。按理说我们这个场景应该会重试，但没有重试。这是因为 Nginx 较新版本（1.9.13）多了个 non_idempotent 配置，默认 POST, LOCK, PATCH 等请求不重试，因为这些操作是非幂等操作，会对服务端数据造成影响（比如发消息接口，重试可能会重复发消息）。日志中也发现 502 的全都是 POST 请求。

要完全解决这个问题就需要对 proxy_next_upstream 配置簇深入看看，我们先做个测试。 Continue Reading...

Windows 10生产力提升之WSL实践

Mac 和 Windows 哪个更好，估计还能再吵几年。抛开部分硬件上的差距，Windows 用作开发上确实有点不顺手，毕竟大部分后端程序都是运行在 Linux 服务器上，macOS 占有先天优势。之前都是通过在 Windows 上起虚拟机来解决这个问题，如今 Windows 10 推出的 WSL（Windows Subsystem for Linux），成为了新的选择。

WSL 的官方介绍：

The Windows Subsystem for Linux lets developers run GNU/Linux environment

- including most command-line tools, utilities, and applications

- directly on Windows, unmodified, without the overhead of a virtual machine

简单来说就是不需要修改，无需虚拟机，就可以在 Windows 上直接使用 Linux 环境（grep, sed, awkd等），运行 Linux 程序（vim, MySQL, Apache等）。这就很舒服了，小孩子才做选择，大人全都要，实际如何我们来实践一番。

安装

首先是按照，非常简单，开启子系统功能后在应用商场选择一个发行版的 Linux 安装就行。官方指南：https://docs.microsoft.com/en-us/windows/wsl/install-win10

启动之后就可以使用了，你可以根据自己使用习惯，做一些初始化的设置（oh-my-zsh啥的）这里就不细说了。WSL 默认是通过安装的应用进入的（直接运行 bash.exe 也行），但大家还是喜欢通过 Xshell 等工具进入了，这就需要做一些配置。WSL 和 Windows 本机是端口共用的（这点特别注意，防止程序端口冲突了），直接通过 127.0.0.1 就能连接上，剩下的就和直接使用 Linux 差不多了。

但是，等你重启电脑，再使用 Xshell 连接时发现连不上了，没有 sshd 进程了，每次都需要打开 WSL 程序然后再运行 sudo service ssh start 有点麻烦。这就是 WSL 不一样的地方了，WSL 不是真正的一个系统，没有开机启动这一说，把 sshd 设置成开机启动也没有用。既然不能加入到 WSL 的启动项，那就加入到 Windows 的启动项中：

编写 run_wsl.vbs 脚本，用来在 bash.exe 中启动 sshd，然后将脚本放到系统启动目录里面（WIN+R 运行 shell:Common Startup 或者 shell:startup）就行了。

1
2
set ws=wscript.createobject("wscript.shell")
ws.run "C:\Windows\System32\bash.exe -c 'sudo /usr/sbin/service ssh restart'",0

不过需要注意 sudo 需要输入密码，还得把密码关了。WSL 中运行 sudo visudo 增加一行：ubuntu ALL=(root) NOPASSWD: ALL，表示 ubuntu （换成自己的）这个用户使用 sudo 运行任何命令时都不用输入密码。

当然安装之后可能会遇到一些其它问题，主要是一些安全软件和 WSL 不兼容，比如卡巴斯基会让 WSL 无法联网，腾讯的 TGP 会影响绑定端口，遇到了只能暂时关掉相关软件，相信之后这些问题会越来越少。

使用 Redis

之前在 Windows 上使用 Redis 比较麻烦，有一个 Windows 版的 Redis 但已经很久没有更新了，还有就是选择虚拟机。现在直接在 WSL 里面编译安装（make & make install）就行了。写好配置文件，sudo redis-server /etc/redis/redis.conf 运行即可。

不过有些同学可能会像我之前把 Redis 注册为 systemd 服务，但发现会报错：System has not been booted with systemd as init system (PID 1). Can't operate 说的也比较明白，系统不是通过 systemd 启动的。其实 WSL 不是一个真正的系统，应该说是一个容器，类似 Docker（这么一说感觉微软野心好大）。

LXSS diagram

（图片来源：https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/）

在 WSL 中运行的程序是真正的 Linux 二进制文件，不是移植版，不过当程序由用户态切换到内核态时`lxss.sys`和`lxcore.sys`驱动将会将 Linux 的系统调用翻译为  NT APIs 来模拟 Linux 内核。简单来说 WSL 是将 LInux 底层 API 用 NT 实现了一遍（所以 WSL 中没有 Linux kernel 代码），而且有些操作还是 Linux 独有的，比如fork()，可想而知这里面工作量有多大，任重而道远。

言归正传，Redis 已经在 WSL 中启动了，我们试试在 Windows 上能不能连上：

完美，就和 Windows 本地装的 Redis 一样。

与IDE集成

虽然说大部分语言都是跨平台的，但是还是有很多差别，比如 Python 的 epoll 只能在 Linux 下使用。在 Windows 上开发不是很方便，没有智能提示，还需要上传到服务器运行、调试。有了 WSL，现在可以在 Windows 上开发，然后直接在 WSL 里面运行。 Continue Reading...

phpMyAdmin浏览数据页面卡死

我们使用phpMyAdmin经常是一进去就直接展开数据库，点击表名查看数据，这样可以清楚的了解表的结构方便写 SQL。默认情况下是显示 25 条数据，即使有几亿行也很快。

但最近我换了一个 read 账号登录，点击表名的时候直接卡死了

应该是查询卡住了，命令行连上数据库，show full processlist发现有个查询确实卡住了：

一开始只关注到状态是`Creating Sort Index`，再结合使用 write 账号登录打开却很快的现象，认为是 read 账号没有 create 权限，导致卡着了（没有权限的话应该是直接报错的）。但是查了下 read 账号其实给的就是全部权限，一度陷入了僵局。

调整心态，回到原点，还是从「使用 write 账号登录打开却很快」的现象出发，查看日志，发现 write 账号进入的话点击表名浏览数据使用的 SQL 没有`ORDER BY`，那就是自动加的，查了下，phpMyAdmin 会自动保存上一次对字段排序的操作，再次操作字段能取消排序，但问题是我现在已经无法进入浏览页面了。

那考虑是不是能在哪里设置，关闭这个。页面上有个浏览模式设置，但这个试了下好像没啥用。

还是看下官方文档吧，找到了设置项，需要把`$cfg['Servers'][$i]['table_uiprefs']`和`$cfg['RememberSorting']`设置为false。这个功能还是好的，但在多人使用同一账号，数据量又比较大的情况下，还是关闭比较好，关闭也不影响排序功能，只是排序的操作不会保存下来。

Since release 3.5.0 phpMyAdmin can be configured to remember several things (sorted column $cfg['RememberSorting'], column order, and column visibility from a database table) for browsing tables. Without configuring the storage, these features still can be used, but the values will disappear after you logout.

然后还得把已经保存的设置项清除掉，位置在数据库：phpmyadmin（默认）表：pma__table_uiprefs，把这个表清空即可又回到之前丝滑的感觉了。

参考资料

https://stackoverflow.com/questions/33809816/phpmyadmin-automatically-adding-order-by-to-browse

https://docs.phpmyadmin.net/en/latest/config.html#cfg_Servers_table_uiprefs

tomcat设置remote JVM debug后stop失败

最近突然出现执行 tomcat/bin/shutdown.sh 停止 tomcat 失败的情况，报错如下：

1
2
3
4
5
6
7
8
9
……
Using CATALINA_PID:    tomcat/bin/CATALINA_PID
ERROR: transport error 202: bind failed: 地址已在使用
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../../../src/share/back/debugInit.c:690]
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
tomcat/bin/catalina.sh: line 365:  4589 已放弃 (core dumped) "jdk1.6.0_45/bin/java" -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -server -Xms2048m -Xmx2048m -XX:PermSize=512M -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8697 -Djava.endorsed.dirs="tomcat/endorsed" -classpath xxx org.apache.catalina.startup.Bootstrap stop
The stop command failed. Attempting to signal the process to stop through OS signal.
Tomcat stopped.

看了一下 catalina.sh: line 365 就是 stop 那里执行失败了，然后调用系统的 kill -15 杀死进程

再仔细看看报错，发现有端口被占用、`dt_socket failed to initialize` 等提示，觉得应该是加了 debug 命令的原因，去掉就好了。

1
2
# tomcat/bin/catalina.sh
JAVA_OPTS="-server -Xms2048m -Xmx2048m -XX:PermSize=512M -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8697"

但这个感觉也不太好，不能因噎废食呀。搜了下相关情况，发现是 JAVA_OPTS 用的不对，应该用 CATALINA_OPTS，因为 CATALINA_OPTS 变量在 stop 的时候不会被使用（如上图）。

所以最优的做法是使用 CATALINA_OPTS 变量设置 remote debug 相关参数。

1
2
3
# tomcat/bin/catalina.sh
JAVA_OPTS="-server -Xms2048m -Xmx2048m -XX:PermSize=512M"
CATALINA_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8697"

 

参考资料

解决tomcat shutdown时的地址被占用问题，https://my.oschina.net/u/1770666/blog/370620

https://stackoverflow.com/questions/11222365/catalina-opts-vs-java-opts-what-is-the-difference

现代化的PHP-写好注释

注释

有个段子：程序员最恨写注释和不写注释的人。个人认为注释主要作用是方便别人或者自己以后能快速理解这段代码逻辑和提升开发效率，这样要说的是如何使用注释来提升开发效率。

众所周知，PHP 是弱类型语言，变量的类型是可以变的，但在实际业务中，一个变量或者函数的返回值往往是确定的，确定的类型能提升我们的编码效率，也能把一些低级的错误（弱类型不代表无类型）扼杀在摇篮里。

PHP 主要通过类型声明来说明变量的类型，PHP7 开始允许更多的函数参数类型限定。比如下面这个例子，声明入参是 int 类型，但使用了 array 函数来处理，PhpStorm 能给出实时的提醒。

调用函数参数错误的话也有提示：

但 PHP 会有隐式类型转换，如上面传入浮点数的时候并没有提示错误，因为这也是合理的。不过 PHP 可以开启严格模式来检查此类错误。

PHP 内置的类型声明基本上够用了，但一般使用注释来实现更加丰富的功能。PHPDoc 是注释 PHP 代码的非正式标准，它有许多不同的标记可以使用。PhpStorm 能根据函数/类方法自动生成基本的标记：

基本标记 `@param` 和 `@return` 也很好理解，参数和返回值，作用和 PHP 自带的类型声明差不多，主要用来限制调用方传参和使用返回值。除了这两个标记之外，还有很多其它比较好用的标记。

Continue Reading...

GitHub 研发链 travis-ci 和 codecov 介绍

经常混迹于 GitHub 的话就会发现很多项目都有一些徽章，出现最多的就数这两个了：

这些徽章都是可以点击的，第一个点进去是 https://travis-ci.org/，travis-ci 是一个 CI（Continuous integration，持续集成） 平台，主要提供集群编译、单测、集成测试的环境。.org 的服务对公有仓库免费，`.com` 面向私人、团队、公司的项目提供商业支持（收费）。使用起来非常简单，使用 Github 帐号登录进去，就能看见开始界面：

核心就是`.travis.yml`的文件配置，一开始可以根据自己的语言选择初始的配置文件：https://docs.travis-ci.com/user/customizing-the-build#Specifying-Runtime-Versions。我这边的项目使用的是 Python，初始配置是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
language: python
python:
  - "2.6"
  - "2.7"
  - "3.2"
  - "3.3"
  - "3.4"
  # PyPy versions
  - "pypy"  # PyPy2 2.5.0
  - "pypy3" # Pypy3 2.4.0
  - "pypy-5.3.1"
# command to install dependencies
install:
  - pip install .
  - pip install -r requirements.txt
# command to run tests
script: pytest

官方注释可以说非常详细，我就不画蛇添足做说明了，根据自己代码实际情况做调整即可：

1
2
3
4
5
6
7
8
9
10
language: python
python:
  - "2.7"
# command to install dependencies
install:
  - pip install -r requirements.txt
# command to run tests
script:
  - nosetests -sv tests
  - nosetests -c demo/nose.cfg demo

配置好之后再 push 代码，就能在 travis-ci 页面上看见项目的构建、测试结果了：

点击图标就能生成我们需要的 MD 语法的代码了，粘贴进 README.MD 中就能显示了。

第二个徽章是 codecov.io（单测覆盖率统计平台），接入过程也很简单，也是不同语言选择不同的配置文件，codecov 可以无缝衔接 travis-ci，只需要在原来的配置文件上稍作修改即可，核心就是生成单测的结果文件。修改后的 `.travis.yml`

1
2
3
4
5
6
7
8
9
10
11
12
13
language: python
python:
  - "2.7"
# command to install dependencies
install:
  - pip install -r requirements.txt
  - pip install codecov
# command to run tests
script:
  - nosetests -sv --with-coverage --cover-tests --cover-package=py_http_api_test tests
  - nosetests -c demo/nose.cfg demo
after_success:
  - codecov

在原来的基础上多了 codecov nose 插件的下载和运行单测时多了`--with-coverage`等参数。最后还是再次 push 代码就能看见单测覆盖率报告了：

codecov 还有自己的配置文件：`codecov.yml`。用来实现一些定制化需求，比如说我需要排除一些模块，不进入覆盖率统计：

1
2
3
4
5
# https://docs.codecov.io/docs/ignoring-paths
ignore:
  - "tests/*"
  - "demo/*"
  - "py_http_api_test/http_test.py"

徽章生成代码的话在`setting`中可以找到：

除了上面介绍的这两个徽章，还可以通过 shields.io 平台生成一些其它的徽章，甚至可以自定义，比如 https://img.shields.io/badge/Python-2.7-brightgreen.svg 就可以生成一个表示 Python 版本的徽章，别人能看懂就行。

1
[![Support Python Version](https://img.shields.io/badge/Python-2.7-brightgreen.svg)](https://www.python.org/)

当然徽章不是重点，不是越多的越牛逼，重要的是规范整个研发流程。上面说的两个其实都是属于 CI（持续集成）中最具代表性的两个环节，算是入门了。关于 CI 是一个很大的话题了，这个有机会以后再说一下。

参考资料：

开源项目徽章集锦，https://segmentfault.com/a/1190000004278253

使用 Python nose 组织 HTTP 接口测试

现在前端 Web、移动端 APP 开发基本上是面向接口编程，后端各种 HTTP 接口已经提供好了，大家只要实现逻辑交互和展示就行。那么问题来了，这么多接口如何方便的进行测试呢？根据个人经验，我认为需要解决三个问题：1. HTTP 接口多种多样，测试程序如何统一？2. 测试程序如何规范组织？3. 接口间有上下文依赖，如何解决？

HTTP 接口多种多样，测试程序如何统一？

后端接口可能来自各个系统，GET/POST 协议的、遵循 RESTful 规范的，使用 session 认证、token 认证的，各式各样的接口都存在。但无论怎么变都无法脱离 HTTP 协议。因为组内的技术栈是 Python，这就很容易想到使用 Python 的 requests 库。首先我们使用`requests.Session()`会话对象，来进行会话保持和 Header、Cookie 等处理。这里我们可以简单封装一个 HttpSession 类，把一些常用操作和设置封装一下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
import requests
# 屏蔽https安全警告
# https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
from requests.packages.urllib3.exceptions import InsecurePlatformWarning
from requests.packages.urllib3.exceptions import InsecureRequestWarning
from requests.packages.urllib3.exceptions import SNIMissingWarning
requests.packages.urllib3.disable_warnings(InsecurePlatformWarning)
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)
requests.packages.urllib3.disable_warnings(SNIMissingWarning)
 
 
class HttpSession(requests.Session):
    """
    http请求会话
    """
 
    def __init__(self):
        super(HttpSession, self).__init__()
        # 不校验SSL证书
        self.verify = False
        # 超时时间
        self.timeout = (60, 600)
 
    def update_cookies(self, cookies):
        """
        更新当前会话cookie
        :param cookies: cookie字典
        """
        requests.utils.add_dict_to_cookiejar(self.cookies, cookies)
 
    def update_headers(self, headers):
        """
        更新当前会话的header
        :param headers: header字典
        """
        self.headers.update(headers)

通过`HttpSession()`来获取一个requests session对象，后续的 HTTP 请求都通过它发起。requests 提供 get()、post() 等各种方法调用，但这会让测试代码显得不统一，这里我们直接调用底层的 request 方法，该方法几乎提供了发起一个 HTTP 请求需要的所有参数，非常强大。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
http_session = HttpSession()
 
def test_get_access_token(self):
    """
    获取access_token
    """
    params = {
        "corpid": 'corp_id',
        "corpsecret": 'corp_secret',
    }
 
    response = http_session.request(
        'GET',
        config['dingtalk_oapi'] + '/gettoken',
        params=params
    ).json()
 
    data = response['access_token']
    print data is not None

这样每一个 HTTP 接口的测试都可以通过`准备参数`、`发起请求`、`断言结果`三板斧来解决。

测试程序如何规范组织？

前面我们已经解决了如何快捷的发起一个 HTTP 请求的问题，这让我们几行代码就可以测试一个接口的返回值。但你会发现新的问题又来了，各种脚本散乱在一堆，返回值解析各种中间变量，各种配置硬编码在代码中，测试结果全靠 print，这时 nose 框架就派上用场了。nose 是 Python 最流行的一个单测框架，提供测试 case 设置标签、测试 case 查找、强大的断言函数，格式化/可视化报告输出等功能。这样就可以像写单测一样写 HTTP 接口测试了。我们可以把一类接口的测试放在一个类里面，甚至可以把基础变量的定义放在基础测试类里面，其它测试类继承这个基类。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
try:
    import ConfigParser
except ImportError:
    import configparser as ConfigParser
import os
import sys
import unittest
 
import nose.config
import ruamel.yaml
 
from py_http_api_test.http_session import HttpSession
 
 
class HttpTest(unittest.TestCase):
    """
    http接口测试类
    """
    # case配置信息(执行环境)
    config = []
    # http会话对象
    http_session = HttpSession()
 
    @classmethod
    def setUpClass(cls):
        """
        初始化配置信息和http_session对象
        :return:
        """
        env = None
        nose_cfg = None
        argvs = sys.argv[1:]
        for idx, arg in enumerate(argvs):
            # 直接获取case配置文件路径
            if '-env=' in arg:
                env = arg.split('=')[-1]
                break
            # 获取nose的配置文件
            if '--config=' in arg:
                nose_cfg = arg.split('=')[-1]
            if '-c' == arg:
                nose_cfg = argvs[idx + 1]
        # 未获取到case配置文件路径，尝试从nose配置文件中获取
        nose_config_files = nose.config.all_config_files()
        if env is None and (nose_cfg is not None or len(nose_config_files) > 0):
            if nose_cfg is None:
                # 用户未指定nose配置文件，则从系统全局配置文件中获取
                nose_cfg = nose_config_files[-1]
            if not os.path.isabs(nose_cfg):
                nose_cfg = os.getcwd() + '/' + nose_cfg
            cf = ConfigParser.ConfigParser()
            cf.read(nose_cfg)
            try:
                env = cf.get('others', 'env')
            except ConfigParser.Error:
                env = None
 
        if env is not None:
            # 参数不是绝对路径
            if not os.path.isabs(env):
                # 根据当前工作路径获取到绝对路径
                env = os.getcwd() + '/' + env
            with open(env) as f:
                inp = f.read()
            cls.config = ruamel.yaml.safe_load(inp)
 
    @classmethod
    def tearDownClass(cls):
        cls.http_session.close()

HttpTest基类只做了两个工作：1. 创建http会话对象；2. 读取配置文件到类变量`config`中。配置文件是一个很好的编程实践，这让我们测试程序和数据能够分离，可以通过调用不同的配置文件来测试不同环境的接口，让我们测试程序不光能做线下测试，还能做线上回归和监控，切换成本非常低。

我这里选择 yaml 语法来组织配置信息，yaml 语法风格类似 json，自带基础数据结构，但更加易于书写和阅读，非常适合做配置文件。通过`-env=xxx`指定配置文件路径（或者 nose.cfg 配置文件中指定），使用 ruamel.yaml 来解析 yaml，转换为 Python 中能直接操作的数据结构。

1
2
3
4
5
6
7
%YAML 1.2
---
# http://open-dev.dingtalk.com/#/corpAuthInfo
dingtalk_oapi: 'https://oapi.dingtalk.com'
corpid: 'dingc2ac01025c48fb7635c2f4657eb6378f'
corpsecret: 'RTw5Vbsh6uKSOu2G25wOmQjQK6SA2NOHNyfHtlEgzQ-CWmvjoGH3c4a-MWTzaJ6Q'
department_parentid: 52711158

这一切都放在`setUpClass`方法中，在具体测试 case 运行之前就已经准备好这些工作了。 Continue Reading...

WordPress通用优化策略及常用插件推荐

WordPress 安装很方便，可以说是开箱即用。但是随着文章增多，访问量增大，会发现 WordPress 很“慢”。这是 WordPress 本身的 PHP 运行机制导致的，每篇文章都要去数据库读取，而且 WordPress 为了支持各种功能，现在已经非常臃肿，每次请求都要加载很多东西。但正是 WordPress 的功能强大，让我们也能很方便的做各种优化。

0x1 使用最新版本的 PHP 和 MySQL

毫无疑问升级基础运行环境是提高性能最好的方式之一。特别的 PHP7 和 MySQL 5.7 较之前的版本性能提升很大。还可以根据服务器配置适当调整 PHP-FPM 和 MySQL 参数。

0x2 使用缓存插件

这里的缓存有两层意思，一是 PHP 层面的运行数据缓存，二是文章页面静态化。这里推荐两个插件来解决这个问题：

1. Redis Object Cache 一款持久对象缓存插件。其实 WordPress 本身带有对象缓存功能，但是是把序列化的对象缓存在文件中，效果不是很好。这个插件通过重写 object-cache.php 文件，把对象缓存到 Redis。直观的感受就是不光前台页面加载速度快了，而且后台响应速度提升更大。

2. Cache Enabler keycdn 公司开发的一款页面静态化缓存的插件。相比 wp-supercache 等插件更加简洁和强大。建议按照官方说明进行增强设置。我使用的是 Nginx，除了正常设置 gzip 外还开启了 gzip_static 参数，让 Nginx 在读取文件的时候优先读取带 gz 后缀的静态文件，不用再做 gzip 压缩。

顺带推荐一个 gzip 检查网站：https://www.giftofspeed.com/gzip-test/

不过使用高级设置后需要把缓存有效期设置为 0（永不失效），可能会造成缓存不会被更新（正常情况下更新文章缓存会被更新）。这里我是通过删除缓存文件然后访问自己 sitemap 中的链接来刷新缓存：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# rebuild cache according to sitemap.xml
 
import os
import requests
import xml.etree.ElementTree as ET
import time
import shutil
 
 
CACHE_DIR = "/var/www/wordpress/wp-content/cache/cache-enabler/"
SITEMAP_URL = "https://static.iyaozhen.com/sitemap.xml"
 
if os.path.isdir(CACHE_DIR):
    shutil.rmtree(CACHE_DIR)
    try:
        sitemap = requests.get(SITEMAP_URL)
    except (requests.HTTPError, requests.ConnectionError) as e:
        print("get sitemap.xml error: %s" % e)
    else:
        urlset = ET.fromstring(sitemap.content)
        print("start rebuild cache at %s" % time.asctime())
        for url in urlset:
            loc = url[0].text
            try:
                requests.get(loc)
            except (requests.HTTPError, requests.ConnectionError) as e:
                print("request %s error: %s" % (loc, e))
            else:
                print("hit %s" % loc)
            finally:
                time.sleep(0.1)
else:
    print("no cache dir: %s" % CACHE_DIR)

https://gist.github.com/iyaozhen/53e6a57a2f7e945ba1161953959a7cb2

0x3 使用 CDN 和图片压缩

用户有时候感觉网站慢，更多的是静态资源加载慢。页面上的 JS、CSS、图片等都需要消耗服务器带宽。而且中国地域辽阔，跨地区、跨运营商更是问题。这时就需要 CDN 了。现在国内各个云都在相互竞争，CDN 比较便宜，免费的也有很多。我之前使用的是七牛云，不过自从服务器迁到腾讯云之后， CDN 也换到了腾讯（免费12个月）。这里推荐同为 keycdn 出的 CDN Enabler 插件，能将页面中的链接替换为 CDN 链接。同时推荐使用 WP Smush 压缩图片，还有使用 BJ Lazy Load 实现图片懒加载（显著提高首屏加载速度）。最后不要忘记站点和 CDN 都配置一下防盗链。

0x4 升级到 HTTP2

HTTP2 支持请求复用，能提高50-70%的加载速度。首先要配置 HTTPS，再简单的配置下就能支持 HTTP2 了。当然静态资源使用的 CDN 最好也要支持 HTTP2，目前国内就又拍云和老牌 CDN 厂商支持，不过其它的很快也会支持了。

0x5 配置`dns-prefetch`、`preconnect`和`prerender`等资源加载参数

Continue Reading...

WordPress 国内优化

众说周知 WordPress 是全球使用量第一的开源博客系统，本博客就是基于此搭建的。但是 WordPress 在国内有些水土不服，有些地方没有考虑中国的国情（GFW），需要做一些小优化。以下代码直接添加在主题或者子主题的模板函数 (functions.php)文件中即可，此文件可在后台直接编辑（外观->编辑）。

1. 移除 Google CDN 字体。英文博客使用 web-font 还是很不错，各个平台使用同一种字体，极大地提升了用户体验，但是中文博客基本用不上，而且 Google CDN 被墙，还会极大影响页面加载速度，所以还是直接去掉吧。

1
2
3
4
5
6
7
8
9
10
if (!function_exists('remove_wp_open_sans')) {
    function remove_wp_open_sans() {
        wp_deregister_style('open-sans');
        wp_register_style('open-sans', false);
    }
}
// 前台删除Google字体CSS
add_filter('wp_enqueue_scripts', 'remove_wp_open_sans');
// 后台删除Google字体CSS
add_filter('admin_enqueue_scripts', 'remove_wp_open_sans');

2. Gravatar 地址替换。WordPress 默认使用的几个 Gravatar 头像地址都被墙了，建议替换为 V2ex 提供的 CDN 地址（支持 HTTP2）。注意，官方地址路径为 /avatar，V2ex 的 CDN 为 /gravatar。

1
2
3
4
5
6
if (!function_exists('replace_to_v2ex_avatar')) {
    function replace_to_v2ex_avatar($avatarUrl) {
        return preg_replace(["/[0-9]\.gravatar\.com(\/|%2F)avatar/", "/secure.gravatar\.com\/avatar/"], "cdn.v2ex.com/gravatar", $avatarUrl);
    }
}
add_filter('get_avatar', 'replace_to_v2ex_avatar');

3. 使用最新的 jQuery 以及使用 CDN（BootCDN，支持 HTTP2）。需要注意测试，可能有些插件会有兼容问题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
if (!function_exists('register_my_jquery')) {
    function register_my_jquery() {
        if (!is_admin()) {
            wp_deregister_script('jquery-core');
            wp_register_script('jquery-core', '//cdn.bootcss.com/jquery/3.1.1/jquery.min.js', true, '3.1.1');
            wp_enqueue_script('jquery-core');
            
            wp_deregister_script('jquery-migrate');
            wp_register_script('jquery-migrate', '//cdn.bootcss.com/jquery-migrate/3.0.0/jquery-migrate.min.js', true, '3.0.0');
            wp_enqueue_script('jquery-migrate');
        }
    }
}
add_action('wp_enqueue_scripts', 'register_my_jquery');

4. 移除自动 dns-prefetch。WordPress 4.6 增加了 dns-prefetch 功能，他会分析页面注入的 js 等脚本然后，加入 DNS 预加载列表。wp-includes/general-template.php：

当然这个功能出发点是好的，但是有些域名解析很慢，预加载可能会拖慢速度，而且我也不需要使用 emoji 和 Google 字体（默认预加载了这两项）。

1
remove_action('wp_head', 'wp_resource_hints', 2);

建议使用插件 instant-articles 来手动设置 DNS 预加载。

目前本博客只进行了这几点国内环境的特色优化，若其它小伙伴还有什么黑科技欢迎评论。当然除了中国特色，也有一些很有效的通用优化策略，敬请期待下篇博文。

参考资料：

最近针对 V2EX 的 Gravatar 头像加载做了一个优化，https://www.v2ex.com/t/141485

http://www.wpbeginner.com/wp-themes/replace-default-wordpress-jquery-script-with-google-library/

https://wordpress.org/support/topic/remove-the-new-dns-prefetch-code/