Particular Service Platform Overview

Messaging is a good way to build loosely coupled, scalable and reliable systems. However, it also has its challenges. The most common difficulty is having visibility of what's happening in the system. This is one of the problems that the Particular Service Platform was built to solve.

The goal of the Platform is to provide a set of tools that make the building and maintenance of messaging systems easier. The tools are tailored to common needs of a messaging system and 'just work' out of the box, enabling developers to focus on other important challenges such as understanding their business domain better. Currently, the Particular Service Platform consists of NServiceBus, ServiceControl, ServiceInsight and ServicePulse.

Particular Service Platform architecture

NServiceBus - where it all begins

NServiceBus, the heart of the system, is a messaging and workflow framework that helps create distributed systems that are scalable, reliable and easy to modify. It supports various messaging patterns, handles long-running business processes in the form of sagas and provides abstraction over multiple queuing technologies. While most queuing technologies try to make guarantees regarding 'at least once' or even 'exactly once' delivery, they often fall short of this promise. NServiceBus contains mechanisms to automatically solve intermittent delivery problems by retrying messages and falling back to an error queue where they can be exposed by the rest of the Platform for human intervention (ServiceControl, ServicePulse).

Moreover, NServiceBus is thoroughly extensible and can be tailored for many requirements. It is compatible with several technologies and many elements of the system can be replaced with custom implementations.

ServiceControl - the foundation

ServiceControl is the monitoring brain in the Particular Service Platform. It collects data on every single message flowing through the system (Audit Queue), errors (Error Queue), as well as additional information regarding sagas, endpoints heartbeats and custom checks (Control Queue). The information is then exposed to ServicePulse and ServiceInsight via an HTTP API and SignalR notifications.

The ServiceControl HTTP API may change at any time. It is designed for use by ServicePulse and ServiceInsight only. Use of this HTTP API for other purposes is discouraged.

It is important to understand that the data is still collected even if ServiceControl is down. When it starts working again, it will process all the information that was saved in the meantime.

To enable ServiceControl to gather this information, configure the solution appropriately:

All endpoints should be configured to forward to the same audit, error, and ServiceControl plugin queues unless the system has been sharded between multiple ServiceControl instances.
ServiceControl consumes messages that arrive in either the configured audit or error queues, i.e. it removes those messages from the queues. If a copy of those messages is required for further processing, configure audit forwarding and/or error queue forwarding.

By default ServiceControl stores information for 30 days, but it can be customized.

Refer to the Optimizing for use in different environments article for more information about practical considerations.

ServiceInsight - message flow visualization

ServiceInsight is a desktop application with features tailored to developers needs. It allows for advanced debugging, tracking the flow of an individual message in the system, observing sagas and more.

It is much easier to quickly spot anomalies and incorrect behavior in the system when presented with information in visual form, such as message flow diagrams or sequence diagrams. At the same time, access more detailed information such as message headers and all message metadata.

ServicePulse - production monitoring

ServicePulse is a web application aimed mainly at administrators. It gives a clear, near real-time, high-level overview of how a system is functioning.

Notifications will occur when the endpoint is down or when a message fails. Custom checks can be built to get alerts for specific scenarios. The interface supports performing common operations for failure recovery, such as retrying failed messages. In order to display and handle them in a custom way see subscribe to publicly exposed events.

Working with the platform

Having ServiceControl and ServiceInsight installed locally on a machine gives significant benefits during development, especially when investigating failures and defects. Additionally, if developing a custom check it is useful to have the full platform installed on a development machine.

After a solution is deployed, ServiceControl and ServicePulse should exist in each environment it was deployed to (e.g. one instance per integration, another one for test and one more for production). ServiceInsight is a client install, so it can be installed on a local machine only and point it to the specific environment or local instance URL.

Related Articles

Last modified