- A microservice using orchestration will make one or more explicit calls to external services or dependencies.
- The calls typically use a synchronous request-response flow and will often access REST-based services.
- If the services need to be called in a specific order, calls to a subsequent service are not made until a response is received for a call to a prior service.
- Because one service explicitly calls another, they are tightly coupled.
- The Portfolio microservice has dependencies on the Accounts and Quotes microservices, which need to be deployed in the test environment along with the Portfolio microservice, but the team that is building the Portfolio microservice may not be the team building the other two microservices.
- The Quotes service has a dependency on a 3rd-party service to retrieve real-time stock prices, and the data returned by that service is always changing. To make a stable test for the Portfolio service, the data returned by the Quotes microservice needs to be constant.
- Unexpected behaviors of the Portfolio service need to be tested, such as when the Accounts and/or Quotes services are unavailable, respond slowly, or respond with unexpected data. It is important to be able to make those services respond with different kinds of unexpected behavior to validate that the Portfolio microservice handles the error conditions properly.
Recommended solutions: A service virtualization solution such as Parasoft Virtualize.
Reactive (choreography) pattern
- One of the primary goals of a microservices architecture is to create independent components.
- As a result, deploying, scaling, and updating the services will be easier.
- This goal is not completely realized, however, when using the orchestration pattern because individual microservices have direct dependencies on other microservices.
- A way to solve this is to use the choreography pattern, also known as “reactive” or “event-driven” microservices.
- In this pattern, microservices do not directly reference each other. Instead, they push messages onto event streams to which other microservices have subscribed.
- The asynchronous communication in this type of architecture introduces the benefit that the services are highly decoupled from each other – instances of each service can get replaced, redeployed, or scaled without the other microservices caring about them.
- The tradeoff is that the asynchronous nature of the events makes it harder to understand how the system will execute and what the flow of events will be. Depending on the order or kind of events that are produced, the system could behave in unexpected ways. This is known as emergent behavior, an inherent challenge in the development and testing of choreographed microservices.
There are different asynchronous messaging patterns that fall under the broader category of event-driven microservices.
- Asynchronous command calls
RabbitMQ custom transport from Parasoft Marketplace
Kafka custom transport from the Parasoft Marketplace