MicroServices Components
Service Registry and Discovery
To maintain coordination among the Microservices and it is essential to locate the respective Microservices timely using the Service Registry and Service Discovery, respectively.
Service Registry holds the location instances that could be used to find the available Microservices to fulfill the task.
Service Discovery mechanisms find the available Microservices using the details in Service Registry. Client-Side Discovery and Server-Side Discovery are two mechanisms of Service Discovery that are used by different Microservices Applications.
Communication in Microservices
In Microservices Architecture, the Microservices communicate with each other using messaging, using a lightweight and straightforward mechanism. There are Synchronous and Asynchronous messaging techniques and several message formats that the Microservices could follow to communicate depending upon the purpose and requirements.
Synchronous Messaging Techniques:
It has two messaging techniques, one is REST and another one is RPC(Remote Procedure Call).
- REST is one of the highly preferred synchronous messaging techniques used by the Microservices.
- RPC can be used as an alternative to the REST messaging technique.
Asynchronous Messaging Techniques:
In cases where an immediate response is not required Asynchronous messaging techniques such as AMQP, STOMP, or MQTT can be used.
- AMQP is a binary, flow-controlled communication protocol that has encryption.
- STOMP is a lightweight and straightforward text-oriented messaging protocol, that provides an interoperable wire format, enabling its clients to communicate with the message broker.
- MQTT, on the other hand, provides publish and subscribe messaging without any queues, which can serve efficiently on resource-constrained devices and low bandwidth, high latency networks such as dial-up lines and satellite links.
Message formats such as JSON, XML, Thrift, Avro or ProtoBuf could be used for communication in Microservices
Integration of Microservices
As the individual Microservices serve different tasks that come within their scope, to realize a business use case, several Microservices have to coordinate and deliver the desired result in a combined effort.
Thus, there has to be inter-service communication using a lightweight message bus or gateway that involves minimal routing without any business logic to avoid complexity within the architecture.
There are different ways in which the inter-services communication takes places, depending upon the requirements and frequency of communication.
Point to Point Inter-services Communication
- In this method, the routing logic depends entirely on the endpoints, letting the Microservices to communicate directly.
API Gateway Inter-services Communication
- A lightweight message gateway acts as the main entry point for all the client or consumers, where the standard and non-functional requirements are addressed at the portal itself.
Message Broker Inter-services Communication
- Asynchronous messages with one-way requests and publish-subscribe approach are queued to connect the different Microservices as per the business logic.
Data Management in Microservices
Each of the Microservices holds their data individually using separate Databases, unlike the Monolithic Applications that have a centralized database, making each of the Microservices utterly independent of each other.
This means each of the Microservices is solely responsible for their Data Integrity, which might raise concerns regarding the consistency. These concerns over Data practice consistency can be addressed by formulating standard protocol and compliances that are to be uniformly practiced across the fleet of Microservices.
Deployment of Microservices
Deployment is very crucial for the functioning of Microservices.
You can use Docker to deploy the Microservices efficiently. Each of the Microservices can be further broken down in processes, that can be run in separate Docker containers. These can be specified with Dockerfiles and Docker Compose configuration files.
You can use provisioning tool such as Kubernetes to manage and run a cluster of Docker Containers across multiple hosts with co-location, service discovery and replication control feature making the deployment powerful and efficient in case of large scale deployments.
Kubernetes defines resources as Objects such as Pods, Services, Volumes and Namespaces.
Pod, which is the basic unit in Kubernetes consists of one or more containers that are co-located on the host machine and share the same resources. These pods have a unique IP address and can see other seeds within the cluster.
Service combines a set of pods that work together inside a cluster. Service is generally not exposed outside the cluster except onto an external IP address outside the group using one of the behaviors: ClusterIP, NodePort, LoadBalancer, and ExternalName.
Volumes are the persistent storage that exists for the lifetime of their respective pods, that are mounted at specific mount points within the container. These are defined by the pod configuration, which cannot be installed onto or link to other volumes.
Namespaces are non-overlapping sets of resources which are intended to be used in environments with many users that are spread across multiple teams, projects, or environments.
Replication and scaling in Kubernetes is done by running a specified number of a pod’s copies across the cluster using a Replication controller, that also takes care of the pod replacement.