search

AcalaNetwork / subway

GNU General Public License v3.0
59 stars 20 forks source link

HTTP Upstream Client #181

Closed shunsukew closed 1 week ago

shunsukew commented 2 weeks ago

Websocket connection to upstream blockchain nodes is great (As-is implementation). It is more efficient than creating TCP connections each time. However, for practical use, having HTTP Upstream Client would be good (at least as optional) to distribute traffic evenly to backends.

Especially when considering backends scaling and environments where node's IP addresses are dynamically being changed, we generally use a Load Balancer between Subway and Backend nodes. (For example, Kubernetes cluster, Pods IPs are dynamically changed, and virtual LB (called Service resource type ClusterIP) is in charge of backend nodes discovery.)

xlc commented 2 weeks ago

What I am thinking is that instead of a Subway instance loading balancing into multiple upstream, we can have multiple Subway each have a stable and persistent connection to RPC nodes directly and we put a LB in front of the Subway instances cluster

shunsukew commented 1 week ago

I see, that makes sense!

From here, just an idea sharing, so not related to original issue I posted above. But, having backend groups and routes traffic based on rpc methods is interesting, we can separate trace nodes and normal archive nodes, and routing trace rpc method calls to its own backend group. In this case, proxy should come in front of the load balance. This is what Optimism Proxyd can handle.

xlc commented 1 week ago

I guess we can have a middleware that is able to select which upstream to use based on the method call. It will require some refactoring but not too hard to do.