...
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.
...
- Get Auth Token Internal communication can be authenticated in two ways, if one service wants something from another service on behalf of a user request, it can use the access token from the user to authenticate against another microservice. This is the preferred way of authenticating interservice requests, as users permissions are automatically applied everywhere in the service chain. However, sometimes it is impossible to provide a user token such as in cron-executed requests, which is why the service registry provides auth token for internal services. A service can get one of those tokens by supplying the api-key to the registry as a proof of authenticity, . The api-key which is generated by the registry and sits in a shared docker volume . This request and thus is accessible to all microservices. This request to get the auth token can happen at the startup of the service and is not necessarily a part of the communication chain, however it has to happen before the rest of this communication which is why it is shown here.
- Query for service in category The registry holds servicenames by categories, so when a service needs information about users, it can query the registry for a service which serves that category. For performance this response can be performed at the startup of the service and cached for the whole lifetime of the application, as this is not going to change often and currently changes would involve a restart of the whole system anyways.
- Name resolution The result of the registry query is a url which the service can use to query other cores. This url is either a Traefik frontend rule or an internal domain name, which can be resolved by the swarm dns as we already saw it in the db request from the core in the above scenario.
- Query The actual query for data from the other service
- Validate token In case the other service used an auth token supplied by the registry, the other service has to validate that token against the registry. In case it was a user token, the usual authentication method can be used.
- Response On successful validation the queried service will return the requested data to the requesting service. Note that token supplied by the registry automatically mean high access rights, as many requests will be open without limitations to other services, so try to protect those auth tokens inside the services.