The basic architecture
​
A possible architecture can look as the following:
Some remarks:
-
The API gateway services can physically being manifested as pure programing language specific packages (in .Net as assemblies for example) or as real self contained services. Depending on your needs.
-
The backend web proxies are the web developers entry point. As here start all the web specific work.
-
Clusters - as a RabbitMq cluster - are not explicitly shown here.
-
Load balancing to various instances of the same micro-service is done via the queue mechanisms.
-
System monitoring is not shown here. But I give a small sample below how a microservice health board - or even a control board - can be easily developed with the help of a messaging broker.
Here is the promised sample configuration for a microservice health board
To illustrate I used this nice, brilliant tool: RabbitMq simulator
The microservice will publish in a defined time frame its health metrics to an "health.exchange". The health.exchange is of type "fanout". This means all incoming messages are spread to all bound queues on the health.exchange. The queues "ADQueueClient1" etcetera. are auto deleted transient queues. This means if a consumer is shut down RabbitMq will delete this queue. So RabbitMq does the clean up job for you. This also works if your client (the health-board) crashes.
The various consumers (ConsumerClient1..3) represent the health board instances. So it basically works as the following: When the health board client is startet, it establishes an auto delete transient queue and binds it to the health.exchange. The consumer now receives health messages form all microservices publishing their health in a certain time frame to the health.exchange.
Now the health board can visualize the health of each microservice. You typically deliver health informations with attributes like: Memory usage, microservice name, server name, instance number etcetera.