Below are the topics we are going to cover in this Microservices Architectural Patterns series
Part 1 Microservices Introduction, microservice template, communication, Service Registry and Discovery
Part 2 Microservice Database patterns and Orchestrator vs choreography
Part 3 Fault tolerance and monitoring
What are microservices ?
Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are
- Highly maintainable and testable
- Loosely coupled
- Independently deployable
- Parallel development and also promotes the scalability
Microservices are the true example for the SAR ( Single responsibility principle )
Key terms in a microservice architecture
Microservice template, microservice registry, discovery, API composition, Event sourcing, Two-Phase Commit, Saga, Circuit breaker
Microservice template : Template contains the project structure along with cross-cutting concerns like Logging, Metrics and connection setup like DB or a messaging brokers
Just a note, it is not necessary to have same project structure or same tech stack. each team can choose their own stack depends upon the requirement
Communication
How these services are communicate with each other?
- RPI - Remote procedure invocation
Using Rest API, gRPC, Apache Thrift microservices can communicate with each other
- Asynchronous Message-Based Communication - The communication between micro services will happen through a Message bus This commination can be achieved through any
message brokers technologies like RabbitMQ or Kafka - Domain-Specific Protocols: Also called as a custom protocol there are numerous domain-specific protocols including:
Email protocols such as SMTP and IMAP Media streaming protocols such as RTMP, HLS, and HDS
Registry :
Before a microservice sends a request to other microservice, it must be aware of the available instances and network location. Ideally, the number of instances of each microservice may be scaled dynamically to adjust the changes in load.
On each service startup, shutdown and on regular intervals microservice registry keeps track of this information.
If one service wants to communicate another, the route will be decided by the registry dynamically. So application code or in-app database no need to maintain other services network location or app id's
How it works
Discovery
it is classified into two types
Client-side discovery : In Client-side discovery Microservice will directly query the service registry to get another service network location and available instances etc.
Server-side discovery: Here, the microservice queries the Load-balancer to get the details of another service. Internally load-balancer call's the registry to get the corresponding information