net microservices interview questions

If you are interested in becoming a Microservices developer, practice for your interviews using these top Microservices interview questions. You can ace your Microservices interview and land a job as a Microservices Developer by using these interview questions on Microservices that our experts have put together. Prepare yourself to respond to inquiries about the fundamentals of microservices, automation in microservices-based architecture, how Docker functions in microservices, etc. Prove yourself as a Microservices expert in your next interview!.

An application is structured using the microservices architectural style, which consists of a group of loosely coupled, independently maintainable, testable, and deployable services that are grouped according to business capabilities.

Microservices architecture should be used if you have a business focus, want to solve a use case or a problem efficiently without being constrained by technology, want to scale an independent service infinitely, and want highly available stateless services that are simple to manage and maintain and can be independently tested.

Unit and integration tests should be used to test every aspect of a microservice’s functionality. One should also have component based testing.

Contract tests should be used to claim that the client’s expectations are not being violated. However, given that they can be time-consuming, only the critical flows should be tested in the microservices’ end-to-end tests. Consumer-driven contract tests and consumer-side contract tests are two possible types of tests.

A combined view of persisted data can be obtained by using Command Query Responsibility Segregation to query multiple databases.

Dependent services find it challenging to update in-flight in a cloud environment where docker s are dynamically deployed on any machine or IP + Port combination. Service discovery is created due to that purpose only.

One of the microservices architecture’s services, service discovery, registers entries for all the services running within the service mesh. All of the actions are available through the REST API. Therefore, as soon as the services are operational, each service registers itself with the service discovery service, which keeps a heartbeat to ensure that the services are still operational. That also serves the purpose of monitoring services as well. Additionally, service discovery aids in fairly allocating requests among the services that have been deployed.

In this architectural pattern, clients connect to the service registry and attempt to fetch data or services from it rather than directly connecting to the load balancer.

Once it has all the necessary data, it performs load balancing on its own and contacts the necessary services directly.

When there are multiple proxy layers and delays are occurring as a result of the multilayer communication, this may be advantageous.

When performing server-side discovery, the proxy layer or API Gateway subsequently tries to connect to the service registry and then calls the pertinent service. The client connects to the API Gateway or proxy layer over here.

A scalable, distributed, and highly automated system can be created using the microservices architecture, which consists of numerous small autonomous services. It is a new trend that resulted from SOA rather than a technology.

The term “microservices” cannot be fully defined by a single definition. Some renowned authors have attempted the following definition:

Around 2006, SOA first gained traction as a result of its distributed architecture approach and its development as a response to the issues with large monolithic applications.

Both of these architectures (SOA and Microservices) have high levels of scalability and are distributed architectures, which is one thing they have in common. Through the use of the remote access protocol (RMI, REST, SOAP, AMQP, JMS, etc.), service components are accessed remotely in both cases. ). Both are highly scalable, modular, and loosely coupled by design. After the introduction of lightweight containers, Docker, and orchestration frameworks (Kubernetes, Mesos), microservices began to gain popularity in the late 2000s. Microservices differ from SOA in a significant manner conceptually -.

Bounded Context is a central pattern in Domain-Driven Design. Everything pertaining to the domain in a bounded context is visible internally but opaque to other bounded contexts. DDD handles large models by breaking them up into different Bounded Contexts and being clear about how they relate to one another.

It is very difficult to deal with a single conceptual model for the entire organization. The only advantage of such a unified model is that enterprise-wide integration is simple, but there are numerous disadvantages as well, such as:

Since the decentralized teams working on individual microservices are largely independent of one another, coordination with other teams is not necessary when changing a service. This can lead to significantly faster release cycles. Realistic monolithic applications make it difficult to accomplish the same thing because even a small change could result in system regression.

The emphasis of the microservices style of system architecture is on the culture of freedom, individual accountability, team autonomy, quicker release iterations, and technology diversity.

Microservices, in contrast to monolithic applications, are not restricted to a single technology stack (Java, Net, Go, Erlang, Python, etc). Each team is free to select the technology stack that best meets its needs. We can, for instance, choose Java for one microservice, C++ for another, and Go for a third.

The words “operations” and “development” were combined to form the term. Effective communication and cooperation between the product management, software development, and operations teams are prioritized in this culture. If properly implemented, the DevOps culture can result in shorter development cycles and faster time to market.

Utilizing various databases for various business needs within a single distributed system is what polyglot persistence is all about. We already have a variety of database products available on the market, each designed to meet a particular business need, such as:

When a need is documents-oriented, a database called “documented oriented” is used. g. Product Catalog). Documents don’t have schemas, so the application can easily adapt to changes in the schema.

Key-value pair based database (User activity tracking, Analytics, etc. ). DynamoDB can store documents as well as key-value pairs.

The user session tracking in memory distributed database is primarily utilized as a distributed cache by numerous microservices.

Polyglot Persistence has numerous advantages that can be reaped in both monolithic and microservices architecture. Any product of reasonable size will have a variety of requirements that might not all be satisfied by a single type of database. For instance, it is much preferable to use a key-value pair or document-oriented NoSql database than a transactional RDBMS database if a particular microservice has no need for transactions.

A recent methodology (and/or manifesto) for creating web applications that run as services is called The Twelve-Factor App.

One codebase, multiple deploys. As a result, we should only use one codebase for various microservices versions. Branches are ok, but different repositories are not.

Explicitly declare and isolate dependencies. The manifesto recommends avoiding depending on host machine software or libraries. Every dependency should be put into pom. xml or build. gradle file.

Store config in the environment. Never enter your environment-specific configuration, especially your password, into a source code repository. In a distributed system, Spring Cloud Config offers server- and client-side support for externalized configuration. You can manage external properties for applications across all environments using Spring Cloud Config Server.

Treat backing services as attached resources. No matter who manages the external services—your team or someone else’s—a microservice should treat them equally. For instance, even if the dependent microservice was created by your team, avoid hardcoding the absolute url for it in your application code. Use Ribbon (with or without Eureka) to define the url instead of hard-coding it in your RestTemplate, as in the following example:

Strictly separate build and run stages. To put it another way, you must be able to build or compile the code, then combine it with particular configuration data to produce a particular release, which you must then purposefully run. It should not be possible to alter code while it is running, for example. g. changing the class files in tomcat directly. Each version of a release should always have a distinct identifier, typically a timestamp. Release details should be unchangeable, and any modifications should result in a new release.

Execute the app as one or more stateless processes. As a result, our microservices must be stateless and not rely on any state to be present in memory or the filesystem. Indeed the state does not belong in the code. Therefore, there are no persistent sessions, in-memory cache, local filesystem storage, etc. Instead, you should use a distributed cache like memcache, ehcache, or Redis.

Export services via port binding. This relates to having your application run independently of an application server that is currently running when you deploy it. Spring Boot offers a method for producing a self-executing uber jar with an embedded servlet container (jetty or tomcat) and all dependencies.

Scale-out via the process model. In the twelve-factor app, processes are a first-class citizen. This does not preclude individual processes from managing their own internal multiplexing using the async/evented model present in tools like EventMachine, Twisted, or Node. js. As a result, the application must also be able to span multiple processes running on various physical machines since a single virtual machine (VM) can only grow so large (vertically scale). Twelve-factor app processes should never write PID files; instead, they should rely on an operating system process manager like systemd, which is a distributed process manager on the cloud.

Processes in the twelve-factor app are disposable, which means they can be started or stopped at any time. This makes it possible for production deploys to be robust, code or configuration changes to be deployed quickly, and fast elastic scaling. Processes should strive to minimize startup time. The ideal time for a process to be up and ready to receive requests or jobs is a few seconds after the launch command is executed. Rapid scaling and release processes are made more agile by quick startup times, and robustness is improved because the process manager can more easily port processes to new physical machines as needed.

Keep development, staging, and production as similar as possible. To avoid “works on my machine” issues, your development environment should be nearly identical to a production one. That said, it’s not necessary for your OS to be the one used in production. You can use Docker to logically separate your microservices.

Treat logs as event streams and send only the stdout portion of each log. Most Java Developers would not agree to this advice, though.

Run admin/management tasks as one-off processes. For instance, a database migration should be carried out entirely through a different process.

The purpose of the microservices architecture is to create large, distributed systems that can safely scale. The advantages of microservices architecture over monoliths are numerous, including:

A typical monolith eShop application is typically a large war file deployed in a single JVM process (tomcat/jboss/websphere, etc.), as shown in the example above. In-process communication techniques like direct method invocation are used by various monolithic components to communicate with one another. A monolithic application’s various components share one or more databases.

Microservices should be autonomous and divided based on business capabilities. Each software component should have single well-defined responsibility (a. k. To build highly cohesive software components, the Single Responsibility Principle (SRP) and the Bounded Context Principle (as described by Domain Driven Design) should be used.

According to its business capabilities, an e-commerce site could be divided into the following microservices, for instance:

Through an API gateway, the client application (browser or mobile app) will communicate with these services and present the user with the pertinent information.

When configuring a microservice’s bootstrap, you must set the following property if you want the service to stop when it cannot find the config-server. yml:

When the config-server cannot be reached during the bootstrap process, using this configuration will result in microservice startup failing with an exception.

By enabling a retry mechanism, a microservice can attempt something up to six times without failing. To make this feature available, we simply need to add spring-retry and spring-boot-starter-aop to the classpath.

Email and SMS notification about orders, payments, and shipments. Through the API gateway, the client application (browser or mobile app) will communicate with these services and present the user with the pertinent information.

As small as possible but as big as necessary to represent the domain concept they own is a good, if general, rule of thumb, according to Martin Fowler.

The bounded context principle and the single responsibility principle should be used to isolate a business capability into a single microservice boundary rather than size as a determining factor in microservices.

Although small services in general are considered microservices, not all small services are. If any service violates the single responsibility principle, bounded context principle, etc. then it is not a microservice irrespective of its size. Therefore, a service’s size is not the only criterion for eligibility to be a microservice.

In fact, because some languages (like Java, Scala, and PHP) are more verbose than others, the size of a microservice is heavily influenced by the language you choose.

Frequently, REST over HTTP, a straightforward protocol, is used to integrate microservices. AMQP, JMS, Kafka, and other communication protocols can also be used for integration.

Synchronous communication between two microservices can be accomplished using RestTemplate, WebClient, and FeignClient. The number of synchronous calls between microservices should ideally be kept to a minimum because they cause latency and make networks brittle. Ribbon, a client-side load balancer, can be added to RestTemplate to improve resource utilization. Hystrix circuit breakers can be utilized to gracefully handle partial failures without having an adverse impact on the ecosystem as a whole. Avoid distributed commits at all costs; instead, choose eventual consistency with asynchronous communication.

In this type of communication, the client simply sends the message to the message broker without waiting for a response. To achieve eventual consistency, asynchronous communication between microservices can be accomplished using AMQP (like RabbitMQ) or Kafka.

In orchestration, we depend on a central system to direct and call additional Microservices in a specific way to finish a task. The main system keeps track of the overall workflow’s step-by-step order and state. Each microservice in choreography operates like a state machine and responds to input from other components. Each service is aware of how to respond to various system events. There is no central command in this case.

In a microservices architecture, orchestration is an anti-pattern because it uses a tightly coupled approach. Whereas, Choreography’s loose coupling approach should be adopted where-ever possible.

Consider creating a microservice to send fictitious e-commerce customers product recommendations. We must have access to the user’s order history, which is stored in a different microservice, in order to send recommendations.

This new microservice for recommendations will use an orchestration approach to make synchronous calls to the order service and fetch the pertinent data, and then we will compute the recommendations based on his prior purchases. The two microservices will be tightly coupled if this is done for a million users.

For the Choreography approach, the order service will publish an event whenever a user makes a purchase using event-based asynchronous communication. This event will be heard by the recommendation service, which will then begin building user recommendations. This is a loosely coupled approach and highly scalable. In this instance, the event only provides the data rather than telling about the action.

There is no correct response to this query; the frequency of releases could be every ten minutes, every hour, or once a week. The degree of automation you have at each stage of the software development lifecycle, including build automation, test automation, deployment automation, and monitoring, will determine everything. Of course, the business requirements will also depend on how few low-risk changes you are willing to make in a single release.

You can easily accomplish multiple deployments per day without significant complexity in an ideal world where boundaries of each microservice are clearly defined (bounded context) and a given service does not affect other microservices.

The development of applications in the Cloud-Native Applications (NCA) style promotes the rapid adoption of best practices for distributed software development and continuous delivery. These applications (AWS, Azure, CloudFoundary, etc.) are made specifically for cloud computing architecture.

Tools like Spring Boot, Spring Cloud, Docker, Jenkins, and Git can make it simple for you to create Cloud-Native Applications.

It is a method of building a distributed system that consists of a number of small services. Each service runs in its own process, is in charge of a particular business capability, and communicates with other services via messaging (AMQP) or the HTTP REST API.

It is a partnership between IT operations and software developers with the objective of consistently delivering high-quality software in accordance with customer needs.

Automated delivery of constant, small, low-risk production changes is everything. This makes it possible to collect feedback faster.

Containers (e. g. Since Docker provides logical isolation to each microservice, the “run on my machine” issue is permanently solved. It’s much faster and efficient compared to Virtual Machines.

Building microservices with Java is made much easier by using Spring Boot and Spring Cloud. Spring Cloud can greatly speed up the development process because it has a ton of modules that can provide boilerplate code for various microservice design patterns. Additionally, Spring Boot offers out-of-the-box support for embedding servlet containers (such as Tomcat, Jetty, and Undertow) inside executable jars (such as uber jars), allowing these jars to be run directly from the command line and negating the need to deploy war files into servlet containers.

Additionally, the entire executable package can be shipped and deployed onto a cloud environment using a Docker container. By offering logical separation for the runtime environment during the development phase, Docker can also aid in eradicating the “works on my machine” problem. This will enable portability between an on-premises and cloud environment.

With an opinionated view of the Spring platform and third-party libraries, Spring Boot makes it simple to create standalone, production-grade Spring-based applications that you can “just run,” allowing you to get started with the least amount of hassle.

By choosing the necessary dependencies for your project using the online tool located at https://start.spring.boot. spring. io/.

One client application (such as an Android app, a web app, an Angular JS app, an iPhone app, etc.) needs a single entry point to the backend resources (microservices), and API Gateway fills that need by providing cross-cutting concerns to them like security, monitoring/metrics, and resiliency.

The client application can make concurrent requests to tens or hundreds of microservices, gathering their responses and modifying them to suit its requirements. In order to distribute the load among the instances in a round-robin fashion, Api Gateway can make use of the client-side load balancer library Ribbon. It can also do protocol translation i. e. HTTP to AMQP if necessary. It can handle security for protected resources as well.

Zero-downtime deployments, as their name implies, do not cause downtime in a production environment. It is a clever method of deploying your changes to production because customers will always have access to at least one service.

One way of achieving this is blue/green deployment. This method involves simultaneously deploying two versions of a single microservice. But only one version is taking real requests. You can switch from an older version to a newer version once the newer version has been tested to the necessary level of satisfaction.

To ensure that the functionality is working properly in the recently deployed version, you can run a smoke-test suite. An updated version can be made live based on the results of the smoke test.

Let’s say that you are running two instances of the same service that are both listed in the Eureka registry. Further, both instances are deployed using two distinct hostnames:

Now, the client application that must make api calls to the books-service might resemble the following:

Now, when ticketBooks-service-green. example. When com goes offline for an upgrade, it does so politely and removes its entry from the Eureka registry. However, until the ClientApp fetches the registry once more (which happens every 30 seconds), these changes won’t appear in the ClientApp. Therefore, ClientApp’s @LoadBalanced RestTemplate may send requests to ticketBooks-service-green for up to 30 seconds. example. com even if its down.

Ribbon’s client-side load balancer has Spring Retry support, which we can use to correct this. The steps listed below must be followed in order to enable Spring Retry:

After completing this, Ribbon will automatically set itself up to use retry logic for any unsuccessful requests to ticketBooks-service-green. example. Ribbon will attempt com com again on the following available instance (in a round-robin fashion). You can customize this behaviour using the below properties:

When there are database changes during the upgrade, the deployment scenario gets more complicated. There can be two different scenarios: 1. database change is backward compatible (e. g. adding a new table column) 2. A database change won’t work with an older application version (e g. renaming an existing table column).

A realistic production app may have much higher levels of complexity; however, such discussions are outside the purview of this book.

The acronym ACID stands for the four fundamental properties—atomicity, consistency, isolation, and durability—that the database transaction manager ensures.

Either all of the records are committed in a transaction involving two or more entities, or none are.

A database transaction must adhere to certain rules, such as constraints and triggers, and only alter the data in question in permissible ways.

A database saves committed records so that they are still accessible in the event of a failure or restart of the database.

Due to the fragile and complex nature of the microservices architecture, 2 Phase Commit should ideally be avoided. In distributed systems, eventual consistency allows us to achieve some level of ACID compliance, so that should be the best course of action.

The Spring team has combined several open-source projects from organizations like Pivotal and Netflix into a Spring project called Spring Cloud. Spring Cloud offers libraries and tools to quickly build some of the prevalent distributed system design patterns, such as the following:

The development, deployment, and operation of JVM applications for the Cloud are incredibly simple with Spring Cloud.

There are some challenges that you must overcome for each individual microservice when implementing a microservices architecture. Furthermore, there can be many difficulties when people interact with one another. It also happens that it becomes simple for developers to maintain services if you foresee some of them and standardize them across all microservices.

Testing, debugging, security, version management, communication (sync or async), state maintenance, etc. are some of the most difficult tasks. Monitoring, logging, performance improvement, deployment, security, and other common issues should be standardized.

Although this is a very individualized question, I can say that it should be based on the following standards to the best of my knowledge.

Real-time downtime of one service may occur, but all other services may continue to operate as intended. Consequently, the downtime in such circumstances has an impact on the specific service and its dependent services.

The microservices architecture pattern includes a concept called the circuit breaker to address this problem. A proxy layer serves as an electric circuit breaker and can be called by any service calling a remote service. Proxy layer should fail quickly and keep checking the remote service for availability if the remote service is slow or unavailable for ‘n’ attempts. Additionally, the calling services ought to handle errors and offer retry logic. Once the remote service is restored, the services begin to function once more, and the circuit is complete.

This way, all other functionalities work as expected. Only one or the dependent services get affected.

This is related to the automation for cross-cutting concerns. Some issues, such as monitoring strategies, deployment strategies, review and commit strategies, branching and merging strategies, testing strategies, code structure strategies, etc., can be standardized.

For standards, we can follow the 12-factor application guidelines. We can achieve great productivity if we adhere to them right away. Additionally, in order to use the newest DevOps trends like dockerization, we can containerize our application. We can orchestrate docker s using mesos, marathon, or kubernetes. We can use a CI/CD pipeline to deploy our newly created codebase once the source code has been dockerized. We can include mechanisms there to test the applications and make sure we gather the necessary data to deploy the code.

We can deploy our code using techniques like blue-green deployment or canary deployment so that we can understand the effects of code that might go live on all of the servers at once. We can conduct AB tests to ensure that nothing breaks when the site goes live. We can use AWS or Google cloud to deploy our solutions and keep them on autoscale to make sure we have enough resources available to handle the traffic we are receiving while easing the burden on the IT team.

This is a very interesting question. The processing takes place in memory in a monolith where HTTP Request is waiting for a response, ensuring that all transactions from these modules operate as efficiently as possible and that everything is carried out as expected. However, it becomes difficult when using microservices because each service runs independently, their datastores can differ, and REST APIs can be set up on various endpoints. Without being aware of the context of other microservices, each service performs some tasks.

In this situation, we can take the following steps to ensure that we can quickly identify the errors

It is an important design decision. The communication between services might or might not be necessary. It can happen synchronously or asynchronously. It can happen sequentially or it can happen in parallel. Therefore, once we have decided on our communication method, we can choose the technology that works best for us.

A single session store can be used by all the microservices, and user authentication can be accomplished. This approach works but has many drawbacks as well. Additionally, services should connect securely and the centralized session store should be secured. Stateful sessions are those where the application manages the user’s state.

In this method, as opposed to the conventional method, the clients hold the information in the form of a token, which is passed along with each request. A server can examine the token and confirm its validity, including its expiration, among other things. After the token has been verified, the token can be used to determine the user’s identity. However, encryption is required for security reasons. The most widely adopted new open standard for this is JWT(JSON web token). Mainly used in stateless applications. Or, you can use OAuth based authentication mechanisms as well.

Logging is a very important aspect of any application. It is simple to support additional application features if we have implemented proper logging in the application. It becomes extremely important to log important details, for example, in order to debug the issues or in order to comprehend what business logic might have been executed.

Bundling the configuration with the microservices is not a good idea because container-based deployment only allows for one per microservice.

Due to the possibility of multiple environments and the need to manage geographically dispersed deployments with potentially different configurations, this approach is not at all scalable.

Additionally, extra caution should be used in production when an application and a cron application are both a part of the same codebase because it might affect how the crons are designed.

To address this, we can centralize all of our configuration in a config service that the application can access at runtime to learn about all of its configurations. One of the services that offers this facility is spring cloud.

Additionally, it aids in information security because the configuration may include passwords, access controls for reports, or database access controls. For security purposes, only dependable parties should be permitted access to these details.

You deal with more than just the application code and application server in a production environment. Dealing with API Gateway, proxy servers, SSL terminators, application servers, database servers, caching services, and other reliant services is necessary.

Deploying and managing these containers is very difficult and may be error-prone, just like in modern microservice architecture where each microservice runs in a separate container.

By controlling a container’s life cycle and enabling automated container deployment, container orchestration provides a solution to this issue.

Additionally, it aids in scaling the application so that a few containers can be easily brought up. whenever the application is under heavy load and when it is not It can also reduce in size by lowering the containers. It is helpful to adjust cost based on requirements.

Additionally, in some cases, it handles internal networking between services so that you do not need to exert additional effort. Additionally, it enables us to replicate or deploy Docker containers at runtime without concern for resource availability. If you configure additional resources in orchestration services, they can be made available or deployed on production servers in a matter of minutes.

An entry point for a collection of microservices is provided by an API Gateway, a service that sits in front of the exposed APIs. Additionally, a gateway can store the bare minimum routing logic for calls to microservices as well as an aggregate of the responses.

Avoid sharing databases between microservices; instead, make the change using exposed APIs.

The service that holds the data should publish messages for any changes to the data so that other services can consume them and update the local state if there is any dependency between the microservices.

If consistency is necessary, microservices shouldn’t keep local state and should instead periodically call an API to retrieve the data from the source of truth.

Due to service boundaries in the microservices architecture, it is possible that you frequently need to update one or more entities when the state of one of the entities changes. In that case, one must publish a message so that a new event can be created and added to those that have already been carried out. In the event of failure, one can repeat all the events in the exact same order to achieve the desired state. Event sourcing can be compared to your bank account statement.

You will start your account with initial money. The most recent state is then generated by individually calculating each credit and debit event as it occurs. When there are too many events, the application can create a periodic snapshot of the events to avoid having to replay every single one of them repeatedly.

In a cloud environment, servers come and go, and new instances of the same services can be deployed to handle an increasing volume of requests. Therefore, having a service registry and discovery that can be queried to determine the address (host, port, and protocol) of a specific server is absolutely necessary. Additionally, we might need to find servers for client-side load balancing (Ribbon) and graceful failover handling (Hystrix).

Spring Cloud offers a few pre-made solutions to this issue, which resolves the issue. Netflix Eureka Server and Consul are the primary two options for service discovery. Lets discuss both of these briefly:

In the AWS cloud, Eureka is a REST (Representational State Transfer)-based service that is primarily used to locate services for middle-tier server load balancing and failover. The main features of Netflix Eureka are:

Spring Cloud provides two dependencies – eureka-server and eureka-client. Eureka server dependency is only required in eureka server’s build. gradle.

To enable eureka discovery, however, each microservice must include the dependencies for the Eureka client.

For keeping track of different instances and their health in the service registry, Eureka server offers a simple dashboard. The user interface was created using Freemarker and is offered out of the box with no additional configuration. Screenshot for Eureka Server looks like the following.

All services registered with Eureka Server are listed in this document. Each server has information like zone, host, port, and protocol.

It is a REST-based tool for dynamic service registry. It can be used to locate a service, register a new service, and perform a service health check.

You can select any of the aforementioned options for your spring cloud-based distributed application. We’ll concentrate more on the Netflix Eureka Server option in this book.

You must set up three separate configuration storage projects if your project setup includes develop, stage, and production environments. So in total, you will have four projects:

The server that can be installed in any environment is the config-server. It is the Java Code without configuration storage.

It is the git storage for your development configuration. Each microservice’s configuration in the development environment will be fetched from this storage. This project is intended to be used with config-server and contains no Java code.

the central server that serves as a service registry (one per zone) All microservices register with this eureka server during app bootstrap.

Additionally, Eureka includes a Java-based client component called the eureka-client that makes using the service much simpler. Additionally, the client has an integrated load balancer that performs simple round-robin load balancing. This client must be a part of every microservice in the distributed ecosystem in order to connect to and register with Eureka-server.

Typically, each region (the US, Asia, Europe, and Australia) has a single cluster of Eureka servers that only keeps track of instances in that region. Services sign up with Eureka and send heartbeats every 30 seconds to renew their leases. In about 90 seconds, the service is removed from the server registry if it is unable to renew its lease for a few times. All Eureka nodes in the cluster receive a copy of the registration data and renewals. To find their services, which could be anywhere in the world, clients from any zone can look up registry information (which occurs every 30 seconds) and place remote calls.

Eureka clients are designed to function in the event that one or more Eureka servers fail. Since Eureka clients contain the registry cache information, they can still function somewhat even if all Eureka servers fail.

Microservices frequently need to call other microservices that are running in different processes over the network. Network calls can fail due to many reasons, including-.

Because of the blocked threads caused by the hung remote calls, this can cause cascading failures in the calling service. A piece of software called a circuit breaker is used to address this issue. The fundamental concept is very straightforward: enclose a potentially problematic remote call in a circuit breaker object that will watch for failures and timeouts. The circuit breaker trips when the failure rate reaches a predetermined level, and any subsequent calls to the circuit breaker return with an error rather than making the protected call. This mechanism gives the option to gracefully downgrade functionality while preventing the cascading effects of a single component failure in the system.

Here, a REST client makes a call to the recommendation service, which then uses a circuit breaker call wrapper to communicate with the books service. Circuit breakers trip (open) circuits when the books-service API calls begin to fail, preventing further calls to book-service until the circuit is closed once more.

Circuit Breaker encloses the initial remote calls, and if any of them are unsuccessful, the failure is recorded. The circuit breaker is in the Closed state when the service dependency is in good health and no problems are found. All invocations are passed through to the remote service.

The circuit enters the Open State if the failure count rises above a certain threshold within a given time frame. Calls always fail in the Open State without even initiating the remote call. The circuit is tripped to an open state by taking into account the following factors:

The circuit enters a half-open state after a set amount of time (defaulting to 5 seconds). Calls are once more made to the remote dependency in this state. Following that, the successful calls switch the circuit breaker back to its closed state, while the unsuccessful calls switch it back to its open state.

In Spring Cloud-powered microservices, there are two different methods for using the Spring Cloud Config client: configuration first bootstrapping and discovery first bootstrapping. Let’s discuss both of them:

Any spring boot application where the Spring Cloud Config client is on the classpath will operate by default in this manner. A configuration client initializes the Spring Environment with remote property sources when it starts up by binding to the Config Server using the bootstrap configuration property.

You can have the Config Server register with the Discovery Service and grant access to the Config Server to all clients via the Discovery Service if you are using Spring Cloud Netflix and Eureka Service Discovery.

Applications built with Spring Cloud do not have this configuration by default, so we must manually enable it using the bootstrap property below. yml.

The advantage of this strategy is that since each microservice can now obtain the configuration via the Eureka service, config-server can change its host and port without the other microservices being aware of it. The disadvantage of this strategy is that finding the service registration at app startup necessitates an additional network round trip.

When migrating functionality to a newer version of microservices, an older system is gradually decommissioned using strangulation.

Typically, one endpoint at a time is Strangled, gradually replacing them all with the newer implementation. Since we can use Zuul Proxy (API Gateway) to handle all traffic from clients of the old endpoints while only rerouting specific requests to the new ones, it is a useful tool for this.

We are /first/ strangling a few endpoints from the legacy app hosted at http://legacy/ with this configuration for API Gateway (zuul reverse proxy). example. com slowly to newly created microservice with external URL http://first. example. com.

By operating each circuit breaker within its own thread pool, Netflix’s Hystrix uses the bulkhead design pattern and implements the circuit breaker pattern. It also gathers a variety of helpful metrics regarding the internal condition of the circuit breaker, such as –

Another Netflix open source project called Turbine can be used to aggregate all of these metrics. These aggregated metrics can be seen using the Hystrix dashboard, which offers excellent visibility into the overall health of the distributed system. In the event that the primary method call fails, Hystrix can be used to specify the fallback method for execution. When a remote invocation fails, this can help with graceful functionality degradation.

It aids in containing failures by preventing cascading failures, offering acceptable fallbacks, and providing graceful service functionality degradation. It works on the idea of fail-fast and rapid recovery. To contain failures, there are two options that can be used: thread isolation and semaphore isolation.

Your application’s concurrency performance is enhanced by parallel processing, concurrent aware request caching, and finally automated batching through request collapsing.

Consider the case where we want to gracefully handle service to service failure without utilizing the Circuit Breaker pattern. A try-catch clause would be added to the REST call as the simple solution. However, Circuit Breaker accomplishes much more than try-catch can, including:

Therefore, to make our system resilient to failures, we must use the circuit breaker pattern rather than wrapping service to service calls in a try/catch clause.

Hystrix’s bulkhead implementation regulates how many concurrent calls can be made to a component or service. By doing this, the number of resources (typically threads) that are waiting on the component or service to respond is constrained.

Assume we have a hypothetical web application for online shopping, as shown in the figure below. Three different components are connected to the WebFront using remote network calls (REST over HTTP).

Let’s assume that the Product Review Service experiences a problem that causes all requests to hang (or time out), which eventually causes all threads responsible for handling requests in the WebFront Application to hang while they wait for a response from the Reviews Service. This would make the entire WebFront Application non-responsive. If there are many requests and the Reviews Service takes a while to respond to each one, the WebFront Application’s behavior would be the same as a result.

By gracefully reducing the functionality, Hystrix’s implementation of the bulkhead pattern would have reduced the number of concurrent calls to components and saved the application in this situation. Assume that there are a maximum of 10 concurrent calls to the Reviews Service and that we have 30 request handling threads overall. When calling Reviews Service, only 10 request handling threads can hang; the remaining 20 threads can continue to handle requests and use the components of Products and Orders Service. This strategy will keep our WebFront responsive even if the Reviews Service isn’t working.

To put things in perspective, one of a based system’s key features is the construction of small utilities and their connection with pipes. For instance, using the command pipeline in the Unix shell ps elf | grep java to find all Java processes in a Linux system is very popular.

A pipe is used to forward the output of the first command as an input to the second command in this case, and it serves no other purpose. like a dumb pipe, which only routes data from one utility to another based on business logic.

Martin Fowler compares Enterprise Service Bus (ESB) to ZeroMQ/RabbitMQ in his article. While ZeroMQ has no logic other than the persistence/routing of messages, ESB is a pipe that contains a lot of logic. The ESB is a fat layer that performs numerous tasks, including routing, business flow & validations, data transformations, and security checks. Therefore, ESB is a type of smart pipe that performs numerous tasks before sending data to the following endpoint (service). The exact opposite viewpoint is promoted by smart endpoints and dumb pipes, who argue that the communication channel should be devoid of any business-specific logic and should only be used to transfer messages between components. On those incoming messages, the components (endpoints/services) should perform all data validations, business processing, security checks, etc.

The principles and protocols upon which the global web and Unix are built should be adhered to by the microservices team.

There are various approaches to managing your REST API’s versioning so that older users can still access the older endpoints. A new versioned endpoint should be created whenever a REST endpoint undergoes a non-backward compatible change.

Most common approach in versioning is the URL versioning itself. A versioned URL looks like the following:

You must make sure as an API developer that only backward-compatible changes are included in a single version of URL. Consumer-Driven tests can assist in early detection of potential API upgrade problems.

It is possible to instantly update the configuration by using config-server. Only Beans with the @RefreshScope annotation declared will pick up the configuration changes.

The following code illustrates the same. Changes to the property message can be made at runtime without restarting the microservices because it is defined in the config-server.

A list of ignored exceptions can be provided using the @HystrixCommand annotation’s attribute ignoreExceptions.

If the actual method call in the example above results in an IllegalStateException, MissingServletRequestParameterException, or TypeMismatchException, Hystrix will not activate the fallback logic (reliable method), but will instead wrap the actual exception in a HystrixBadRequestException and rethrow it to the caller. It is taken care by javanica library under the hood.

Each microservice in a microservices architecture must own its own private data, which can only be accessed by third parties through service ownership. We will transgress the bounded context principle if we start sharing the private datastore of a microservice with other services.

If not implemented properly, microservices architecture can become complicated and unmanageable. Best practices can be used to create resilient and highly scalable systems. The most important ones are.

Learn about the industry in which your company operates; this is crucial. Only then will you be able to correctly partition your microservice based on business capabilities and define the bounded context.

It is typical for everything to be automated, from continuous integration to continuous delivery and deployment. Otherwise, managing a sizable fleet of microservices would be very difficult.

Maintaining a state inside a service instance is a terrible idea because we never know where a new instance of a particular microservice will be spun up for scaling out or for handling failure.

Since distributed systems will inevitably experience failures, we must design our system to do so gracefully. Failures come in many forms and must be handled as such, for instance –

We should make an effort to make our services backward compatible, and explicit versioning needs to be used to accommodate various RESt endpoint versions.

When communicating between microservices, asynchronous communication should take precedence over synchronous communication. Asynchronous messaging has many benefits, one of which is that it prevents the service from blocking while it waits for a response from another service.

If no new updates are made to a particular data item, eventual consistency, a consistency model used in distributed computing to achieve high availability, essentially ensures that all accesses to that item will eventually return the value that was most recently updated.

We should always design our services to accept repeated calls without any negative side effects because networks are fragile. To prevent the service from processing duplicate requests sent over the network as a result of network failure or retry logic, we can add some sort of distinctive identifier to each request.

Sharing is regarded as a best practice for monolithic applications, but not for microservices. Sharing violates the Bounded Context Principle, so we won’t develop any universal shared models that operate across microservices. For instance, rather than creating a large model class that is used by all services, if various services require a common Customer model, we should create one for each microservice with just the fields necessary for a specific bounded context.

It is challenging to isolate service changes as there are more dependencies between services, which makes it challenging to modify one service without affecting others. Additionally, developing a single model that applies to all services makes the model itself complex and ambiguous, making it difficult for anyone to understand the model.

When it comes to domain models, we sort of want to go against the DRY principle of microservices architecture.

Caching is a performance optimization method for getting service query results. It helps minimize the calls to network, database, etc. Caching can be used at various levels in a microservices architecture.

A great free tool for describing the APIs offered by microservices is Swagger. It provides very easy to use interactive documentation.

Swagger annotation on a REST endpoint can be used to automatically create and expose API documentation through a web interface. In order to view the list of APIs, their inputs, and error codes, an internal and external team can use a web interface. To obtain the results, they can even directly invoke the endpoints from the web interface.

For consumers of your microservices, Swagger UI is a very effective tool for explaining the range of endpoints offered by a specific microservice.

Nearly all servers and clients natively support basic authentication, and even Spring security has excellent native support for it. But there are a number of reasons why it is not a good fit for microservices, including:

Each JWT claim consists of three parts: the header, the claim, and the signature. These 3 parts are separated by a dot. The entire JWT is encoded in Base64 format.

The entire JWT is Base64 encoded to be compatible with the HTTP protocol. Encoded JWT looks like the following:

A claim part has a client_id, expiry, issuer, user_id, scope, and other attributes. It is encoded as a JSON object. You can add custom attributes to the claim. You want to exchange this information with the third party.

Typically, a signature is a one-way hash of the payload and header that is calculated using the HMAC SHA256 algorithm. Keep the password you used to sign the claim private. As an alternative to symmetric cryptography, the claim can also be encrypted using a public/private key.

OAuth2. The Client (mobile app or web app) does not need to be aware of the credentials of the Resource Owner (end-user) when using the delegation protocol 0 ().

In addition to Junit, AssertJ, Hamcrest, Mockito, JSONassert, Spring Test, Spring Boot Test, and a number of other helpful libraries, this starter will import two spring boot test modules: spring-boot-test and spring-boot-test-autoconfigure.

One of the most frequent uses of JWT is for authentication, particularly in (but not only in) microservices architecture. When a user logs in to a microservice, the oauth2 server generates a JWT, and all subsequent requests can use the JWT AccessToken as the authentication method. implementing single sign-on by distributing JWT among various applications running on various domains

Using public/private key pairs and JWT, you can verify that the senders are who they claim to be. JWT is thus a useful method for exchanging information between two parties. An example use case could be -.