iframe的src动态修改并刷新_入口网关服务发现-Openresty动态upstream

提示

在本文前，我建议你先了解一下 Nginx 的基础，同时熟悉基础的 Lua 语言语法，另外再回顾一下 HTTP 的请求过程，对于 Nginx 的负载均衡基本原理也要有基础的了解，掌握这些对我们看本文时能起到一定的帮助。

动态 Upstream 场景

首先，我们来看第一部分内容，也就是动态 Upstream 的场景。

我们先来看一下这样一个典型的场景，整体了解动态 Upstream 的作用。

从图中流量的整体入口开始看，流量从左上方按照箭头方向访问站点，最先交给第一级服务 Nginx，Nginx 承担入口网关的作用，通常情况下，通过 Nginx Upstream来作负载均衡，从而实现将入口的流量均匀地分配给后台的 real server处理。

从图中我们可以看到，右上角的方框中有两台 Real server ，分别是 App server 1 和 App server 2。

那我们需要的动态 Upstream 是一个什么场景呢？当往这组集群中再添加一台新的后台服务 real server，也就是 App server 3 ，并且实现将入口的流量动态的(非手动方式)分发给新 App server 3，这个时候我们就需要用到动态配置upstream了。

动态 Upstream 实现意义

结合在上面的场景，要实现动态upsteam，首先后台服务节点App server 1 和 App server 2 ，它们将自己的信息(如：负载情况、服务状态情况、连接信息、服务名称等)实时的上报给管理中心, 使得管理中心会收集 App server 1 和 App server 2 的节点状态，同时管理中心也会根据自身的策略动态地调整 Nginx 的 Upstream 配置。

假如当某一个Real server的负载过高，此时便可以通过管理中心去动态地调整 Nginx 的 Upstream策略，入口网关动态地添加新的节点从而实时性的实现Real server资源水平的扩容，反之实现动态减少后台节点也是同样原理。这样的场景中做到及时调整upstream策略，从而使得入口网关动态分流，实现及时资源缩容和故障感知。

这个场景中，如果upstream配置不是通过动态的方式去实现调整，就需要通过手动的方式(先修改配置，再手工重启服务等)，手动的方式没法做到自动化及实时触发调整。

我们再看一个常见的 K8s 的入口网关架构，这里就使用了动态 Upstream。我们知道 K8s + Docker 的服务部署模式下，ETCD 作为服务注册发现中的 KV存储数据库，存取着后台节点服务的注册信息，包含服务名称、连接方式等。所以，在图中会把所有后台的 服务节点(App1-App4) 的信息注册到ETCD 的数据库中存储。然后 入口网关(如：Nginx) 通过查看etcd中数据并根据变化情况动态地调整Upstream 配置，这个就是在K8S中动态入口网关理论原理。

图中上面的箭头表示一个服务的注册和动态的 Upstream 更新配置文件。下面的箭头表示动态的实现负载均衡策略流量转发，这个就是在 K8s 和 Docker 的部署场景中入口网关的实现原理。

动态 Upsteam 实现方式

我们知道Nginx 本身诞生的比 K8s 和 Docker 更早，Nginx 默认的配置模块是有来实现动态Upstream 是有局限的，所以我们想要实现，通常有这么几种方式：

• 第一种方式是通过 Nginx+Lua，使用 Lua 语言开发接口，做到动态调用，也就是基于 Openresty 动态实现 Upstream，因为我们知道 Openresty 服务本身就是基于 Nginx 和 Lua 的一个结合体。
• 第二种方式是通过已经开源并成熟的组件，如 confd 工具或 国内某大公司开源的 nginx-upsyncmodule 的模块来实现动态 Upstream。
• 第三种方式是通过一个独立的入口网关把 Nginx 完全替换掉，比如我们现在了解的 Kong 网关还有Traefik，都是在 K8s 中支持云原生的非常好的网关服务。

接下来我们来演示 Openresty 动态 Upstream 方案，使用Lua 语言开发一套动态的接口，我们可以动态地调用接口实现一个动态的分流。这个方案中实现了3个接口，让 Openresty 支持添加、删除、监控 Upstream 后台节点的功能(如图接口1-接口3)。

我们看下如图描述的内容：

通过开放接口，管理中心或者配置中心用可以调用这三个接口动态修改入口网关的负载均衡配置。我们接下来重点介绍Openresty Lua 语言如何开发实现这三个接口。

演示

以下演示所用的代码，你回复upstream获取！

• 第一部分是安装流程；

最好按官方文档自行安装。

• 第二部分是配置方式；

以下内容比较繁琐，请参考演示代码，代码太长这里就不贴出来了。

然后配置 Nginx 服务，Nginx这里作用不是作代理入口，而是 在整个演示场景的 real server 节点，我们需要模拟三个端口的后台服务。通过 Openresty 来负责做代理网关并负载均衡，所以我们可以配置一个基于 Nginx 的虚拟端口的虚拟主机。这里我做了三份配置文件 81、82、83，三份配置文件分别占用三个端口，然后我们可以自己参考这三个配置文件来进行配置，然后启用 Nginx。

启用 Nginx 后会占用 81、82、83 三个端口，我们还可以用浏览器来访问这三个端口。访问 83 端口时会显示一个 Server 3 和 url 3 的黄色的页面。然后我们访问 82 端口，显示的是 Server 2 和 url 2的红色背景页面信息 访问 81 端口时显示的是 Server 1 和 url 1 的蓝色文字背景信息。

配置 Openresty 的 Upstream ，cd到 Openresty 的目录下，然后 cd 到 Nginx 目录，Nginx 的 conf 目录下有一个 Nginx.conf 文件，这是一个 Openresty 的主配置文件。同一级的 Nginx 目录下还有一个 ngx_lua 配置目录，这里已经放好了lua开发的代码文件。这个目录是我自定义新建的，里面有三个脚本；upsops.lua 是用来做动态调节 Upstream 节点信息的接口代码；upstream.lua 是用来设置负载均衡策略的代码，另外一个srvcheck.lua是实现节点信息获取的代码。

openresty 服务的配置 nginx.conf 中，分别对这三个代码文件做了引用，配置会对外提供几个访问路径，其中一个是根的访问路径，也就是对外提供服务的访问路径，一个是location=/ups一会我们拿这个重点讲解这个，它是实现动态更新配置 Upstream 主机节点信息的接口。

location 对外提供服务的时候，会引用到 proxy_pass 的本地的一组服务单元。服务单元分别配置了三台主机，也就是我们刚刚配置的三台 Nginx 虚拟主机的连接信息，然后后面的balancer_by_lua_flie 就是修改了默认的配置负载均衡策略。

upsops.lua 脚本的实现逻辑当用户请求这个路径是ups 的时候，它会交给 Lua 解析处理。然后到 ngx_lua 目录下upsops.lua，在最上面定义了一些本地的变量,有获取请求的参数，客户端的请求方法赋值给了 OP。

OP 主要是有哪两个方法呢？这个接口代码支持是增加(add)删除(del)两个，这里会先获取所有主机的 Upstream 的服务节点，客户端通过发送put 请求传递过来的需要添加或者删除的新节点的信息，然后传递给 变量server ，这里会判断一个请求是否有带参数，并进行一个校验，接着还会关联一个独立的函数[function down_server(upstream_name,server)]。这里会用来判断一个逻辑，这个逻辑用来控制在 Upstream 后台 Real server 里最少应该保持一台主机，如果低于一台的话是不允许的，现实中如果upstream的后台服务节点数不可能为零。

代码最后会去判断客户端传递过来的操作方法(OP)，是选择增加 Upstream 节点，还是删除Upstream 节点，如果在删除节点时候会调用 down_server 的方法判断，判断它是不是符合至少保留一个节点的要求。

• 第三部分是测试;

启动nginx和openresty。

通过 800 端口来进行访问测试，首先显示的是一个蓝色的页面，我们再来刷新这个页面，第 2 次的时候会出现 server 2 url 2，再刷就会到 server 3 url 3 了，所以我们会看到它是一个因为配置负载均衡而轮循展示。

接下来我们可以删除一台主机，调用刚刚讲到的 upsops 脚本里面暴露出来的 ups 接口。我们用 curl命令来模拟一个 put 的方法，-v 显示整个的请求过程，后面就是请求的链接，ups 就是我们刚请求的接口路径，然后 op=add 就是选择添加主机操作。这里，我们先删除一台主机，选择删除 83 端口节点，然后回车。

curl -v -X PUT 'http://127.0.0.1:800/ups?op=del&server=127.0.0.1:83'

这个时候会看到返回的是 200 的状态码，并且会有一个提示删除 83 端口的后台服务成功。这个时候再来刷新页面，看看 server 3 还会不会再出现，我们可以多刷新几次。这个时候会发现我的浏览器会停留在 server 1 和 url 2 间进行不断的变更，而不会出现 server 3(对应 83 端口的服务)。

同样我们来演示如何把 server 3 加回来，也就是 端口为 83 节点的信息加回来，这时我们把 op后的操作改成 add。这时同样也会返回正确的提示。同样，再到浏览器端中看一下。这个时候 server 3 就加回来了。

curl -v -X PUT 'http://127.0.0.1:800/ups?op=add&server=127.0.0.1:83'

你有没有发现，整个过程都是通过调用接口来实现的，也就是说我们要模拟动态发现的时候，其实就可以在管理或者注册中心节点，通过调用这种HTTPAPI接口的方式来动态的调用upstream配置。

好了，今天内容就到这里！

未完待续