Light-router is a service that provides consumers with another option to do service discovery if they cannot leverage client module provided by light-4j.
There are two ways to deploy light-router, and it is highly recommended for the client to own the instance of light-router.
For demo purposes, the light-router will be deployed in Kubernetes cluster master node as it has a static IP address. By following the steps below, you should have a router instance up and running and connect to multiple instances of API A in the Kubernetes cluster. Communication between API A, B, C, and D is handled with the client module inside each API.
The light-router will be deployed to the sandbox which is our development Kubernetes cluster master node.
["API D: Message 1 from port 7444","API D: Message 2 from port 7444","API B: Message 1","API B: Message 2","API C: Message 1","API C: Message 2","API A: Message 1","API A: Message 2"]
Light-router is an infrastructure service that can assist internal clients, and is not built on top of Java 8 for service discovery and security. It also can act as an external access point for external client to access internal service. In this case, it is playing a role of distributed API gateway.
All previous steps with Consul discovery are based on a dockerized consul instance with http connections. In production, we need to have a consul cluster and https needs to be enabled. In the next step, we are going to explore the Consul cluster with TLS connection.