本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议,欢迎转载、或重新修改使用,但需要注明来源。 [署名 4.0 国际 (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/deed.zh) 本文作者: 苏洋 创建时间: 2021年03月18日 统计字数: 9821字 阅读时间: 20分钟阅读 本文链接: https://soulteary.com/2021/03/18/use-docker-and-nginx-njs-to-implement-api-aggregation-service-part-1.html ----- # 使用 Docker 和 Nginx NJS 实现 API 聚合服务(前篇) 两个月前,我曾写过一篇名为[《从封装 Nginx NJS 工具镜像聊起》](https://soulteary.com/2021/01/10/let-us-start-with-the-mirroring-of-the-nginx-njs-tool-package.html)的文章,简单介绍了 Nginx 官方团队推出的 NJS 以及我为他定制的 Docker 镜像。 这篇文章,我将介绍如何使用 Nginx NJS 用精简的代码行数编写一套 API 聚合工具,并如何使用 Docker 将其封装为可用服务。 ## 写在前面 本篇内容涉及到几块内容,如果你不熟悉,可以翻阅我之前的相关文章加深理解和掌握: - Docker 及容器封装,[以往文章](https://soulteary.com/tags/docker.html) - Nginx 和它的模块,[以往文章](https://soulteary.com/tags/nginx.html) - Nginx NJS,[以往文章](https://soulteary.com/tags/njs.html)、[njs-learning-materials](https://github.com/soulteary/njs-learning-materials) (学习资料开源仓库) 为了能够模拟和演示接近真实的聚合服务功能,我在经常使用的开源软件的官网随便找了两个接口: - MySQL: `https://www.mysql.com/common/chat/chat-translation-data.json` - Redis: `https://redislabs.com/wp-content/themes/wpx/proxy/signup_proxy.php` 好了,万事俱备,我们开始进行实践。 ## 编写 Nginx NJS 脚本 万丈高楼平地起,先从最简单的部分开始。 ### 使用 NJS 编写 Nginx 基础接口 在我们尝试聚合接口前,先试着写一个最基础的版本,让 Nginx 能够模拟输出一个类似 `{ code: 200, desc: "这是描述内容"}` 的接口。 如果你熟悉 Node 或者其他后端语言,下面代码要做的事情,就一目了然了:首先定义了一个名为 `simple` 的函数 ,接着定义了我们要展示的接口数据,然后设置 Nginx 响应内容类型为 UTF8 编码的 JSON,以及接口 HTTP Code 为 200,最后声明模块中的 `simple` 是可被公开调用的。 ```js function simple(req) { var result = { code: 200, desc: "这是描述内容" }; req.headersOut["Content-Type"] = "application/json;charset=UTF-8"; req.return(200, JSON.stringify(result)); } export default { simple }; ``` 将上面的内容保存为 `app.js`,并放置于一个名为 `script` 目录中,我们稍后使用。接着我们声明一份可以让 Nginx 调用 NJS 的配置文件: ```bash load_module modules/ngx_http_js_module.so; user nginx; worker_processes auto; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; js_import app from script/app.js; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; keepalive_timeout 65; server { listen 80; server_name localhost; charset utf-8; gzip on; location / { js_content app.simple; } } } ``` 将上述内容保存为 `nginx.conf`,我们同样稍后使用。 可以看到这份配置文件和以往的配置文件看起来差别不大,但是确实又有一些“不同”,将所有和 NJS 无关的内容去掉,就可以清晰的看到 NJS 是如何和 Nginx 联动的。 ```bash load_module modules/ngx_http_js_module.so; ... http { ... js_import app from script/app.js; server { ... location / { js_content app.simple; } } } ``` 首先是全局显式声明加载 `ngx_http_js_module.so` 模块,然后是将我们编写的脚本引入 Nginx HTTP 块作用域内,最后则是调用脚本具体的方法提供服务。 为了方便的验证服务,我们还需要编写一个简单的 compose 编排文件: ```yaml version: '3' services: nginx-api-demo: image: nginx:1.19.8-alpine restart: always ports: - 8080:80 volumes: - ./nginx.conf:/etc/nginx/nginx.conf - ./script:/etc/nginx/script ``` 上一篇文章提过,目前 NJS 已经是 Nginx 官方模块,并默认附带在官方 Docker 镜像中,所以我们这里直接使用最新的官方镜像 `nginx:1.19.8-alpine` 就可以了。 将上面的文件保存为 `docker-compose.yml` ,适当调整下上面文件的目录结构,并使用 `docker-compose up` 启动服务,访问 `localhost:8080`,可以看到我们得到了我们想要的结果,浏览器中出现了接口内容。 ![浏览器中展示接口结果](https://attachment.soulteary.com/2021/03/18/simple.png) 和我们使用 Nginx 调用 CGI 程序不同,可以看到接口处理时间只花费了 1ms ,虽然这和我们实现的代码复杂度非常低有关系,但是通常网络开销导致我们得到的结果会远大于这个数值。从某个角度说明不需要“外部程序”计算参与时, Nginx 直接参与结果计算在性能方面是有潜力的。 ### 尝试编写获取远端数据的接口 接着我们来编写一个能够获取远端数据的接口,和之前编写的方式类似,只需要将我们定义的接口返回数据替换为使用 `subrequest` 方法请求的数据接口结果即可。 ```js function fetchRemote(req) { req.subrequest("https://www.mysql.com/common/chat/chat-translation-data.json").then((response) => { req.headersOut["Content-Type"] = "application/json;charset=UTF-8"; req.return(200, JSON.stringify(response)); }) } export default { fetchRemote }; ``` 为了便于区分,我们这里将函数名改为更贴切的“fetchRemote”,接着将 `nginx.conf` 文件中的调用方法也进行更新: ```bash ... location / { js_content app.fetchRemote; } ... ``` 随后使用 `docker-compose up` 重新启动服务,再次访问 `localhost:8080` 来验证程序的结果是否符合预期。 然而页面返回了类似下面的结果: ```js {"status":404,"args":{},"httpVersion":"1.1","remoteAddress":"172.21.0.1","headersOut":{"Content-Type":"text/html","Content-Length":"555"},"method":"GET","uri":"https://www.mysql.com/common/chat/chat-translation-data.json","responseText":"\r\n404 Not Found\r\n\r\n

404 Not Found

\r\n
nginx/1.19.8
\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n","headersIn":{"Host":"localhost:8080","Connection":"keep-alive","Cache-Control":"max-age=0","sec-ch-ua":"\"Google Chrome\";v=\"89\", \"Chromium\";v=\"89\", \";Not A Brand\";v=\"99\"","sec-ch-ua-mobile":"?0","DNT":"1","Upgrade-Insecure-Requests":"1","User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36","Accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9","Sec-Fetch-Site":"none","Sec-Fetch-Mode":"navigate","Sec-Fetch-User":"?1","Sec-Fetch-Dest":"document","Accept-Encoding":"gzip, deflate, br","Accept-Language":"zh-CN,zh;q=0.9,en;q=0.8,ja;q=0.7"}} ``` 页面虽然返回了数据,但是显然不是我们想要的结果。 检查 Nginx 日志,可以进一步了解这个错误发生的原因。 ```bash [error] 33#33: *1 open() "/etc/nginx/htmlhttps://www.mysql.com/common/chat/chat-translation-data.json" failed (2: No such file or directory), client: 172.21.0.1, server: localhost, request: "GET / HTTP/1.1", subrequest: "https://www.mysql.com/common/chat/chat-translation-data.json", host: "localhost:8080" ... ``` 不卖关子了,来聊聊“正确答案”。 ### 正确的获取远程数据 这里会发生错误因为 NJS 的 `subrequest` 方法仅支持将请求使用异步方式发送给反向代理。 将要请求地址改为由 Nginx 反向代理,这里因为这个接口我们仅用作 NJS 调用,不需要提供开放访问,所以可以添加 `internal` 指令,来进行外部访问限制处理,避免 NJS 之外调用过程访问我们的远端接口: ```bash location /proxy/api-mysql { internal; proxy_pass https://www.mysql.com/; proxy_set_header Host www.mysql.com; } ``` 接着修改之前代码中的请求地址: ```js function fetchRemote(req) { req.subrequest("/proxy/api-mysql/common/chat/chat-translation-data.json").then((response) => { req.headersOut["Content-Type"] = "application/json;charset=UTF-8"; req.return(200, JSON.stringify(response)); }) } export default { fetchRemote }; ``` 再次启动服务,可以看到我们已经能够获取远端数据,但是结果看起来有一些问题: ```TeXT {"status":200,"args":{},"httpVersion":"1.1","remoteAddress":"172.27.0.1","headersOut":{"Content-Type":"application/json","Content-Length":"1863","X-Frame-Options":"SAMEORIGIN","Strict-Transport-Security":"max-age=15768000","Last-Modified":"Tue, 27 Nov 2018 20:34:52 GMT","Accept-Ranges":"bytes","Vary":"Accept-Encoding","Content-Encoding":"gzip","X-XSS-Protection":"1; mode=block","X-Content-Type-Options":"nosniff"},"method":"GET","uri":"/proxy/api-mysql/common/chat/chat-translation-data.json","responseText":"\u001f�\b\u0000\u0000\u0000\u0000\u0000\u0000\u0003�Z[o\u0013G\u0014~G�?��W(\u0002�J�R�\u0014���Bk�JT}\u0018{��$�]3��4��|!j�i�4��&$��P(��;qA��}�\u001b\u0016\u0007'1�_�\u0019�\u001d��c�(�M\"9^9����sf��\u0006\u0019+!\u0003���p\u0016}�\b����\u0017B\rD���?ᄆ�e�98�B�D�\u0010�o�q\u0003�؂��c[lh@U\u00022�xk��\u0004 ``` 出现这个问题的原因是因为远端服务器给我们返回了 GZip 后的数据,所以这里我们有两个选择,告诉服务器我们不支持 GZip,或者让 Nginx 对取回的数据进行解压缩。 因为存在即是我们告诉远程服务器,我们不支持 GZip,远程服务器还是会发送压缩后的数据(常见于CDN),所以这里建议使用方案二,再次修改 Nginx 配置,让 Nginx 能够自动解压缩远端数据。 ```bash location /proxy/api-mysql { internal; gunzip on; proxy_pass https://www.mysql.com/; proxy_set_header Host www.mysql.com; } ``` 但是当我们重新启动服务进行测试的时候会发生另外一个问题: ![距离成功很近的时的错误](https://attachment.soulteary.com/2021/03/18/empty.png) ```TeXT [error] 33#33: *4 pending events while closing request, client: 172.28.0.1, server: 0.0.0.0:80 [error] 33#33: *8 too big subrequest response while sending to client, client: 172.28.0.1, server: localhost, request: "GET / HTTP/1.1", subrequest: "/proxy/api-mysql/common/chat/chat-translation-data.json", upstream: "https://137.254.60.6:443//common/chat/chat-translation-data.json", host: "localhost:8080" ``` 检查日志可以看到上面的错误提示,这是因为 GZip 解压缩之后,数据量远大于 Nginx 默认处理临时数据的 Buffer 容量,所以我们要进一步对此进行调整: ```TeXT subrequest_output_buffer_size 200k; location /proxy/api-mysql { internal; gunzip on; proxy_pass https://www.mysql.com/; proxy_set_header Host www.mysql.com; } ``` 这里的`subrequest_output_buffer_size` 配置数值根据自己的场景需求进行调整即可。再次重启服务,会看到我们已经能够获取正确的远程接口数据内容了。 ![从远端获取的数据内容](https://attachment.soulteary.com/2021/03/18/unzip.png) ### 编写具备聚合功能的程序 因为我们要聚合多个接口,所以我们将 NJS 代码和 Nginx 配置同时进行一些调整。 我在这里就不演示很挫的顺序执行模式了,因为对于这些无上下文依赖的接口,使用异步并发获取的方式可以消耗尽可能少的时间来提供结果。当然,串行请求也是有场景的,我会在后面的文章中提到如何灵活使用 NJS 控制请求流程。 ```js // https://github.com/nginx/njs/issues/352#issuecomment-721126632 function resolveAll(promises) { return new Promise((resolve, reject) => { var n = promises.length; var rs = Array(n); var done = () => { if (--n === 0) { resolve(rs); } }; promises.forEach((p, i) => { p.then((x) => { rs[i] = x; }, reject).then(done); }); }); } function aggregation(req) { var apis = ["/proxy/api-mysql/common/chat/chat-translation-data.json", "/proxy/api-redis/wp-content/themes/wpx/proxy/signup_proxy.php"]; resolveAll(apis.map((api) => req.subrequest(api))) .then((responses) => { var result = responses.reduce((prev, response) => { var uri = response.uri; var prop = uri.split("/proxy/api-")[1].split("/")[0]; try { var parsed = JSON.parse(response.responseText); if (response.status === 200) { prev[prop] = parsed; } } catch (err) { req.error(`Parse ${uri} failed.`); } return prev; }, {}); req.headersOut["Content-Type"] = "application/json;charset=UTF-8"; req.return(200, JSON.stringify(result)); }) .catch((e) => req.return(501, e.message)); } export default { aggregation }; ``` 接着对 Nginx 配置文件中的部分进行调整: ```bash ... location / { js_content app.aggregation; } subrequest_output_buffer_size 200k; location /proxy/api-mysql { internal; gunzip on; proxy_pass https://www.mysql.com/; proxy_set_header Host www.mysql.com; } location /proxy/api-redis { internal; gunzip on; proxy_pass https://redislabs.com/; proxy_set_header Host redislabs.com; } ... ``` 最后再次启动服务,来验证我们能否拿到正确的远程数据,并将数据们进行聚合。 ![It works](https://attachment.soulteary.com/2021/03/18/aggregation.png) 看样子,我们已经拿到了我们想要的结果,接着来简单聊聊容器封装。 ## 使用容器对 NJS 应用进行封装 前文提到,NJS 模块由 Nginx 官方镜像默认支持,我们可以直接使用 `nginx:1.19.8-alpine` 为基础来进行镜像构建。 镜像文件非常简单,只需要三行: ```bash FROM nginx:1.19.8-alpine COPY nginx.conf /etc/nginx/nginx.conf COPY app.js /etc/nginx/script/app.js ``` 将上面的内容保存为 `Dockerfile`,然后使用 `docker build -t njs-api .` 构建出我们的镜像。 如果你选择使用 `docker images` 查看镜像,你会发现我们构建的镜像非常小巧,几乎能够和 Nginx 官方镜像尺寸保持一致,所以在公网分发的时候,会有非常大的优势,根据 docker 增量分发的特性,我们其实只会分发上面那三行配置中的后两行构建结果(layers),差不多几 KB。 ```bash njs-api latest f4b6de5dacb8 3 minutes ago 22.6MB nginx 1.19.8-alpine 5fd75c905b52 7 days ago 22.6MB ``` 在构建镜像之后,使用 `docker run --rm -it -p 8090:80 njs-api` 可以进一步验证服务是否能够正常运行,不出意外,会得到上一小节图片中的结果。 ## 最后 好了,来总结一下。 本篇文章中,因为我们没有使用任何非 Nginx 镜像外的 Runtime ,所以得到的镜像结果非常小巧,十分利于进行网络分发。 同时因为 NJS 和 Nginx 简单清晰的设计理念,NJS 程序伴随请求生命周期结束而释放,NJS 引擎执行效率比较高,以及NJS 引擎本身只是实现了 ECMA 的一个子集(整体复杂度低),加之子请求的生命周期非常短暂,所以我们的服务可以使用非常低的资源(接近于 Nginx 原生资源占用)提供一个接近 Nginx 原生服务的性能。 如果你经常写业务代码,你会发现本文留下了一些明显可以改进性能的话题没有诉诸笔墨:如何提聚合接口的性能,如何在定制过的 Nginx 镜像、环境中和三方模块一起工作,以及 NJS 到底能够干哪些更复杂的活? 下一篇 NJS 内容,我将展开聊聊这些。 --EOF