51CTO專訪淘寶清無：漫談Nginx服務器與Lua語言

http://os.51cto.com/art/201112/307610.htm

說到Web服務器，也許你第一時間會想到Apache，也許你會想到Nginx。雖說Apache依然是Web服務器的老大，可是在全球前 1000大Web服務器當中，22.4%使用NGINX。這些服務器包括諸如Facebook、Hulu和WordPress之類的網絡巨頭使用的服務 器。在今年剛剛結束的O'Reilly Velocity China 2011會議上，51CTO編輯有幸採訪到了目前就任淘寶的王曉哲。在《淘寶網Nginx定製開發實戰》的主題演講上，王曉哲與朱照遠爲你們分享淘寶網是 怎麼經過定製開發Nginx服務器內核以及開發有效的模塊達到亞洲最大電子商務網站的經驗。

 

王曉哲：花名清無 一淘-數據平臺與產品部技術專家。任職於數據平臺部-量子恆道組，負責量子統計總體技術架構搭建。對海量數據處理、高性能高可用的Web服務相關技術有濃厚興趣。

51CTO張浩：您從何時開始接觸Nginx的？您是否接觸過其餘的服務器，好比Apache或者IIS？

清無：我是2008年開始接觸Nginx的，當時在雅虎中國作開放平臺的相關開發，很是看中Web服務器的大並 發服務能力，對Apache2Event模型、lighttpd和Nginx進行調研比較後，才選擇了性能更爲優異的Nginx進行開發和使用。除了 IIS之外，Linux平臺上生產級的開源Web服務器我基本上都接觸過，如apache/lighttpd/Nginx/cherokee等。

51CTO張浩：您在最初在Nginx上工做時使用的是什麼語言？在您的分享中很是看好Lua語言，您又是從什麼時候開始接觸Lua語言的？

清無：最初在應用程序側使用的是PHP，但在開放平臺的實際業務中對PHP的併發能力很不滿，就一直在考慮如何提高業務側在這方面的表現。2009年進入淘寶後量子統計也有相似的訴求，通過多方比較選擇了將Lua解釋器嵌入Nginx的方案，也是從那時開始接觸Lua語言。

51CTO張浩：其實不少開發者對Lua語言的瞭解來自《憤怒的小鳥》這款經典遊戲，做爲在服務器端工做的人，您認爲Lua語言做爲Web服務器中的膠水語言與在移動應用開發中有哪些不一樣？既然咱們對Lua語言的瞭解是從《憤怒的小鳥開始》那麼您有沒有進行過相關開發呢？

清無：從基本結構來講，移動應用中以UI事件爲主體的事件循環同Web服務器中以I/O事件爲主體的事件循環有 驚人的類似之處，差異無非是前者所處理的事件大部分由用戶操做所產生，然後者處理的事件則大部分由外設（主要是網卡）產生。移動應用中使用的Lua開發框 架一般仍是標準的「填空」模式，即開發人員要站在系統事件循環的視角上，顯式將業務邏輯切分爲多塊，用Lua腳本去編寫若干回調函數分別實現各塊，再由事 件循環在合適的時機去調用它們完成相關操做。而ngx_lua經過協程封裝I/O操做以後，讓開發人員能夠站在業務邏輯的視角上以天然的線性邏輯書寫代 碼，由底層的ngx_lua將其隱式轉換爲多塊回調的形式運行。

除此以外我以爲兩者差異不大，移動平臺上硬件機能差、Web服務器上併發處理請求多，兩者都須要開發人員對運行性能和資源佔用保持很高的敏感性。

雖然我我的正在使用Lua語言，但說到移動應用的開發我我的只是嘗試過一些iOS上的Lua開發框架，沒有實際發佈過應用。

51CTO張浩：相比PHP，Lua語言在整個架構上的優點在哪裏？換句話說是Lua語言哪些地方吸引了您？

清無：Lua的緊湊、快速和內建協程支持是最吸引個人地方，前2點是實現高併發服務的基礎，後1點則保證了咱們能夠將回調式異步操做轉變爲隱式異步操做，在保證併發服務能力的同時極大地下降了業務邏輯實現成本。

51CTO張浩：如今Nginx的增加很是迅速，有數據表示在世界上1000臺服務器中有22.4%使用 Nginx。這些服務器包括諸如Facebook、Hulu和WordPress之類的網絡巨頭使用的服務器。您以爲Nginx與Apache相比優點在 哪裏？好比在壓力承載與開發維護上？

清無：在Apache漫長的發展過程當中，開發團隊和社區產出了至關豐富的擴展模塊，這些模塊是Apache流行 的重要緣由。遺憾的是它們如今也是阻撓Apache轉型的最大障礙，能夠說是成也模塊、敗也模塊。由於Web服務器的擴展模塊總會深度嵌入請求處理過程的 各個層面，服務模型一旦肯定，爲了保證擴展模塊兼容性，就沒法再作大的修改。Apache從一開始選擇的是多進程服務模型（Prefork），同時得益於 設計明晰的內部處理流程，使得此模型下模塊很是容易開發；隨着互聯網的迅猛發展，Apache開發團隊也意識到了多進程模型的併發服務瓶頸並着手改進，先 後開發出了Worker（thread）服務模型和Event（Leader-Follower）服務模型。但不管哪一個模型，都是爲了最大程度地兼容原有 擴展模塊而設計，保留了阻塞式請求處理流程，這就至關於本身爲併發服務能力設置了一層天花板。

相比Apache，Nginx就沒有這些歷史包袱，有機會從頭作正確的事，它借鑑了Apache中良好的內部流程設計，同時摒棄了阻礙性能進一步提高的阻塞式請求處理方案，加上Igor本人對開發高性能程序方面有豐富經驗，就造就了Nginx這樣一個後起之秀。

在內核上同Apache相比，Nginx更爲精巧，單機併發處理能力要強不少，但缺點是難以開發複雜的擴展模塊和深度定製代碼，這是選擇非阻塞 I/O複用服務模型的缺點。咱們但願後續能經過增強ngx_lua對Nginx核心的控制能力來完全解決Nginx擴展困難的問題。

51CTO張浩：在本期的Velocity上的一個主要基調就是爲用戶最溫馨的體驗，那麼做爲架構師來說在進行架構設計的時候須要注意哪些方面的細節？

清無：做爲技術架構師，快速、穩定是架構設計時追求的2個終極目標，也是爲用戶創造溫馨體驗的基本前提。設計是一個權衡的過程，沒有最好的設計，只有最合適的設計，在設計的過程當中大體上須要注意四個方面：

1. 儘可能減小數據通路上的沒必要要環節，多一個環節就多一分出錯可能
2. 同時關注運行效率和開發效率，視具體場景有所側重
3. 正視而非掩蓋系統異常，要對依賴系統故障時的自動處理機制有較周全的考慮
4. 儘可能將系統組件的內部運行狀態以監控接口形式暴露出來，讓運維工做白盒化

把握好以上要點基本上就能夠設計出符合業務需求的系統架構。

51CTO張浩：您從參加工做到如今最大的感觸是什麼？您對基層的運維開發人員在職業規劃上又有哪些建議呢？

清無：「聚焦」纔是硬道理。人的總精力有限，投入的方向多，攤到各個方向上的精力就少，更難出成績。若是想在技 術領域有所做爲，就要善於從平常工做中發現問題並思考解決方案，及時總結經驗，多花時間學習基礎理論，在熟悉了所在領域的基本情況後，能夠選擇一個方向重 點投入精力進行研究積累，只要時間投入夠多，總能獨樹一幟。