51
CHAPTER 3 | Architecting container and microservice-based applications
Figure 4-15. Anti-patterns and patterns in communication between microservices
As shown in the above diagram, in synchronous communication a “chain” of requests is created
between microservices while serving the client request. This is an anti-pattern. In asynchronous
communication microservices use asynchronous messages or http polling to communicate with other
microservices, but the client request is served right away.
If your microservice needs to raise an additional action in another microservice, if possible, do not
perform that action synchronously and as part of the original microservice request and
reply
operation. Instead, do it asynchronously (using asynchronous messaging or integration events,
queues, etc.). But, as much as possible, do not invoke the action synchronously as part of the original
synchronous request and reply operation.
And finally (and this is where most of the issues arise when building microservices), if your initial
microservice needs data that’s originally owned by other microservices,
do not rely on making
synchronous requests for that data. Instead, replicate or propagate that data (only the attributes you
need) into the initial service’s database by using eventual consistency (typically by using integration
events, as explained in upcoming sections).
As noted earlier in the
Identifying domain-model boundaries for each microservice
section,
duplicating some data across several microservices isn’t an incorrect design—
on the contrary, when
doing that you can translate the data into the specific language or terms of that additional domain or
Bounded Context. For instance, in the
eShopOnContainers
application
you have a microservice named
identity-api
that’s in charge of most of the user’s data with an entity named
User
. However, when
you need to store data about the user within the
Ordering
microservice, you store it as a different
entity named
Buyer
. The
Buyer
entity shares the same identity
with the original
User
entity, but it
might have only the few attributes needed by the
Ordering
domain, and not the whole user profile.
52
CHAPTER 3 | Architecting container and microservice-based applications
You might use any protocol to communicate and propagate data asynchronously across microservices
in order to have eventual consistency. As mentioned, you could use integration events using an event
bus or message broker or you could even use HTTP by polling the other services instead. It doesn’t
matter. The important rule is to not create synchronous dependencies between your microservices.
The following sections explain the multiple communication styles you can consider using in a
microservice-based application.
Dostları ilə paylaş: