The microservice manager is, by some aspects, next to RabbitMQ, the heart or nexus of the system. It is the main brain, if you will, of the ecosystem. From it, we can control different aspects of the system as well as send and receive messages. You can have it do anything that you like, it's your blank canvas. In our world, we wanted to subscribe to all our messages, and once they were received, display them to the user. You, of course, will do different things once you make the code production ready for your world. But the microservice manager can trigger events, listen for events, and trigger more events predicated upon responses; it's really whatever you can dream up.
In this chapter we will cover:
- Developing a centralized Microservice Manager
- Integrating all previous message subscriptions
- Process all previously received messages
As we said, in our world, just to give you some idea, our microservice manager will be subscribing to all the messages we are sending. Where there are two messages, one for request and one for response, we will be subscribing to the response message. You could very easily expand this to listen for the request messages and then keep track of who does and does not send our responses. It could be a good first indicator of a microservice degrading in its service capabilities! You could also use the cache manager to track the number/volume of each request and issue a report on this at a predetermined time.
The health status messages are probably the most important. If you log these into a database, you will have a temporal history of your entire ecosystem, and again, you can use that information to generate reports as needed. Day one of your microservices doesn't calculate a Credit Default Swap (CDS), price a bond, or something else critical to the business needs; trust me when I say you'll be very glad you have this information as a reference.