Deploying Distributed / Microservice Solutions

The ABP Framework is designed to consider distributed and microservice systems, where you have multiple applications and/or services communicating internally. All of its features are compatible with distributed scenarios. This document highlights some points you should care about when you deploy your distributed or microservice solution.

Application Name & Instance Id

ABP provides the IApplicationInfoAccessor service that provides the following properties:

  • ApplicationName: A human-readable name for an application. It is a unique value for an application.
  • InstanceId: A random (GUID) value generated by the ABP Framework each time you start the application.

These values are used by the ABP Framework in several places to distinguish the application and the application instance (process) in the system. For example, the audit logging system saves the ApplicationName in each audit log record written by the related application, so you can understand which application has created the audit log entry. So, if your system consists of multiple applications saving audit logs to a single point, you should be sure that each application has a different ApplicationName.

The ApplicationName property's value is set automatically from the entry assembly's name (generally, the project name in a .NET solution) by default, which is proper for most cases, since each application typically has a unique entry assembly name.

There are two ways to set the application name to a different value. In this first approach, you can set the ApplicationName property in your application's configuration. The easiest way is to add an ApplicationName field to your appsettings.json file:

{
    "ApplicationName": "Services.Ordering"
}

Alternatively, you can set AbpApplicationCreationOptions.ApplicationName while creating the ABP application. You can find the AddApplication or AddApplicationAsync call in your solution (typically in the Program.cs file), and set the ApplicationName option as shown below:

await builder.AddApplicationAsync<OrderingServiceHttpApiHostModule>(options =>
{
    options.ApplicationName = "Services.Ordering";
});

Using a Distributed Event Bus

ABP's Distributed Event Bus system provides a standard interface to communicate with other applications and services. While the name is "distributed", the default implementation is in-process. That means, your applications / services can not communicate with each other unless you explicitly configure a distributed event bus provider.

If you are building a distributed system, then the applications should communicate through an external distributed messaging server. Please follow the Distributed Event Bus document to learn how to install and configure your distributed event bus provider.

Warning: Even if you don't use the distributed event bus directly in your application code, the ABP Framework and some of the modules you are using may use it. So, if you are building a distributed system, always configure a distributed event bus provider.

Info: Clustered deployment of a single application is not considered as a distributed system. So, if you only have a single application with multiple instances serving behind a load balancer, a real distributed messaging server may not be needed.

See Also

Contributors


Last updated: December 07, 2022 Edit this page on GitHub

Was this page helpful?

Please make a selection.

To help us improve, please share your reason for the negative feedback in the field below.

Please enter a note.

Thank you for your valuable feedback!

Please note that although we cannot respond to feedback, our team will use your comments to improve the experience.

In this document
Community Talks

Building Modular Monolith Applications Using .NET and ABP Framework

17 Oct, 17:00
Online
Watch the Event
Mastering ABP Framework Book
Mastering ABP Framework

This book will help you gain a complete understanding of the framework and modern web application development techniques.

Learn More