-
Notifications
You must be signed in to change notification settings - Fork 0
/
bib
66 lines (39 loc) · 3.09 KB
/
bib
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249
https://assets.infoq.com/newsletter/architect/en/newsletter_sample/35Architects_NL_June2020.html
fowloer
https://www.thoughtworks.com/pt/insights/blog/microservices-nutshell
https://www.redhat.com/pt-br/topics/microservices
Assistir esse vídeo e resumir, responder perguntas
stackoverflow é monolito: https://www.youtube.com/watch?time_continue=7&v=cFCW6VX0y74&feature=emb_logo
- equipe pequena (menos de 20 pessoas). facilita monolito
- sempre em evolução (no último ano 90% foi modificado). sempre atualizando com as bibliotecas/frameworks etc.
- componentização -> bibliotecas. não faz a organização do código para distribuir, mas para desenvolver.
- desempenho. 9 servidores (rodando a 10% da capacidade) (média de 5mil requisições por segundo). A saída é via software. tuning de sql etc.
- Quebra de camadas: a lógica de acesso a dados está no controller também
- perde em testabilidade, mas ganha em desempenho. diminui camadas. diminui alocações. o garbage collector era um problema.
- Um dos motivos: escala horizontal era caro. eles não tinham dinheiro.
- entender onde estão os gargalos. a página de pergunta tem 80% do tráfego. Página do perfil não precisa ter esse cuidado todo.
- não foram para a nuvem. 1 hop apenas. na nuvem, o mínimo que conseguiram foi 10. Cada hop desse adiciona tempo nas chamadas.
- Não há escala horizontal.
- A última escala vertical foi em 2015.
### Nubank
SHARD - 20 X 600 = 12k BDs.
Tem um desafio aqui inclusive para a AWS. muito banco. esgotou.
mas muito caro. a aws está preocupada porque está acabando. nubank é o maior cliente da AWS nesse sentido.
Exemplo muito bacana para a disciplina de arquitetura de software.
Shard
- 600 serviços por shard. 600 bds. cada microsserviço tem um bd e vários microsserviços
- há limites específicos por shard
- O banco, no geral, é o problema
- Existe um shard global para conversar um com outro (roteamento)
- Os bancos são isolados no shard. tudo é isolado. completamente separado. A ideia é saber exatamente o que a infra suporta e não passar disso.
- Na teoria, novos cliente iriam para o shard N. Contudo, a capacidade dos anteriores foi aumentando, então há alocação nos outros tb.
- 80 milhoes de clientes. 20 por shard.
Datomic precisa de um storage por tras. 99% dos casos no nubank é dynamoDB
peer escala horizontalmente a leitura, mas não a escrita;
escrita deve ser serial. dois serviços não podem alterar dados de um cliente no mesmo momento. precisa ser feito via transactor.
o datomic fez com que o nubank adotasse clojure
se o transactor cair, leitura ainda continua.
usam kafka com escrita baseada em filas.
datomic é importante para instituição financeita por causa do log das escrita. os dados são imutaveis. o que se tem é historico. toda atualização é feita através de uma nova observação e marcando a anterior como desatualizada. sempre uma linha nova.
conflito entre requisitos. tem operações que precisa ser executadas com mais desempenho, então bypassa o transactor.