基于 RESTful API 的系统的架构决策和错误处理(使用 nginx + redis)
Architectural decision and error handling for a RESTful API based system (using nginx + redis)
我在 HTTP 之上开发 RESTful API 方面还很陌生,所以这就是为什么我有一些基本的体系结构问题。为了简单起见,我将身份验证放在等式之外。
RESTful API 应由 nginx(在反向代理配置中)和 Redis 处理。某些 HTTP request/responses 可能会在 HTTP Body 中使用 JSON。
从消息传递的角度来看,我想实现的是:
1. (Client -> nginx) 通过 HTTP 向 nginx 发出 RESTful API 请求。
2. (nginx -> Redis) nginx 将 API 请求传递给 Redis 并发出 "publish newRequest",之后 nginx 将等待 Redis 的响应(使用 nginx 3rd party Redis 模块)。
2.1 我不太确定上述 "wait for the response from Redis" 将如何实际实施。但是,我可以考虑订阅一个 Redis 事件,该事件将在我的自定义 Redis "application"(见下文)处理完请求后立即发布。您是否知道更好的方法?
3. (Redis -> Redis "Application") (上面发布的)"newRequest"会唤醒它的Redis订阅者,这是一个Redis"application"(基于Redis C++客户端的自定义C++代码).
4. (Redis "Application" -> Redis -> nginx -> Client) Redis "application" 将处理请求,然后发布响应(用于唤醒 Redis 订阅者 - 从 2.1 - 和从而将 "response" 传递回 nginx,最后传递给原始调用者)
4.1 现在.. 我的 Redis "application" 可能会失败,所以我想将此类错误传达给原始调用者(使用两个 HTTP 响应错误代码 + 一些描述性 JSON 附加)。但是从我的 Redis "application" 我无法控制 HTTP 响应错误代码(这是由 nginx 管理的)。所以我有点想知道.. how/where 可以更干净地实现错误处理,这样我的 Redis "application" 将驱动错误处理,而不必为每个新错误更新 nginx 配置我添加到我的 Redis "application"?
在此先感谢您的支持!
此致
众所周知(对我而言)nginx 第 3 方 Redis 模块通常使用基本 request/response 协议,而不是长期 Pub/Sub。它们都使用了一个主要的 nginx 特性——对上游服务器的异步子请求。异步意味着工作进程在响应到达之前不会阻塞,而是继续处理来自客户端的其他请求和来自上游服务器的响应。
Here 很好地概括了 nginx 的特性。
你的想法 "Redis Application" 对我来说有点奇怪和多余。
使用 redis2-nginx-module 时,您通过使用 Redis 作为存储的 nginx conf 文件处理 RESTful API 的可能性非常有限。最流行的用法 - 只是页面缓存。
但是你可以在 Redis 端使用 EVAL 命令做一些聪明的事情。不是我喜欢的方式。
我建议使用完美的 OpenResty 捆绑包。
在 LuaNginxModule 和 LuaRestyRedis 的帮助下,您可以在 nginx 中实现任何智能逻辑并使用 Redis 作为存储。使用 LuaRestyRedis 模块,您将能够编写非常简单但仍然高效的代码来以异步方式处理对 Redis 的子请求。在处理一个 RESTFul 请求时,您甚至可以并行或顺序向 Redis 发出多个子请求。
它还有一个 LuaCjson 模块,支持 JSON 解析和编码。
流水线会更简单:
客户端 <-> nginx <-> Redis
我在 HTTP 之上开发 RESTful API 方面还很陌生,所以这就是为什么我有一些基本的体系结构问题。为了简单起见,我将身份验证放在等式之外。
RESTful API 应由 nginx(在反向代理配置中)和 Redis 处理。某些 HTTP request/responses 可能会在 HTTP Body 中使用 JSON。
从消息传递的角度来看,我想实现的是:
1. (Client -> nginx) 通过 HTTP 向 nginx 发出 RESTful API 请求。
2. (nginx -> Redis) nginx 将 API 请求传递给 Redis 并发出 "publish newRequest",之后 nginx 将等待 Redis 的响应(使用 nginx 3rd party Redis 模块)。
2.1 我不太确定上述 "wait for the response from Redis" 将如何实际实施。但是,我可以考虑订阅一个 Redis 事件,该事件将在我的自定义 Redis "application"(见下文)处理完请求后立即发布。您是否知道更好的方法?
3. (Redis -> Redis "Application") (上面发布的)"newRequest"会唤醒它的Redis订阅者,这是一个Redis"application"(基于Redis C++客户端的自定义C++代码).
4. (Redis "Application" -> Redis -> nginx -> Client) Redis "application" 将处理请求,然后发布响应(用于唤醒 Redis 订阅者 - 从 2.1 - 和从而将 "response" 传递回 nginx,最后传递给原始调用者)
4.1 现在.. 我的 Redis "application" 可能会失败,所以我想将此类错误传达给原始调用者(使用两个 HTTP 响应错误代码 + 一些描述性 JSON 附加)。但是从我的 Redis "application" 我无法控制 HTTP 响应错误代码(这是由 nginx 管理的)。所以我有点想知道.. how/where 可以更干净地实现错误处理,这样我的 Redis "application" 将驱动错误处理,而不必为每个新错误更新 nginx 配置我添加到我的 Redis "application"?
在此先感谢您的支持!
此致
众所周知(对我而言)nginx 第 3 方 Redis 模块通常使用基本 request/response 协议,而不是长期 Pub/Sub。它们都使用了一个主要的 nginx 特性——对上游服务器的异步子请求。异步意味着工作进程在响应到达之前不会阻塞,而是继续处理来自客户端的其他请求和来自上游服务器的响应。
Here 很好地概括了 nginx 的特性。
你的想法 "Redis Application" 对我来说有点奇怪和多余。
使用 redis2-nginx-module 时,您通过使用 Redis 作为存储的 nginx conf 文件处理 RESTful API 的可能性非常有限。最流行的用法 - 只是页面缓存。
但是你可以在 Redis 端使用 EVAL 命令做一些聪明的事情。不是我喜欢的方式。
我建议使用完美的 OpenResty 捆绑包。 在 LuaNginxModule 和 LuaRestyRedis 的帮助下,您可以在 nginx 中实现任何智能逻辑并使用 Redis 作为存储。使用 LuaRestyRedis 模块,您将能够编写非常简单但仍然高效的代码来以异步方式处理对 Redis 的子请求。在处理一个 RESTFul 请求时,您甚至可以并行或顺序向 Redis 发出多个子请求。
它还有一个 LuaCjson 模块,支持 JSON 解析和编码。
流水线会更简单: 客户端 <-> nginx <-> Redis