nginx_lua vs nginx+php 應用場景

在我的印象中很多人還是選擇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也可以單步調試。到時候我們也會分享給大家。