SegmentFault 專訪丨OpenResty 國內社區推動者：艾菲

導讀

OpenResty Con 2015 即將在北京舉辦，這是全球第一屆 OpenResty 技術大會。而本次大會的發起者之一艾菲本人，也正是 OpenResty 國內推動者，因而藉此機會，SegmentFault 獨家專訪艾菲，瞭解他與 OpenResty，與開源的共同經歷。

艾菲（@河馬大俠AF），企業安全架構師，iresty 組織成員。嵌入式工程師出身，實現過一套完整的工業機器人主控系統，自動壁障，路徑規劃，精確識別，任務控制，但願用代碼賦予機器生命。2013 年加入奇虎，被 OpenResty 的魅力吸引，感覺到另一種充滿生命力的軟件設計思想，並着手根據自身業務特性在 OpenResty 中添加更多 API。

關於 OpenResty：

OpenResty（也稱爲 ngx_openresty）是一個全功能的 Web 應用服務器，它打包了標準的 Nginx 核心，不少的經常使用的第三方模塊，以及它們的大多數依賴項。

OpenResty 經過匯聚各類設計精良的 Nginx 模塊，將 Nginx 有效的變成一個強大的 Web 應用服務器，從而讓 Web 開發人員可使用 Lua 腳本語言調動 Nginx 支持的各類 C 以及Lua 模塊，快速構造出足以勝任 10K+ 併發鏈接響應的超高性能 Web 應用系統。

OpenResty 國內社區推動者：艾菲

初識 OpenResty

你是從何時開始接觸 OpenResty 的？

在加入奇虎以前，我在一家創業公司作嵌入式開發，負責一款工控機器人的主程序設計開發，業餘時間研究反彙編，作外掛，自娛自樂。

2013 年 7 月正式加入奇虎企業安全事業部，負責服務端日誌數據處理和升級程序，由於業務上的交集接觸到 OpenResty（簡稱OR），剛開始是徹底將 Nginx 當作 Lua 的網絡庫，經過腳本的方式來操做各類請求，生成消息體。後來，隨着使用的深刻才愈加以爲將腳本語言的 VM 嵌入 Nginx 的開發模型兼具優秀的執行效率和開發效率都是其它任何語言或者框架不可比擬的。

今年 9 月，Nginx 官方宣佈支持 JavaScript，其設計思想和 OR 一模一樣，只是主角換成了用戶羣體更爲普遍的 JS，這充分說明將腳本解釋器嵌入一個 Nginx，並提供利用腳本語言訪問 Nginx 的思路是正確的。

奇虎是國內爲數很少的選擇 OpenResty 作服務端的公司，公司的產品線選擇這門技術是有必定風險的，能不能談談最終選擇這門技術的思路？

其實這裏邊想談的不少，產品線上新技術的引入一般狀況下都會遭到質疑甚至否認，最好的方式是給產品一個過渡期，將新技術慢慢引入到業務中。

在最開始的產品線上有兩套服務端程序，一套是用 CPP 搭建的 HTTP 服務器 + 日誌分析主程 + 策略任務分發主程，另一套則是用 OR 搭建的 HTTP 服務器，Web 層面是基於 Yii 框架寫的，而存儲則是共用 Postgres。這樣一來，兩套框架上的業務就有一個橫向的比較，一段時間後，不管從業務穩定性、開發效率、QPS 等方面 OR 都以壓倒性優點勝出，能夠說 OR 在這個時候就已經表現出其強悍的生產力。

再後來，以前的混合式的服務端框架已經達到性能瓶頸，加上部門產品線的戰略調整，咱們有機會設計一套具有更高性能的服務端架構，這讓咱們很是興奮。新架構方案選型很是 OPEN，幾乎全部的重要組件都是來自開源社區，這是由於以前開源軟件的使用經驗讓咱們意識到開源的代碼纔是安全、穩定的，更值得信任的。

在選型過程當中還有一些小故事，架構選型的時候正值 Golang 如日中天，NodeJS 也是風聲水起，在 Golang、NodeJS 仍是 OR 之間存在一些分歧，後來咱們團隊的大拿認爲，咱們指望的是一套能用同步的思惟編碼，但背後的實現是異步的，這樣既不會陷入 callback hell，也不會在代碼裏作大量的併發控制，在這樣的思想指導下，OR 就成爲服務端架構核心的惟一選擇。

固然在項目的實施過程當中也遇到了不少挑戰，所幸 OR 的開源生態並不是咱們預料的那樣糟糕，咱們都能找到類似的場景解決方案，稍加調整也能應用到本身的產品線。

能方便談談大家的產品線在發展過程當中都遇到過哪些問題嗎？

任何產品在實現的過程當中，細枝末節的問題都會遇到很多，這裏就不一一提了，我將咱們遇到的問題歸爲兩大類：平臺兼容性和實施部署。

平臺兼容性問題是產品性質決定的，咱們的產品面向的是企業級用戶，而一些小的企業或者單位不肯意也沒有能力去部署維護一套基於 Linux 系統的服務端系統，而 Windows 系統上的架構又很難知足大型企業的需求，咱們也曾用過將大企業的終端切分紅小節點，分開部署，級聯管理的方式，可是帶來了巨大的部署成本，因此咱們被迫設計一套能將相同業務代碼跑在不一樣系統環境下的架構，這一點其實仍是蠻厲害的，固然也要贊一下咱們組的大神們作出的架構選型，他們真的是很是給力。

實施部署問題我相信是大多數互聯網公司發展到必定規模都會遇到的問題，但咱們實施層面並非成百上千臺服務器的功能灰度發佈，或是服務發現、容災等偏向於運維的問題，這一點差異仍是蠻大的。首先，咱們的服務器是基於私有云架構的，咱們須要將產品服務端部署在用戶現場，而現場物理機的系統多是 CentOS、Ubuntu、RedHat 等等，衆所周知，軟件在各類 Linux 發行版本的依賴是有差別的，而實施人員又沒法去 yum，apt-get（大多企業用戶是隔離網環境），這幾乎使得產品的批量化部署成爲了避免可能，或者門檻很高，因而在產品開發的初期咱們就比較「激進」地選擇了 Docker，在 Docker 裏構建一套完整的天擎服務端，而後將鏡像打包到用戶現場，跑起來，這樣一來真正的部署過程就簡化爲兩個步驟：1. 裝 Docker； 2. 導入鏡像。

OpenResty 的優點

OpenResty 有哪些典型的應用場景以及技術優點，你能簡單介紹下嗎？

項目的官方文檔上提到 OR 的主要技術應用點有如下方面：

• 在 Lua 中揉和和處理各類不一樣的 NGINX 上游輸出（proxy，drizzle，postgres，redis，memcached 等）

• 在請求真正到達上游服務器以前，Lua 能夠爲所欲爲的作複雜的訪問控制和安全檢查

• 經過 Lua 爲所欲爲的控制操做響應頭裏的信息

• 在內容 handler 中隨意編寫複雜的 web 應用，使用同步的編程方式可是內置的異步非阻塞，訪問後端數據庫和其餘存儲

• 在 rewrite 階段，經過Lua完成很是複雜的 URL Dispatch

• 經過 Lua 爲子請求或者任意 location 實現快速高效的緩存機制

上述的技術特色決定了 OR 的應用場景能夠是普遍的，能夠用於實現 api server、路由控制、高併發入口、動態服務降級、動態負載均衡，因爲腳本語言的易用性，這些控制的實現複雜度不會很高。值得一提的是如今的網絡環境愈來愈複雜，網絡攻擊手段也愈來愈高明，這就要求WAF（網站應用級入侵防護系統）也應該是一個高效的響應系統。

這裏的高效不只包括過濾、攔截過程，並且還要具有防添加御規則的高效。這些應用場景都是咱們在項目的開發中遇到並總結出來的，並由發起了一個開源項目《OpenResty 最佳實踐》，本意是將這些應用實踐記錄下來，沒想到卻引發了衆多開發者的共鳴，你們都積極響應，參與貢獻，並與咱們分享 OR 在各自技術場景中的應用。讓咱們驚訝的是，OR 不光是在 api server 場景下，並且在前端渲染，一些知名遊戲的服務端還有云服務等領域都有應用，一些技術愛好者爲了在公司內部推廣這門技術，甚至爲其編寫框架，想在 PHP 開發者中推廣。咱們很是高興看到這樣的結果，同時也會盡力去辦好此次大會，組織更多技術交流，也算是對開源項目的支持和對開源文化的回饋。

關於社區與開源

談到回饋開源社區，據我所知在國內除了一些知名的做品，其它的開源項目參與者少，你怎麼看這種現象呢？

這種現象很正常，普通的開源項目通常能有必定量的用戶加上幾個貢獻者就已經很不錯了。

在我看來，目前存在兩種形式的開源，第一種充分利用像 GitHub 這樣的代碼託管平臺提供的服務，將源碼貢獻出來供交流或自娛自樂，一些優秀做品的做者甚至會提交詳細項目文檔和創辦討論組，在論壇作 Q&A。這類開源項目在開源的初期每每完成度就已經很高，可是後期的發展思路和方向都會收到做者自身精力的限制到達一個瓶頸。

第二種開源是爲某種領域的應用構建生態核心區域，而後創辦技術社區來討論項目將來的發展，以後能夠造成某種形式的商業支持，幫助和推進項目的發展。OR 這個項目在很長一段時間內都屬於第一種形式的開源，因此咱們但願在 11 月 14 日舉辦一場 OpenResty 技術大會，同時這也是這門技術的首次技術型會議，咱們但願經過這樣一種形式讓這門技術吸引到更多人的注意力，持續推進這門技術的發展，固然咱們也請到做者章亦春老師本人來到大會現場，談談他對這個項目的將來發展的想法，但願能促成一些商業化的支持，讓社區走的更遠。

目前社區商業化是個難題，垂直類社區廣泛會作一些人才輸送和項目外包，你怎麼看？

整個團隊都清楚地認識到社區商業化的必要性，要讓參與的人有回報才能促進良性循環，問題在於商業化的形式，咱們請教過一些作過社區商業化的前輩，也假設過一些可能性，但都差強人意。

最開始咱們想是否能對社區的成員設立收費環節，又或者在在線平臺作收費視頻教程，但這些都有可能會影響到社區成員的感覺而致使成員的流失。也有人提議，可否經過舉辦技術大會來實現盈利，但就目前此次大會來看，依靠會議的盈利來支持社區的開銷是不可能的，咱們收取的贊助費和門票只夠支付場地費和活動的集體開銷，而活動自己是爲了面向技術愛好者，打造良好的技術氛圍，吸引更多人蔘與，並在其中獲得成長。所以活動要接地氣，不能走高大上的路線，在這裏作商業化的切入不太合適。還有朋友建議是否能經過對外提供解決方案並收取諮詢費來實現商業化，可是我的以爲成不了規模，同時可能還會收到社區成員自身所在公司的限制，天然就更談不上盈利咯。

咱們心中都存在一種理想主義的商業模型，但願促進 OR 的發展，讓其在各個領域都能獲得應用，而後經過基金會的形式創建基金池，企業經過贊助基金會的來影響社區的發展，社區的貢獻者也能經過貢獻獲取收益，在這樣的良性模式下催生出更多具備創造力的組件，讓 OR 的生態更加豐富。

OpenResty Con 2015

OpenResty 最開始的討論僅限於 Google Group，這讓國內的開發者訪問門檻變高，很可貴到該技術最新的發展趨勢和應用場景。因此咱們但願經過對外演講、在線視頻、開源項目、論壇建設的方式推進 OpenResty 在國內的發展，聚攏現有的使用者，活躍技術交流從而促進這門技術的發展。

2015 年中，咱們正式以 iresty 組織的名義發起對外宣傳，並在一羣技術愛好者的幫助下促成了 11 月 14 日首屆 OpenResty 技術大會，指望經過此次大會促進 OpenResty 技術交流，讓更多的人加入到 OpenResty 陣營，來推進 OpenResty 社區的發展。此次聯合了來自奇虎360、京東、阿里雲、又拍雲、酷狗、Adobe 等公司的一線工程師來作分享，OpenResty 主要做者章亦春老師也會參加本次大會，一同探討 OpenResty 將來的發展。

大會詳情你們能夠訪問 http://www.iresty.com 瞭解。最後，再次宣傳下 OpenResty 社區 http://openresty.org ，期待看到愈來愈多的開發者加入！