對於Web高效能伺服器上的選擇，這個是很多人頭痛的問題。對於Apache、lighttpd、Nginx都用他們優點，在什麼情況下我們如何去選擇適合自己的Web高效能伺服器，如何去搭建一個適合自己的架構環境，這個是一個很麻煩的事情。接下來，在ADC 2012（Alibaba Developer Conference 2012）大會上，51CTO記者有幸採訪到了一淘資料平臺與產品部技術專家——清無（花名），為我們解讀Nginx_lua的一些優勢及劣勢，以及在高效能伺服器上的選擇。

王曉哲：花名清無，一淘網技術專家。任職於一淘資料部，負責量子恆道整體技術架構搭建。對海量資料處理、高效能高可用的Web服務相關技術有濃厚興趣。

清無你好，lua我們都知道是一種嵌入式的指令碼語言，而它最著名的是應用在暴雪的魔獸世界和網易的大話西遊中。那麼在淘寶上的應用lua主要是應用在那塊？

清無：目前在一淘網這邊Nginx_lua主要應用在兩塊地方，一塊是傳統的一淘資料庫量子統計店鋪經，資料介面部分完全是用Nginx_lua來做。另一塊是一淘的廣告部門有一部分資料介面也使用著Nginx_lua。

具我的瞭解，你開始接觸nginx應該是2008年的。在08年時，很多高效能的WEB伺服器也非常多，比如apache、lighttpd等等。這些都是高效能的開源伺服器，你選擇nginx是因為什麼？它那方面比較吸引你？

清無：08的時候高效能WEB伺服器除了Nginx以外其實只有lighttpd是開源的，lighttpd和Nginx比較的話有一個很明顯的缺點是lighttpd的模組機制設計的很不好，lighttpd的模組機制過多的把模組本身的請求處理邏輯和底層的網路事件的處理組合在一起，所以不像Nginx的模組結構這麼清晰，當然Nginx的模組設計很大程度上也借鑑了Apache的這種模組設計，所以這塊有一個先天的優勢。當時其實我最早接觸lighttpd，然後Nginx出來以後，就對比它們模組結構上的差異後，覺得Nginx似乎更有優勢一些。實測對於我們這種網路I/O密集型的應用來說，只要不是你實現的這個邏輯有多大缺陷，其實在放lighttpd或者Nginx差別不是特別大。

Nginx的優勢你剛剛也講了，你有沒有哪nginx和其他的開源web伺服器做過一些效能比較？可以跟我們網友進行一些分析。

清無：比較的話是這樣，首先架構如果有問題的話無論你實現如何它都是有問題的，所以我的比較首先在架構搭建上，每連線或者每請求單執行緒單程序這種服務模型，直接就被刷掉，肯定不可能做到很高的服務能力。餘下來清一色的都是基於RO多路**的這種結構體系，那麼在這個體系上我們才去檢驗這個*****，實際上拿一個IPP的請求來壓測看它實現的質量如何，通常來說這部分一旦架構體系決定以後，實測這個效能差異不是特別的大，除非說是某個特性一個實現另一個沒實現這種情況，我們測出來的差異通常是在10%-20%上下波動而已。

lua目前最高的版本是5.2，你們現在使用的是哪個版本？

清無：我們現在使用的是5.1.2，後面那個是補丁號。

如果我認為它的版本越高，效能越強你認為對嗎？

清無：呵呵，不太對。對於lua來說每一個版本的變化意味著它將加入新的語法元素或者變更了內部的一些實現的方式。嚴格意義上並不說明它的效能就好，比如對5.2和5.1來說，不管對於環境表或者其他的一些機制的修改上面，嚴格的來說他都是一種新的語言了。所以目前來說遷移到5.2最大的障礙其實還是5.2裡面對於底層介面的這種概念的變化。因為5.1裡面對於//形成隔離//方面下了很多工夫，然後使用它的全域性表加環境表這種機制，但是5.2裡面徹底取消了全域性表的概念，也取消了CU級別上一系列對環境表操作的介面，對我們來說肯定是不能平滑的遷移到5.2，如果有這個需求的話，我們可以做，但目前還沒有看到這個需求。另外一個阻礙我們升級版本號的問題是LuaJIT，luaJIT的效能比標準的lua要高很多，所以//深層//裡面我們通常用JIT，但是luaJIT目前對lua5.2的支援並不是那麼緊，它目前還是以5.1為主，所以這塊我沒可能較長的時間跟著luaJIT的腳步來。

據我瞭解lua的特點是體積小、快速、簡單，作為獨立程式設計並不是它的主要使用方式，因為它不像java那樣有一個完善的庫，必須嵌入到其他的大型語言中才能發揮出它的併發能力和靈活性。你們目前的主語言是什麼？

清無：實際上我們是分場景，根據具體的業務場景來選擇最合適的語言。對一淘資料庫來說像Java，PHP，C++和lua都用。

在我的印象中很多人還是選擇nginx+php這種組合搭配，你的選擇是nginx+lua，那麼nginx+lua比和php的組合優勢在哪裡？

清無：首先，Nginx+php之間是要有程序之間通訊的，這樣以來基礎的效能開銷就很大。lua是嵌在Nginx程序內部的，它不需要有兩套程序在那裡獨立工作。所以這塊從結構上來說就有決定性的優勢在裡面。再加上執行緒之間通訊的時候需要大量的反序列化和序列化的工作，然後兩套程序帶來額外情況是更多的程序更多的切換開銷，所以單機上面Nginx_php要比Nginx_lua要低很多。但是相對來說仍然要回到我們做什麼事情上面，因為Nginx_lua目前最大的劣勢就是周邊的模組相當的不健全，我們需要大量的時間來積累這些模組。php積累了十幾年的時間了，如果說你對效能的要求並不是那麼高，我的併發數就是幾十，那麼你用php就是最合適的。但是如果像一淘資料的資料介面，機器數就那麼一點，因為我的大量成本在MySQL叢集上面，它是這塊的主力，那麼對外的資料介面我希望儘可能降成本，併發數又非常大，php肯定是不行，那麼我們就要選擇Nginx_lua。但這塊的話對模組的劣勢看起來不是那麼大，因為它的邏輯相對來說較為固定，我們可以忍受這樣的成本，我們去為這個邏輯來定製一些模組。

你認為目前nginx+lua能滿足你現在的需求嗎？有沒有嘗試或尋找其他最佳的搭檔？

清無：對於我們資料介面的這部分需求是完全可以滿足的，至於其他的需求我們還要具體發現，尋找最佳決解方案。因為在計算機行業沒有一招吃遍天這種事。

作為一名技術架構師，在效能這塊你認為到何處為止？還是無止境的追求？

清無：這個要看我們是在做生意還是在個人事情，如果是在公司，比如在具體的事情上面，然後是一個團隊協作的情況下，那麼盲目的追求效能的極限是一個不合適的行為，因為你的追求是要付出相應的成本和開銷的，而往往在一個企業的環境裡面這個是不可容忍的。最合適的架構往往是針對你去解決問題的那個架構，而不是去追求效率最高的架構。所以我們具體在企業裡面做專案的時候，顯然適可而止是最好的。蓋過了你這個使用者的最大需求你就沒必要去付出更多的精力來做，因為其他的問題有很多，你沒必要停留在效能這個問題上，效能只是其中的一個問題，在一個問題上沒必要投入太大的精力。但是，從開發人員個人的角度來說，追求效能的極限是一個很好的想法和行為，因為開發者自己對效能極限的追求體現出對完美的追求，對於完美的追求意味著它可以從上層到底層的專研，而專研是提升個人素質最有效的動力。所以是分開來看這個問題。

你剛剛在大會上也講了一些nginx lua的優勢和劣勢，能不能在這裡也給我們網友分享一些？

清無：剛才也說了一個是周邊模組不完善，不健全。如果你用到的這個東西比較複雜的時候可能生產力上不去，目前Nginx_lua最適合的人員是資料介面層，以及所有的網路中間層，你需要最求併發，高效能的網路中間層。因為它本身的邏輯相對來說比較簡單，或者完全用lua本身就可以變現出來，這個用起來收效比例是最大的。那麼如果你目前要做一個複雜的WEB訪問站，有大量模板要套，有大量的複雜邏輯嵌在裡面，然後要訪問mail要訪問其他服務的話，目前來說我覺得還是php或者其他比較成熟的語言。就我們目前應用來說也是這樣，中間層會大量的使用lua，但是前端展現層的話要麼全部移到瀏覽器上面用JS+模板的形式來實現，要麼就是用PHP這樣來做。另外的劣勢就是除錯的輔助工具不太多，因為高階點的php程式設計師會往往會使用XDebug或者其它的除錯工具，可以單步除錯，線上除錯。跟php相比目前還欠缺這樣的一個機制。到時候我們會仿照XDebug 去實現DPT V2協議，我們實現相容DPT V2這樣的一種機制內連到Nginx_lua裡面，那樣Nginx_lua也可以單步除錯。到時候我們也會分享給大家。

來源:http://developer.51cto.com/art/201207/347738.htm