2019 年 3 月 23 日，OpenResty 社群聯合又拍雲，舉辦 OpenResty × Open Talk 全國巡迴沙龍·北京站，好未來高階工程師吳鈞澤在活動上做了《 當 OpenResty 遇上教育行業 》的分享。
OpenResty x Open Talk 全國巡迴沙龍是由 OpenResty 社群、又拍雲發起，邀請業內資深的 OpenResty 技術專家，分享 OpenResty 實戰經驗，增進 OpenResty 使用者的交流與學習，推動 OpenResty 開源專案的發展。活動將陸續在深圳、北京、上海、杭州、成都、武漢等城市巡迴舉辦。
吳鈞澤：好未來高階工程師。Swoft開源框架開發者，ServiceMesher 社群成員，重度開源愛好者。目前主要負責商城交易系統，對分散式系統架構、高效能應用有著濃厚的興
GithubID：wujunze
個人部落格：www.wujunze.com/
以下是分享全文：
OpenResty 由於它的特性所在，很多情況下大家都用它來做閘道器，好未來現在也大量深度地使用 OpenResty。
我在 2014 年開始接觸 OpenResty，發現一個有意思的事情，金磚國家包括中國、巴西、印度、俄羅斯、南非，而 OpenResty 的所有的技術都源自於金磚國家，Lua 是作者是巴西教授，Nginx 來自俄羅斯，OpenResty 的創始人章亦春來自中國，可以說 OpenResty 這個專案是由金磚國家孵化的。
回到分享主題，我今天為大家分享的主要是四點，背景、選型、架構，以及未來的規劃。
好未來為什麼要用閘道器
好未來有很多事業部，技術棧非常複雜，語言包括 PHP、GO、Java 等，但 PHP 佔主流。我之前曾嘗試用 PHP 解決微服務閘道器，但是效果並不是很理想。後來一直在尋找合適的解決方案，直到遇上 OpenResty。
我們有許多專案要對外提供一些 API 的服務，不同的專案也有不同的許可權：比如 A模組是負責商戶的，要走商戶的許可權；B 模組是負責顧客，要走顧客的許可權，或者是對外部的其他介面。在這種情況下，要是沒有閘道器做統一管理，那就要“架構不規範，搬磚兩行淚”。
此外是 API 的互相呼叫，好未來會經常做線上活動，為了保護後端 API 的健壯，不能讓它承擔業務承載量超過閾值的請求量，那就需要限流、限頻次。我想大家應該需要有一個統一的流量接入層，閘道器服務本身就是一個流量接入層，要求閘道器的高可用、高效能，所以說閘道器本身的高可用也是很重要的。
我對閘道器做了一些技術調研：一類是基 於OpenResty 的 Kong 和 Orange；與 GO 相關的是 Traefik 和 APIGateway；還有基於Java 的 Zuul 和 Spriag Cloud Gateway；還有 PHP 的 Swoole 和 Vrata；最後就是阿里雲和 AWS 等雲服務的閘道器。
我做技術選型時考慮的首先是 Java 生態很好，但是我不熟悉；GO 是一個比較合適的備選方案，GO 是後起之秀，國內的社群生態也越來越好了，但是 GO 我也不是很熟；然後就是 OpenResty，Kong 是一個非常成功的商業化公司，它有開源版和商業版。開源版已經可以滿足我們大部分的需求，它的商業版可以滿足更好的需求，比如 UI 皮膚等高階功能，但我感覺它對中國本地化做得不是太好；最後就是 Orange，它是國內開發者做的開源閘道器平臺。
好未來的自研之路
最開始為了業務，產品部提出需要快速上線，第一個方案就是刀耕火種的時代，為了業務，真的是能用就行。於是，我們做了一個可以跑起來的版本，很簡單：直接用原生的 OpenResty 開發方式，不管是什麼框架，先滿足業務。然後我們所有的 API 都是通過自研的 JWT 元件鑑權。
“吃飽了還要吃好”，於是我們做了進化方案。
好未來接著做了 OpenResty 的自研閘道器，是兄弟部門從 0 到 1 開發的。後來我們組合了閘道器的內部共創，一起交流怎麼來讓閘道器滿足我們的需求。當時我們有兩個方案，稱之為 Plan A 和 Plan B。
閘道器演進之 Plan A
PlanA 是一個基於 OpenReaty 開發的現代化閘道器，它比我們一開始的刀耕火種版本強很多，比如有外掛化開發、內建豐富變數、視覺化後臺，還支援分散式。
首先這是一個老生常談的圖，大家都見過類似的圖，訪問量包括 PC、App 和其他一些終端，中間層就是閘道器層，最後是服務層。有外掛和模組，請求改寫，然後是流量控制、認證、鑑權，還有 API 的版本控制、協議轉換、快取、報警、日誌監控……這些都是常用閘道器都有的功能，然後我們為了內部的其他定製化和自主可控，做了一些開發。日誌監控是通過非同步的訊息佇列，然後做 ES 分析。通過整體的閘道器，做接入流量的管控和鑑權，可以滿足大部分的業務場景。
閘道器演進之 Plan B
當然我們還有 Plan B 的方案，是另外一個兄弟事業部主導開發的，簡約而不簡單。Plan B 是基於 Orange 開發，方案包括了外掛化開發、分散式配置檔案、叢集管理和動態 Upstream 管理。
上圖是閘道器的工作圖：最上面一層是 LVS，四層的負載均衡，LVS 把流量打到最外面，再到第一層的 Gateway，中間再到業務層，此處又做了業務閘道器，最後是 API 層，這就是整體的一個網站的架構。
閘道器的作用是什麼？負責負載均衡，包括內外隔離，讓外層負責一些流量相關，內部負責一些更細的業務相關，這和大家寫程式碼會有一些抽象和分層的套路類似。智慧排程可以把流量切到不同叢集，不同可用區，還有對後端服務的管理。
如果大家對原版 Orange 有了解，可以看出我們這個方案相當於是 Orange Plus。Orange 的開源版本是用 MySQL 儲存配置的，加強的第一個地方是把 Orange 拆成兩塊，一個是 Gateway，一個是 Gwadmin：Gwadmin 做配置管理，Gateway 就是做閘道器，做配置的做配置，做流量的做流量。
它們之間是通過 ECTD 來同步的。Gwadmin 把配置推到 ETCD，然後 confd 再把配置拉下來，拉下來之後，我們會專門有一個 Worker，比如說在 20 個 Worker 中有 1 個 Worker 每隔十秒鐘監聽一下檔案變動，Worker 然後會起一個 timer，如果有配置檔案發生變化，它會通知到另外的 19 個 Worker 來更新這些配置檔案，所以說，ETCD 解決了我們閘道器儲存的問題。
然後介紹一下動態 Upstream 管理，我們發現了有個模組叫 DYUPS，基於 DYUPS 我們就做了一個動態 Upstream 管理。配置檔案如果重啟可能會丟失 Upstream，針對丟失的可能性我們有一個兜底的方案，confd 拉完之後會往本地儲存一份，如果 ETCD 涼了，起碼閘道器有一個老版本的配置檔案，不至於閘道器涼。
總結 Orange 和 OpenResty
Orange 是一個基於 OpenResty 的輕量級閘道器，有豐富的外掛支援。據我瞭解，有一些公司在生產環境上已經使用 Orange。Orange 是可用的，已經經過生產環境驗證。Orange 目前的情況“已經可以吃飽了，但是並不是吃得很好”，我們未來要做的就是“讓大家吃得更好”。
Orange 後續還會支援 k8s 和 gRPC，做一些開發和包裝，包括完善的單元測試，對於一個開源專案來說單元測試是很重要的，像我一般用開源專案，我會先看這個單元測試的專案，出了 BUG 就涼了，或者你不知道改了這個 BUG 會不會出現其他的 BUG；然後我們要讓 Orange 更穩定，更健壯。
OpenResty 有一些非常好玩的東西，我自己常琢磨一些玩法。這是我個人在玩的或者看到的一些好玩東西：
比如把Rust塞進 OpenResty，rlua 相當於是 Rust 和 Lua 的繫結器，Lua 和 Rust 可以互相呼叫，但是建議這個東西不要在生產環境使用。
還有把 GO 塞進 Lua，變成 gopher-lua。
玩法也包括把 Lisp 塞進 Lua。之前有人分享過，他們生產環境用的是 urn，相當於 Lisp 的一個方言，他們用得很舒服。我這裡要吐槽一下 Lua，如果它在大規模業務當中寫的話，Lua 工程化有點麻煩，所以說他們可能就用 Lisp。不得不佩服這個專案，不管東西合不合適，起碼人家可以做出來，思路很清晰，用 Lisp 寫一些 Lua 模組。
此外還有相關的生態擴充，有人把 PHP 塞進 Nginx，這個東西也是一個玩具，但是思路還是挺有意思的。
現在 Orange 這個專案主要是我和社群的開發者在維護，大家對 Orange 有什麼建議、或者想一起來開發、優化、使用它的話，可以一起來交流。
演講視訊及 PPT 觀看：