bender v0.2.1

bender

Kill all humans. Distributed, expiring service registry. Designed to support continuous deployments.

This module was inspired by Thalassa.
Differences include:

• no master - there's no separation between the main host and instances running on load balancers
• no persistant storage - no Redis, no anything
• no built-in HAProxy support - see bender-haproxy

How it works

Bender is long-standing, stateful, distributed daemon handling service registration. It uses CRDT as its data storage layer.

Registration flow

The typical registration flow is as follows:

1. Client registers with Bender using HTTP API
2. Receiving Bender updates CRDT
3. online event is triggered on all Bender nodes

After registering, client has to renew registration each n ms, depending on Bender's settings.

Deregistration flow

When a registration expires, the following happens:

1. First Bender node to notice that registration expired updates CRDT
2. offline event is triggered on all Bender nodes

Entities

Bender recognizes 3 types of entities.

Registration

Node registration.

Properties:

• resource (string, required) - always 'Registration'
• host (string, required) - node's address
• port (number, required) - node's port
• app (string, required) - application name
• version (string, required) - application version

Backend

Set of nodes serving specified app version.

• resource (string, required) - always 'Backend'
• name (string, required) - backend name
• app (string, required) - name of application this backend serves
• version (string, required) - version of application this backend serves

Frontend

Serves a specified backend.

• resource (string, required) - always 'Backend'
• name (string, required) - backend name
• backend (string, required) - name of backend to serve

HTTP API

POST /registrations

Create new registration.

GET /registrations

Get all registrations.