BeyondJ Clustering with Hazelcast
Hazelcast (http:// hazelcast.org) is a library that makes it easy to share information between different Java applications and different JVMs. BeyondJ uses Hazelcast to power its clusters. Early on we made a design decision to adopt a shared-nothing approach and as such we had no need for master/slave cluster members. Every member of the cluster is created equal and we have no need for replication servers and all that jazz. Information between BeyondJ cluster members is shared by passing messages using the publish/subscribe pattern.
We can install BeyondJ on multiple machines and cluster the container by simply configuration Hazelcast discovery http://docs.hazelcast.org/docs/2.4/manual/html/ch12s02.html.
Each BeyondJ instance will publish each configuration change to the Hazelcast cluster, and all other instances will download and update their configuration and cache of services. That way each instance of BeyondJ on each machine will have the same relative configuration as any other, as well be able to launch any new applications discovered from the cluster configuration. So when we need to launch a new application into the cluster, we simply upload a jar or zip artefact to a single instance of BeyondJ. That instance will publish the artefact to be launched, including its configuration, to the cluster. All other cluster members will download the artefact and its configuration and launch instances of the application in their own JVMs. Once each instance finishes the launch, it publishes the URL of the local application to the cluster. In turn, all other instances will update their cache of services to include the newly launched application instance (across the cluster). The end result is that each instance will have the same number and version of known applications, and a cache of addresses via which those applications can be reached. Each instance of BeyondJ will then load balance across the cluster for each application.
This ensures that a request can come to any instance of BeyondJ in the cluster, and can be served from any instance within the cluster, according to the specified load balancing strategy.
So what is the end result? A single jar, which can be installed on multiple machines providing near unlimited scaling, service discovery, load balancing, clustering, high availability, location transparency, liveliness, self-healing, metrics and dash boards. Wew!
Suppose we have written our application and now we want to deploy it to three machines to be accessed by 30 000 clients. To achieve high availability and liveliness we will deploy 10 000 instances per machine. We are going to launch a single JVM on each machine and deploy BeyondJ to each. Next, we will simply launch our browser and point it to an instance of BeyondJ installed on one of our three servers. We will then upload a jar or zip file of our application via the browser interface. We have the option to also upload an XML configuration file which would specify how many instances we need launched on each machine within our cluster (in this case 10 000 on each machine). We also have the option to specify the number of instances, among other options, within the browser interface. We will click deploy and voila, thats it. We will wait a few moments, and BeyondJ will launch for us 10 000 instances of our shiny micro service on each of our three servers. Immediately we will start getting reports and feedback on all 30 000 instances.
The number of our application instances is only limited by the amount of resources (memory, threads) available on each machine.