In this page we will have a look at the communication between the services based on the example of the development state of April 2017. This is to give an overview over the inner workings between the services. Important for this document is to differentiate between the term "service" and "instance". A service is a set of similar instances, and because we will have a lot of them we call them "microservice". An instance is... an instance of the service? Guess that's self-explanatory.
Setup
In the diagram you can roughly see an overview of what components there are right now. I want to focus your attention on the fact that there omscore and omsevents appear twice. This is to give an example for scaling these applications. Scaling means replicating the same service several times, which brings the advantage of fault-tolerance, higher throughput and the possibility to use more physical machines with our setup. Theoretically each of the boxes with a double border can run on any machine, they just all need to be connected in a swarm-cluster. The number of two replicas is arbitrarily chosen by me.
Then there are two parts which appear different, the swarm dns and the Traefik reverse-proxy. Both provide some way to perform service discovery inside our network. The swarm dns is aware of the services which are defined inside the docker-compose.yml and will return an instance of the existing instances of these service by a scheduling mechanism like round robin. This is useful as a service inside the swarm can just query an address like http://omscore and will be connected to one of the instances of omscore. Traefik is also able to do loadbalancing, however therefore it is necessary to query traefik with a specific url, like /omsevents/frontend/all/eventsController.js. Traefik then matches this request to a backend by specific rules, also called "frontend". In the scenario, three frontends are active. Backend is the name for an instance which is part of the service hooked to the frontend. Traefik will reverse-proxy requests from the wild internet and performs its own loadbalancing and health checking. It can also be used for internal service discovery by just querying one of the frontends from inside the network.
more to follow soon!