2019 年 3 月 23 日，OpenResty 社区联合又拍云，举办 OpenResty × Open Talk 全国巡回沙龙·北京站，好未来高级工程师吴钧泽在活动上做了《 当 OpenResty 遇上教育行业 》的分享。
OpenResty x Open Talk 全国巡回沙龙是由 OpenResty 社区、又拍云发起，邀请业内资深的 OpenResty 技术专家，分享 OpenResty 实战经验，增进 OpenResty 使用者的交流与学习，推动 OpenResty 开源项目的发展。活动将陆续在深圳、北京、上海、杭州、成都、武汉等城市巡回举办。
吴钧泽：好未来高级工程师。Swoft开源框架开发者，ServiceMesher 社区成员，重度开源爱好者。目前主要负责商城交易系统，对分布式系统架构、高性能应用有着浓厚的兴
GithubID：wujunze
以下是分享全文：
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 和其他一些终端，中间层就是网关层，j而后是服务层。有插件和模块，请求改写，然后是流量控制、认证、鉴权，还有 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 有什么建议、或者想一起来开发、优化、使用它的话，可以一起来交流。
