Book Image

Hands-On Microservices with C#

By : Matt Cole
Book Image

Hands-On Microservices with C#

By: Matt Cole

Overview of this book

C# is a powerful language when it comes to building applications and software architecture using rich libraries and tools such as .NET. This book will harness the strength of C# in developing microservices architectures and applications. This book shows developers how to develop an enterprise-grade, event-driven, asynchronous, message-based microservice framework using C#, .NET, and various open source tools. We will discuss how to send and receive messages, how to design many types of microservice that are truly usable in a corporate environment. We will also dissect each case and explain the code, best practices, pros and cons, and more. Through our journey, we will use many open source tools, and create file monitors, a machine learning microservice, a quantitative financial microservice that can handle bonds and credit default swaps, a deployment microservice to show you how to better manage your deployments, and memory, health status, and other microservices. By the end of this book, you will have a complete microservice ecosystem you can place into production or customize in no time.
Table of Contents (16 chapters)
11
Trello Microservice – Board Status Updating
12
Microservice Manager – The Nexus

Creating common messages

Let's start with a very simple message, the deployment messages:

public class DeploymentStartMessage
{
public DateTime Date { get; set; }
}
public class DeploymentStopMessage
{
public DateTime Date { get; set; }
}

As you can see, they are not overly complicated. What will happen is that we will have a DeploymentMonitor microservice. As soon as our deployment kicks off, we will send a DeploymentStartMessage to the message queue. Our microservice manager will receive the message, and immediately disable tracking each microservice's health until the DeploymentStopMessage is received.

Always include all your messages in the same namespace. This makes it much easier for EasyNetQ and its type name resolver to know where the messages are coming from. It also gives you a centralized location for all your messages, and lastly, prevents a lot of weird looking exchange and queue names!