Sou relativamente novo na arquitetura de microsserviço. Temos um aplicativo da Web de tamanho moderado e estou avaliando os prós e contras de dividi-lo em microsserviços, em vez de um sistema monolítico que temos agora em desenvolvimento.
Pelo que entendi, considere os microservices A e B , cada um deles baseado em um subconjunto de dados que o outro tem. Se uma mensagem for postada por A dizendo que algo foi alterado, B pode consumir essa mensagem e replicar uma cópia local das informações de A e usá-la para fazer o que for necessário para B .
No entanto, e se B falhar ou falhar e, depois de um tempo, voltar novamente. Durante esse tempo de inatividade, A publicou mais duas mensagens. Como o B sabe como atualizar sua cópia local das informações de A ?
Concedido, se B for o único consumidor da fila de A , ele poderá começar a lê-lo assim que voltar a ser on-line, mas e se houver outros consumidores dessa fila e essas mensagens forem consumidas?
Como um exemplo mais concreto, se um serviço Users tiver seu endereço de e-mail atualizado enquanto um% microservice Billing estiver inativo, se o microsserviço Billing for novamente ativado, como ele saberá que o e-mail foi atualizado ?
Quando os microsserviços voltam, ele faz uma transmissão dizendo "Ei, estou de volta, me dê todas as suas informações atuais?"
Em geral, quais seriam as melhores práticas do setor para sincronização de dados?
Eu desafiaria toda a sua ideia de "empurrar os dados para todos os outros microservices".
Normalmente, se um serviço de faturamento precisa de um endereço de e-mail, ele apenas solicita ao serviço de endereço o endereço de e-mail do cliente específico. Ele não precisa conter uma cópia de todos os dados de endereço, nem será informado se alguma coisa mudar. Ele apenas pergunta e recebe a resposta dos dados mais recentes.
Depois de pesquisar um pouco mais, me deparei com artigo do qual tirei algumas citações que acho úteis para o que quero realizar (e para qualquer futuro leitor). Isso oferece uma maneira de adotar um modelo de programação reativa sobre um modelo de programação imperativo.
Fornecimento de eventos
O que isso ajuda a conseguir é que, se um microsserviço cair, outros eventos pertinentes a ele estão sendo publicados, os eventos e são consumidos por, digamos, outras instâncias desse microsserviço, quando esse microsserviço voltar , pode se referir a esseThe idea here is to represent every application’s state transition in a form of an immutable event. Events are then stored in a log or journal form as they occur (also referred to as ‘event store’). They can also be queried and stored indefinitely, aiming to represent how the application’s state, as a whole, evolved over time.
event store para recuperar todos os eventos que ele perdeu durante o período em que caiu.
Apache Kafka como agente de eventos
Considere o uso do Apache Kafka, que pode armazenar e despachar milhares de eventos por segundo e possui mecanismos integrados de replicação e tolerância a falhas. Ele tem um armazenamento persistente de eventos que podem ser armazenados em disco indefinidamente e consumidos a qualquer momento (mas não removidos) do Tópico (a fila de fantasia do Kafka) foram entregues.
The events are then assigned offsets that univocally identify them within the Topic — Kafka can manage the offsets itself, easily providing “at most once” or “at least once” delivery semantics, but they can also be negotiated when an event consumer joins a Topic, allowing microservices to start consuming events from any arbitrary place in time — usually from where the consumer left off. If the last consumed event offset is transactionally persisted in the services’s local storage when the usecases ‘successfully complete’, that offset can easily be used to achieve an “exactly once” event delivery semantics.
Na verdade, quando os consumidores se identificam com Kafka, Kafka registra quais mensagens foram entregues a qual consumidor, para que ele não seja exibido novamente.
Sagas
For more complex usecases where the communication among different services is indeed necessary, the responsibility of finishing the usecase must be well recognized — the usecase is decentralized and only finishes when all the services involved acknowledge their task as successfully completed, otherwise the whole usecase must fail and corrective measures must be triggered to rollback any invalid local state.
É quando a saga entra em cena. Uma saga é uma sequência de transações locais. Cada transação local atualiza o banco de dados e publica uma mensagem ou evento para acionar a próxima transação local na saga. Se uma transação local falhar porque viola uma regra de negócios, a saga executa uma série de transações de compensação que desfazem as alterações feitas pelas transações locais anteriores. Leia este para obter mais informações.
Você pode substituir uma fila de eventos normal por um modelo de editor / assinante, onde A service publica uma nova mensagem de tópico T e B type de microservices assinaria o mesmo tópico.
Idealmente, B seria um serviço sem estado e utilizaria um serviço de persistência desanexada, de modo que uma instância B service com falha fosse substituída pela geração de uma ou mais instâncias de B service para continuar seu trabalho, lendo do mesmo serviço de persistência compartilhada.
Tags database microservices