Play Microservices - api gateway and service discovery

Question

We're planning to develop some microservices based on the play framework. They will provide rest apis and lots of them will be using akka cluster/cluster-sharding under the hood.

We would like to have an api gateway that exposes the apis of our internal services, but we're facing one big issue:
- Multiple instances of each service will be running under some ip and port.
- How will the api gateway know where the services instances are running?
- Is there maybe something load-balancer-like for play that keeps track of all running services?

Which solution(s) could possibly fill the spot for the "API Gateway"/"Load Balancer"?

Answer 1

The question you're asking is not really related to play framework. And there is no single answer that would solve what you need.

You could start by reading akka Service Discovery and then make your choice based what fits you more.

We're building services with akka-http and use akka-cluster but use unrelated technologies to expose and run the services.

Check out

• Kong for API Gateway
• Consul for DNS based service discovery
• docker swarm for running containers with mesh network for load balancing

Answer 2

You are looking for following components,

1. Service Registry : The whole point of this component is to keep track of "what service are running on what addresses". This can be as simple as a simple database which keeps entries for all the running services and their instances. Generally the orchestration service is responsible to register new service instances with Service Registry. Other choice can be to have instances themselves notify the service registry about their existence.

2. Service Health Checker : This component is mostly responsible for doing periodic runtime checks on the registered service instances and tell service registry if any of them is not working. The service registry implementation can then either mark these instances as "inactive" till they are found to be working by Service Health Checker in future (if ever).

3. Service Resolution : This is the conceptual component responsible for enabling a client to somehow get to the running service instances.

The whole of above components is called Service Discovery.

In your case, you have load-balancers which can act as a form of ServiceDiscovery.

I don't think load-balancers are going to change much over time unless you require a very advanced architecture, so your API gateway can simply "know" the url's to load-balancers for all your services. So, you don't really need service registry layer.

Now, your load-balancers inherently provide a health-check and quarantine mechanism for instances. So, you don't need an extra health check layer.

So, the only piece missing is to register your instances with the load balancer. This part you will have to figure out based on what your load-balancers are and what ecosystem they live in.

If you live in AWS ecosystem and your load balancers are ELB, then you should have things sorted out in that respect.