Here are our variables:
/// <summary> The timer. </summary>
private static Timer _timer = null;
/// <summary> The log. </summary>
readonly static ILog _log = LogManager.GetLogger(typeof(BaseMicroService<T>));
/// <summary> Identifier for the worker. </summary>
private string _workerId;
/// <summary> The lifetimescope. </summary>
readonly ILifetimeScope _lifetimescope;
/// <summary> The name. </summary>
private static string _name;
/// <summary> The host. </summary>
private static HostControl _host;
/// <summary> The type. </summary>
private static T _type;
/// <summary> The connection factory. </summary>
/// <summary> The bus. </summary>
private IBus _bus;
private ICacheManager<object> _cache = null;
The first variable up to bat is our timer. The timer is going to be scheduled to go off every 60 seconds, and with each trigger of the timer, we will send out a Heartbeat message. When we receive this message, our base microservice class will be responsible for packaging that information into our HealthStatus message and publishing it. From there, I am sure you can imagine storing this information in a database, separated by microservice ID, for historical tracking, emailing status results, and many more purposes. Regardless of what we do with it, health monitoring is a very important component of a properly designed microservice ecosystem.
Second, we have our log4net log manager, which will handle logging information for us. We will not cover log4net in this book. There are certainly many good technical references that you can find with a quick internet search.
Third, we have our worker ID. This is Guid represented by a string, which is assigned by the constructor and will serve as the unique identifier for this microservice. Since we will be having many microservices, and since there is nothing stopping multiple instances of the same microservice from running, this unique ID becomes important. This variable will become important once we get to our Bitcoin and microservice manager microservices, since they have the capability for consensus management, and the unique worker ID will be a great help there. But more on that later.
Fourth, we have our lifetime scope variable from our Autofac container. The lifetime of something within a microservice is no different than anything else. It is the time that your object lives, from the time you call new until it is disposed. The scope, on the other hand, is the area within the microservice where the object lives, where it can be shared with and among other objects, and so on.
So then, a lifetime scope is a combination of both of these. A lifetime scope equates to what some folks call a unit of work in an application. The work begins a lifetime scope, services or objects will get resolved from that lifetime scope, and, at the end of that unit of work, you will dispose of the lifetime scope and Autofac will dispose of the resolved services for you automatically. Did you get all of that?
Fifth, we have the name of our microservice. Even though this is an optional parameter, through Topshelf, we will create a practice of always providing it. In addition to providing the name of each microservice, we also concatenate the environmental machine name to the name provided. For example, if your name is ABC and you are running on a machine entitled SomeLaptop, then the name for the microservice will be ABC_SomeLaptop.
Sixth, we have the HostControl. This is a Topshelf component that is passed to our start method and it will be retained to use for stopping the service.
Seventh, we have the type of object our base microservice will be. As a generic class, our BaseMicroService can take many types of classes as its parameter. This means that we will now need to change the signature of our class to this in order to handle generics:
public class BaseMicroService<T> where T : class, new()
Next, we have the IBus object of EasyNetQ. EasyNetQ's main job in life is to make RabbitMQ easier to work with, which is why this object abstracts away communications, network topology, and more.
And finally, we have the CacheManager object. This CacheManager will be responsible for allowing objects to be stored within an in-memory runtime cache.