If you are aiming for a microservice architecture everything is easy as long as the services do not have to communicate with each other. When this is necessary the services have to find each other.
Current solutions for service registration and discovery
This process is called service discovery and there are some newer solutions.
Standards for service discovery
Besides these implementations a lot of standards have own specifications for service discovery like:
- SSDP – Simple Service Discovery Protocol
- UDDI – Universal Description, Discovery and Integration
- XEP-0030: Service Discovery
- Open Service Broker API
Challenges of current solutions
I don’t think that a new solution is needed because solutions like Consul, Eureka and SnoopEE require the following:
- You have to learn a proprietary API
- You have to maintain an own service registry and discovery server
- You have to use solutions that are mainly made for the Java world
- It is unlikely that your choosen solution will be maintained for a long time
- The given solutions are using a lot of ressources like main memory
Service discovery with DNS SRV and TXT records
In this blog post I will emphasize on:
In short DNS SRV records.
I am proposing to use DNS SRV records for service lookups and encrypted TXT records for needed configurations. This is shown in the picture above.. Let me give you an example based on the microservice architecture shown in this blog post.
Example Microservice URLs
Let’s assume we have the following URLs for the services.
|–||https://production.example.com/||Main URL including Login|
This would result in the following SRV records on the production.example.com domain:
Currently two challenges are visible:
- The entry for invoicing and timetracking point to the same server and the url path is not given in the SRV record.
- If credentials or other configuration parameters are needed these are not given in the SRV records
Configuration with encrypted TXT records
My proposed solution for saving these information is to encrypt them with the public key of the SSL certificate that is used for production.example.com and then save the base64 encoded string in the TXT record for the given domain.
When encoding this with RSA and openssl ith the following command:
cat _timetracking._tcp.production.example.com.properties | openssl rsautl -encrypt -pubin -inkey public.pem -oaep | openssl base64
The following output will be created:
This will create the following TXT record
_timetracking._tcp.production.example.com. 60 IN TXT "biymNCFyc5kePbBPANirNKJwFWq5QnQKblFZiyCD/glKelnOCxwvLtnBjTPebXNIv/cUjLZUdrEd4lWkOoyPultcMseiIfwP8VAQtNVZnJcWjqiDUxSDCJGLWNzM4n6+rclRRYPyHinw9viga4Rl7jukWWs18bsGVRdk1xvDFVvGuyTn/VpZdWYiyd2pqxhOAtiB/dadQ3W5uCEu5per34vXQzwUJLeMXVAxA+45JqEQnWFrLIrWGA3dN/uHgL81iapmYO7J7rM7HoMHUqRnjkaz7POrJbQBu1XbvyY0odG8jX/pFqRdMvF+FlDTUvLGUatiFNsG/yiB69CpLMv5JA=="
This record can be decrypted to get back the local values.
Combined with the Microprofile Config API this solves the following service registry, discovery and configuration challenges:
- No new infrastructure needed
- Build on standards that are unlikely to change
- Every programminc language has DNS lookup capabilities
- A JSON Format
- Tools for maintaining records on multiple providers
- Dynamic reconfiguration possible when setting a low time-to-live
- Continuous integration pipelines with build, test and production systems are supported
- Uses the already available SSL public key infrastructure
- DNS is proven to be super scalable, reliable and when using DNSSEC secure