Beehive router architecture
Oct 05 2009
Beehive is an open-source application deployment implementation that uses technologies like squashfs, erlang and ruby. It aims to provide a simple, easy application deployment platform. This post will go over the router portion of Beehive.
Beehive is implemented with two servers. One server is the backend server that sits on the nodes that are available to deploy applications. The other is the router server. Note, these are not exclusive of each other, but there must be a router server that the client connects to and the backend nodes must have knowledge of access to the router. Here are a few specifications for the router of Beehive.
- Mochiweb will handle the incoming requests
- Beehive's custom router implementation will receive the request
- Beehive's router looks up the subdomain host's name in it's known
- The request is then handled by the backend node by spawning a http client response to the backend nodeThis is the basic diagram for the request handling.
With this in mind, let's get right to the implementation of the router server. We'll come back to the backend server after we flush out the router implementation.
For the router server, we'll use the following modules (leaving out the obvious application details, like supervisors, etc.):
This is responsible for keeping track of all the backends the router knows about. When a new backend comes online, it will register itself with the backend_registry on the router node.
This is responsible for keeping track of the current apps or packed applications that the router knows about. At an n-interval, the backend server (on the remote host) checks the node for new applications. If there is a new application found, it calls register to this server.
This is the glue between the two above mentioned servers. And handles messages to connect a client to the backend server that matches up to the requested resource.
Backend registry process
When the backend starts up, it must either be given a router_node, or it assumes the router is located on the same machine at the localhost name.
Each backend node has a backend process that pings the system to see if there is a new application present. If there is an application present that was not previously known about, the app registry server is notified and updated.
When a request comes in, the router_srv is notified of a new request and asks the app_registry_srv for the list of backends that support the subdomain carrying the application.
Enhance the application lookup by routing to the fastest responding backend server. This could be done by registering the router's backend server as a "listener" on the backend's backend_srv.