API gateway for WebSocket

问题:

I need a API gateway for my websocket application.

1. Analyse and identify unusual requests from certain IP
2. Quotas and Rate Limiting
3. Statistics
4. Free or commercial
5. Solid performance

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:

• 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.

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

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

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?

回答1:

(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.

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.

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.)

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

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.

2. Also easily managed from a handler.

3. Ditto.

4. 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.

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

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.

For more info:

• 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

回答2:

A G-WAN protocol handler will let you implement such a proxy to multiplex requests through one single connection (or a connection per worker thread for more scalability).

That's what G-WAN makes easy: breaking the mould to create custom solutions.