¶ Microservices
In any enterprise system you need services that talk to each other. In a Busby system these are microservices, each microservice sits on the bus and talks to other microservices through the messaging layer.
Microservices come in a few varieties
- built in - core microservices delivered with all systems, eg authentication service, directory service
- per project - microservices built to carry out a particular function unique to a deployment. These can be written in Java, JavaScript (TypeScript) or C#.
- nanoservices - Busby provides an in-built way to create very simple services through scripting, these are akin to lambda expressions.
The Busby Admin tool shows all of the configured services on a system. The services are spread across multiple hosts.
¶ Messaging
At its heart Busby is built upon a messaging framework – https://www.rabbitmq.com. This framework is used to set up the necessary communication channels between the various services on a system. The complexity of the messaging implementation is hidden behind a simple abstraction of services, providers and subscribers.
The general concept is that services provide capabilities that can be called upon.
Providers run pieces of code that instantiate or call upon a service.
Meanwhile, subscribers connect to services to use the services capabilities.
The following diagram shows the routes of various messages in an alarm system.
Each service can be provisioned across multiple providers. When a subscriber attaches to a service, the exact provider that it connects to is unknown. This inherently flexible messaging mechanism can change call by call and allows service level redundancy and load balancing.
Behind the scenes a directory service determines the messages that flow between both provider and subscriber. The directory service also acts as a directory of the providers that are available and whether they can receive requests.
Once a connection is established, messages are directly routed from subscriber to provider.
¶ Message types
Busby restricts the types of messages through the bus to two types, first request and response, here a question is asked by a subscriber and a provider responds; second status messages, in this case subscribers can register for interest in status from a provider and get an unsolicited message each time an event of interest happens. These two mechanisms
use simple JSON payloads. Anything more complex in terms of message orchestration is configured in the business logic, normally in a workflow.
¶ Provider status
Providers can be in one of the following states
| State | Description |
|---|---|
| Active | The provider is actively receiving messages for this service. If a new subscriber tries to connect to the associated service then it will be given details of this provider. There can only be one Active provider for a service. |
| Standby | The provider is ready to become active if the Active provider is stopped. This means that it has synchronised any persistent data from the associated Active provider. It is possible to have multiple Standby providers for a single service. |
| Online |
When setting up services if they do not have persistence, it is often possible to set them to an Active - Active mode. The screen grab below shows the nano service being configured in this way.
In this case when providers are run, and they are are available then they will report as Online. Any Online service is available to pick up request messages, when a subscriber connects to an Active - Active service it will be given the least busy provider to connect to.
|
| Offline | A service is running but has not provided its status to the directory service yet. This state is often used when providers are starting up. |
| No Comms | If a provider does not send any provider status to the directory service for a 10 seconds then it will go into No Comms. |