29
CHAPTER 3 | Architecting container and microservice-based applications
be accessed either synchronously through its API endpoints(REST, gRPC, SOAP, etc) or asynchronously
via messaging(AMQP or similar).
Encapsulating the data ensures that the microservices are loosely coupled and can evolve
independently of one another. If multiple services were accessing the same data, schema updates
would require coordinated updates to all the services. This would break the microservice lifecycle
autonomy. But distributed data structures mean that you can’t make a single ACID transaction across
microservices. This in turn means you must use eventual consistency when a business process spans
multiple microservices. This is much harder to implement than simple SQL joins, because you can’t
create integrity constraints or use distributed transactions between separate databases, as we’ll
explain later on. Similarly, many other
relational database features aren’t available across multiple
microservices.
Going even further, different microservices often use different
kinds
of databases. Modern
applications store and process diverse kinds of data, and a relational database isn’t al
ways the best
choice. For some use cases, a NoSQL database such as Azure CosmosDB or MongoDB might have a
more convenient data model and offer better performance and scalability than a SQL database like
SQL Server or Azure SQL Database. In other cases, a relational database is still the best approach.
Therefore, microservices-based applications often use a mixture of SQL and NoSQL databases, which
is sometimes called the
polyglot persistence
approach.
A partitioned, polyglot-persistent architecture for data storage has many benefits. These include
loosely coupled services and better performance, scalability, costs, and manageability. However, it can
in
troduce some distributed data management challenges, as explained in “
Identifying domain-model
boundaries
” later in this chapter.
Dostları ilə paylaş: