nginx - 基于 RESTful API 的系统的架构决策和错误处理(使用 nginx + redis)

Question

我对在 HTTP 之上开发 RESTful API 还很陌生，所以这就是为什么我有一些基本的架构问题。为简单起见，我将身份验证放在等式之外。

RESTful API 应由 nginx(在反向代理配置中)和 Redis 处理。某些 HTTP 请求/响应可能在 HTTP 正文中使用 JSON。

从消息传递的角度来看，我想实现的是:

1. (Client -> nginx) 通过 HTTP 向 nginx 发出 RESTful API 请求。

2. (nginx -> Redis) nginx 会将 API 请求传递给 Redis 并发出“publish newRequest”，之后 nginx 将等待 Redis 的响应(使用 nginx 3rd party Redis 模块)。
2.1 我不太确定上面的“等待Redis的响应”将如何实际执行。然而，我可以考虑订阅一个 Redis 事件，该事件将在请求被处理后立即由我的自定义 Redis“应用程序”(见下文)发布。您是否知道更好的方法？

3. (Redis -> Redis "Application") (上面发布的) "newRequest"将唤醒它的 Redis 订阅者，这是一个 Redis "应用程序"(基于 Redis C++ 客户端的自定义 C++ 代码)。

4.(Redis“应用程序”-> Redis -> nginx -> 客户端)Redis“应用程序”将处理请求，然后发布响应(用于唤醒 Redis 订阅者 - 从 2.1 开始 - 从而传递“response”返回到 nginx，最后返回到原始调用者)
4.1 现在.. 我的 Redis“应用程序”可能会失败，所以我想将此类错误传达回原始调用者(使用 HTTP 响应错误代码 + 附加的一些描述性 JSON)。但是从我的 Redis“应用程序”我无法控制 HTTP 响应错误代码(这是由 nginx 管理的)。所以我有点想知道.. 如何/在哪里可以更干净地实现错误处理，这样我的 Redis“应用程序”将驱动错误处理，而不必为我在 Redis 中添加的每个新错误更新 nginx 配置“申请”？

在此先感谢您的支持!

最好的问候

Answer 1

众所周知(对我而言)nginx 第 3 方 Redis 模块通常使用基本的请求/响应协议(protocol)，而不是长期有效的 Pub/Sub。它们都使用了一个主要的 nginx 特性——对上游服务器的异步子请求。异步意味着工作进程在响应到达之前不会阻塞，而是继续处理来自客户端的其他请求和来自上游服务器的响应。

Here很好地概述了 nginx 的功能。

你对“Redis 应用程序”的想法对我来说有点奇怪和多余。

与 redis2-nginx-module使用 Redis 作为存储的 nginx conf 文件处理 RESTful API 的可能性非常有限。最流行的用法 - 只是页面缓存。

但是您可以在 Redis 端使用 EVAL 命令做一些聪明的事情。不是我喜欢的方式。

我建议使用完美的 OpenResty捆。 在 LuaNginxModule 和 LuaRestyRedis 的帮助下，您可以在 nginx 中实现任何智能逻辑并使用 Redis 作为存储。使用 LuaRestyRedis 模块，您将能够编写非常简单但仍然高效的代码来以异步方式处理对 Redis 的子请求。在处理一个 RESTFul 请求时，您甚至可以并行或顺序地向 Redis 发出多个子请求。

它还有一个支持 JSON 解析和编码的 LuaCjson 模块。

流水线会更简单: 客户端 <-> nginx <-> Redis