Category: microservices Design Patterns

Microservices Design Patterns – Circuit Breaker ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. These services often interacts with other microservices. Now there is always a possibility that a service is overloaded or unavailable. In such a case the caller service will also wait. If multiple services are getting blocked then it will hamper the performance and can cascade the impact on overall application. Now, how to prevent a service failure or network failure from cascading to other services. If one service is down then it should not be given further requests. Solution We can use circuit breaker pattern where a proxy service acts as a circuit breaker. Each service should be invoked through proxy service. A proxy service maintains a timeout and failures count. In case of consecutive failures crosses the threshold failures count then proxy service trips the circuit breaker and starts a timeout period. During this timeout period, all requests will failed. Once this timeout period is over, proxy service allows a given limited number of test requests to pass to provider service. If requests succeed the proxy service resumes the operations otherwise, it agains trips the circuit breaker and starts a timeout period and no requests will be entertained during that period. Print Page Previous Next Advertisements ”;

Service Discovery ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. These services often run in containerized/virtual environments and their number of instances and location changes dynamically. So we require a mechanism to enable client of a microservice to make requests to dynamically changing service instances. Solution We can use Service Discovery pattern. To implement this pattern, we need a router/load balancer running at a particular fixed location and a service registry where all microservice instances are registered. Now a client makes a service request, it will come to the load balancer which then inquires the service registry. If service instance is available, then the request is redirected to the available service instance. Print Page Previous Next Advertisements ”;

Microservices Design Patterns – Health Check ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. Now in case a database is down or cannot afford more connections then a monitoring system should raise alerts. Loadbalancer/service registry/api gateway should not redirect any request to such failed service instances. So we need to detect if a running service instance is able to take request(s) or not. Solution We can add a health check point to each service e.g. HTTP /health which returns the status of service health. This endpoint can perform the following tasks to check a service health − Connections Availablity − Status of database connections or connections to infrastructure services used by current service. Host Status − Status of host like disk space, cpu usage, memory usage etc. Application specific logic − business logic determining service availablity. Now a monitoring service e.g. load balancer, service registry periodically invokes the health check endpoint to check the health of the service instance. Print Page Previous Next Advertisements ”;

Distributed Tracing ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. Requests often span multiple services. Using external monitoring, we can check overall response time and no. of invocations but how to get insight on individual transactions/operations. A service may use databases, messaging queues, event sourcing etc. How to track scattered logs across multiple services? Solution We can instrument a service which is designed to perform the following operations − Corelation ID − Generate a unique external request id per external request and pass this external id to each service involved in processing the request. Log the Corelation ID − Each log message generated by processing service should have this correlation id. Record the Details − Records the start/end time and other relevant details in logs when a request is processed by a service. Searchable Logs As logs should be placed at a centralized location, following diagram showcase how to use Kafka, LogStash and Kibana to aggregate logs and search the indexed logs using required filters. Microservices generates logs, which are published using kafka log appender which then output the log messages to kafka cluster. LogStash ingests the messages from kafka, transforms the messages and publish to elastic search container. Now kibana provides a visual interface to search/read indexed logs from elastic search container and provides required filters. Print Page Previous Next Advertisements ”;

Microservices Design Patterns – Saga ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment and if we”ve used a database per service design pattern then how to implement a transaction which spans multiple services. Solution We can use Saga Pattern. A saga is a sequence of local transactions. In this pattern, each transaction updates the database and triggers an event or publishes a message for next transaction in saga. In case, any local transaction fails, saga will trigger series of transactions to undo the changes done so far by the local transactions. Consider an example of order service and customer service. Order service can make an order and then ask customer service if credit limit is crossed or not. In case credit is crossed, the customer service will raise an event to order service to cancel the order otherwise to place the order successfully. In order to implement this pattern, we often need to Choreography based saga or Orchestrator based saga. In choreography based saga, services handles the domain events during local transactions and either complete the transaction or undo the same while in orchestrator based saga, an orchestrator object handles events during local transactions and then tell coordinate which local transaction is to be executed. Print Page Previous Next Advertisements ”;

Decompose By Subdomain ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service should be developed independently in agile manner to enable continous delivery/deployment. When a large, complex application is to be built using microservice architecture, the major problem is how to design loosely coupled microservices or to break a large application into small loosely coupled services? Solution We can define a microservice corresponding to Domain-Driven Design(DDD) subdomains. DDD refers to business as a domain and a domain can have multiple subdomains. Now each subdomain refers to different areas. For Example − Order Management − Order Management subdomain refers to Orders. Customer Management − Customer Management subdomain refers to Customers. Subdomains can be further classified using following criterias − Core − Most important and key differentiator of an application. Supporting − Business related and are used to support the business activities. Generic − Not specific to business but are used to enhance the business operations. Example Consider an example of an Online Book Store. It can have following subdomains and corresponding microservices − Books Catalog Management Inventory Management Order Management Warranty Management Advantages Stable Architecture − As business subdomains are stable, this architecture is highly stable. Cross-functional Teams − Development Teams works independently, are cross-functional and are organized around functional features instead of technical features. Loosely Coupled Services − Developed services will be loosely coupled and cohesive. Dis-advantages Need good understand of Business − Business subdomains needs be indentified after understanding the business. Understanding organizational structure can help as organizations are structured based on their capabilities. High Level Domain Model needed − Business domain objects required as they corresponds to business subdomains. Print Page Previous Next Advertisements ”;

Performance Metrics ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. How to analyze and troubleshoot application problems. How to track application performance and check bottlenecks. How to tracking mutiple services with minimum runtime overhead? Solution We can implement a instrumentation service which will be responsible to gather statistics about individual operations and a central metrics service which should aggregates metrics and provides the reporting and alerting. These services can collect the performance metrics in two ways − Push − A services pushes the metrics to central metrics service. Pull − The central metrics service pulls the metrics from the services. Examples Following are the examples of Instrumentation libraries − Java Metrics Library − A Java library to get insight into what code does in production. Prometheus client libraries − Prometheus libraries to monitor services. Following are the examples of Metrics Aggregation libraries − Prometheus − An open-source systems monitoring and alerting toolkit. AWS Cloud Watch − AWS resources and service observability and monitoring service. Print Page Previous Next Advertisements ”;

Microservices Design Patterns – Overview ”; Previous Next Microservice is a service-based application development methodology. In this methodology, big applications will be divided into smallest independent service units. Microservice is the process of implementing Service-oriented Architecture (SOA) by dividing the entire application as a collection of interconnected services, where each service will serve only one business need. The Concept of Going Micro In a service-oriented architecture, entire software packages will be sub-divided into small, interconnected business units. Each of these small business units will communicate to each other using different protocols to deliver successful business to the client. Now the question is, how Microservice Architecture (MSA) differs from SOA? In one word, SOA is a designing pattern and Microservice is an implementation methodology to implement SOA or we can say Microservice is a type of SOA. Following are some rules that we need to keep in mind while developing a Microservice-oriented application. Independent − Each microservice should be independently deployable. Coupling − All microservices should be loosely coupled with one another such that changes in one will not affect the other. Business Goal − Each service unit of the entire application should be the smallest and capable of delivering one specific business goal. To apply these principles, there are certain challenges and issues which must be handled. Microservices Design Patterns discusses those common problems and provides solutions to them. In coming sections, we”ll discuss the problems and the solution using the applicable design pattern. Design Patterns relevant for Microservices are grouped into five major categories. Decomposition Design Patterns − A application is to be decomposed in smaller microservices. Decomposition design patterns provides insight on how to do it logically. Integration Design Patterns − Integration design patterns handles the application behavior in entirety. For example, how to get result of multiple services result in single call etc. Database Design Patterns − Database design patterns deals with how to define database architecture for microservices like each service should have a seperate database per service or use a shared database and so. Observability Design Patterns − Observability design patterns considers tracking of logging, performance metrices and so. Cross Cutting Concern Design Patterns − Cross Cutting Concern Design Patterns deals with service discovery, external configurations, deployment scenarios etc. Print Page Previous Next Advertisements ”;

Discuss Microservices Design Patterns ”; Previous Next Microservice is a service-based application development methodology. In this methodology, big applications will be divided into smallest independent service units. Microservice is the process of implementing Service-oriented Architecture (SOA) by dividing the entire application as a collection of interconnected services, where each service will serve only one business need. In this tutorial, we”ll cover all the important design patterns while using/developing the microservices which helps in solving the common problems developers/users face in a microservices based architecture. Print Page Previous Next Advertisements ”;

Microservices Design Patterns – Aggregator ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. When a large, complex application is to be built using microservice architecture, we often need to get the combined result of multiple microservices and show on the application. Solution We can define an Aggragator as a simple web module will act as a load balancer, which means it will call different services as per requirements. Following is a diagram depicting a simple microservice web app with aggregator design. As seen in the following image, the “Aggregator” is responsible for calling different services one by one. If we need to apply any business logic over the results of the service A, B and C, then we can implement the business logic in the aggregator itself. An aggregator can be again exposed as another service to the outer world, which can be consumed by others whenever required. While developing aggregator pattern web service, we need to keep in mind that each of our services A, B and C should have its own caching layers and it should be full stack in nature. Print Page Previous Next Advertisements ”;