Apache vs Nginx

    他們都是web服務(wù)器，都能伺服靜態(tài)文件。Apache更加流行，擁有更多的功能；Nginx則相對功能少、小巧、快速。Apache 和 Nginx都能在盒子外（out-of-the-box）伺服Ruby服務(wù)器，為此你需要使用另外的插件來組合他們。Apache 和 Nginx都能作為反向代理，就是說他們能夠把進(jìn)來的HTTP請求轉(zhuǎn)發(fā)給其他服務(wù)器，接著把該服務(wù)器的響應(yīng)轉(zhuǎn)給客戶端。

    Mongrel以及其他production模式的服務(wù)器vs WEBrick

    Mongrel是ruby實現(xiàn)的應(yīng)用服務(wù)器，具體來說：

    1，在自己的進(jìn)程空間中加載Ruby app.
    2， 創(chuàng)建一個TCP socket，允許它可以和外部世界(例如Internet)通信。Mongrel在這個socket上監(jiān)聽HTTP請求，并把請求數(shù)據(jù)轉(zhuǎn)發(fā)給Ruby app。
    3，Ruby app返回一個描述HTTP響應(yīng)的對象，Mongrel將其轉(zhuǎn)換為真正的HTTP響應(yīng)字節(jié)，并發(fā)回到socket中。

    然后Mongrel已經(jīng)不再維護(hù)了，其他替代服務(wù)器是：
    Phusion Passenger
    Unicorn
    Thin
    Puma
    Trinidad (JRuby only)
    TorqueBox (JRuby only)

    接下來我會講一講他們和Mongrel的區(qū)別

    WEBrick和Mongrel很像，區(qū)別如下：

    webrick不適合用于production模式。WEBrick完全是用ruby寫的，Mongrel以及其他ruby app 服務(wù)器，部分ruby部分C，主要是ruby，但它的HTTP 解析器為了性能是用C寫的。

    WEBrick比較慢且不夠強(qiáng)壯，有普遍知道的內(nèi)存泄漏問題，以及HTTP解析問題。因為WEBrick是ruby默認(rèn)自帶的，所以WEBrick經(jīng)常用于development模式下作為默認(rèn)服務(wù)器，而其他服務(wù)器則需要另外安裝。不建議在production模式下是用WEBrick服務(wù)器，雖然因為某些原因，Heroku選擇了WEBrick作為默認(rèn)服務(wù)器，他們以前是使用的Thin，但我不知道他們?yōu)槭裁磽Q到了WEBrick

    app服務(wù)器世界

    當(dāng)前所有的Ruby app 服務(wù)器都是http類型的，一些服務(wù)器直接將80端口暴露到internet中，另一些則沒有。

    暴露80端口的：Phusion Passenger, Rainbows。

    沒有直接暴露的：Mongrel, Unicorn, Thin, Puma. 這些服務(wù)器必須必須置于反向代理服務(wù)器之后，比如Apache and Nginx。

    我不了解Trinidad and TorqueBox,，所以就忽略了。為什么有些服務(wù)器必須置于反向代理之后呢？

    一些服務(wù)器的一個進(jìn)程在同一時間只能處理一個請求，如果你想同時處理兩個請求，你就需要啟動多個服務(wù)器實例，都伺服同一個Ruby app。這種多進(jìn)程app 服務(wù)器稱為app服務(wù)器集群（比如Mongrel Cluster, Thin Cluster）。你必須啟動Apache 或者 Nginx，給集群做反向代理，Apache/Nginx會處理好集群中不同應(yīng)用實例間的分發(fā)工作。(更多內(nèi)容參見章節(jié) "I/O并發(fā)模型").

    web 服務(wù)器可以緩存請求和響應(yīng)。有些客戶端的發(fā)送數(shù)據(jù)、接收數(shù)據(jù)的速度緩慢，web服務(wù)器可以隔離app server和慢客戶端。你當(dāng)然不希望app server 在等待客戶端收發(fā)數(shù)據(jù)時什么也不干。Apache 和 Nginx 擅長同時很多事情，因為他們是多線程或者基于事件的。

    大多數(shù)的app server可以伺服靜態(tài)文件，但不是很擅長。Apache 和 Nginx的速度更快。人們經(jīng)常直接使用 Apache 或者 Nginx伺服靜態(tài)文件，而不會處理前向請求（ forward requests ），這是比較安全的策略。 Apache 和Nginx足夠聰明，可以保護(hù)app server遠(yuǎn)離惡意請求。

    為什么有些服務(wù)器可以直接暴露在Internet中？

    Phusion Passenger和其他app server不一樣，其中一個比較特點是可以融入其他服務(wù)器。

    Rainbows的作者公開指出，Rainbows可以直接暴露在internet中。他十分不會在解析HTTP過程中遭受攻擊。still, the author provides no warranty and says that usage is at own risk.

    Application 服務(wù)器對比

    在這一章中，我會比較我提到的大多數(shù)服務(wù)器，但不包括Phusion Passenger。Phusion Passenger和其他的不一樣，我會單獨開出一章。我還會忽略Trinidad 和 TorqueBox，因為我對他們不是很了解。只有你用到JRuby的時候才會涉及到他們。Mongrel 是塊暴露的石頭。像之前提到的，Mongrel僅僅是單線程、多進(jìn)程，所以它只用于集群（cluster）中。沒有進(jìn)程監(jiān)控，意味著如果集群中一個進(jìn)程崩潰了，則需要手動重啟。人們需要使用額外的進(jìn)程來照看Mongrel，比如Monit 和 God。

    Unicorn 是從Mongrel中fork出來的。支持監(jiān)控一定數(shù)量的的進(jìn)程：如果一個進(jìn)程崩潰了，則會被主進(jìn)程自動重啟。它能讓所有進(jìn)程都監(jiān)聽同一個共享的socket，而不是每個進(jìn)程獨自使用單獨的socket。這會簡化反向代理的配置。像Mongrel一樣，也是單線程、多進(jìn)程。Thin 利用EventMachine庫，實現(xiàn)基于事件的 I/O model。它并不是使用Mongrel的HTTP解析器，沒有基于Mongrel。它的集群節(jié)點沒有進(jìn)程監(jiān)控，所以你需要去監(jiān)控進(jìn)程是否崩潰。每個進(jìn)程監(jiān)聽獨自的socket，不像Unicorn一樣共享socket。理論上來說，Thin的I/O模式允許高并發(fā)，這也是Thin被應(yīng)用的大部分場合。一個Thin的進(jìn)程只能處理一個并發(fā)請求，所以你還需要集群。關(guān)于這個古怪的性質(zhì)，更多內(nèi)容參見“I/O并發(fā)模型”。

    Puma 也是從Mongrel中fork出來的，但和Unicorn不一樣的是，Puma被設(shè)計成多進(jìn)程的。目前不支持集群。你需要特別確認(rèn)的是你能實現(xiàn)多核（ You need to take special care to ensure that you can utilize multiple cores ）。 更多內(nèi)容參見“I/O并發(fā)模型”。

    Rainbows 通過給不同的庫實現(xiàn)多種并發(fā)模型 。

    I/O并發(fā)模型

    單線程，多進(jìn)程。 Ruby app Server中比較常見、流行的I/O模型，主要是因為Ruby生態(tài)系統(tǒng)多線程支持比較差。一個進(jìn)程同時僅且只能同時處理一個請求，web 服務(wù)器通過多進(jìn)程來進(jìn)行均衡負(fù)載。這種模型比較穩(wěn)定，開發(fā)者不會輕易造成并發(fā)bug。這種模型適合執(zhí)行快速的短請求，不適合速度慢、長請求阻塞I/O的運算，例如 調(diào)用HTTP API。

    純多線程 ?，F(xiàn)在Ruby生態(tài)系統(tǒng)已經(jīng)很支持多線程了，所以這種I/O模型變得切實可行。多線程支持高I/O并發(fā)，既適合短請求也適合長請求。開發(fā)者也很容易造成并發(fā)bug，幸運的是大多數(shù)框架按照這種方式設(shè)計，所以也不太可能發(fā)生。有一個需要注意的事情是，因為使用了全局解釋器鎖（GIL），MRI Ruby 解釋器不能均衡使用多個CPU內(nèi)核，即使有多個線程。為此，你可以使用多個進(jìn)程，每個進(jìn)程使用一個CPU內(nèi)核。JRuby 和 Rubinius沒有GIL，所以他們的一個進(jìn)程可以均衡負(fù)載多個CPU內(nèi)核 。

    結(jié)合多線程、多進(jìn)程 。Phusion Passenger Enterprise 4以后版本實現(xiàn)了。你可以輕易在以下模式切換：單進(jìn)程多線程，純多線程，多進(jìn)程多線程。這種模式給出了最好的選擇方式。

    事件。這種模式和之前提到的模式不一樣。它允許極高的I/O并發(fā)，以及非常適合長請求。為實現(xiàn)此功能，需要從應(yīng)用到框架詳?shù)脑敿?xì)支持。然而主要的框架（Rails和 Sinatra ）并不支持事件模型。這也是實際上一個Thin進(jìn)程同時不能處理多個請求的原因，就像單線程多進(jìn)程模型一樣。只有專門的框架才充分利用事件I/O模式，例如Cramp。

海外服務(wù)器免費測試：http://hbjsdrq.com/