nginx-upstream-bio/nio/netty-zuul2-apigateway-openresty-orange-lua-docker 用API网关把API管起来

upstream_addr

等到走了一些弯路,才发现nginx的upstream本来就有一个upstream_addr的模块,一下子我觉得找到了方向,不过看这个变量的说明,发现它主要用在记录log上面,而且没说明外界如何获取。查了一些资料之后,发现nginx有一个add_header,该指令干的事情就是在http response header里面加入自己定义的header,于是我在conf里面添加了这条指令,如下:

locaiton /test {
add_header Kss-Upstream $upstream_addr
proxy_pass http://backend2
}

如果直接请求test,会狠好的得到upstream的addr,但是,如果是subrequest请求,就发现得不到了,如下:

location /test1 {
local res = ngx.location.capture("/test")
ngx.say(res.header["Kss-Upstream"])
}

请求test1的时候,发现subrequest的response header里面根本没有Kss-Upstream这个字段。当时狠迷惑,google之后发现这个:Headers not returned from subrequest,原来,subrequest的header是不会返回到parent request这个层面的。至于如何处理,我按照上面的说明采用了两种做法,发现都可行。

more_set_headers

agentzh举了more_set_headers这种做法的一个例子,直接把add_header换成more_set_headers "Kss-Upstream: $upstream_addr"2这条语句搞定。

header_filter_by_lua

另一个做法就是使用header_filter_by_lua这个指令,该指令是处理header response filter的,在里面将upstream_addr的值设置到nginx的一个变量里面。如下:

【nginx】 install

http://www.cnblogs.com/franjia/p/5826602.html

http://www.cnblogs.com/brishenzhou/p/6140458.html

    • https://github.com/Netflix/zuul
    • https://www.jianshu.com/p/b9f3f6a16911
    • BIO,同步阻塞IO,阻塞整个步骤,如果连接少,他的延迟是最低的,因为一个线程只处理一个连接,适用于少连接且延迟低的场景,比如说数据库连接。
    • NIO,同步非阻塞IO,阻塞业务处理但不阻塞数据接收,适用于高并发且处理简单的场景,比如聊天软件。
    • 多路复用IO,他的两个步骤处理是分开的,也就是说,一个连接可能他的数据接收是线程a完成的,数据处理是线程b完成的,他比BIO能处理更多请求,但是比不上NIO,但是他的处理性能又比BIO更差,因为一个连接他需要两次system call,而BIO只需要一次,所以这种IO模型应用的不多。
    • 信号驱动IO,这种IO模型主要用在嵌入式开发,不参与讨论。
    • 异步IO,他的数据请求和数据处理都是异步的,数据请求一次返回一次,适用于长连接的业务场景。

https://hub.docker.com/r/syhily/orange/

http://www.ttlsa.com/orange/orange-nginx-openresty-api-gateway/

http://www.cnblogs.com/cbcye/p/6041170.html[

http://www.cnblogs.com/zdz8207/p/Nginx-Lua-OpenResty.html

[安装Nginx+Lua+OpenResty开发环境配置全过程实例]

https://www.jianshu.com/p/3dc01a283c89

https://hub.docker.com/r/openresty/openresty/