Please enable JavaScript.
Coggle requires JavaScript to display documents.
Microservice Patterns (:pushpin:Estratégias de decomposição (:pushpin…
Microservice Patterns
:pushpin:Estratégias de decomposição
:pushpin:O que é a arquitetura de microserviços exatamente?
:pushpin:O que é arquitetura e porque isso importa?
:round_pushpin:Uma definição de arquitetura de software
Existem muitas
Na definição que o livro utiliza:
The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.
Documenting Software Architectures by Bass et al.
A arquitetura é a divisão das partes de um software e o relacionamento entre estas partes
Facilita a divisão de trabalho e conhecimento
Define como os elementos de software interagem
:round_pushpin:O modelo de visão 4+1 da arquitetura de software
:memo:Visão lógica
Código implementado
Os elementos criados pelos desenvolvedores
:package:Visão de Implementação
O output do build do sistema
Java JAR
Executáveis
:gear:Visão de processos
Os componentes em tempo de execução
E a comunicação entre eles (IPC)
:computer:Visão de entrega
Como os processos são mapeados nas máquinas
:movie_camera:Cenários
Para cada visão exemplificam como se dará o funcionamento
:round_pushpin:Porque arquitetura importa?
Arquitetura não tem a ver com requisitos funcionais
:round_pushpin:Arquitetura tem a ver com requisitos não funcionais
:chart_with_upwards_trend:Escalabilidade
:old_key:Confiabilidade
:wrench:Matunabilidade
:nut_and_bolt:Testabilidade
:mailbox:Entregabilidade
:book:Arquitetura trata de como os compontentes de software são particionados e conectados de forma a solucionar requisitos não-funcionais de um sistema.
:pushpin:Overview de estilos arquiteturais
:round_pushpin:Um estilo de arquitetura envolve
Vocabulário de componentes e conectores
Conjunto de limitações de como os componentes e conectores devem ser usados
Estilo em camadas
:round_pushpin:Arquitetura em camadas
Cada camada possui responsabilidades definidas
Uma camada superior só pode depender de uma cada inferior
Three-tier Architecture
É uma arquitetura em camadas aplicado a Visão Lógica
Camada de Apresentação
Camada de Persistência
Camada de Negócios
Possui problemas
Não representa bem o fato de que mais de um tipo de cliente irá solicitar a aplicação
Não representa bem o fata de mais de um tipo de persistência será utilizada pela aplicação
Define que as regras de negócio sejam dependentes do banco de dados
Na prática em geral a camada de
Você pode aplicar em qualquer visão de arquitetura
Camadas em estilo top-down
:round_pushpin:Arquitetura Hexagonal
Camadas em estilo Onion
A logica de negócio fica no centro
Ao invés de camada de apresentação, possui camada de aplicação que se comunica com a camada de negócios através de Inbound Adapters
Ao invés da camada de persistencia possui outbound adapters que invocam a camada de negócios e aplicações externas
A lógica de negócios possui um ou mais Ports que são conjuntos de operações para que a regra de negócio interaga com o mundo externo. Existem inbounds ports e outbounds ports
:book: Existem muitos estilos de arquitetura de uma aplicação, dentre eles: Arquitetura em camadas e Arquitetura Hexagonal
:pushpin:A arquitetura de microserviços é um estilo arquitetural
Arquitetura monolítica
Visão de implementação em um único componente
Pode utilizar qualquer estilo arquitetural da camada de visão
Arquitetura de microserviços
Visão de implementação em múltiplos componentes
Componentes são serviços
Conectores são protocolos de comunicação
Serviços possuem baixo acoplamento
O que é um serviço?
Aplicação independente
Implementa uma funcionalidade única
Fornece uma API para ser acessada por um cliente
Uma API consiste de Commands, Queries e Events
Um desenvolvedor não pode criar código que atravesse a API
O que é baixo acoplamento?
Serviços só se comunicam através de API
Nada de se comunicar através de banco de dados
Bibliotecas compartilhadas
Você deve se esforçar para para utilizar somente bibliotecas compartilhadas em situações onde provavelmente não irá haver mudança. Em geral coisas genéricas em linguagem de negócio como uma classe Money
Tamanhos de serviços não são importantes
Precisa ser de um tamanho gerenciado por uma única equipe
Se você precisa constantemente mudar um serviço por causa de mudanças em outro, então você pode ter criado um monolíto distribuído
Precisa ser de um tamanho que não demore demais para a execução de testes
:book: Diferente da arquitetura monolíticia, a arquitetura em microserviços visa decompor uma aplicação em diversos componentes de implementação. Utilizando serviços com baixo acoplamento.
:dart:Como a arquitetura de microserviços se relaciona com o conceito de arquitetura de software
:desert_island:Entre muitas arquiteturas a de microserviços se propõe a facilitar e otimiar o desenvolvimento de software, mas o que é uma arquitetura de microserviços
:book: Arquitetura de microserviços é uma arquitetura da que age na visão de implementação onde decompõe a aplicação em serviços. Muitas vezes utiliza a arquitetura Hexagonal na visão lógica.
:pushpin:Definindo uma arquitetura de microserviços
:pushpin:Identificando as operações do sistema
Operações de sistema é uma abstração de uma requisição que a aplicação deve resolver
No modelo 4+1 de visão arquitetural as operações do sistema são o +1.
Onde procurar
:check:User stories
:check:User Scenarios
:check:Requisitos funcionais
Passos
Cria um modelo de alto nivel apenas com o nome das classes que proveem um vocabulario para descrever a operação
O modelo de domínio deriva dos substantivos do requisito
O modelo também pode ser definido através de Event Storming
Identifique as operações e descreva-as como comportamento do modelo do domínio
As operações derivam dos verbos dos requisitos
Existem dois tipos de operações de sistema
Commands
Possui uma especificação de parametros, valor de retorno, e comportamento em termos de modelo de dominio
O comportamento consiste de pre-condições que devem ser verdadeiras quando a operação é invocada.
As pré-condições refletem os Givens do scenario
E pós-condições que são operações que devem ser verdadeiras depois das operações serem invocadas
As pós-condições refletem os Thens do scenario
Queries
Fornecem dados para leitura
Ultimamente essas operações correspondem REST, RPC ou messageria, mas é útil tratá-los de forma abstrata.
:pushpin:Definindo serviços por decompor em capacidades de negócio
:desert_island:Uma vez definidas as operações do sistema é necessário definir os serviços que irão executar as operações, uma das formas de fazer isso é por decompor segundo as capacidades de negócio
Capacidades de negócio definem O QUE uma organização faz e não COMO faz
Não mudam com o tempo
Podem ser pensadas como serviços,mas orientado a negócios e não tecnicamente
A especificação de uma capacidade consiste de
Inputs
Outputs
Acordos de serviço
Uma capacidade é dividida em sub-capacidades que a compoem
Um benefício chave de decompor por capacidades é que elas são mais estáveis
Uma vez definida as capacidades, você atribui cada uma a um serviço
:pushpin:Definindo serviços por Decompor em subdomínios
:desert_island:Uma vez definidas as operações do sistema é necessário definir os serviços que irão executar as operações, uma das formas de fazer isso é por decompor segundo os subdominios
Um subdomínio é identificado observando as diferentes áreas de negócio de uma empresa, cada uma irá compartilhar uma linguagem ubíqua dentro de seu contexto
O contexto de um subdomínio é definido por um Bounded Context
Em uma estrutura de microserviços cada bounded context pode ser mapeado para um ou mais serviços
Cada subdomínio possui o seu modelo de domínio
:pushpin:Guia para decomposição
:desert_island:Independente da forma como você irá decompor o sistema em serviços existem algumas regras gerais que podem ser aplicadas
Princípio da responsabilidade única
A class should have only one reason to change.
Principio de Encapsulamento Comum
The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package.
Serviços que mudam junto devem ser somente um
:pushpin:Obstáculos para a decomposição de aplicações em microserviços
:desert_island:Desafios que você encontra ao implementar uma arquitetura de microserviços
Latencia de Rede
Muitas serviços geram muitas requisições
Pode resolver criando uma batch API
Pode resolver juntando serviços em um único e assim removendo substituindo IPC por chamadas de código
Disponibilidade reduzida por causa de comunicação síncrona
Requisiçoes bloqueantes
Manter consistencia de dados entre serviços
Utilizando SAGA
Obter uma visualização consistente dos dados
Se for realmente necessário é preciso deixar os dados em um único serviço
God classes atrapalhando a decomposição
São classes que implementam lógicas para clientes distintos, se tornam muito grandes e dificeis de integrar
Uma solução errada seria passar a classe para uma biblioteca e criar um banco em separado só para isso
Uma solução errada seria passar a classe para um serviço especifico, porem seria um serviço anemico
DDD possui uma solução separando o modelo de acordo com o contexto delimitidao
:pushpin:Definindo APIs de serviços
Uma API consiste de operações e eventos
Atribuir operações à serviços
As vezes a operação deve estar no serviço que precisa da informação
As vezes a operação deve estar no serviço que possui a informação
:desert_island:Definir uma arquitetura de microserviços envolve em
1) identificar as operações do sistema
2) decompor o sistema
3) a definir uma API
:desert_island:A parte mais importante da arquitetura de microserviços é a definição do serviços
:dart:Entender arquitetura de software e porque é importante
:dart:Decompor aplicações em microserviços
:dart:Facilitar a decomposição utilizando Bounded Context
Gerenciando transações com Sagas
:wrench:Gerenciamento de transações
A necessidade por transações distribuidas em um arquitetura de microserviços
:desert_island: Sistemas monolíticos resolver a consistência de dados como ferramentas como frameworks para garantir uma transação. Microserviços não conseguem utilizar a mesma idéia.
:dart: O que torna o gerenciamento de transações complexo em microserviços
Porque cada serviço tem seu próprio banco de dados você precisa de um mecanismo que garanta a consistência entre múltiplos bancos de dados
O problema com transações distribuidas
:desert_island: A forma mais comum de resolver consistencia entre multiplos serviços é a utilizaçao de transações distribuidas, mas isso causa alguns problemas ao utilizarmos em microserviços
Usando o padrão saga para manter consistencia de dados
:desert_island: Em um arquitetura dados precisam ser armazenados em serviços separados, com banco de dados separados. De forma que as transações não conseguem ser ACID, elas são ACD.
:dart: Como resolver o problema de consistência de dados entre múltiplos serviços
IPC em uma estrutura de microserviços
Overview de IPC em arquitetura de microserviços
Estilos de interação
Dimensões
Um pra um ou um pra muitos
Sincrona ou assincrona
Request / Response
Cliente envia a requisição e aguarda a resposta
One-to-one e Síncrono
Acoplamento entre cliente e Servidor
Nem sempre esse acoplamento existe, por exemplo, usando mensagens por um message broker não acopla o cliente ao servidor, mas pode ser que o cliente fique bloqueado esperando a resposta
Muitas vezes, não sempre (reactive), bloqueia cliente, que está esperando
Async Request / Response
Cliente envia requisição para o cliente, mas sabe que ele não vai responder no momento então não fica bloqueado aguardando
One-to-one e Assíncrono
Não bloqueia cliente e pode não bloquear o servidor
Publish / Subscribe
One way notifications
Definindo Apis em microserviços
Evoluindo Apis
Formatos de mensagens