Skip to content

GlenTiki/seneca-load-balancer

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

5 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Seneca

A Seneca.js service load balancer that allows you to run multiple instances of services listening for the same pattern.

Seneca-load-balancer

IN PROGRESS, NOT PROD READY

npm version Build Status Dependency Status Gitter chat

This is a plugin for Seneca that allows you to load balance between multiple running instances of your services. This allows you to build what appears to be the evolving standard for microservices (run as many as needed of the same service at once to meet demand, load balance between them). This only works with http and tcp transports.

Example

At the end of this example, you will have seen how to run some services, hook your load-balancer to them, and then the load balancer will send out jobs to them from some client. The client sends all acts to the load-balancer, the load-balancer then sends acts to a running service, and the service gets a reply from the client.

The service/server below (service.js) is run with the command node math.js SOME_PORT, allowing you to create the same service listening on multiple ports.

var seneca = require('seneca')()

// A basic pattern to use
seneca.add({ a: 1 }, function (input, done) {
  console.log(input)
  done(null, { b: 1, port: process.argv[2] })
})

// eg. run with node ./test.js 10201
seneca.listen({ port: process.argv[2] })

The code below (balancer.js) is how you would setup your customised load-balancer. You just .use() the load-balancer, and supply it with some options/config. I will supply SOME_LOAD_BALANCE_CONFIG_OBJECT later.

var Seneca = require('seneca')()
var SOME_LOAD_BALANCE_CONFIG_OBJECT = {...}

seneca.use(require('seneca-load-balancer'), SOME_LOAD_BALANCE_CONFIG_OBJECT)

seneca.listen({port: 10100})

The code below (client.js) is an example of a client that wants to use our already defined service. This client connects to our load-balancer, NOT the services themselves.

var seneca = require('seneca')()

seneca.client({ port: 10100, pin: {} })

setInterval(function () {
  seneca.act({ a: 1 }, console.log)
}, 10000)

If you ran service.js three times, you need some way of connecting to it. e.g if you ran the following:

node ./service.js 10201
node ./service.js 10202
node ./service.js 10203

now run the client. this will try every ten seconds to hit our currently running service, and log the result. when it starts getting replies with the b and port property, we know we succeeded

node ./client.js

Now, we need the balancer to connect our client to our services. This is where the config object mentioned above comes in. This object has a specific stucture, explained in full later. however, for this example, the following config works:

var config = {
  services: [
    {
      //we can use seneca pattern style definitions here, or standard objects!
      pattern: 'a:1',
      locations: [
        { host: 'localhost', port: '10201', spec: 'http' },
        { host: 'localhost', port: '10202', spec: 'http' },
        { host: 'localhost', port: '10203', spec: 'http' }
      ]
    }
  ]
}

now, with the config above, run ./balancer.js with the following:

node ./balancer.js

Contributing

This module follows the general Senecajs org contribution guidelines, and encourages open participation. If you feel you can help in any way, or discover any Issues, feel free to create an issue or create a pull request!

If you wish to read more on our guidelines, feel free to

License

Copyright Glen Keane and other contributors 2016, Licensed under MIT.

About

A Seneca.js service load balancer that allows you to run multiple instances of services listening for the same pattern.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published