Swiftiply 是一个用于Web应用程序后端未知的集群代理,它专门为支持来自Web框架的HTTP流量而设计。与Pen(http://siag.nu/pen/)不同的是,Swiftiply并不打算作为一个通用的TCP协议负载均衡器。与HAProxy(http://haproxy.1wt.eu/)不同的是,它不是一个高度可配置的通用代理。
那它的优点呢?它是一个快速的有针对性的集群代理。返回来比较Switiply和HAProxy,Switiply的可靠性要优于HAProxy(通过运行于Mongrel服务器的IOWA,Rails,Merb和Ramaze后端进程的测试)。
Swiftiply与传统的代理服务器运作方式不同。在Swiftiply中,后端进程是Swiftiply服务器的客户端,它保证socket连接至Swiftiply。该体系主要的一个的优点是:后端进程可随意进行启动和停止而无需通知代理服务器。明显的缺点是:这并不是后端通常期望的行为。
因为Mongrel是大多数Ruby框架的首选部署方法, 所以Swiftiply包含一个Mongrel已被修改成为swiftiply客户端的版本(在swiftcore/swiftiplied_mongrel.rb中可找到)。它对所有现存的Mongrel处理程序是透明的。
此外,作为swiftiplied_mongrel的旁系分支,还存在另一个版本的swiftiplied_mongrel.rb文件,你可以在swiftcore/evented_mongrel.rb中看到。这是一个用EventMachine处理网络流量的Mongrel,它将会在事件而不是线程模式的基础上建立一个Mongrel。对很多应用程序来说,在事件模式的基础上运行可以比在线程模式下提供更大的吞吐量,尤其当并发请求发生的时候。
这是因为,在先到先服务的基础上,事件模式会在不经过线程的情况下高效地处理请求。相较于线程模式下的单个、无并发模式的Mongrel而言,对于典型的Rails应用,这意味着请求将被更加轻巧、快速地处理。尤其在有冰法请求的情况下,区别将更加明显。
因为Swiftiply在后台与服务器建立连接,因此他们都会在同一个端口发生。这点很重要,因为每个后端进程都会因为同样的端口号而产生冲突。为了解决这个问题,我们提供了一个帮助脚本swiftiply_mongrel_rails。它只是对mongrel_rails进行了一层简单的封装,让一个应用在合适的PID队列中可以开启、关闭N个后端。
Merb例:
cluster_address: swiftcore.org2KB项目(www.2kb.com,源码交易平台),提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务