Project specification - emiovska/microservices-monitoring GitHub Wiki

1. Overview

Nowadays the microservice architecture is adopted by a lot of big project just because of the possibility to create high available and scalable services. Sometimes there is a big challenge to scale some service, running multiple instances. In the cloud environment multiple instances by service can be created. Each of the service can be dynamically started on different location (host and port). If we want to scale one service using the described approach we should solve the problem how this service should be visible to the other services.

1.1 Service self registration library

The service registry library will be developed as separate project. The main purpose of the library is to provide self service registration. The library is developed using Java EE to provide possibility to include in any Java framework. The scope of work of this library is to listen when the service starts up/ shutdown and notifies the service registrar about the service state. The component informs the service registrar about the host, port, the ID of the service and the health check endpoint URL. The address on which the service should register/deregister itself is configured using a properties file. The file should have a static defined name service.registry.properties. Also the service should provide health check endpoint. This health check endpoint will be used by the service registrar to check if the service is available. The health check will be realized in a form of heartbeats, sending HTTP PUT request. The provided library will be exposed as a maven dependency for further usage.

Usage: To use the out of the box functionality provided by the service self registration library we should just create a new project, include the service registry library using static jar or maven dependency and configure service.regitry.properties in the resource directory. The property file must contains the registration and deregistration url. After we successfully configure the above and we have up and running service registrar, the new created service should register itself to the configured registrar.

1.2 Service registrar

The service registrar is also another library which will be developed as separate project. The service registrar is the component which knows all about all active services. This component listen for service registration/service deregistration on endpoint configured in properties file. The properties file should have a static name service.registrar.properties. The library should provide notification mechanism to notify all subscribed clients which are interested about services state changes. Also the library should notify the subscribed clients when the components starts up. The provided library will be exposed as a maven dependency for further usage.

Usage: To use the out of the box functionality provided by the service registrar library we should just create a new project, include the service registrar library using maven dependency and configure service.registrar.properties file in the resource directory. After we successfully configured the above and start a service which knows how to register itself on the service registrar, a configured subscriber should be notified about state changes

1.3 Integration of service self registration and service registrar

After the above modules/libraries are developed and are ready to be used, a integration project should be created. The project should contains:

  • Service registrar application which will include as a dependency the provided service registrar library. The project should implement client class which will be able to listen about service state changes. All active services will be stored in a database. After restart (on startup) the component should check the state of all tracked services in the database. The application will also expose API endpoints for all active registered services and querying according to given service ID. The documentation about this API endpoints should be documented using Swagger.

  • Three or more microservices which as dependency should have the service self registration library. Thee services will register itself on the configured service registrar.

2. Infrastructure

The integration project will be integrated with Heroku as platform as a service environment.