SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio interoperáveis que podem ser facilmente reutilizados e compartilhados entre aplicações e empresas
- Não é uma tecnologia
- Não é um produto
- Não é um WebService
- Não é um software
- Não é um framework
- Não é uma metodologia
- Não é uma solução de negócio
- Uma arquitetura baseada em reusabilidade com serviços bem definidos e providos por componentes de TI;
- Seus componentes possuem baixo acoplamentos;
- Provê plataforma, tecnologia e linguagens independentes;
-
Desacoplamento:
- Integrações inteligentes, flexibilidade, alinhamento com negócio;
-
Reutilização de serviços:
- Produtividade, manutenibilidade;
-
Infraestrutura de plataforma:
- Padronização corporativo (Log, Governança, etc.);
Uma arquitetura monolítica típica de um sistema complexo pode ser representada pela figura abaixo, onde todas as funções do negócio estão IMPLEMENTADAS EM UM UNICO PROCESSO
- Fácil de desenvolver;
- Fácil manutenção;
- Apenas um deploy;
- Tráfego de rede baixo;
- Aumento de complexidade e tamanho ao longo do tempo;
- Alta dependência de componentes de código;
- Escalabilidade do sistema é limitada;
- Falta de flexibilidade;
- Dificuldade para colocar alterações em produção;
Uma das grandes desvantagens é que é muito difícil ESCALAR o sistema. Muito comum que cada cliente que você tiver, vai ter que replicar/duplicar o servidor, isso duplicando o custo.
Quanto mais clientes tiver, mais servidor vai ser preciso, mais caro vai ficar.
“um serviço com um único propósito e que execute bem a sua tarefa dentro de um nível de granularidade e suporte as mudanças do sistemas que são consideradas importantes tanto em tempo de projeto quanto em tempo de execução. O foco principal é tentar construir software que pode se adaptar e isto só é possível de ser feito se as partes forem pequenas suficientes para se ajustar às diferenças nas mudanças de sua arquitetura.” –– RUSS MILE
- Manutenção e evolução dos serviços mais estáveis;
- Serviços com baixo nível de acoplamento e interdependência; Escalabilidade do sistema;
- Redução de custos;
- Flexibilidade de tecnologia;
- Facilidade de colocar alterações em produção;
- Resiliencia;
- Aumento da produtividade;
- Implementação de entrega contínua;
- Monitoramento e automação de processos;
- Foco na entrega de valor ao cliente;
- Aumento da complexidade da coordenação;
- Comunicação entre os microsserviços;
- Governança;
- Um conjunto de pequenos autônomos que trabalham juntos. "Newman, Sam";
- Software modularizado em pequenos serviços que se comunicam através de uma forma padronizada;
- Se comunicam através de uma API Restfull (HTTP / Json);
-
Out-of-process:
- Possibilidade de execução fora dos processos.
-
Chamadas remotas:
- Microsserviços são acessados por chamadas remotas.
-
Independente de linguagem de programação:
- São agnósticos a linguagem de programação, ou seja, você pode ter serviços escritos em node, java, python, etc.
-
Baixo acoplamento:
- Você é dono somente do seu domínio de negócio. Não necessitando de outro serviço para gerar novas versões e ou evoluir seu produto;
-
Escalabilidade horizontal e vertical:
- Você pode aumentar o número de réplicas (scale horizontal) e/ou aumentar a capacidade computacional de seu serviço (scale vertical);
-
Agilidade:
- Trabalhando em conjuntos de negócio menores você garante agilidade no desenvolvimento de software.
-
Equipe pequena e focada:
- Utilizando o conceito de two-pizzas team você garante foco e produtividade do time de desenvolvimento.
-
Entregas rápidas:
- Por ser altamente testável, um micro serviço pode estar disponível rapidamente em produção com garantias de segurança e qualidade.
-
Combinação de tecnologias:
- Times podem ser multidisciplinares em tecnologias para desenvolver os microsserviços.
- Modele os serviços em torno de domínio da empresa.
- Descentralize tudo. Equipes individuais são responsáveis por projetar e criar serviços. Evite compartilhar esquemas de dados ou códigos.
- O armazenamento de dados deve ser privado para o serviço que é o proprietário dos dados. Use o melhor armazenamento para cada serviço e tipo de dados.
- Os serviços comunicam-se por meio de APIs bem projetadas. Evite o vazamento de detalhes da implementação. As APIs devem modelar o domínio, não a implementação interna do serviço.
- Evite acoplamento entre serviços. Causas de acoplamento incluem protocolos de comunicação rígidos e esquemas de banco de dados compartilhados.
- Descarregue preocupações abrangentes, como autenticação e terminação SSL, para o gateway.
- Mantenha o conhecimento de domínio fora do gateway.
- Os serviços devem ter um acoplamento flexível e alta coesão funcional.
- Isole falhas. Use estratégias de resiliência para impedir que falhas em um serviço distribuam-se em cascata.
- A rede é confiável;
- Latência é zero;
- A banda de internet é infinita;
- A rede é segura;
- A topologia de rede não muda; Existe somente UM administrador; Custo de transporte é zero;
- A rede é homogênea;
- Infrastructure as a Service significa entregar computação de infraestrutura sob demanda.
- É um dos 3 modelos de serviços da computação em nuvem.
- IaaS provê:
- Servidores: Computação e máquinas;
- Storage;
- Rede;
- Sistemas Operacionais;
- O usuário ao invés de adquirir softwares ou máquinas, espaço em data centers ou equipamentos de rede ele praticamente aluga espaços para estes recursos em uma infraestrutura externa.
- IaaS pode ser obtida em:
- Nuvem pública:
- É considerada nuvem pública uma infraestrutura que consiste de recursos compartilhados, liberados sob demanda baseado na internet.
- Nuvem privada:
- Incorpora a maioria das features de uma nuvem pública como virtualização porém fica dentro de uma rede privada.
- Nuvem Híbrida:
- Mistura de uma nuvem privada com uma nuvem pública, geralmente conectadas através de um túnel VPN.
- Nuvem pública:
- Recursos são distribuídos como serviço;
- Possibilita escalabilidade dinâmica;
- Custos variados;
- Quando a demanda for volátil, ou seja, você tem a possibilidade diminuir e aumentar sua capacidade computacional de acordo com a necessidade.
- Empresas sem capacidade de investimento em hardware.
- Empresas com crescimento rápido e necessidade de escala rápida de sua infraestrutura.
- Por estratégias de negócios rápidas.
- Quando a legislação não permitir guardar os dados fora da infraestrutura interna da empresa, ou a terceirização do armazenamento não é permitida.
- Não é aconselhável quando os níveis de desempenho necessários para aplicação tenham limite de acesso ao provedor da cloud.
- PaaS pode ser considerada IaaS adicionada uma camada middleware e/ou componentes prontos.
- Uma camada de abstração entre seu aplicativo em nuvem e seu provedor de IaaS.
- É um ambiente de execução escalável e com alta disponibilidade para aplicações customizadas.
- PaaS, é uma categoria de computação em nuvem que fornece uma plataforma e um ambiente para permitir que os desenvolvedores criem aplicativos e serviços pela Internet.
- Fornece fundamentalmente escala elástica do seu aplicativo.
- Infraestrutura na nuvem, escalável e com alta disponibilidade nativa.
- Alta produtividade no desenvolvimento e manutenção de aplicações sob demanda.
- Resumindo: baixo custo (TCO), confiabilidade e diminuição do tempo de entrega.
-
Desenvolvimento 100% focado no negócio:
- Por direcionar a arquitetura lógica e administrar a arquitetura física de forma bem transparente, é possível desenvolver uma aplicação que vá demandar uma requisição por minuto ou 10 mil requisições por segundo da mesma forma, com o mesmo nível de preocupação do ponto de vista técnico: apenas a lógica de negócio.
-
Produtividade
- O simples fato de não se gerenciar balanceamento de carga, replicação,cluster, instalando e configurando middlewares(servidores de aplicação, banco de dados, etc.) já é um grande ganho. Além disso, os grandes fornecedores estão criando camadas de componentes prontos para uso, APIs e aceleradores de desenvolvimento nessas plataformas.
- A plataforma por trás do PaaS foi criada justamente para trazer benefícios e acelerar o desenvolvimento. Existe esforço dos fornecedores para deixar essa camada o mais padrão possível, mas ainda existe uma boa parte que é proprietária.
- Ao adotar PaaS, é natural que se adote também essa camada proprietária, caso contrário, poderia se trabalhar direto na infraestrutura.
- É esta camada que permite dar um salto de produtividade e lidar com escalabilidade e disponibilidade de forma transparente.
- A decisão a ser tomada é: menos custo e mais entregas contra o efeito “lock-in” das aplicações construídas nessa abordagem.!
- Plataformas são muito eficientes para construção de novas aplicações.
- A migração de aplicações já existentes para elas é um processo custoso ou mesmo inviável (dependendo da tecnologia atual e da plataforma almejada).
- Somente uma base de código por aplicação;
- Vários deploys por aplicação;
- Desenvolvedor possui uma cópia local do repositório;
- Declare e isole explicitamente as dependências;
- Uma aplicação 12 fatores nunca confia na existência implícita de pacotes em todo o sistema;
- Uma declaração de dependência explícita é que simplifica a configuração da aplicação para novos desenvolvedores;
- Na prática:
- Tenha sempre um gerenciador de dependências configurado para seu projeto (maven, gradle, npm, pip e etc);
- A configuração de uma aplicação é tudo que é provável variar entre deploys(homologação, produção, desenvolvimento, etc).
- Uma aplicação 12 fatores armazena configuração em variáveis de ambiente ou algum recurso de configuração distribuída.
- Necessitamos de facilidade na troca de ambientes sem ter a necessidade de alterar o codebase.
- Trate serviços de apoio como recursos anexados;
- Serviço de apoio é qualquer serviço que o App consuma via rede como parte de sua operação normal:
- Ex: Banco de Dados, Mensageria, Cache.
- Não se deve fazer distinção entre serviços locais e terceiros;
- Uma base de código é transformada em um deploy através de 3 estágios:
- Construção: Converte o repositório em um pacote executável;
- Lançamento: Combina o artefato construído com a configuração do deploy.
- Execução: Roda o app no ambiente de execução através dos processos específicos do APP.
- O app 12 fatores utiliza separação estrita entre os estágios de construção, lançamento e execução.
- Você não deve introduzir estado em seus serviços; os aplicativos devem ser executados como um processo único e sem estado.
- Os processos dos Doze Fatores são stateless e não compartilham nada. Esse fator está no núcleo da arquitetura de microsserviços.
- Seu serviço deve estar visível para outras pessoas via ligação de alguma porta. Se você criou um serviço, verifique se outros serviços podem tratar isso como um recurso, se assim o desejarem. O aplicativo de doze fatores é completamente independente de outros recursos.
- Divida seu aplicativo em pequenos pedaços, em vez de tentar aumentar seu aplicativo (executando uma única instância na máquina mais poderosa disponível). Aplicativos pequenos e definidos permitem a expansão conforme necessário para lidar com as cargas variadas. O processo deve ser dimensionado individualmente, com o Fator 6 (sem estado), torna-se transparente este tipo de abordagem.
- Os processos devem consumir menos tempo. Certifique-se de poder correr e parar rapidamente. E que você pode lidar com falhas. Sem isso, o dimensionamento automático e a facilidade de implantação e desenvolvimento estão sendo diminuídos. Você pode conseguir isso com contêineres.
- Mantenha o desenvolvimento, a homologação e a produção o mais semelhante possível, para que qualquer pessoa possa utilizá-lo da mesma forma. A implantação contínua precisa de integração contínua com base em ambientes correspondentes para limitar desvios e erros. Isso também incentiva implicitamente uma cultura DevOps na qual o Desenvolvimento e as Operações de Software são unificados.
A conteinerização é uma grande ajuda aqui.
- Trate os logs como fluxos de eventos. O registro é importante para validar erros e também verificar a integridade geral do seu sistema. Ao mesmo tempo, seu aplicativo não deve se preocupar com o armazenamento dessas informações. Esses logs devem ser tratados como um fluxo contínuo capturado e armazenado por um serviço separado.
- Execute tarefas administrativas / gerenciamento como processos pontuais - tarefas como migração de banco de dados ou execução de scripts pontuais no ambiente. Para evitar mexer com o banco de dados, use as ferramentas criadas ao lado do aplicativo e isole completamente sua aplicação por exemplo.
- Containerizado;
- Gerenciado dinamicamente;
- Orientado a microserviços:
- Automação;
- Registro e Descoberta;
- Rastreamento distribuído / Observabilidade;
- Cloud:
- Elasticidade;
- Modelo on-demand;
- Devops:
- Processos;
- Ferramentas;
- Cultura;
- Entrega contínua:
- Automação;
- Microsserviços:
- Automação;
- Registro e Descoberta;
- Rastreamento distribuído / Observabilidade;
- Anti-fragilidade / Engenharia de caos;
- BOSH:
- Suporte a múltiplas clouds (evitar ficar preso a um provider);
- Separação clara entre sistemas;
- Provisionamento rápido;
- Escalabilidade;
- Monitoramento de saúde;
- Controle de falhas;
- Deploy canário;
- Arquiteturas cloud native aprimoram nossa capacidade de praticar DevOps e Entrega Contínua (Continuous Delivery), e elas exploram as características da infraestrutura na nuvem (Cloud Infrastructure).
- "Cloud-native" é um adjetivo que descreve as aplicações, arquiteturas, plataformas / infraestrutura, e processos que, em conjunto, tornam "econômico" trabalhar de forma a melhorar nossa capacidade de responder rapidamente às mudanças e reduzir a imprevisibilidade.
- Arquiteturas cloud-native aprimoram nossa capacidade de praticar DevOps e Continuous Delivery, e elas exploram as características da infraestrutura na nuvem. Eu defino arquiteturas cloud-native como tendo as seguintes seis qualidades:
- Modularidade (através de Microservices);
- Capacidade de observação;
- Implementabilidade;
- Testabilidade;
- Descartabilidade;
- Substituível;
- Criado para ser escalável;
- Tolerante a falhas;
- Decomposto em serviços;
- Envia o máximo trabalho para a plataforma se possível;
- Automatizado;
- Pequenos sistemas Linux minimalistas;
- Compartilhado Kernel do Host;
- Processos trabalhando isoladamente;
- Commits e versionamento de containers;
- Compartilhamento de ambientes customizados;
- Por que os contêineres são bons para micro serviços?
- Projetado para executar um aplicativo por contêiner;
- Separação natural da carga de trabalho;
- Muito leve;
- Ótimo para dimensionar rapidamente;
- Melhor uso de recursos;
- Os contêineres compartilham o SO host e, quando apropriado, Binários e bibliotecas;
- Formatos padrão de contêiner, como o Docker, são distribuições cruzadas entre linux compatível;
- Incrivelmente fácil de mover sua carga de trabalho • Equilibre melhor os recursos do sistema;
- Permita que os desenvolvedores trabalhem em um ambiente de produção simulado;
- Remove o problema "funcionou na minha máquina";
Tecnologia Open Source que permite criar, executar, testar e implantar aplicações distribuídas dentro de containers de software. Ele permite que você empacote um software de uma padronizada para o desenvolvimento de software, contendo tudo que é necessário para a execução: código, runtime, ferramentas, bibliotecas, etc. Docker permite que você implante aplicações rapidamente, de modo confiável e estável, em qualquer ambiente.
- Existem mais de 500 mil aplicações Dockerizadas, um crescimento de 3100% ao longo de 2 anos;
- Mais de 4 bilhões de containers já foram puxados até hoje;
- Docker é apoiado por uma grande e crescente comunidade de colaboradores e usuários;
- A adoção do Docker aumentou mais de 30% no último ano;
- Cerca de 30% dos containers Dockers estão rodando em produção. \29% das empresas que já ouviram falar em Docker planejam usá-lo;
A parte cliente fala com o Docker daemon, que faz o trabalho pesado de construção, execução e distribuição de seus containers e imagens Docker, também controla os recursos executados. O cliente Docker e Docker daemon, podem ser executados no mesmo sistema, também é possível conectar um cliente Docker a um Docker daemon remoto. O cliente Docker e daemon se comunicam através de uma API REST, através de sockets UNIX ou uma interface de rede, para execuções de comandos ou scripts.
- Containers tem como base sempre uma imagem, pense como na seguinte analogia do mundo Java, uma imagem é uma classe e um container é como um objeto instância dessa classe, então podemos através de uma imagem “instanciar” vários containers, também através de recursos chroot, Cgroups é possível definirmos limitações de recursos recursos e isolamento parcial ou total dos mesmos.
- Algumas características dos containers
- Portabilidade de aplicação;
- Isolamento de processos;
- Prevenção de violação externa;
- Gerenciamento de consumo de recursos;
Imagens são templates para criação de containers, como falado no slide anterior, imagens são imutáveis, para executá-las é necessário criar uma instância dela (container), também vale ressaltar que as imagens são construídas em camadas, o que facilita sua reutilização e manutenção. Em resumo uma imagem nada mais é do que um ambiente totalmente encapsulado e pronto para ser replicado onde desejar.
São scripts com uma série de comandos para criação de uma imagem, nesses scripts podemos fazer uma séries de coisas como executar comandos sh, criar variáveis de ambiente, copiar arquivos e pastas do host para dentro da imagem.
É como um repositório GIT, onde as imagens podem ser versionadas, comitadas, “puxadas” etc, quando recuperamos uma imagem, usando o comando docker pull por exemplo, estamos normalmente baixando a imagem de um registro Docker, o repositório oficial do Docker é o Docker HUB, onde é possível hospedar e versionar imagens públicas e privadas.
- Fundamentado na experiência de mais de 20 anos de Eric Evans no desenvolvimento de sistemas, o DDD é uma abordagem que reúne um conjunto de boas práticas, padrões, ferramentas e recursos da orientação a objetos que têm como objetivo a construção e desenvolvimento de sistemas de acordo com o domínio e regras de negócio do cliente.
- Além disso, questões relacionadas ao processo de desenvolvimento, como a necessidade de um estreito relacionamento entre a equipe de programadores e os especialistas do domínio, também são tratadas pela abordagem.
- O principal conceito do DDD é o modelo.
- O modelo expressa o domínio e negócio do cliente e pode ser criado utilizando desenhos, fluxogramas, diagramas, etc.
- O importante é que ele represente o negócio do cliente.
- Como principais componentes do DDD, podemos listar: a linguagem onipresente, a arquitetura em camadas e os padrões.
- É uma abordagem de desenvolvimento de software que reúne um conjunto de conceitos, princípios e técnicas cujo foco está no domínio e na lógica do domínio com o objetivo de criar um Domain Model ou (modelo do domínio).
- Significa desenvolver software de acordo com o domínio relacionado ao problema que estamos propondo resolver.
- O foco da abordagem é criar um domínio que “fale a língua” do usuário usando o que é conhecido como linguagem Ubíqua(ubiquitous language ou linguagem Comum,Onipresente)
- Linguagem Ubíqua (linguagem comum) entende-se que ao trabalhar com DDD devemos conversar usando uma mesma língua, em um único modelo, de forma que o mesmo seja compreendido pelo cliente, analista, projetista, desenhista, testador, gerente, etc. nesta linguagem, que seria a linguagem usada no dia a dia.
- O modelo é evolutivo: A cada iteração entre especialistas de domínio e a equipe técnica, o modelo se torna mais profundo e expressivo, mais rico, e os desenvolvedores transferem essa fonte de valor para o software.
- Assim, o modelo vai sendo gradualmente enriquecido com o expertise dos especialistas do domínio destilado pelos desenvolvedores, fazendo com que o time ganhe cada vez mais insight sobre o negócio e que esse conhecimento seja transferido para o modelo (para o código) através dos blocos de construção do DDD.
- Quando novas regras de negócio são adicionadas e/ou regras existentes são alteradas ou removidas, a implementação é refatorada para refletir essas alterações do modelo no código.
- No final, o modelo (que em última instância será o software) vai expressar com riqueza de conhecimento o negócio.
- O código fica menos acoplado e mais coeso.
- O negócio é melhor compreendido por todos da equipe o que facilita o desenvolvimento.
- Alinhamento do código com o negócio.
- Favorecer reutilização.
- Mínimo de acoplamento.
- Independência da Tecnologia.
- Event Storming é uma técnica de design rápido que engaja especialistas do domínio de negócios com desenvolvedores para que alcancem um ciclo rápido de aprendizagem (aprender o máximo possível no menor tempo possível
- Segundo Martin Flowler - Bounded Context (Contexto limitado) é um padrão central no design orientado a domínio.
- É o foco da seção de design estratégico da DDD que trata de lidar com grandes modelos e equipes. O DDD lida com modelos grandes, dividindo-os em diferentes contextos limitados e sendo explícito sobre suas inter-relações.
- Para encontrar os comandos, agregações e boundaries usaremos o conceito de Evento Storming;
- Event Storming é uma técnica de design rápido que engaja especialistas do domínio de negócios com desenvolvedores para que alcancem um ciclo rápido de aprendizagem (aprender o máximo possível no menor tempo possível;
- Use eventos de domínio para implementar explicitamente os efeitos colaterais de alterações em seu domínio. Em outras palavras, e usando terminologia DDD, use eventos de domínio para implementar explicitamente efeitos colaterais entre várias agregações.
- Opcionalmente, para melhor escalabilidade e menor impacto em bloqueios de banco de dados, use consistência eventual entre agregações dentro do mesmo domínio.
- Um evento é algo que ocorreu no passado. Um evento de domínio é algo que ocorreu no domínio que você deseja que outras partes do mesmo domínio (em processo) tenham conhecimento. As partes notificadas geralmente reagem de alguma forma aos eventos.
- Um benefício importante dos eventos de domínio é que os efeitos colaterais podem ser expressos explicitamente.
- Em resumo, eventos de domínio ajudam você a expressar, explicitamente, as regras de domínio, com base na linguagem ubíqua fornecida pelos especialistas do domínio. Os eventos de domínio também permitem uma melhor separação de interesses entre classes dentro do mesmo domínio.
- É importante garantir que, assim como uma transação de banco de dados, todas as operações relacionadas a um evento de domínio sejam concluídas com êxito ou nenhuma delas seja.
- Os eventos de domínio são parecidos com eventos do estilo de mensagens, com uma diferença importante. Com mensagens reais, enfileiramento de mensagens, agentes de mensagens ou um barramento de serviço que usa o AMQP, uma mensagem é sempre enviada de forma assíncrona e comunicação entre processos e computadores.
- Isso é útil para a integração de vários contextos delimitados, microsserviços ou até mesmo aplicativos diferentes. No entanto, com os eventos de domínio, ao acionar um evento na operação de domínio em execução no momento, você deseja que os efeitos colaterais ocorram dentro do mesmo domínio.
- A primeira etapa do Event Storming consiste em mapear os eventos que ocorrem no domínio que está sendo estudado.
- Um evento é qualquer coisa relevante que aconteceu no passado e tende a ser de simples compreensão para pessoas não técnicas.
- O padrão para descrever o evento é utilizar o verbo no passado e deve-se tentar mapear todos os eventos.
- Para essa etapa, utilizamos os post-its de cor laranja.
- Talvez possa existir um pouco de dificuldade inicial para explicar o que é um evento para os especialistas de negócios (não técnicos).
- O facilitador deve cuidar para que, sem que percebam, os participantes fujam do escopo da etapa e comecem a citar o mapeamento das entidades ou regras de negócios.
- Alguns exemplos de eventos identificados: Produto Ativado, Produto Desativado, Licença Utilizada, Licença Liberada, Novo Ambiente Criado.
- Nesta etapa, você muda da análise do domínio para os primeiros estágios do design do sistema.
- Até esse momento, você está simplesmente tentando entender como os eventos no domínio se relacionam - é por isso que a participação de especialistas em domínios é tão crítica.
- No entanto, para criar um sistema que implemente o processo de negócios em que você está interessado, é necessário passar à questão de como esses eventos ocorrem.
- Os comandos são o mecanismo mais comum pelo qual os eventos são criados.
- A chave para encontrar comandos é fazer a pergunta: "Por que esse evento ocorreu?".
- Nesta etapa, o foco do processo passa para a sequência de ações que levam a eventos;
- Seu objetivo é encontrar as causas pelas quais os eventos registram os efeitos. Os tipos de gatilhos de eventos esperados são:
- Um operador humano toma uma decisão e emite um comando;
- Algum sistema ou sensor externo fornece um estímulo (SEDA, EDA, Cron, Event Sourcing);
- Um evento resulta de alguma política - processamento tipicamente automatizado de um evento precursor;
- A conclusão de algum período determinado de tempo decorrido;
- Outra parte importante do processo que se torna mais detalhada nessa etapa é a descrição de políticas que podem acionar a geração de um evento a partir de um evento anterior (ou conjunto de eventos).
- Avalie se o elemento de dados é uma entidade comercial principal, identificada exclusivamente por uma chave, suportada por vários comandos.
- Tem uma vida útil ao longo do processo de negócios. Isso levará ao desenvolvimento de uma análise do ciclo de vida da entidade.
- Esse primeiro nível de definição de dados ajuda a avaliar o escopo e a responsabilidade do micro serviço à medida que você começa a ver pontos em comum emergindo dos dados usados entre vários eventos relacionados.
- O comando de disparo é identificado em um post-it azul.
- O comando pode se tornar uma operação de micro serviço exposta via API.
- A pessoa humana que emite o comando é identificada e mostrada em uma nota laranja.
- Alguns eventos podem ser criados aplicando políticas de negócios.
- Identificação dos comandos que geram os eventos;
- Geralmente os comandos estão associados à alguma ação do usuário, interação com sistema externo ou gerados por um temporizador/cron;
- Verbo na forma imperativa;
- Deve ser colocado no lado esquerdo do evento que ele gera;
- Durante o processo, é comum identificar que um comando pode gerar vários eventos;
- Agregação é um padrão no Domain Driven Design.
- Um agregado DDD é um cluster de objetos de domínio que podem ser tratados como uma única unidade.
- Um exemplo pode ser um pedido e seus itens de linha, esses serão objetos separados, mas é útil tratar o pedido (junto com seus itens de linha) como um único agregado.
- Um agregado terá um de seus objetos componentes como a raiz agregada. Quaisquer referências externas ao agregado devem apenas ir para a raiz agregada.
- A raiz pode assim garantir a integridade do agregado como um todo.
- Agregados são o elemento básico da transferência de armazenamento de dados - você solicita carregar ou salvar agregados inteiros. As transações não devem cruzar fronteiras agregadas.
- Às vezes, os agregados DDD são confundidos com as classes de coleção (listas, mapas, etc.). Agregados DDD são conceitos de domínio (ordem, visita à clínica, lista de reprodução), enquanto as coleções são genéricas.
- Um agregado geralmente contém coleções múltiplas, junto com campos simples.
- O termo "agregado" é comum e é usado em vários contextos diferentes (por exemplo, UML), caso em que não se refere ao mesmo conceito que um agregado DDD.
- Os aggregates são a parte do sistema que recebem os comandos e que geram os eventos, eles são os objetos que armazenam os dados e são modificados pelos comandos.
- Aplicativos tradicionais têm usado frequentemente transações de banco de dados para impor a consistência.
- Em um aplicativo distribuído, no entanto, isso muitas vezes não é viável.
- Uma única transação empresarial pode abranger vários repositórios de dados, ser demorada ou envolver serviços de terceiros.
- Por fim, cabe ao aplicativo, não à camada de dados, impor as variáveis necessárias para o domínio. É isso que as agregações destinam-se a modelar.
- São a parte do sistema que recebem os comandos e que geram os eventos, eles são os objetos que armazenam os dados e são modificados pelos comandos.
- Pode-se utilizar o nome entidade ou dado quando falar sobre Aggregate.
- Durante o exercício, pode ser que os Aggregates se repitam ao longo da linha do tempo, mas não se deve agrupá-los.
- Bounded Context é um padrão central no design orientado a domínio.
- É o foco da seção de design estratégico da DDD que trata de lidar com grandes modelos e equipes.
- O DDD lida com modelos grandes, dividindo-os em diferentes contextos limitados e sendo explícito sobre suas inter-relações.
- À medida que você tenta modelar um domínio maior, fica progressivamente mais difícil criar um único modelo unificado.
- Diferentes grupos de pessoas usarão vocabulários sutilmente diferentes em diferentes partes de uma grande organização.
- A precisão da modelagem rapidamente se depara com isso, muitas vezes levando a muita confusão. Normalmente, essa confusão se concentra nos conceitos centrais do domínio.
- Contextos limitados têm conceitos não relacionados (como um tíquete de suporte existente apenas em um contexto de suporte ao cliente), mas também compartilham conceitos (como produtos e clientes).
- Contextos diferentes podem ter modelos completamente diferentes de conceitos comuns, com mecanismos para mapear entre esses conceitos polissêmicos para integração.
- Vários fatores traçam limites entre contextos.
- Normalmente, a dominante é a cultura humana, já que os modelos agem como linguagem onipresente, você precisa de um modelo diferente quando a linguagem muda.
- Você também encontra vários contextos no mesmo contexto de domínio, como a separação entre os modelos de banco de dados relacional e na memória em um único aplicativo.
- Esse limite é definido pela maneira diferente como representamos os modelos.
- Podem estar relacionados à divisões departamentais.
- Podem ser diferentes visões que os especialistas do negócio possuem sobre o mesmo conceito.
- Agregadores que são importantes.
- Mapear eventos que “naveguem” entre os domínios.
-
Síncrona:
- Espera resposta;
- Comunicação em “tempo real”;
- Balanceador de carga a nível de infraestrutura;
- Tratamento de erros pode ser pelo status do http;
-
Assíncrona:
- Não espera resposta;
- Comunicação entre os dados pode ser “delay” entre as estruturas;
- Balanceador de carga pode ser uma fila;
- Possibilidade de Service Discovery / Message broker;
- Tratamento de erros pode ficar no gerenciador da fila;
- Em caso de erros o gerenciador de mensagens pode tratar o reenvio;
- Mudanças de estado;
- Dispare e esqueça;
- Atores de eventos (consumidores x produtores);
- Acontecimentos no passado;
- Estados imutáveis;
- Diminui acoplamento entre aplicações;
- Processos assíncronos;
- Encaixa perfeitamente com patterns (CQRS / DDD);
- Reprodução de estados;
- Segundo Martin Fowler, 4 temas estão sempre presentes:
- Event Notification;
- Event-carried state transfer;
- Event Sourcing;
- CQRS;
- Arquitetura distribuída;
- Arquitetura Microsserviços;
- Volumetria dos dados;
- Responsividade;
- Escalabilidade;
-
Suporte a demanda de negócio com melhor serviço:
- menos espera, sem processos batch;
-
Sem integrações ponto a ponto:
- Dispare e esqueça;
-
Possibilita grandes performances:
- Uso de brokers poderosos (Kafka);
- Processo sincronizado de comunicação;
- Possui uma lógica na sequência de eventos;
- Existe um ponto de partida e chegada;
- Você sabe exatamente o resultado ao final da execução; Acoplamento apertado;
- Confiança em APIs RESTFull;
- Acoplamento de serviço solto para agilidade e tolerância a falhas;
- Desenvolvimento mais rápido e ágil;
- Aplicações mais consistentes e eficientes;
- Uma desvantagem da orquestração é que o controlador das chamadas precisa se comunicar diretamente com cada serviço e aguardar a resposta de cada um deles. Agora que essas interações estão ocorrendo na rede, as invocações demoram mais e podem ser afetadas pela disponibilidade da rede e do serviço que está sendo invocado.
- Em ambientes menores, isso pode funcionar bem, mas as coisas desmoronam quando você está falando de centenas ou mesmo milhares de microsserviços. Você basicamente criou um aplicativo monolítico distribuído que é mais lento e quebradiço do que os do passado! Assim como um maestro perderia sua capacidade de gerenciar efetivamente uma orquestra maciça, porque cada músico aguarda atenção individual, não é viável solicitar a um serviço de controle para gerenciar tantos microsserviços.
- Fluxos de longa duração:
- Coreografia pode ter um longo fluxo de ações a serem realizadas. Referindo-se ao termo "longa duração", queremos dizer que pode levar minutos, horas ou até semanas até que o processamento do pedido seja concluído;
- Colaboração de eventos:
- O ponto central da idéia de colaboração de eventos é que todos os microsserviços publicarão eventos quando algo relevante para o negócio acontecer dentro deles. Outros serviços podem se inscrever nesse evento e fazer algo com ele, por exemplo armazenar as informações associadas de forma ideal para seus próprios fins;
- Transformação de comando de evento:
- Por definição, um evento visa informá-lo sobre um fato relevante que ocorreu e que algum outro serviço pode estar interessado. Mas, no momento em que exigimos que um serviço acompanhe um evento, usamos esse evento como se tivesse o significado semântico de um comando. A consequência disso: acabamos com um acoplamento mais apertado do que o necessário.
- Uma saga é uma sequência de transações locais. Cada serviço em uma saga realiza sua própria transação e publica um evento. Os outros serviços ouvem esse evento e executam a próxima transação local. Se uma transação falhar por algum motivo, a saga também executa transações de compensação para desfazer o impacto das transações anteriores.
- Quando um usuário faz um pedido em um serviço de delivery, pode existir esta sequência de ações:
- O serviço de pedidos de comida cria um pedido. Neste ponto, o pedido está em um estado PENDENTE. Uma saga gerencia a cadeia de eventos.
- A saga entra em contato com o restaurante através do serviço de restaurante.
- O serviço de restaurante tenta fazer o pedido no restaurante escolhido. Depois de receber uma confirmação, ele envia uma resposta.
- A saga recebe a resposta. E, dependendo da resposta, ele pode aprovar o pedido ou rejeitá-lo.
- O serviço de pedido de comida altera o estado do pedido. Se o pedido fosse aprovado, informaria o cliente com os próximos detalhes. Se rejeitado, também informará o cliente com uma mensagem de desculpas.
- Saga baseada em Orquestração:
- Nessa abordagem, existe um orquestrador Saga que gerencia todas as transações e direciona os serviços participantes para executar transações locais com base em eventos. Este orquestrador também pode ser considerado um SAGA MANAGER.
- Saga baseada em Coreografia:
- Nesta abordagem, não há orquestrador central. Cada serviço participante da Saga realiza suas transações e publica eventos. Os outros serviços atuam sobre esses eventos e realizam suas transações. Além disso, eles podem ou não publicar outros eventos com base na situação de negócio.
- Uma prática de desenvolvimento de software onde os membros do time de desenvolvimento integram seu trabalha constantemente;
- Cada integração é feita automaticamente por um processo para detectar falhas rapidamente;
- Reduz drasticamente problemas de integração e possibilita o desenvolvimento de um software seguro e coeso;
- Escreva testes automatizados para desenvolvedores;
- Execute compilações privadas;
- Confirme código com frequência;
- Não confirme código com defeito;
- Evite obter código com defeito;
- Corrija construções com defeito imediatamente;
- Todos os testes e inspeções devem passar;
- Quão frequentes você entrega software em produção para os seus usuários?
- Mais de uma vez por dia?
- Mais de uma vez por semana?
- Mais de uma vez por mês?
- Mais de uma vez por ano?
- Uma vez por ano ou menos?
- Releases entregue em produção de forma frequente:
- Medida real de progresso
- Feedback do usuário
- Reduz consideravelmente o risco de release
- Princípios:
- Cada commit gera um release candidate;
- Automatize tudo que pode ser automatizado;
- If it hurts, do it more often and bring the pain forward”;
- A qualidade interna é obrigatória;
- Testes automatizados são essenciais;
- Todo mundo é responsável pela release;
- Pronto significa released;
- Melhoria Contínua(Continuous Improvement);
- Commit Stage:
- Poll SCM;
- Compilação;
- Cobertura dos testes;
- Unitários e integração;
- Qualidade do código fonte;
- Conformidades com padrões empresariais;
- Possíveis bugs;
- Boas práticas;
- Empacotamento e publicação;
- Acceptance Stage:
- Testes automatizados;
- Testes funcionais;
- Testes de aceitação;
- Testes de performance;
- Testes de segurança;
- Automatização + testes = sucesso;
- Reduza os riscos com releases incrementais;
- Existem inúmeras formas de se construir um build pipeline. Descubra a sua;
- Cultura de DevOps é necessária;
- Prepare-se: quanto tempo você demora para reconstruir o seu ambiente a partir do zero?
- Dificuldades:
- Exige mudança cultural;
- Maior dificuldade encontrada nas implantações de Continuous Delivery;
- Exige Ciclos Curtos;
- Empresas organizadas em silos/áreas;
- Requer envolvimento de todos;
- Também chamada de cliente / servidor
- Pode ser síncrono ou assíncrono
- O cliente envia uma requisição ao servidor
- O servidor retorna uma resposta ao cliente\
- Ou ocorre um erro!
- Há um alto acoplamento entre o cliente e o servidor
- Ambos serviços precisam estar responsivos no momento
- Uma falha no servidor gera uma falha no cliente
- Produtor ou publicador: gera as mensagens
- Consumidor ou subscritor: notificado quando há mensagens
- Há um desacoplamento entre o produtor e o consumidor
- Estrutura em que cada mensagem produzida por um produtor é entregue a um único consumidor
- Adequado para a distribuição de carga
- Quando não há nenhum consumidor registrado ou disponível, a mensagem geralmente é armazenada
- Assim que um consumidor estiver disponível, a mensagem é entregue
- Estrutura em que cada mensagem produzida por um produtor é entregue a todos os consumidores registrados
- Multicast
- Geralmente não há persistência das mensagens
- Somente consumidores registrados no momento em que a mensagem é gerada a recebem
- Sistema especializado em recepção e envio de mensagens
- Desconhece detalhes sobre os produtores e consumidores
- Capazes de persistir mensagens
- Capazes de entregar novamente uma mensagem em caso de falha do consumidor
- Existem diversos serviços de mensageria bem conhecidos
- Exemplos: Kafka, ActiveMQ, RabbitMQ
- Um message broker confiável é essencial em uma arquitetura de microsserviços
- Importante evitar um ponto único de falha!
- Ou seja, um componente que, caso falhe, impacta ou indisponibiliza o sistema todo!
- Replicação / redundância
- Também é importante lidar com problemas de escalabilidade
- Monitoramento constante, já que tende a ser um componente do sistema bastante demandado
- Os exemplos de código a seguir utilizam o protocolo AMQP (Advanced Message Queuing Protocol)
- Implementado pelo ActiveMQ, RabbitMQ e outros
- Escritos em TypeScript, rodando sobre nodejs
- https://github.com/luisfpg/produtor-consumidor
- Há uma única tentativa de entrega da mensagem
- Ela é perdida em caso de erro
- Nenhum estado é mantido, portanto é a implementação mais simples e rápida
- deal para IoT, por exemplo, com sensores constantemente enviando medições
- Mas não pode ser usada quando perdas eventuais de mensagens não são toleradas
- É realizada a entrega da mensagem. Em caso de erro ou limite de tempo, ela será entregue novamente
- Há necessidade de manter estado no componente de entrega
- Poderá duplicar o processamento ou resultado
- Por isso é essencial que o tratamento de mensagens seja idempotente, isto é, não deixe o estado do sistema inconsistente se executado mais de uma vez
- Há a garantia de que cada mensagem seja entregue uma única vez, mesmo que hajam falhas ou limite de tempo
- É o mecanismo mais complexo, pois exige estado em ambos os componentes de entrega e recepção
- O componente de envio deve manter estado para retransmitir mensagens falhadas...
- ... e o de recepção deve manter estado para ignorar mensagens que já tenham sido previamente enviadas
- Nesta abordagem, o sistema gera mensagens que representam eventos que ocorrem em um microsserviço
- Para que outros microsserviços possam reagir de acordo
- Exemplos:
usuario:registrado:<id>pedido:realizado:<id>pagamento:aprovado:<id>- ...
- Semelhante a eventos de domínio, mas com os dados
- Importante cuidar do versionamento / lock otimista
- Exemplo:
{ "evento": "usuario:atualizado", "versao": 3, "nome": "Fulano", "email": "fulano@email.com", "login": "fulano" }
- Neste caso, os consumidores são “trabalhadores”
- Cada evento contém uma seleção do que será processado
- Identificador(es), intervalo de datas, etc
- Exemplo: quando há grandes volumes de dados a serem processados, pode-se dividir o processamento
- Aplicações serverless necessitam de um servidor para rodar!
- Mas elas não sabem qual servidor vai rodá-las
- O conceito de serverless é geralmente relacionado ao FaaS
- Function as a service
- Mas o conceito pode ser considerado mais amplo
- Serviços gerenciados (bases de dados, buscas, mensageria, etc) também podem ser considerados serverless
- Aplicações serverless retiram do operador do sistema a responsabilidade de gerenciar a infraestrutura do sistema
- Atualizações de segurança do sistema operacional
- Atualizações do software de base (bibliotecas)
- Administração de capacidade ou escala
- Assim, o desenvolvedor / operador pode focar-se apenas na aplicação
- Neste modelo, o desenvolvedor empacota funções
- Geralmente é utilizado um container (como o Docker)
- A medida que há demanda, o ambiente aloca recursos para executar a função
- Quando a demanda cessa, o ambiente libera recursos
- Adequado para funções de processamento, não para sistemas de persistência de dados
- Todos os principais provedores cloud ofertam FaaS
- Mas... Cuidado com o vendor lock-in!
- Ocorre se as funções forem escritas utilizando a API de um provedor específico
- Neste caso será muito difícil uma eventual migração para outro provedor se necessário
- Otimização de custos, pois somente será cobrado quando houver demanda
- Escala flexível: a infraestrutura vai alocar mais recursos com o aumento de demanda, e desalocar recursos desnecessários
- Inclusive até chegar ao ponto de nenhum recurso alocado, ou seja, custo zero
- Aumento na complexidade da infraestrutura
- Difícil prever o custo final, pois depende da demanda
- Maior dificuldade na depuração
- O código de cada função é isolado em um container
- Quando é necessário aumentar a escala, pode ocorrer um atraso devido ao tempo necessário para inicializar a função
- O tempo de “aquecimento” da função pode impactar na experiência do usuário. O Java é um exemplo notável.
-
Uma solução padronizada emerge: Knative
-
Roda sobre o Kubernetes (k8s), que é um padrão de fato
- Suportado pela grande maioria dos provedores de cloud
-
Expõe cada função em um containers (Docker)
-
O Knative atribui uma URL para invocar cada função
-
A função deve levantar um servidor HTTP
-
O Knative roteia uma requisição para a função
-
Como a única responsabilidade da função é escutar em uma porta e retornar uma resposta, ela pode ser escrita em qualquer linguagem de programação
- Funciona com containers (Docker)
- Resolução DNS e balanceamento de carga para os serviços
- Escalonamento de serviços, permitindo inclusive a auto-escala (aumento e diminuição na quantidade de réplicas de um serviço de acordo com a demanda)
- O Kubernetes é um sistema complexo
- Mas que busca resolver um problema complexo
- Pode ser instalado desde a máquina do desenvolvedor...
- KinD (Kubernetes in Docker) ou Minikube
- ... até clusters de milhares de nodos!
- Na versão 1.25, até 5.000 nodos!
- O exemplo de código a seguir é escrito em TypeScript, rodando sobre nodejs
- É utilizada a biblioteca Hapi
- Disponível em: https://github.com/luisfpg/exemplo-knative
- Nem todo o tipo de aplicação é adequado para o modelo
- Ideal para funções disparadas por eventos
- Sensores
- Eventos do domínio de negócio que demandam processamento adicional
- Processamento multimídia
- Extração, transformação e carga (ETL) de dados
- Mas não para aplicações que ficam o tempo todo rodando
- Ou que fazem processamentos excessivamente longos
- Como o container que roda a função é efêmero, isto é, será criado e destruído muitas vezes, ele deve:
- Iniciar rápido (milisegundos)
- Ocupar pouca memória
- Responder rápido
- As funções não devem ter estado! Qualquer estado deve ser lido a cada execução da base de dados
- Alguns provedores limitam o tempo máximo que uma função pode rodar (10 - 15 minutos)
- A arquitetura de microsserviços é uma evolução natural da arquitetura monolítica
- Incorpora aspectos como comunicação de rede, escalabilidade, distribuição / replicação e muito mais!
- Ou seja: é um mundo complexo!
- São muitos conceitos, aspectos, modelos e tecnologias em constante evolução...
- Mas todos esses elementos foram desenvolvidos a partir da necessidade de sistemas mais escaláveis e confiáveis
- Nestes casos, o monolito não é a melhor opção
- Ou mesmo uma opção viável!
- Fica a sugestão: a melhor forma de consolidar todos os conceitos apresentados é com a prática!
Em 15/12/2023 - Nota 9 - 1º