好將來吳鈞澤：當 OpenResty 趕上教育行業

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 觀看：

當 OpenResty 趕上教育行業