WebSocket的API网关 [英] API gateway for WebSocket

问题描述

我需要一个用于websocket应用程序的API网关.

I need a API gateway for my websocket application.

1. 分析并确定来自某些IP的异常请求
2. 配额和速率限制
3. 统计
4. 免费或商业
5. 表现出色

我的WebSocket的子协议是WAMP，所以恐怕没有现成的产品可以完成这项工作.

The sub-protocol of my WebSocket is WAMP, so I am afraid there is no existing product to do the job.

我打算开发一个，并假设它会以这种方式工作:

I intend to develop one and suppose it will work in this way:

• 我的客户端应用程序和websocket服务器之间安装了一个代理(NGINX或HAProxy)
• 代理将请求/响应复制到另一个应用程序，我称之为monitor
• monitor应用程序分析流并控制代理以限制/阻止某些ip.
• monitor应用程序与之同时运行，如果它关闭了，则不会影响我的应用程序和代理.

• There is a proxy (NGINX or HAProxy) installed between my client application and my websocket server
• The proxy duplicates the request/response to another app, which I call monitor
• The monitor app analyses the flow and control the proxy to limit/block certain ip.
• The monitor app run alongside and if it is down, it does not affect my application and the proxy.

这种方法听起来可行.但是代理似乎不支持重新使用与monitor的上游连接.

This approach sounds feasible. But the proxy seems not support reusing upstream connection to the monitor.

假设从代理服务器到客户端建立了1万个连接，那么代理服务器还在monitor应用的上游建立了1万个连接?那是不可接受的.

Suppose there are 10K connections established from proxy to clients, then proxy also establishes 10K connections as upstream to monitor app? that is unacceptable.

我希望在代理和monitor之间仅建立一个或几个连接以发送重复的请求/响应.当然，代理会为每个请求/响应通知monitor真实的源/目标.

I expect only one or several connections are established between proxy and monitor to send the duplicate requests/responses. Certainly the proxy informs monitor the real source/target for each request / response.

是否有任何满足此要求的代理或产品，所以我只需要减少开发工作?

Is there any proxy or product satisfying this requirement so that I only need develop less?

推荐答案

(TL; DR ...对不起！)
我正在做一个与G-WAN类似的项目.最初，我编写了API servlet，但效果很好，并没有充分利用G-WAN功能.借助G-WAN支持的一些指导，我开始探索处理程序的使用.我将我的API servlet移植到了处理程序中的URL重写例程中(为API查询返回的大部分内容都是静态/预渲染的内容).我现在正在研究404处理程序例程，以捕获尚未预渲染内容的情况，将其转换为按需渲染请求并动态构建响应.

(TL;DR ... sorry!)
I'm working on a project doing something very similar with G-WAN. Initially, I wrote API servlets, which worked quite well didn't take full advantage of G-WAN capabilities. With some pointers from G-WAN support, I started exploring the use of handlers; I ported my API servlets to a URL-rewrite routine in a handler (vast majority of the content returned for an API query is static / pre-rendered content). I'm now working on a 404-handler routine to catch the cases where we don't (yet) have the content pre-rendered, turning them into render-on-demand requests and building the response dynamically.

从客户端来看，这一切看起来都是动态的.但是通过对静态路径进行URL重写并允许G-WAN分派我们的按需案例，它减少了我们必须编写的代码量，并且利用了G-WAN中的一些高度优化的功能.我将这些细节作为吉尔所说的打破常规"的一个例子.最初，我们的方法看起来很像我们将如何使用nginx进行实现(除非不需要像fcgi这样的网关).尽管一旦我们精简了要求并抛弃了许多有关如何构建Web服务的假设，这确实是一个很大的进步.

From the client side, it all looks totally dynamic. But by doing URL-rewrites to static paths and allowing G-WAN to dispatch our on-demand cases, it reduces the amount of code we have to write, AND makes use of some highly-optimized features in G-WAN. I'm mentioning these details as an example of what Gil referred to as "breaking the mould." Initially our approach looked a lot like how we would do an implementation with nginx (except without the need for a gateway like fcgi). It has been quite an improvement though once we stripped down to requirements and threw away many assumptions about how web services should be constructed.

如果您打算使用C ++进行开发，请谨慎使用.从G-WAN到外部库的链接是"C"，而不是"C ++".他们这样做是出于性能和内存占用的原因(不错的选择)，但是当我开始用C ++编写一些我想从我的G-WAN Servlet和处理程序中引用的库例程时，我并没有想到这一切.从各种C ++应用程序引用.这不是一个热门话题-大量的"C"库可以很好地与C ++应用配合使用.但是，通过Servlet通过G-WAN通过"C"链接引用动态C ++类库(.so)会很麻烦. (我的简单解决方法是将共享的" C ++代码移动到.h文件中，并将它们包括在我的G-WAN处理程序和Servlet以及C ++应用程序中.这不干净，但很方便.)

One word of caution, if you plan on doing development in C++. The linkage from G-WAN to external libraries is "C" and not "C++". They did this performance and memory-footprint reasons (good choice), but I hadn't thought that through fully when I started writing some library routines in C++ that I intended to reference from within my G-WAN servlets and handlers in addition to being referenced from various C++ applications. It's not a showstopper - plenty of "C" libraries out there that work just fine with C++ apps. But it would be cumbersome to reference a dynamic C++ class library (.so) via a "C" linkage through G-WAN from a servlet. (My simple fix was to move my "shared" C++ code into .h files and just include them into my G-WAN handlers and servlets, as well as in my C++ apps. Not clean, but expedient.)

从G-WAN角度讲5点:

To your 5 specific points, from a G-WAN perspective:

1. 根据您对"analyse"和"unusual"的定义，这可以在协议处理程序中的C/C ++中轻松完成，也可以使用外部库.如果阻塞是一个问题，有多种方法可以使该异步成为单独的进程，或者可能是非阻塞的I/O.

1. Depending on your definition of "analyse" and "unusual" this could easily be done in C/C++ within your protocol handler, or you can make use of external libraries. There are multiple ways to make that asynchronous, either as separate processes or maybe just non-blocking I/O, if blocking is an issue.

还可以轻松地从处理程序进行管理.

Also easily managed from a handler.

同上.

是的. :)取决于您想要的支持水平.如果您完全依靠SO和其他社区支持，则免费.我们选择了廉价的支持订阅，并且响应远远超出了我们的预期.

Yes. :) Depends on the level of support you want. Free if you rely exclusively on SO and other community support. We opted for an inexpensive support subscription, and the responses have well exceeded our expectations.

哦，是的！我们在头几天确认了这一点.

Oh yeah! We confirmed that in the first few days.

哦，还有最后一件事:一旦花了一两个小时编写了一些G-WAN servlet，您可能很难回到其他Web/应用程序/服务机制.使用servlet，我只需保存编辑器中的更改，然后在浏览器窗口中单击刷新"以查看新结果(尝试使用fcgi实现！).我在服务器上运行了多个G-WAN实例(配置了不同的IP地址和端口号)，因此在一台计算机上，我有多个开发代码库，以及一个生产服务器.为了进行开发，我在终端会话(而不是作为守护程序)中运行G-WAN，并且可以在我的servlet和处理程序代码中使用printf(...)，以查看后端发生了什么以及在后端发生了什么.我的浏览器窗口.

Oh, and one last thing: Once you have spent an hour or two writing some G-WAN servlets, you may have a hard time going back to other web/app/service mechanisms. With servlets, I just save my changes from the editor and hit refresh on the browser window to see the new result (try that with an fcgi implementation!). I have multiple instances of G-WAN running on my server (configured for different IP addresses and port numbers) so on a single machine, I have multiple stages of development code bases, plus a production server. For development, I run G-WAN in a terminal session (not as a daemon), and can make use of printf(...) in my servlet and handler codes to see what is happening on the back-end vs what happens in my browser window.

有关更多信息:

• G-WAN协议处理程序
• G-WAN用户手册(从第34页开始)
• 处理程序状态
• 从Servlet，处理程序中调用库函数
• 并查看G-WAN安装包的handlers文件夹中的示例.

• G-WAN Protocol Handler
• G-WAN User's Manual (starting around page 34)
• handler states
• calling library functions from servlets, handlers
• and also look at the examples in the handlers folder of the G-WAN installation package.

祝你好运！
肯

Good luck!
Ken

这篇关于WebSocket的API网关的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！