Estruturar microsserviços: Considerações sobre dadosDesigning microservices: Data considerations

Este capítulo descreve considerações para gerir dados numa arquitetura de microsserviços.This chapter describes considerations for managing data in a microservices architecture. Uma vez que cada microsserviço gerencia seus próprios dados, integridade de dados e a consistência de dados são desafios críticos.Because every microservice manages its own data, data integrity and data consistency are critical challenges.

Diagrama das considerações de dados

Um princípio básico dos microsserviços é o facto de cada serviço gerir os seus próprios dados.A basic principle of microservices is that each service manages its own data. Dois serviços não devem partilhar um arquivo de dados.Two services should not share a data store. Em vez disso, cada serviço é responsável por seu próprio arquivo de dados privados, que não podem aceder diretamente a outros serviços.Instead, each service is responsible for its own private data store, which other services cannot access directly.

O motivo para esta regra é evitar não intencional acoplamento entre serviços, o que pode resultar se os serviços compartilham os mesmos esquemas de dados subjacente.The reason for this rule is to avoid unintentional coupling between services, which can result if services share the same underlying data schemas. Se houver uma alteração ao esquema de dados, a alteração tem de ser coordenada entre todos os serviços que se baseie nessa base de dados.If there is a change to the data schema, the change must be coordinated across every service that relies on that database. Isolando o arquivo de dados de cada serviço, podemos limitar o escopo das alterações e preservar a agilidade de implementações verdadeiramente independentes.By isolating each service's data store, we can limit the scope of change, and preserve the agility of truly independent deployments. Outro motivo é que cada microsserviço pode ter seus próprios modelos de dados, consultas, ou padrões de leitura/escrita.Another reason is that each microservice may have its own data models, queries, or read/write patterns. Usar um arquivo de dados partilhado limita a capacidade de cada equipe para otimizar o armazenamento de dados para o serviço específico.Using a shared data store limits each team's ability to optimize data storage for their particular service.

Diagrama de uma abordagem de errado para CQRS

Essa abordagem com Naturalidade para persistência poliglota — a utilização de várias tecnologias de armazenamento de dados num só aplicativo.This approach naturally leads to polyglot persistence — the use of multiple data storage technologies within a single application. Um serviço pode necessitar dos recursos de esquema na leitura de uma base de dados do documento.One service might require the schema-on-read capabilities of a document database. Outro poderá ter a integridade referencial fornecida por um RDBMS.Another might need the referential integrity provided by an RDBMS. Cada equipe é livre para criar a melhor opção para o seu serviço.Each team is free to make the best choice for their service. Para mais informações sobre o princípio geral de persistência poliglota, consulte utilizar os melhor arquivo de dados para a tarefa.For more about the general principle of polyglot persistence, see Use the best data store for the job.

Nota

Não há problema para os serviços partilhar o mesmo servidor de banco de dados físico.It's fine for services to share the same physical database server. O problema ocorre quando os serviços compartilham o mesmo esquema, ou leitura e gravação para o mesmo conjunto de tabelas de base de dados.The problem occurs when services share the same schema, or read and write to the same set of database tables.

DesafiosChallenges

Alguns desafios resultam dessa abordagem distribuída para a gestão de dados.Some challenges arise from this distributed approach to managing data. Em primeiro lugar, pode haver redundância em arquivos de dados, com o mesmo item de dados que aparecem em vários locais.First, there may be redundancy across the data stores, with the same item of data appearing in multiple places. Por exemplo, dados podem ser armazenados como parte de uma transação, em seguida, armazenados noutro local para análises, relatórios, ou arquivar.For example, data might be stored as part of a transaction, then stored elsewhere for analytics, reporting, or archiving. Os dados estão duplicados ou particionados podem levar a problemas de integridade de dados e a consistência.Duplicated or partitioned data can lead to issues of data integrity and consistency. Quando as relações de dados abrangem vários serviços, é possível utilizar técnicas de gerenciamento de dados tradicionais para impor as relações.When data relationships span multiple services, you can't use traditional data management techniques to enforce the relationships.

Modelação de dados tradicional utiliza a regra de "um fato num único local."Traditional data modeling uses the rule of "one fact in one place." Cada entidade é apresentada uma única vez no esquema.Every entity appears exactly once in the schema. Outras entidades podem conter referências a ele, mas não duplicá-lo.Other entities may hold references to it but not duplicate it. A vantagem óbvia para a abordagem tradicional é que as atualizações são feitas num único lugar, o que evita problemas com consistência de dados.The obvious advantage to the traditional approach is that updates are made in a single place, which avoids problems with data consistency. Numa arquitetura de microsserviços, deve considerar como as atualizações são propagadas em todos os serviços e como gerenciar a consistência eventual quando dados são apresentados em vários locais, sem a consistência forte.In a microservices architecture, you have to consider how updates are propagated across services, and how to manage eventual consistency when data appears in multiple places without strong consistency.

Abordagens para a gestão de dadosApproaches to managing data

Não existe nenhuma abordagem única que está correta em todos os casos, mas aqui estão algumas Diretrizes gerais para gerir dados numa arquitetura de microsserviços.There is no single approach that's correct in all cases, but here are some general guidelines for managing data in a microservices architecture.

  • Adote a consistência eventual sempre que possível.Embrace eventual consistency where possible. Compreenda os locais no sistema em que terá de consistência forte ou transações ACID e os locais onde a consistência eventual é aceitável.Understand the places in the system where you need strong consistency or ACID transactions, and the places where eventual consistency is acceptable.

  • Quando precisar de garantias de consistência forte, um serviço pode representar a fonte verdadeira para uma determinada entidade, o que é exposta através de uma API.When you need strong consistency guarantees, one service may represent the source of truth for a given entity, which is exposed through an API. Outros serviços poderão conter a sua própria cópia dos dados ou um subconjunto dos dados, que são eventualmente consistente com dados mestre, mas não considerada a fonte verdadeira.Other services might hold their own copy of the data, or a subset of the data, that is eventually consistent with the master data but not considered the source of truth. Por exemplo, imagine um sistema de comércio eletrónico com um serviço de pedidos de cliente e um serviço de recomendação.For example, imagine an e-commerce system with a customer order service and a recommendation service. O serviço de recomendação pode escutar eventos do serviço de pedidos, mas se um cliente solicitar um reembolso, é o serviço de pedidos, não o serviço de recomendação, que tem o histórico de transação completa.The recommendation service might listen to events from the order service, but if a customer requests a refund, it is the order service, not the recommendation service, that has the complete transaction history.

  • Para transações, utilizar padrões como Supervisor de agente do Scheduler e transação de compensação para manter os dados consistente em vários serviços.For transactions, use patterns such as Scheduler Agent Supervisor and Compensating Transaction to keep data consistent across several services. Se pretender armazenar uma informação adicional de dados que captura o estado de uma unidade de trabalho que abrange vários serviços, para evitar a falha parcial entre vários serviços.You may need to store an additional piece of data that captures the state of a unit of work that spans multiple services, to avoid partial failure among multiple services. Por exemplo, mantenha um item de trabalho numa fila durável, enquanto uma transação de vários passo está em curso.For example, keep a work item on a durable queue while a multi-step transaction is in progress.

  • Store apenas os dados que precisa de um serviço.Store only the data that a service needs. Um serviço só poderá ter um subconjunto das informações sobre uma entidade de domínio.A service might only need a subset of information about a domain entity. Por exemplo, no contexto limitado de envio, é necessário saber o cliente que está associado a uma entrega em particular.For example, in the Shipping bounded context, we need to know which customer is associated to a particular delivery. Mas não precisamos que o endereço de cobrança do cliente — gerenciado pelo contexto limitados de contas.But we don't need the customer's billing address — that's managed by the Accounts bounded context. Pensando cuidadosamente o domínio e, usando uma abordagem DDD, podem ajudar aqui.Thinking carefully about the domain, and using a DDD approach, can help here.

  • Considere se os serviços são coerente e relativamente acoplados.Consider whether your services are coherent and loosely coupled. Se dois serviços estão continuamente a trocar informações entre si, resultando em chatty APIs, convém redesenhar seus limites de serviço, através da intercalação dois serviços ou refatoração sua funcionalidade.If two services are continually exchanging information with each other, resulting in chatty APIs, you may need to redraw your service boundaries, by merging two services or refactoring their functionality.

  • Utilize um condicionada por estilo de arquitetura eventos.Use an event driven architecture style. Neste estilo de arquitetura, um serviço publica um evento quando existirem alterações seus modelos públicos ou entidades.In this architecture style, a service publishes an event when there are changes to its public models or entities. Os serviços interessados podem subscrever esses eventos.Interested services can subscribe to these events. Por exemplo, outro serviço pode utilizar os eventos para construir uma vista materializada dos dados que é mais adequados para a consulta.For example, another service could use the events to construct a materialized view of the data that is more suitable for querying.

  • Um serviço que é proprietário de eventos deve publicar um esquema que pode ser utilizado para automatizar serializando e desserializando os eventos, para evitar o acoplamento rígido entre os publicadores e subscritores.A service that owns events should publish a schema that can be used to automate serializing and deserializing the events, to avoid tight coupling between publishers and subscribers. Considere o esquema JSON ou uma estrutura como o Microsoft Bond, Protobuf ou Avro.Consider JSON schema or a framework like Microsoft Bond, Protobuf, or Avro.

  • Em grande escala, os eventos pode se torne um estrangulamento no sistema, por isso considere utilizar a agregação ou criação de batches para reduzir a carga total.At high scale, events can become a bottleneck on the system, so consider using aggregation or batching to reduce the total load.

Entrega por drone: Escolher os arquivos de dadosDrone Delivery: Choosing the data stores

Mesmo com apenas alguns serviços, o contexto de envio estagnação ilustra vários dos pontos abordados nesta seção.Even with only a few services, the Shipping bounded context illustrates several of the points discussed in this section.

Quando um utilizador agenda uma entrega de novo, o pedido do cliente inclui informações sobre a ambos os a entrega, por exemplo, as localizações de recolha e de redução e sobre o pacote, como o tamanho e peso.When a user schedules a new delivery, the client request includes information about the both the delivery, such as the pickup and dropoff locations, and about the package, such as the size and weight. Estas informações definem uma unidade de trabalho, o que o serviço de ingestão envia para os Hubs de eventos.This information defines a unit of work, which the Ingestion service sends to Event Hubs. É importante que a unidade de trabalho permanece no armazenamento persistente enquanto o serviço de Scheduler está em execução do fluxo de trabalho, para que não existem pedidos de entrega são perdidos.It's important that the unit of work stays in persistent storage while the Scheduler service is executing the workflow, so that no delivery requests are lost. Para obter mais discussões do fluxo de trabalho, consulte ingestão e fluxo de trabalho.For more discussion of the workflow, see Ingestion and workflow.

Os serviços de back-end se preocupa com diferentes partes das informações no pedido e também tem leitura diferente e escrever perfis.The various backend services care about different portions of the information in the request, and also have different read and write profiles.

Serviço de entregaDelivery service

O serviço de entrega armazena informações sobre cada entrega que atualmente é agendada ou em curso.The Delivery service stores information about every delivery that is currently scheduled or in progress. Está à escuta de eventos a partir de drones e controla o estado de entregas que estão em curso.It listens for events from the drones, and tracks the status of deliveries that are in progress. Também envia eventos de domínio com as atualizações de estado de entrega.It also sends domain events with delivery status updates.

Espera-se que os utilizadores com frequência irão verificar o estado de uma entrega enquanto estão a aguardar seu pacote.It's expected that users will frequently check the status of a delivery while they are waiting for their package. Por conseguinte, o serviço de entrega requer um arquivo de dados que enfatiza o débito (leitura e escrita) sobre o armazenamento de longo prazo.Therefore, the Delivery service requires a data store that emphasizes throughput (read and write) over long-term storage. Além disso, o serviço de entrega não executa quaisquer consultas complexas ou análise, simplesmente obtém o estado mais recente para uma entrega determinado.Also, the Delivery service does not perform any complex queries or analysis, it simply fetches the latest status for a given delivery. A equipa do serviço de entrega escolheu a Cache de Redis do Azure para seu alto desempenho de leitura / escrita.The Delivery service team chose Azure Redis Cache for its high read-write performance. As informações armazenadas no Redis tem duração relativamente curta.The information stored in Redis is relatively short-lived. Quando uma entrega estiver concluída, o serviço de entrega de histórico é o sistema de registo.Once a delivery is complete, the Delivery History service is the system of record.

Serviço de entrega de históricoDelivery History service

O serviço de entrega histórico escuta de eventos de status de entrega do serviço de entrega.The Delivery History service listens for delivery status events from the Delivery service. Ele armazena estes dados no armazenamento de longo prazo.It stores this data in long-term storage. Existem dois diferentes casos de utilização para esses dados históricos, que têm requisitos de armazenamento de dados diferentes.There are two different use-cases for this historical data, which have different data storage requirements.

O primeiro cenário é agregar os dados para fins de análise de dados, para otimizar o negócio ou melhorar a qualidade do serviço.The first scenario is aggregating the data for the purpose of data analytics, in order to optimize the business or improve the quality of the service. Tenha em atenção que o serviço de entrega histórico não realiza a análise real dos dados.Note that the Delivery History service doesn't perform the actual analysis of the data. Ele é responsável apenas pela ingestão e armazenamento.It's only responsible for the ingestion and storage. Para este cenário, o armazenamento tem de estar otimizado para análise de dados através de um grande conjunto de dados, usando uma abordagem de esquema na leitura para acomodar uma variedade de origens de dados.For this scenario, the storage must be optimized for data analysis over a large set of data, using a schema-on-read approach to accommodate a variety of data sources. Azure Data Lake Store é uma boa se encaixam para este cenário.Azure Data Lake Store is a good fit for this scenario. Data Lake Store é um sistema de ficheiros Apache Hadoop compatível com o Hadoop Distributed File System (HDFS) e está otimizado para desempenho para cenários de análises de dados.Data Lake Store is an Apache Hadoop file system compatible with Hadoop Distributed File System (HDFS), and is tuned for performance for data analytics scenarios.

O outro cenário é permitir que os utilizadores procurar o histórico de uma entrega depois de concluída a entrega.The other scenario is enabling users to look up the history of a delivery after the delivery is completed. O Azure Data Lake não está otimizado especialmente para este cenário.Azure Data Lake is not particularly optimized for this scenario. Para um desempenho ideal, a Microsoft recomenda a armazenar dados de séries de tempo no Data Lake nas pastas particionadas por data.For optimal performance, Microsoft recommends storing time-series data in Data Lake in folders partitioned by date. (Consulte ajuste do Azure Data Lake Store para um desempenho).(See Tuning Azure Data Lake Store for performance). No entanto, essa estrutura não é ideal para procurar registos individuais por ID.However, that structure is not optimal for looking up individual records by ID. A menos que saiba também o carimbo de hora, uma pesquisa por ID de requer a análise de toda a coleção.Unless you also know the timestamp, a lookup by ID requires scanning the entire collection. Por conseguinte, o serviço de entrega histórico também armazena um subconjunto dos dados históricos no Cosmos DB para a pesquisa mais rápida.Therefore, the Delivery History service also stores a subset of the historical data in Cosmos DB for quicker lookup. Os registos não precisam de manter-se indefinidamente no Cosmos DB.The records don't need to stay in Cosmos DB indefinitely. Entregas mais antigas podem ser arquivadas — Digamos, após um mês.Older deliveries can be archived — say, after a month. Isso poderia ser feito através da execução de um processo em lotes ocasionais.This could be done by running an occasional batch process.

Serviço de pacotePackage service

O serviço de pacote armazena informações sobre todos os pacotes.The Package service stores information about all of the packages. Os requisitos de armazenamento para o pacote são:The storage requirements for the Package are:

  • Armazenamento de longa duração.Long-term storage.
  • Capaz de lidar com um grande volume de pacotes, que requerem elevada taxa de transferência de escrever.Able to handle a high volume of packages, requiring high write throughput.
  • Suporte consultas simples por ID do pacote.Support simple queries by package ID. Sem associações complexas ou requisitos de integridade referencial.No complex joins or requirements for referential integrity.

Como os dados do pacote não são relacionais, uma base de dados orientada do documento é apropriado e do Cosmos DB pode alcançar um débito muito elevado ao utilizar coleções em partição horizontal.Because the package data is not relational, a document oriented database is appropriate, and Cosmos DB can achieve very high throughput by using sharded collections. A equipe que funciona no serviço de pacote está familiarizada com a pilha MEAN (MongoDB, Express. js, AngularJS e node. js), para que eles selecionam os API do MongoDB para o Cosmos DB.The team that works on the Package service is familiar with the MEAN stack (MongoDB, Express.js, AngularJS, and Node.js), so they select the MongoDB API for Cosmos DB. Isso permite que eles tirem partido das suas experiências existentes com o MongoDB, ao obter os benefícios do Cosmos DB, que é um serviço gerido do Azure.That lets them leverage their existing experience with MongoDB, while getting the benefits of Cosmos DB, which is a managed Azure service.