Microservices nowadays are gaining a lot of momentum, all due to the case that it helps ease the development of the application by breaking the application into parts such that each part specializes in a particular task. This separation helps the developers in building the application component by component and launching them as they are ready to be shipped.
Though, the application development efforts are eased through Microservices, issues for devops increase. Managing the growing number of Microservices, abstracting the internal interfaces and routing the traffic properly to the correct service. To help overcome the issues, we have the concepts of API Gateways and Service Registries. Where the API Gateways can help in providing abstraction to internal interfaces consisting of number of Services built upon different protocols, the Service registry helps in maintaining the record of which Service is running and where it is running, what is the current status of the service.
The Service Registry can be leveraged by API Gateways, to route requests to the correct service by locating where they are running (host and port). Another case, where the service registry can be used is, to automatically spawn services as required and maintain the record of where they are running.
Recently, I took upon a challenge for myself to build a Microservice Registry Server. The aim with this was to understand, how the service registries are created, how the individual Microservices can communicate with the Registry Server to register and unregister as they go live or stop respectively and how the API Gateways can communicate with the registry to find the correct location for where to route the request.
To build this Microservice Registry Server, a considerable amount of time was spent reading a number of different articles and publications explaining how the API Gateways work, researching about the best way through which communication can be established between the different services and between the Registry Server and how to implement a reliable interaction between the registry server and the applications that want to communicate with the registry server.
Microservice Registry Server Architecture
So, while building the Microservices Registry Server, there were a few goals that had the utmost priority, some of these were:
- Modular Architecture
- Simple communication between different parts of the Registry Server
- Easy interfacing between Microservices and the Server
Keeping the above in mind, the Registry Server consists of various components, working together to bring the project alive. These components include:
- XMLRPC Server: To allow different services to register with the server, they need to access the API exposed by the server. During the development, I had a choice of choosing whether I should go and take the path of RESTful API that can be exposed by the Server or go some other way around. After going through a lot of option, I settled with the fact of using Remote Procedure Calls through which the applications can interact with the Server to register and unregister themselves. To implement this, I went ahead with using a simple XMLRPC Server that will listen to the requests and do the necessary action over them.
- MicroDB: MicroDB is an in-memory database, leveraging the functionality of python lists and dictionaries. MicroDB is a small serverless, in-application embeddable database, that can be used efficiently to store a small number of records. MicroDB provides a JSON based API that can be used to interact with the Database.
- ServiceDB: ServiceDB is a data store built on top of the MicroDB for storing the Service Records. The ServiceDB provides a simple API that can be used by the applications and plugins to register or unregister a Service from the database. The other functionalities provided by the ServiceDB include, querying the service information, updating the service status and traversing the service records.
The XML-RPC API
The service register exposes a simple XML-RPC based API, that can be leveraged by the Microservices to register and unregister themselves from the Service Registry. Some of the methods exposed by the XML-RPC API include:
- register(): The register method, takes in the name of the service, the information about where it is running (host and port), the service status and registers the service with the ServiceDB. Once registered with the ServiceDB, the consuming applications can query the ServiceDB for finding the available services and where they are running.
- update_status(): The method takes in the name of the service and the new status value and updates the status in the ServiceDB such that it is reflected to all the consuming applications. The service status are a predefined set of values that are defined inside the ServiceDB.
- unregister(): The method, takes in the name of the service that has already been registered with the ServiceDB, and is used to unregister the service from the database.
 Python xmlrpclib
Also published on Medium.