Microservices Design Patterns

This section talks about design patterns associated with implementing microservices.

Edge Server

Problem

In a system landscape with multiple microservices, it is desirable to expose some microservices outside of the platform and hide the others from external access.

../../_images/EdgeMicroservice.png

The Edge Server / Edge Microservice design pattern

Solution

  • We only expose the edge microservice as a service externally. In Kubernetes, we can define this as a loadBalancer node which operates at Layer 7 {HTTP(S)} of the OSI stack.

  • All internal communication is handled through internal microservice names. With Kubernetes, this is done by defining the network policyTypes as ingress and / or egress. Whitelisted rules and explicity specified so that all other traffic is blocked.

  • Externally exposed services must protect against malicious requests by using best practices such as OAuth, JWT tokens and API keys to ensure that clients are trustworthy.

Distributed Tracing

Problem

  • Incoming requests get handled by different microservice instances and logs are consolidatedfor all running instances mean that all such requests may look the same.

  • There must be a way to track such reuests and messages that flow between microservices while processing an external request to the platform.

Solution

  • To track processing between cooperating microservices, we need to ensure that all related requests and messages are marked with a common correlation ID and that the correlation ID is part of all log events.

  • Based on a correlation ID, we can use the centralized logging service to find all related log events for that request. If the log even also includes business related identifiers such as the ID of a customer, product or order, we can fnd all related log events for that business identifier using that correlation ID.

Circuit Breaker

Problem

  • A platform containing multiple microservices that uses synchronous intercommunication can be expoed to a chain of failures. If one microservice stops responding, its clients might get into problems as well and stop responding to requests from their clients.

  • This problem can propagate recursively throughout a system landscape and take out major cooperating microservices.

Solution

  • Open the circuit and fail fast (without waiting for a timeout) if problems with the service are detected.

  • Probe for failures (also know as half-open circuit); allow a single request to go through on a regular basis to check whether the service is operating normally again.

  • Close the circuit if the probe detects that the service is operating normally again. This makes the set of cooperating microservices more reslient to these kinds of problems, i.e. they are self-healing.