常在互联网混,哪能不身兼一两个翻墙技能。
大学时候一直在用 goAgent,不过当时是不是就会死掉一会儿的 goAgent 还是还是很让人无语的,还好得益于教育网的封锁并不是很严重,翻墙的需求还不是很强烈,用 goAgent 偶尔翻翻就够了。
后来不想折腾 goAgent 了,就在 github 上找了个更新 hosts 的工具,什么时候被墙了就 pull 一下,方便省事儿。
上班之后公司网实在是坑,就花钱买了翻墙服务,同时也抱着能赞助一个程序员活下去就顺手解救一把的态度。坑爹的是买了一年的会员采用了一个月服务就挂了(没错,说的就是你 红杏)。
在后来就用上了时空隧道(基本上用来用去都是 chrome 插件,中毒 chrome 用户),一只用到现在。推荐给大家:时空隧道
最后说一句,推荐没有优惠!没有优惠!

本文链接 http://sfyumi.github.io/2015/10/31/breakthrough-gfw
作者 sfyumi

Introduction

负载均衡一般被用来优化资源利用率、最大化吞吐量、降低延迟和容错配置。

Nginx 可以作为一种十分有效的 HTTP 负载均衡工具来使用,通过 nginx 的负载均衡分发流量到不同的应用服务器,可以提升 web 应用的性能、伸展性和可靠性。

Load balancing methods

Nginx 支持下面几种负载均衡策略:

  • round-robin(轮询) — 根据轮询分发请求到不同的服务器
  • least-connected(最少连接) — 将最新请求分发到活动连接最少的服务器
  • ip-hash(ip 哈希) — 用一个哈希函数来决定最新请求应该被分发到哪一个服务器(基于客户端的 ip).

Default load balancing configuration

举个栗子
最简单的 nginx 负载均衡配置看起来像这样:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
http {
upstream myapp1 {
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}

server {
listen 80;

location / {
proxy_pass http://myapp1;
}
}
}

在上面的例子中,有三个一样的应用跑在 srv1-srv3 服务器上。当我们没有配置任何负载均衡策略的时候,nginx 会采用默认的负载均衡策略——轮询。所有的请求都被代理到 myapp1 服务器群,然后 nginx 根据 HTTP 负载均衡分发请求。

Nginx 反向代理包括对 HTTP, HTTPS, FastCGI, uwsgi, SCGI, and memcached 的负载均衡策略。

如果想要配置 HTTPS 的负载均衡,只需要使用 “https” 协议就可以了。

当设置 FastCGI, uwsgi, SCGI, or memcached 的负载均衡策略时,只需要使用分别使用 fastcgi_pass , uwsgi_pass , scgi_pass , and memcached_pass 指令就可以了。

Least connected load balancing

另一种负载均衡策略是最少连接。当一些连接完成所需时间更长时,使用最少连接策略可以更公平地控制均衡负载。

当使用最少连接负载均衡策略时,nginx 会把新请求分发给不太忙的服务器,从而避免分发过多的请求给忙碌的服务器造成过载。

只要把 least_conn 指令配置成服务器群配置的一部分 nginx 就会采用最少连接负载均衡策略:

1
2
3
4
5
6
upstream myapp1 {
least_conn;
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}

Session persistence

值得注意的是,轮询和最少连接负载均衡可能会把来自同一个客户端的请求分发到不同的服务器。它们不保证同一个客户端的请求会分发到同样的服务器上。

如果需要把同一个客户端请求分发到同样的服务器的,换句话说就是让客户端的会话“持续”而又“有粘性”地选择连接到特定的服务器,那么可以使用 ip 哈希负载均衡策略。

ip 哈希负载均衡策略会使用客户端的 ip 地址作为哈希的 key 来决定选择服务器群中某台服务器来处理客户端的请求。这种方式确保来自同一台客户端的请求会分发到同一台服务器上,除非这台服务器处于不可用状态。

只需要把 ip_hash 指令添加到服务器群(upstream)配置中就可以使用 ip 哈希负载均衡策略了:

1
2
3
4
5
6
upstream myapp1 {
ip_hash;
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}

Weighted load balancing

除了上面三种负载均衡策略,我们还可以通过配置服务器权重来更深入地影响 nginx 负载均衡算法。

在上面几个例子中,并没有配置服务器权重,那么这意味着 nginx 在进行负载均衡计算的时候会同等地看待配置的服务器。

假如有足够的请求,并且请求的处理模式一致而且完成的速度足够快,那么轮询负载均衡策略意味着根据基本上一致的权重来分发请求到服务器上。

当一个服务器被配置了权重的时候,权重值就会被当做负载均衡算法决策因素的一部分。

1
2
3
4
5
upstream myapp1 {
server srv1.example.com weight=3;
server srv2.example.com;
server srv3.example.com;
}

当采用上面的配置的时候,每5个请求将会如下方式分发到应用服务器上:
三个请求会分发到 srv1,一个会分发到 srv2,另一个会分发到 srv3

权重式负载均衡策略可以在最近版本的 nginx 运用到最少连接和 ip hash 负载均衡策略中。

Health checks

nginx 的反向代理实现包括了被动的 health checks 策略。当某个特定的服务器由于错误而响应失败时,nginx 会把这台服务器标记为 failed,并且会在一短时间内不把后续的请求分发到这台服务器上。

max_fails 指令可以设置允许的在 fail_timeout 时间内尝试与服务器交互的最大连续失败次数。max_fails 默认为 1。当 max_fails 设置成 0 的时候,这台服务器的 health checks 功能将会被禁用。fail_timeout 参数同时也定义了服务器被标记为 failed 的时长。服务器出错并且经过 fail_timeout 的时间间隔之后, nginx 会开始优雅地用活跃的客户端请求来探测出错的服务器。如果这些探测成功了,那么这台服务器将会被标记为正常。

强烈建议读完 max_failsfail_timeout 的链接。

Further reading

另外,还有很多的命令以及参数可以控制 nginx 的负载均衡,例如 proxy_next_upstream , backup , down , and keepalive 。同时,可以通过阅读 reference documentation 来获取更多信息。

Reference links

http://nginx.org/en/docs/http/load_balancing.html
http://nginx.org/en/docs/http/ngx_http_upstream_module.html
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#ip_hash
http://blog.csdn.net/xiajun07061225/article/details/9318871
http://blog.csdn.net/xiajun07061225/article/details/9318871

本文链接 http://sfyumi.github.io/2016/03/15/Using-nginx-as-HTTP-load-balancer/
作者 sfyumi
译自 Using nginx as HTTP load balancer

折腾了好久的 Ubuntu 下 HEXO 安装与使用方法

久别的重逢

看了一下在 Github 上的第一篇也是唯一一篇 blog,居然是三个月之前写的。当时刚入职,以为就要开始新的人生,同时也想维护起来自己的技术博客,希望能记录下来成长历程。不过后来操作系统换成 ubuntu 之后 hexo 一直没有安装成功,博客也就一直荒废在那儿,默默记录着我的懒惰。

趁着周末,我实在看不下去博客就这么荒着,再加上工作了三四个月也接触到了很多东西,积累了很多想法,就趁着周末好好折腾了一下 hexo,现在终于能运行良好了(当然不能自动部署到 github 这种小问题是可以忽略的)。

HEXO 概述

HEXO 是基于 nodejs 的快速简单并且强大的静态博客框架。

HEXO 特性

  • 快速生成文章( 从 Markdown 编译成 HTML)
  • 支持 Github 风格的 Markdown 语法和大部分 Octopress 插件
  • 一键部署到 Github Pages,Heroku 等
  • 强大的插件系统

快速入门(是的,快速入门其实是给有经验的人看的)

就我个人经验,快速入门其实并不是太适合纯新手。当然快速入门可以作为接触 hexo 的开始,然后当你踩过很多坑之后你,回过头来看才会真正地喜欢上快速入门。

安装

前提是必须先安装 nodejs

1
npm install hexo -g

开始博客之旅

1
2
3
$ hexo init blog
$ cd blog
$ npm install

启动博客服务器

1
hexo server

新建一篇博客

1
hexo new "Hello Hexo"

生成静态文件

1
hexo generate

然后就可以在localhost:4000访问刚才新生成的 Hello World 文章了。

坑与解决方案

从源码安装 nodejs

  1. 从 github 下载 v4.2.1(LTS)版源码

    1
    wget https://github.com/nodejs/node/releases/tag/v4.2.1
  2. 从源码安装

    1
    2
    3
    4
    5
    tar zxvf node-4.2.1
    cd node-4.2.1/
    ./configure
    make
    sudo make install
  3. 查看 node 版本

    1
    2
    node -v
    # v4.2.1
  4. 一个服务器 demo

    1
    2
    3
    4
    5
    6
    7
    8
    # http.js
    var http = require("http");
    http.createServer(function(request, response) {
    response.writeHead(200, {"Content-Type": "text/html"});
    response.write("Hello Node!");
    response.end();
    }).listen(8000);
    console.log("server start at 8000");
  5. 运行 http 服务器

    1
    2
    3
    node http.js
    # server start at 8000
    # 然后就能从 http://localhost:8000/ 访问了

hexo deploy 无法部署到 github

1
2
3
4
cd sfyumi.github.io
git clone git@github.com:sfyumi/sfyumi.github.io.git public
cd pubic/
git push

通过 git 手动 push 到 github

总结

我遇到的问题当然不止这些,不然也不会拖了三个月才又重新开始 hexo 之旅,但到目前来说它们都被解决了(当你看到这篇博客出现在我的主页上的时候)。

本文链接 http://sfyumi.github.io/2015/10/31/work-on-hexo
作者 sfyumi

我们是新时代的炼金术师

乾坤何处说清浊,意气与谁论短长。

每一次 Hello World 都是一次冒险。

我们与这个世界并不友好地相遇,邂逅一场场探险,可不变地总是当我们说:Hello World,世界都会回应我们:Syntax Error

不过我还是想对这神秘的世界说一句:Hey Siri。技术总在进步,而我们是新时代的炼金术师,把细节隐藏在魔法之后,把黄金从普通的石块中提炼出来。

不要问我为什么眼中常含泪水,因为我被炼金术坑得太深。

本文链接 http://sfyumi.github.io/2015/08/17/hello-world
作者 sfyumi