Microservices Patterns

Microservices Patterns

8 Core Components are Microservices Architecture

Service Discovery

·                A service registry that helps services locate and communicate with each other.

Load Balancer

·                A component that distributes incoming requests to the appropriate service instances.

API Gateway

·                An entry point for client requests that routes requests to the appropriate microservices, performs authentication and authorization and handles other tasks such as caching and request-response mapping.

Service Registry

·                A database of all available microservices, their endpoints, and metadata.

Circuit Breaker

·                A mechanism that helps prevent cascading failures by interrupting communication between services when one service is not responding.

Service Monitoring

·                A system that tracks the health and performance of microservices and generates alerts in case of failures or performance degradation.

Service Orchestration

·                A layer that coordinates communication and interactions between microservices to ensure that they work together correctly.

Configuration Server

·                A centralized repository for storing configuration information that is accessible to all microservices.

 

Microservice Synchronous Call:

API Gateway Pattern

• Sits between client and multiple backend services and manages routing to internal MS.
• API gateway can handle.

o    (Cross-Cutting Concern) authentication/authorization/Protocol conversion/ rate limiting/Monitoring/Load balancing.

o    Centralize features at single place rather than every MS.

o    It also aggregates multiple MS and compiles as a single response.

• Single point of entry
• Aggregate multiple MS to the client applications
• Single endpoints expose to client.
• Working as a Routing request and reverse proxy

·       There is multiple API gateway patterns

o    Gateway Routing Pattern

o    Gateway aggregation pattern

o    Gateway offloading Pattern

 Gateway Routing Pattern

• Routing Microservice calls to internal MS.
•  Route requests to multiple MS by exposing a single endpoint.
• Multiple MS exposes through Single Endpoint & route them to internal backend MS based on the request.
• Gateway Service endpoint will configure internal MS.
• Client can call multiple MS through Single endpoints.
• No impacts if any changes to any behind MS

 

 Gateway aggregation pattern

• It aggregates multiple Individual MS (internal MS) into a single request to client.

o    In this case for one use case client needs to perform multiple calls to different MS to build the response.

o    Aggregate patterns do the orchestration of MS response into Single output and based on client request it send the response back to Client.

• Multiple MS exposes through Single Endpoint
• Gateway Service endpoint will configure internal web services.
• The client can call Single use case (using multiple MS) through Single endpoints.
• No impacts if any changes to any behind MS
• avoid network calls and latency.
• Single point of failures is drawback.

Gateway offloading Pattern

• It combines commonly used functions/features into proxy services (into API Gateway)

o    (Cross-Cutting Concern)

ü  authentication/authorization

ü  Protocol conversion

ü  rate limiting

ü  Monitoring

ü  Load balancing

ü  Logging

ü  SSL certification.

• Single point of implementation as MS
• Individual MS will be not taken pain to implement these features.
• Its usage in API gateway to only public endpoint will be expose.
• Gateway will authenticate client request and other features as needed.
• avoid network calls and latency.
• Make sure highly resiliency and scalability.

Benefits for API Gateway:

·       The main benefit of this gateway aggregation pattern is to reduce chattiness communication between

·       Another main benefit is cross-cutting concerns and gateway offloading.

·       API Gateway can aggregate multiple internal microservices into a single client request.

·       This routing feature provides to decouple client applications from the internal microservices, so it is separating responsibilities on network layer.

·       API gateways provide abstraction over the backend microservices.

 

Working of API Gateway

·       API Gateway validates the incoming request after that API gateway check.

·       The IP address is into IP Allow listing or not. , API Gateway can provide allow listing and deny listing for IP based protections.

·       After that API gateway passes to the request the passes request to do identity provider, In order to perform authentication and authorization. API Gateway receives an authenticated session. From the identity provider with validating token information.

·       After that API gateway checks the rate limiting based on the IP address and headers for the authenticated

·       session.

o    In example:

§  API Gateway can reject requests from an IP address exceeding a certain rate.

·       And after that API gateway routing request to internal microservices with the Service Discovery feature,

·       it performs route matching and redirect requests to the specific microservices.

·       API Gateway also transforms requests to appreciate protocol for internal microservices with protocol

  BFF (Backend for frontend) Pattern

• Separate API gateway per specific frontend applications 
• (Cross Cutting Concern) authentication/authorization/Protocol conversion/ rate limiting/Monitoring/Load balancing/logging/SSL certification
• Multiple API Gateway as per client applications (Mobile/Web-based/ etc)
• Single point of implementation as MS
• An API Gateway call multiple MS API for specific front end and similarly other API Gateway can call same MS for different frontend applications. 
• API can be tailored based on front end needs as well and those APIs can only serve those purpose.
• Avoid single point of failure.
• Based on client type API Gateway will be configured to support MS call.

 

Benefits:

This is the client focused interfaces and provide minimal logic on the front-end code and streamline. The data representation. It has well focused interface for the front-end client application. With applying Backend for Frontend API Gateways, client could become very easy and manageable, and every client has data focused, retrieve operation from the Backend for Frontend API Gateways.

 

Drawback:

The main drawback is increased latency. Since adding additional layer into your network architecture, it become with increased latency and it is good for large scale microservice applications, which has several client applications.

Service Aggregator Pattern

• get the request from client or from API Gateway
• Gateway pass request to Service aggregator 
• Build Service aggregator which will call other MS and aggregate those data and send response back to API Gateway or Client 
• Aggregator Service request data from Several different MS 
• Centralized logic into a specialized MS
• Increase coupling and latency between Micro service.

Service Registry Pattern / Discovery Pattern

• MS should register to Service registry.
• Due to Scaling and changing IP addresses, endpoints will keep changing.

o    Service location will keep changing.

o    to avoid fixed endpoints, MS should be registered in the registry.

• Provide register and discover MS in the cluster.

·       the service discovery pattern uses a centralized server for service registry to maintain a global view of microservice network locations and microservices update their locations in the service registry at fixed intervals.

• get the request from client or from API Gateway
• API Gateway pass request to Service discovery (based on IPs)
• Get MS endpoint with updated location (IPs) 
• API gateway will call/route to individual MS.
• Any new MS should be registered into Registry. Every MS should be registered before exposing to client.
• Centralized logic into an API Gateway 

 

There are 2 main source discovery patterns available to implement service discovery for microservices,

o    client-side service registry,

o    server-side service registry.

 

There are 3 participants in the service discovery pattern.

o   Service Registry

o   Client / Consumers,

o   Microservices.

 

Note:

-        Netflix provides a service discovery pattern called Netflix Eureka and available for the Spring Boot Java applications.

-        The container orchestrator systems automatically handle to service discover operation itself.

o    For example:

§  Kubernetes has a service definition that basically performs all these tasks after definition of the Kubernetes service component.

 

 

 

Materialized View Pattern 

• MVP, Store its own local and denormalized copy of data in MS DB
• MS should have table contains a denormalized copy of data from other MS.
• eliminates expensive cross service calls. 
• these tables are only read purpose / Read Model
• It supports entire operation with Single process.
• example:

o    MS name is X and it needs some data from another MS called Y

o    Get Y MS tables and move under X MS 

o    These Y MS tables in X MS is always be read purpose and will get updates from Y MS timely manner.  

• Use eventual Consistency read tables will be updated time to time. 
• This pattern reduced the coupling and improved the reliability and response time with reducing latency.

CQRS (Command query, Responsibility and Segregation) Pattern

• Order to avoid complex queries to get rid of heavy Joins.
• Separate read and write operation with separating database. 
• Reading and writing database will have different strategy to handle the request to support large volume of data. 
• to avoid lock on database while updating or adding any data into the tables.
• Separate DB for single MS 
• Any write operation will go to write database. 
• Any read operation will go through read database. 
• Keep synch both databases. 
• Published an event from write DB which will be subscribe by read DB and update the delta data (eventual consistency).
• May be NoSQL and SQL database for different purpose. 
• where NOSQL as de-Normalized DB
• and SQL as Normalized DB 

 

 

Benefits

·       Scalability: when we separate read and write databases, we can also scale these databases separately and independently. Read databases follows the denormalized data to perform complex join queries and also complex business logic is goes into the write database with this separation system query performance is increases.

·       Performance: Implementing CQRS improves the application performance for all aspects.

·       maintainability and flexibility: Benefit of the CQRS is flexibility of system that is better evolve over time.

 

Drawback:

·       Complexity: CQRS makes your system more complex design.

·       Eventual consistency: When we separate the read and write databases, the read data may be stay old and not updated for a while.

 

SAGA Pattern

• Manage data consistency across MS in distributed transaction cases.
• Creates a set of transaction that updates MS sequentially and publish an event to triggers the next transaction for next MS.
• if one of the steps failed it triggers rollback transaction.
• It involves multiple MS which is series of local transaction that worked together to achieve one of the use case
• Either overall transaction completions or each individual transaction should rollback to initial state
• Each MS have own tables and DB so performing each step and doing some transaction for specific MS and move to next either REST call or triggers and event for successive MS.
• Two types of SAGA patterns
• Choreography SAGA
• publish an event using Message Broker 
• One MS perform task and publish an event and successive MS will subscribe these events and do the needful and so on until transaction completed. 
• Orchestration SAGA
• Create an Orchestration MS
• This Orchestration MS will communicate each MS and collect data and build single response.

GraphQL:

 

GraphQL is a query and manipulation language for APIs and runtime for fulfilling queries with your existing data. GraphQL was developed internally by Facebook in 2012 before being publicly released in 2015. GraphQL allows clients to define the structure of the data required, and the same structure of the data is returned from the server.

GraphQL provides a complete and understandable description of data in our API and gives client the power of to ask for exactly what they need and nothing more.

 

GraphQL provides access many resources in a single request, reducing the number of multiple network calls and bandwidth requirements. It enables to developers ask for exactly what is needed and get back predictable results.

GraphQL use HTTP protocol is the same as the Rest API, but GraphQL uses HTTP POST method when querying data. If you look at the characteristics of GraphQL, the first characteristic is asked for what is needed, get exactly that. Send a GraphQL query to API and get exactly as requested. GraphQL queries always returns predictable results. Characteristic is getting many resources in a single request. While Rest API required loading from multiple urls, GraphQL APIs, get all the data for application needs in a single request.

 

GraphQL Core Concepts

·       A GraphQL schema is made up of object types that define which kind of object can request and which fields. Clients send the queries, GraphQL validates the queries against the schema, then execute the validated queries.

·       Resolver is a function that attaches to the fields in a schema. During the execution, the resolver is called to produce the value.

·       Mutation is a GraphQL operation that allows you to insert new data or modify the existing data on the server side.

Advantages:

GraphQL is faster than other communication APIs like Rest API because it reduced to multiple calls.

 

Disadvantage

GraphQL query is very complex. GraphQL has just a simple query language. When a query requested, the server performs database access. When access multiple fields in one query. It may request too many nested fields data at a single time. That could cause performance problems to avoid recursion queries. Can not cached data through GraphQL.

Option 1 –

There can be only 1 GraphQL schema that works as API Gateway proxy which can route the request to the targeted microservices and coercing their response. Microservices still would use REST / Thrift protocol for communication though.

Having 1 GraphQL Schema as an API Gateway will have a downside where every time you change your microservice contract input/output, must change the GraphQL Schema accordingly on the API Gateway Side.

Option 2 –

To have multiple GraphQL schemas one per microservice. Having a smaller API Gateway server that route the request to the targeted microservice with all the information of the request + the GraphQL query.

Using Multiple GraphQL Schema per microservices, make sense in a way because GraphQL enforces a schema definition, and the consumer will need to respect input/output given from the microservice.

gRPC

there are 2 types of APIs when designing synchronous communication in microservice architecture. It transports binary messages.

·       Public APIs.

o    Public APIs should be aligned with the client request, and client can be web browser or mobile. public API should use Restful APIs over the HTTP protocol application request.

·       Backend APIs.

o   Backend APIs must consider network performance instead of easily readable JSON payloads. When it comes to backend APIs, inter service communication can result in a lot of network traffic. For that reason, serialization speed and payload size become more important. Backend APIs, support these protocols and binary serialization.

 

 

A problem during communicating with backend API, the problem is inter-service communication makes heavy load on network traffic. network performance happened during inter service communication and backend communication and real time communication can bring down overall application performance. Business teams decide performance and streaming requirements.

 

For example:

Client request to backend microservices, but that microservices requires to call another microservices internal of the microservices. Adding item into shopping cart that need to calculate with up-to-date discount information. Shopping cart microservices expose API to the client When the client invokes this API to adding item into a shopping cart. Shopping cart microservices goes to invoke discount microservices to get latest discount information before adding items into shopping cart to calculate latest prices.

 

 

 

what is the best practice to using this communication: -

The best practice is to use Rest API between the client and the server, and which is the Public APIs and use gRPC between inter service communication to be performant. Use gRPC APIs, which is a scalable and fast API and able to develop different technologies with RPC framework. This will be also technology agnostic.

 

gRPC is an open-source remote procedure call system, initially developed at Google. gRPC is a framework to efficiently connect services and build distributed systems. It is focused on high performance and uses the HTTP/2 protocol to transport binary messages. It is relying on the protocol buffer language to define service contracts. Protocol buffers also known as protobuf, allows you to define the interface to be used in service-to-service communication regardless of the programming language. It generates cross-platform client and server bindings for many languages.

 

Most common usage scenarios include connecting services in microservice style architecture and connect mobile devices, browser clients to backend services. The gRPC framework allows developers to create services that can communicate with each other efficiently and independently from their preferred programming language. Once define a contract with Protobuf file, this contract can be used by each service to automatically generate the code that can set up the communication infrastructure. This feature simplifies the creation of the service interactions and together with high performance, makes gRPC the ideal framework for creating microservices and communicating between inter service communications.

How it works

gRPC, a client application can directly call a method on a server application on a different machine like it is a local object. It's making it easier for you to build distributed applications and services. As with many RPC systems, gRPC is based on the idea of defining a service that specifies methods, and these can be called remotely with their parameters and return types.

 

On the server side, the server implements this interface and runs a gRPC server to handle client calls. On the client side, the client has a setup that provides the same methods as the server gRPC client, and servers can work and talk to each other in a different of environments from servers to your own desktop applications, that can be written in any language that gRPC supports.

 

gRPC server, written by the C++ service, and 2 gRPC clients which are written with Ruby and Java client, and these are the client applications. Create gRPC server in Java or C-sharp with the clients in Go, Python or Ruby, all different applications can communicate over the pro to request which have defined into protobuf files.

-        Proto Request

-        Proto Response

 

 Tech Stack for Microservices:

·       Front end applications,

o    Angular,

o    Vue

o    React JS.

 

·       API gateway technology choices.

o    Kong Gateway,

o    Tyk API Gateway,

o    Express API Gateway

o    Amazon API Gateway

o    APIGEE

 

·       Technology choices for service discovery.

o    Netflix Eureka: if we deploy our microservices on the container orchestrator.

o    Kubernetes: handle service Discovery operation

o    Serverless Orchestration: handle the service discovery with creating containers in the same availability zones.Microservices Patterns

Microservice Asynchronous Call: