ScaleCube Microservices is message-driven and asynchronous by default, it is built to scale due to its peer-to-peer nature. Empowered by the ScaleCube-Cluster gossip capabilities which aims to answer the cross-cutting-concerns of a microservices applications such as: service discovery, location transparency and fault-tolerance via real time failure-detection. ScaleCube Microservices provides fluent java-8 functional APIs and Reactor Project Mono benefits. The ScaleCube Microservices are lightweight and embeddable in-order to reduce restrictions regards service implementation. It only requires a simple declaration of the Service APIs as an entry point to the service component. With ScaleCube Microservices its possible to provision services within the same process, multiple processes on the same hardware or multiple processes on multiple hardwares thus enabling ease of development and testing of a distributed applications. There is no need to worry about the final topology and hardware sizing at the development stage. Write once scale anywhere.Click this link to learn more about ScaleCube Services
Distributed peer-to-peer applications require weakly-consistent knowledge of cluster membership information at all participating members.
ScaleCube provides scalable and efficient implementation of cluster membership algorithm.
Cluster Membership component is responsible for managing information about existing members of the cluster.
It is a running Java implementation of SWIM protocol for distributed group membership, with a few minor adaptations.
It uses suspicion mechanism over the failure detector events, accompanied by a separate membership updates dissemination component (gossip protocol).
The Cluster Membership also introduces a separate gossip protocol component instead of piggybacking membership updates on top of failure detector messages. It is done in order to reuse gossip component for other platform events and have more fine grained control over time intervals used for gossiping and failure detection pinging. New members to the cluster joins via well known configured server addresses (seed members).
The Cluster Membership also extends SWIM protocol with the introduction of periodic SYNC messages in order to improve recovery from network partitioning and message losses.
The Transport component is responsible of maintaining point-to-point connections between the members in the cluster. It is used as a backbone for asynchronous messaging between the members of the cluster.