Swiftiply 英文原文：Swiftcore Swiftiply v. 0.6 Documentation

概要

Swiftiply是一个为web应用程序设计的集群代理服务器，与其他集群代理不同的是Swiftiply让后端进程来与之连接（后端进程就是Swiftipy服务器的客户端），正如浏览器是在用户端一样。这样做的优势在于允许后端进程来维护与代理服务器的持久化连接，这样就消除了socket的建立与拆除的消耗。更重要的是在不需要人代理的任何通知或者配置的情况下，允许后端进程被启动或者关闭。因此，在高消耗的情况下所要做的事情就是要启动那些进程，并且立即可以开始使用。

这种架构的并不具用大多数框架有的缺点，即大多数Ruby框架利用Mongrel作为主要的部署工具。Swiftiply提供了一个重写了部分Mongrel(Version 1.0.1)的类，这就可以让任何Mongrel调度程序可以透明的使用Swiftipy.

因为Mongrel是大多数Ruby框架的比较好的部署方式，Swiftipy内置了一个修改过的Mongreld（在swiftcore/swiftiplied_mongrel.rb中），以便能够作为Swiftiply的客户端运作。对于已经存在的Mongrel调度程序这些本来就应该是透明的，与Swiftiply协同工作。

另外，Swiftiply还有另外一个swiftipied_mongrel的分支版本，这个版本可以在swiftcore/evented_mongrel.rb找到。在这个版本的Mongrel中，通过创建一个基于事件模型而不是线程模型的Mongrel，让事件机器（eventMachine）操作网络通讯，对于很多应用程序来说，运行在基于事件的模型比运行在线程模型中，能够提供更好的吞吐量，特别是当用并发请求进来的时候。

基于事件的操作基于按照先来先服务的原则，而且没有令人头疼的线程，因此能更有效率的处理请求。对于典型的Rails应用程序，如果是单一的、非并发的请求，请求处理可能会比基于线程的Mongrel稍微快一点，但是如果当情况是并发的请求时，差距就会明显拉开。

安装

使用如下命令安装 Swiftiply:

ruby setup.rb

Swiftiply 的可执行文件将被安装到 ruby 的 bin 目录，包括相关的一些脚本文件。库文件被安装到 lib 目录，同时生成 rdoc 信息：

ruby setup.rb --help

上述命令可用来查看参数列表。

安装完毕后，可通过下面命令来运行测试套件：

ruby setup.rb test

Swiftiply 依赖于 EventMachine 和 Mongrel 的支持，目前使用的是 Mongrel 1.0.1. Swiftiply (和 EventMachine) 可使用 gem viagem install swiftiply 来安装.

快速开始

要启动一个 Swiftiply 实例，首先需要创建配置文件（使用 YAML 格式）：

cluster_address: swiftcore.org
cluster_port: 80
daemonize: true
epoll: true
epoll_descriptors: 20000
map:
  - incoming:
    - swiftcore.org
    - www.swiftcore.org
    outgoing: 127.0.0.1:30000
    default: true
    docroot: /var/www/swiftcore.org/docs
  - incoming: iowa.swiftcore.org
    outgoing: 127.0.0.1:30010
  - incoming: analogger.swiftcore.org
    outgoing: 127.0.0.1:30020
  - incoming:
    - swiftiply.com
    - www.swiftiply.com
    - swiftiply.swiftcore.org
    outgoing: 127.0.0.1:30030
    redeployable: true
    docroot: /var/www/swiftiply.swiftcore.org/docs
    cache_directory: public
    cache_extensions:
      - htm
      - html
      - txt

然后使用如下命令启动 Swiftiply:

swiftiply -c config_file

这样一个 Swiftiply 实例就运行起来了，开始侦听来自浏览器的连接。

Swiftiply 命令行参数

-c, --config CONFFILE
    使用该参数来指定配置文件
--cluster-address [ADDRESS]
    侦听的主机名、IP地址
--cluster-port [PORT]
    侦听的端口
--backend-address [ADDRESS]
    当配置文件不匹配时默认主机名或IP地址
--backend-port [PORT]
    当配置文件不匹配时默认的端口
-d, --daemonize [YN]
    使用在后台运行 Swiftiply
-t, --timeout [SECONDS]
    服务器失效的超时时间，默认是3秒，这个数值应该小点
-p, --print-config
    打印完整配置

框架支持

Swiftcore IOWA

IOWA 内置支持运行于事件、集群模式。

Rails

Swiftiply 提供给 mongrel_rails 一个 _REPLACEMENT_，通过一个环境变量的使用，可以用来告知其运行于事件模式还是 swiftiplied 模式.

为了在事件模式下运行 Rails app，设置环境变量 EVENT。在类 Unix 系统上：

env EVENT=1 mongrel_rails

为了运行于 swiftiplied 模式:

env SWIFT=1 mongrel_rails

因为 Swiftiply 后台向 Swiftiply 服务器建立连接，他们都会连向同样的端口。这一点很重要。每个后台都运行在同样的端口上。为了更容易的启动多个 Rails 后台，提供了一个辅助脚本，swiftiply_mongrel_rails。它是对 mongrel_rails 的轻量封装，允许一次启动 N 个后台，带有正确的 pid 文件，以及停止功能。

Merb

merb 源代码（当前仅仅是主干），内置有 Swiftiply 的支持，正如对 Rails 的支持一样。

Ramaze

包含了 Ramaze 的几个适配器，允许 Ramaze运行于事件模式或者 swiftiply 模式的 mongrel 中。它们被安装到

ramaze/adapter/evented_mongrel.rb

ramaze/adapter/swiftiplied_mongrel.rb

其它框架

Swiftiply 同样已经与 Camping 及 Nitro 一起测试过。对其直接的支持还没有捆绑，但在下一次发布中可能会。同时，你的应用程序是使用 evented_mongrel 还是 swiftiplied_mongrel，需要做的就是引用正确的库 -- swiftcore/evented_mongrelorswiftcore/swiftiplied_mongrel。

配置

Swiftiply用一个配置文件来定义它该去哪监听到来的连接， 是否需要守护进程，并且提供了一个输入域名与需要代理到流量出口的地址/端口的映射。流出地址/端口是指当前站点后台将要连接到的地方。配置文件使用YAML格式。在Swiftiply配置文件中，配置项以键值对的形式出现，每行一个，在key与value之间用一个英文冒号(:)分隔，列表项的每一项由一个短横线(-)开头，每行一个。

下面是一些可以在Swiftiply配置文件中配置的项目：

cluster_addresscluster_address: 0.0.0.0

这是指定Swiftiply需要从哪个地址/ip监听从浏览器来的流量。

cluster_portcluster_port: 8080

这是指定Swiftiply需要从哪个在cluster_address上的端口号来监听从浏览器来的流量.

daemonizedaemonize: true

如果设置成true, Swiftiply将尝试将自己放入后台中. 当前情况下只在那些支持forks()方法的平台中起作用(例如win win32 平台就不行).

epollepoll: true

就版本 0.8.0 而言，EventMachine 现在对于事件循环，在支持 epoll() 的平台上支持它的使用（Linux 2.6），而非 select()。epoll() 的好处是，文件描述符增加时性能不会下降，并且它可以使用超过 1024 个文件描述符，而 Ruby 下的 select() 则会受其限制。这允许 Swiftiply 扩展到同时可以处理数千个连接。启用 epoll 没有负面影响，因为它会在不支持的平台以静默的方式报错，所以 Swiftiply  现在默认是试图启用 epoll 的支持。如果处于某些原因，你希望确保不使用它，那么你可以使用 epoll: false 来禁用它。

epoll_descriptorsepoll_descriptors: 20000

Swiftiply 默认将描述符表的大小设置为 4096。这意味着它可以处理 4096 个活动连接。如果你想限制它为更大值，可以使用这个设置来改变表大小。

timeouttimeout: 3

timeout 是指 Swiftiply 对浏览器连接、等待后台接管连接、提供服务，并在放弃返回给浏览器 503  Server Unavailable 错误之前所 保持的秒数。默认是 3 秒。如果你的 web 框架响应慢，你可以需要调高这个值，但保持尽可能的低。

map:
  - incoming:
    - swiftcore.org
    - www.swiftcore.org
    outgoing: 127.0.0.1:30000
    default: true
    docroot: /var/www/swiftcore.org/docs
  - incoming: iowa.swiftcore.org
    outgoing: 127.0.0.1:30010
  - incoming: analogger.swiftcore.org
    outgoing: 127.0.0.1:30020
  - incoming:
    - swiftiply.com
    - www.swiftiply.com
    - swiftiply.swiftcore.org
    outgoing: 127.0.0.1:30030
    docroot: /var/www/swiftiply.swiftcore.org/docs
    cache_directory: public
    cache_extensions:
      - htm
      - html
      - txt

map 部分包含了入主机名与站点所监听的出地址/端口间的映射。

incoming  - incoming: foo.bar.com

或者

  - incoming:
    - foobar.com
    - www.foobar.com

这是需要对之匹配的主机名。

outgoingoutgoing: 127.0.0.1:33333

这是站点后台期望连接上的地址/端口号。

defaultdefault: true

如果这个选项设置为 true，那么这组出入集合就是默认的出入集。任何进入到 Swiftiply 的请求，如果没有匹配上任何其它的集合，就会发送到这个默认出入集。

docrootdocroot: /var/www/swiftiply.swiftcore.org/docs

Swiftiply 本身会直接服务于你的静态文件。为了启用它，仅需提供一个 docroot 声明。Swiftiply 在将请求调度给后台之前会在 docroot 中检查与请求 URI 匹配的文件。如果未匹配，则会将请求 传递过去。

cache_directorycache_directory: public

Rails，以及其它框架，有能力在目录中缓存生成的页面，web 服务器之后可以用其完成请求，不再需要请求在框架内走个来回才能完成。如果你的应用使用的是页面缓冲，你可以让 Swiftiply 用这条指令服务其中的文件。如果在 docroot 中未找到请求 URI，那么 Swiftiply 会在 docroot/cache_directory 中查找。如果没有找到能够完成请求 URI 的文件，它会在 URI 后添加 .html，并再次检查。

cache_extensionscache_extensions:
  - htm
  - html
  - txt

如果你想用 Swiftiply 来检查 just.html 之外的更多扩展，在 cache_extensions 指令后，列出每一项。每一项都会被依次检查，直到满足匹配。如果没有找到，那么请求将会被分配给一个后台处理。

redeployableredeployable: true

如果属性 redeployable 被打开（默认是关闭的），那么如果一个后台没了 -- 被杀死、崩溃、挂起、被天上掉下的海象砸到、等等。。。 -- Swiftiply 会检测这些，只要后台没有给出应答，就会重新将请求部署给下个可用的后台。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务