Additional resources
•
Unit & Integration testing
on the eShopOnContainers
https://github.com/dotnet-architecture/eShopOnContainers/wiki/Unit-and-integration-testing
•
Load testing
on the eShopOnContainers
https://github.com/dotnet-architecture/eShopOnContainers/wiki/Load-testing
Implement background tasks in microservices with
IHostedService and the BackgroundService class
Background tasks and scheduled jobs are something you might need to use in any application,
whether or not it follows the microservices architecture pattern. The difference when using a
microservices architecture is that you can implement the background task in a separate
process/container for hosting so you can scale it down/up based on your need.
158
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications
From a generic point of view, in .NET we called these type of tasks
Hosted Services
, because they are
services/logic that you host within your host/application/microservice. Note that in this case, the
hosted service simply means a class with the background task logic.
Since .NET Core 2.0, the framework provides a new interface named
IHostedService
helping you to
easily implement hosted services. The basic idea is that you can register multiple background tasks
(hosted services) that run in the background while your web host or host is running, as shown in the
image 6-26.
Figure 6-26. Using IHostedService in a WebHost vs. a Host
ASP.NET Core 1.x and 2.x support
IWebHost
for background processes in web apps. .NET Core 2.1 and
later versions support
IHost
for background processes with plain console apps. Note the difference
made between
WebHost
and
Host
.
A
WebHost
(base class implementing
IWebHost
) in ASP.NET Core 2.0 is the infrastructure artifact you
use to provide HTTP server features to your process, such as when you’re implementing an MVC web
app or Web API service. It provides all the new infrastructure goodness in ASP.NET Core, enabling you
to use dependency injection, insert middlewares in the request pipeline, and similar. The
WebHost
uses
these very same
IHostedServices
for background tasks.
A
Host
(base class implementing
IHost
) was introduced in .NET Core 2.1. Basically, a
Host
allows you
to have a similar infrastructure than what you have with
WebHost
(dependency injection, hosted
services, etc.), but in this case, you just want to have a simple and lighter process as the host, with
nothing related to MVC, Web API or HTTP server features.
Therefore, you can choose and either create a specialized host-process with
IHost
to handle the
hosted services and nothing else, such a microservice made just for hosting the
IHostedServices
, or
you can alternatively extend an existing ASP.NET Core
WebHost
, such as an existing ASP.NET Core Web
API or MVC app.
159
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications
Each approach has pros and cons depending on your business and scalability needs. The bottom line
is basically that if your background tasks have nothing to do with HTTP (
IWebHost
) you should use
IHost
.
Dostları ilə paylaş: |