node package manager

bender

Distributed, expiring service registry

bender

Build Status

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.