好将来吴钧泽：当 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 赶上教育行业