4 changed files with 132 additions and 2 deletions
@ -0,0 +1,60 @@
|
||||
+++ |
||||
title = "Microservices: Where Is the Source of Truth?" |
||||
date = 2020-02-17 |
||||
|
||||
[taxonomies] |
||||
tags = ["microservices", "state", "source of truth"] |
||||
+++ |
||||
|
||||
When we are talking about a system, there is one point that we need to discuss |
||||
where the "Source of Truth" of it is. In Monoliths, the source of truth is the |
||||
storage itself. But where does it sit in a system that is composed by multiple |
||||
parts? |
||||
|
||||
<!-- more --> |
||||
|
||||
Just to be clear here: What I mean by "source of truth" is whatever you can |
||||
use to check if the system is producing the correct values. For example, in a |
||||
pipeline to count how much users transfer in a CDN, the source of truth could |
||||
be the logs (you can read the logs and check if the service responsible for |
||||
summing the results is correct); in an e-commerce site, we could assume the |
||||
source of truth to be the items in every invoice for the total revenue (if you |
||||
sum all the items quantities by their prices, you'll get the revenue back). |
||||
|
||||
One important factor of a source of truth is that not only you can use it to |
||||
check if your services are correct, but you can also re-apply its content back |
||||
to the system to rebuild artifacts. |
||||
|
||||
But here is a problem: If your system is distributed and [each microservice is |
||||
building a different artifact](@./microservices-artifact-input-state.md), where |
||||
is the source of truth? |
||||
|
||||
Previously, I mentioned that microservices could keep an state in order to |
||||
produce the artifact. That could be the source of truth for that microservice, |
||||
as long as it doesn't delete old data -- in which case, how would you rebuild |
||||
old artifacts if you can't return the state to an old... state? |
||||
|
||||
Another solution is to make the insertion microservice (the one that captures |
||||
data from an external source) to build this source of truth; in case of the |
||||
need to rebuild the data, you can just add an API in that microservice for it |
||||
to republish data related to a certain object, which will go down the pipeline |
||||
and every microservice will rebuild their artifacts. |
||||
|
||||
And, finally, if you build an event source pipeline correctly, you can build a |
||||
single service that will listed to _every_ event and keep a global event |
||||
source, which you can again expose an API to replay all events of an object. |
||||
|
||||
{% note() %} |
||||
.. although I have a feeling that certain events should be changed; for example, |
||||
if you make the event source replay everything related to an invoice -- in |
||||
order to reproduce the complete invoice artifact -- you may have to replay a |
||||
"create user" event, which won't make sense 'cause the object already exists, |
||||
and it shouldn't create a new user with the same information. |
||||
|
||||
Either that, or you could make the invoice service request the costumer |
||||
service the data if it doesn't have it already. |
||||
{% end %} |
||||
|
||||
Anyway, one recommendation that I have is to always build something that can |
||||
keep track of your data, in case you need to rebuild your artifacts and your |
||||
state removes old data (which is perfectly normal, I must add). |
||||
@ -0,0 +1,70 @@
|
||||
+++ |
||||
title = "Microserviços: Onde Fica a Fonte da Verdade?" |
||||
date = 2020-02-17 |
||||
|
||||
[taxonomies] |
||||
tags = ["microserviços", "fonte da verdade", "estado"] |
||||
+++ |
||||
|
||||
Quando estamos falando de um sistema, existe um ponto que precisamos discutir |
||||
que é onde a "fonte da verdade" está. Em monolitos, a fonte da verdade está no |
||||
armazenamento dos dados em si. Mas onde é que essa fonte fica em um sistema |
||||
que é composto de múltiplas partes? |
||||
|
||||
<!-- more --> |
||||
|
||||
Só para ficar claro aqui: O que eu quero dizer com "fonte da verdade" é |
||||
qualquer coisa que você possa usar para verificar se o sistema está produzindo |
||||
os valores corretos. Por exemplo, em um pipeline que conta quanto foi |
||||
transferido de cada usuário em uma CDN, a fonte da verdade podem ser os logs |
||||
(você pode ler os logs e verificar se o sistema responsável por somar os |
||||
valores está correto); num site de e-commerce, podemos assumir que a fonta da |
||||
verdade é a lista de itens comprados em cada pedido para receita total (se |
||||
você somar todas as quantidades e seus preços de venda, você vai ter a receita |
||||
total de volta). |
||||
|
||||
Um fator importante da fonte da verdade e que você pode usar tanto para |
||||
verificar se os serviços estão corretos quanto reaplicar o conteúdo de volta |
||||
no sistema para que artefatos sejam reconstruídos. |
||||
|
||||
Mas existe um problema: Se o sistema é distribuído e [cada microserviço cria |
||||
um artefato diferente](@./microservices-artifact-input-state.pt.md), onde é |
||||
que fica a fonte da verdade? |
||||
|
||||
Anteriormente, eu mencionei que microserviços podem manter um estado para |
||||
produzir o artefato. Essa pode ser a fonte da verdade para o microserviço, |
||||
desde que o mesmo não apague dados antigos -- nesse caso, como é que artefatos |
||||
antigos seriam reconstruídos se você não pode retornar o estado a um estado |
||||
anterior? |
||||
|
||||
Outra solução é alterar o microserviço de importação de dados (aquele que |
||||
captura dados de uma fonte externa) para construir a fonte da verdade; havendo |
||||
a necessidade de reconstruir artefatos, você pode simplesmente adicionar uma |
||||
API nesse microserviço para que ele republique os dados relacionados com um |
||||
determinado objeto, que irão percorrer o pipeline e cada microserviço irá |
||||
reconstruir seus artefatos. |
||||
|
||||
E, finalmente, se você construir um pipeline de event source corretamente, |
||||
você pode criar um serviço que irá escutar _todos_ os eventos e manter um |
||||
event source global, que você pode, novamente, expor uma API para reenviar os |
||||
eventos relacionados com um objeto. |
||||
|
||||
{% note() %} |
||||
... embora eu tenha a sensação que certos eventos precisariam ser alterados; |
||||
por exemplo, se você mandar o event source reenviar os eventos relacionados |
||||
com um epdido -- para que seja recriado o artefato desse pedido -- você pode |
||||
ter que reaplicar um evento de "criar usuário", que não vai fazer sentido |
||||
porque o objeto já existe e não deve ser criado mais um usuário com as mesmas |
||||
informações. |
||||
|
||||
Ou isso ou você vai ter que fazer com que o serviço de pedidos peça os dados |
||||
do cliente se ele já não tiver os mesmos. |
||||
{% end %} |
||||
|
||||
De qualquer forma, uma recomendação que eu tenho é sempre construir alguma |
||||
coisa que possa guardar os seus dados, de forma que você possa reconstruir |
||||
seus artefatos novamente e os serviços apagam dados antigos (que é |
||||
perfeitamente normal, diga-se de passagem). |
||||
|
||||
<!-- vim:spelllang=pt |
||||
--> |
||||
Loading…
Reference in new issue