Tag: dev

Página 229

Ao escolher o tipo do modelo de cache a usar com a arquitetura baseada em espaço, lembre-se de que, na maioria dos casos, ambos os modelos serão aplicáveis em determinado contexto do aplicativo, ou seja, os caches replicado e distribuído não resolvem todos os problemas. Em vez de tentar fazer concessões por meio de um único modelo de cache consistente no aplicativo, utilize o ponto forte de cada um. Por exemplo, para uma unidade de processamento que mantém o inventário atual, escolha um modelo de cache distribuído para a consistência dos dados; para uma unidade de processamento que mantém o perfil do cliente, escolha um cache replicado para desempenho e tolerância a falhas.

Observações sobre o Near-Cache

Near-cache é um tipo de modelo híbrido de cache ligando as grades de dados em memória e um cache distribuído. Nesse modelo (Figura 15-14), o cache distribuído é referido como full backing cache e cada grade de dados in-memory contida em cada unidade de processamento é referida como front cache. O front cache sempre contém um subconjunto menor do full backing cache e utiliza uma política de remoção para excluir os itens mais antigos para que os mais novos possam ser adicionados. O front cache pode ser o que é conhecido como cache MRU (mais recentemente utilizado), contendo os itens usados mais recentes, ou um cache MFU (mais frequentemente usado), contendo os itens usados com mais frequência. Uma alternativa seria uma política de remoção com substituição aleatória, que pode ser usada no cache de frontend para que os itens sejam removidos de modo aleatório quando é necessário espaço para adicionar um novo item. A substituição aleatória (Random Replacement ou RR, em inglês) é uma boa política de remoção quando não há uma análise clara dos dados em relação a manter o de uso mais recente versus mais frequente.

Figura 15-14. Topologia de near-cache Embora os caches de front-end sejam sempre mantidos sincronizados com o full backing cache, os caches de front-end contidos em cada unidade de processamento não são sincronizados entre outras unidades de processamento que compartilham os mesmos dados. Isso significa que várias unidades de processamento que compartilham o mesmo contexto de dados (como perfil do cliente) provavelmente terão dados diferentes em seu front cache. Isso cria inconsistências no desempenho e na resposta entre as unidades porque cada unidade contém dados diferentes no

Página 230

front cache. Por isso, não recomendamos usar um modelo de near-cache para a arquitetura baseada em espaço.

Exemplos de Implementação

A arquitetura baseada em espaço é muito adequada para aplicativos com altos picos no volume de usuários ou requisições e aplicativos com taxa de transferência acima de 10 mil usuários simultâneos. Exemplos dessa arquitetura incluem aplicativos como sistemas de ingressos para concertos online e sistemas de leilão online. Os dois exemplos requerem desempenho, escalabilidade e níveis de elasticidade altos.

Sistema de Ingressos para Concertos

Os sistemas de ingressos para concertos têm um domínio de problema único no sentido de que o volume de usuários simultâneos é relativamente baixo até ser anunciado um concerto popular.

Assim que os ingressos são colocados à venda, em geral os volumes de usuários têm um pico de várias centenas de usuários simultâneos para vários milhares (possivelmente dezenas de milhares, dependendo do concerto), todos tentando conseguir um ingresso (tomara que com bons lugares!). Os ingressos costumam esgotar em minutos, requerendo características de arquitetura que são oferecidas pela arquitetura baseada em espaço.

Existem muitos desafios associados a esse sistema. Primeiro, há apenas certo número de ingressos disponível, independentemente das preferências de lugar. A disponibilidade de assentos deve ser atualizada continuamente e disponibilizada o mais rápido possível, dado o alto número de requisições simultâneas. E mais, supondo que os lugares atribuídos são uma opção, a disponibilidade de assentos também deve ser atualizada o mais rápido possível.

Acessar continuamente um banco de dados central de forma síncrona para esse tipo de sistema provavelmente não funcionaria; seria muito difícil para um BD típico lidar com dezenas de milhares de requisições simultâneas por meio das transações de banco de dados padrão nesse nível de escala e frequência de atualização.

A arquitetura baseada em espaço seria boa para um sistema de ingressos para concerto devido aos altos requisitos de elasticidade desse aplicativo. Um aumento instantâneo no número de usuários simultâneos esperando para comprar os ingressos seria imediatamente reconhecido pelo gerenciador de implementação, que, por sua vez, iniciaria um grande número de unidades de processamento para lidar com o grande volume de requisições. O ideal é que o gerenciador seja configurado para iniciar o número necessário de unidades de processamento um pouco antes de os ingressos serem colocados à venda, tendo essas instâncias em standby um pouco antes do aumento significativo na carga de usuários.

Sistema de Leilão Online

Os sistemas de leilão online (dar lances em itens em um leilão) compartilham as mesmas características dos sistemas de ingressos online descritos antes, ou seja, ambos requerem altos níveis de desempenho e elasticidade e ambos têm picos imprevisíveis na carga de usuários e requisições. Quando um leilão inicia, não há como determinar quantas pessoas participarão dele e, dessas pessoas, quantos lances simultâneos ocorrerão para cada valor pedido.

Página 231

A arquitetura baseada em espaço seria boa para esse tipo de problema no sentido de que várias unidades de processamento podem ser iniciadas conforme a carga aumenta; e quando o leilão acalma, as unidades não usadas podem ser destruídas. Unidades de processamento individuais podem ser dedicadas a cada leilão, assegurando a consistência nos dados dos lances. E mais, devido à natureza assíncrona dos data pumps, esses dados podem ser enviados para outro processamento (como o histórico de lances, análise do lance e auditoria) sem muita latência, aumentando o desempenho geral do processo dos lances.

Classificações das Características da Arquitetura

Uma estrela na tabela de classificações das características na Figura 15-15 significa que a característica específica não é bem suportada na arquitetura, já cinco estrelas significam que a característica é um dos recursos mais fortes no estilo. A definição de cada característica identificada no placar pode ser encontrada no Capítulo 4.

Figura 15-15. Classificações das características da arquitetura baseada em espaço

Página 232

Note que a arquitetura baseada em espaço maximiza a elasticidade, a escalabilidade e o desempenho (todos com cinco estrelas). São os atributos condutores e principais vantagens desse estilo. Os altos níveis das três características são conseguidos utilizando o cache de dados em memória e removendo o BD como uma restrição. Como resultado, é possível processar milhões de usuários simultâneos usando esse estilo de arquitetura.

Embora os altos níveis de elasticidade, escalabilidade e desempenho sejam vantagens aqui, há um trade-off, especificamente em relação à simplicidade geral e à testabilidade. A arquitetura baseada em espaço é um estilo muito complicado devido ao uso do cache e da eventual consistência do armazenamento de dados primário, que é o sistema definitivo de registro.

Muito cuidado ao assegurar que nenhum dado seja perdido no caso de uma falha em uma das várias partes móveis nesse estilo (veja “Evitando a Perda de Dados”, no Capítulo 14).

A testabilidade tem uma estrela devido à complexidade envolvida em simular os altos níveis de escalabilidade e elasticidade suportados no estilo. Testar centenas de milhares de usuários simultâneos na carga de pico é uma tarefa muito complicada e cara e, como resultado, a maioria dos testes de alto volume ocorre em ambientes de produção com uma carga extrema real. Isso produz um risco significativo para a operação normal em tal ambiente.

O custo é outro fator ao escolher esse estilo. A arquitetura baseada em espaço é relativamente cara, em grande parte devido a taxas de licença para produtos em cache e à alta utilização de recursos nos sistemas em nuvem e locais devido às altas escalabilidade e elasticidade.

É difícil identificar o particionamento da arquitetura baseada em espaço e, assim, nós a identificamos como particionada por domínio e tecnicamente. Essa arquitetura é particionada por domínio não apenas porque se alinha com um tipo específico de domínio (sistemas altamente elásticos e escaláveis), mas também por causa da flexibilidade das unidades de processamento. Essas unidades podem agir como serviços de domínio do mesmo modo que os serviços são definidos em uma arquitetura baseada em serviços ou de microsserviços. Ao mesmo tempo, a arquitetura baseada em espaço é tecnicamente particionada no sentido de que separa as preocupações sobre o processamento transacional com cache e o armazenamento de dados real no BD via data pumps. Unidades de processamento, data pumps, leituras/gravações de dados e BD formam uma camada técnica em termos de como as requisições são processadas, muito semelhantemente a como uma arquitetura com n camadas monolíticas é estruturada.

O número de quanta na arquitetura baseada em espaço pode variar com base em como a IU é planejada e a comunicação acontece entre as unidades de processamento. Como as unidades não se comunicam de modo síncrono com o BD, o próprio BD não faz parte da equação do quantum. Assim, os quanta em uma arquitetura baseada em espaço normalmente são delineados pela associação entre as várias IUs e as unidades de processamento. As unidades que se comunicam de modo síncrono entre si (ou pela grade de processamento para a orquestração) fariam parte do mesmo quantum arquitetural.

Página 233

16. Arquitetura Orientada a Serviços e Baseada em Orquestração

CAPÍTULO 16 Arquitetura Orientada a Serviços e Baseada em Orquestração Os estilos de arquitetura, como os movimentos da arte, devem ser entendidos no contexto da época na qual se desenvolveram, e essa arquitetura exemplifica essa regra mais do que qualquer outra. A combinação das forças externas que costumam influenciar as decisões da arquitetura, junto a uma filosofia organizacional lógica, mas definitivamente desastrosa, condenou essa arquitetura à irrelevância. Mas é um ótimo exemplo de como certa ideia organizacional pode ter um sentido lógico, embora impeça as partes mais importantes do processo de desenvolvimento.

História e Filosofia

Esse estilo de arquitetura orientada a serviços apareceu quando os negócios se tornaram empresas no final dos anos 1990: fusão com empresas menores, crescimento em um ritmo acelerado e necessidade de uma TI mais sofisticada para incluir esse crescimento. Porém, os recursos computacionais eram escassos, preciosos e comerciais. A computação distribuída teve que ser disponibilizada e se tornou necessária, e muitas empresas precisaram de uma escalabilidade variável e de outras características vantajosas.

Muitos estímulos externos forçaram os arquitetos da época a seguirem com arquiteturas distribuídas com grandes limitações. Antes dos SOs de código aberto serem considerados confiáveis o bastante para um trabalho sério, tais sistemas eram caros e licenciados por máquina. Do mesmo modo, os servidores do banco de dados comerciais vinham com esquemas de licença intricados, fazendo os revendedores do servidor do aplicativo (que ofereciam um pool de conexões do banco de dados) lutarem com os revendedores do banco de dados. Assim, os arquitetos deviam reutilizar o máximo possível. Na verdade, a reutilização em todas as formas se tornou a filosofia dominante nessa arquitetura, com os efeitos colaterais vistos em “Reutilização… e Acoplamento”.

Esse estilo também exemplifica até que ponto os arquitetos podem defender a ideia de particionamento técnico, que tinha boas motivações, mas consequências ruins.

Topologia

A topologia desse tipo de arquitetura orientada a serviços é mostrada na Figura 16-1.

Página 234

Taxonomia

Serviços do Negócio

Serviços Corporativos

Página 235

que compõem os serviços comerciais granulares grandes, ligados via mecanismo de orquestração.

Essa separação de responsabilidade flui a partir da meta de reutilização nessa arquitetura. Se os desenvolvedores conseguirem criar serviços menores da empresa no nível correto de granularidade, o negócio não terá que reescrever parte do fluxo de trabalho corporativo novamente. Aos poucos, aumentará a coleção de ativos reutilizáveis na forma de serviços reutilizáveis da empresa.

Infelizmente, a natureza dinâmica da realidade desafia essas tentativas. Os componentes corporativos não são materiais de construção, com soluções durando décadas. Mercados, mudanças na tecnologia, práticas de engenharia e muitos outros fatores confundem as tentativas de impor uma estabilidade no mundo do software.

Serviços do Aplicativo

Nem todos os serviços na arquitetura requerem o mesmo nível de granularidade ou reutilização dos Serviços Corporativos. Os serviços do aplicativo são serviços únicos com uma implementação. Por exemplo, talvez um aplicativo precise da geolocalização, mas a organização não deseja dedicar tempo nem esforço para tornar isso um serviço reutilizável. Um serviço do aplicativo, em geral pertencendo a uma equipe do aplicativo, resolve esses problemas.

Serviços da Infraestrutura

Serviços da infraestrutura fornecem as questões operacionais, como monitoramento, gerenciamento de logs, autenticação e autorização. Esses serviços tendem a ser implementações concretas, pertencendo a uma equipe de infraestrutura compartilhada que trabalha de perto com os profissionais de DevOps.

Mecanismo de Orquestração

O mecanismo de orquestração é o centro da arquitetura distribuída, unindo as implementações do serviço do negócio usando a orquestração, incluindo recursos como coordenação transacional e transformação da mensagem. Essa arquitetura costuma estar ligada a um banco de dados relacional ou a alguns, em vez de um database-per-service (banco de dados por serviço), como nas arquiteturas de microsserviços. Assim, o comportamento transacional é lidado de modo declarativo no mecanismo de orquestração, não no banco de dados.

Esse mecanismo define a relação entre os serviços do negócio e da empresa, como eles mapeiam juntos e onde ficam os limites da transação. Também age como um hub de integração, permitindo que os arquitetos integrem um código personalizado com pacotes e sistemas de software de herança.

Como o mecanismo é o centro da arquitetura, a lei de Conway (veja “Lei de Conway”, no Capítulo 8) prevê corretamente que a equipe dos arquitetos de integração responsável por esse mecanismo se torna uma força política dentro da organização, sendo um gargalo burocrático.

Embora essa abordagem possa parecer atraente, na prática é um grande desastre. Descarregar o comportamento de transação em uma ferramenta de orquestração parecia bom, mas encontrar o nível certo de granularidade das transações ficou cada vez mais difícil. Ao passo que criar

Página 236

Fluxo das Mensagens

Reutilização… e Acoplamento

Página 237

Página 238

Página 239

Classificações das Características da Arquitetura

Muitos critérios modernos que usamos para avaliar a arquitetura hoje não eram prioridades quando essa arquitetura era popular. Na verdade, o movimento de software ágil acabou de começar e ainda não entrou nas organizações que têm um tamanho que as torne propensas de usar essa arquitetura.

Uma estrela na tabela de classificações na Figura 16-5 significa que a característica específica não é muito suportada na arquitetura, já cinco estrelas significam que ela é um dos recursos mais fortes no estilo da arquitetura. A definição de cada característica identificada no placar pode ser encontrada no Capítulo 4.

Talvez a arquitetura orientada a serviços seja a arquitetura de finalidade geral mais tecnicamente particionada já experimentada! De fato, a reação contra as desvantagens dessa estrutura levou a arquiteturas mais modernas, como os microsserviços. Ela tem um quantum, mesmo que seja uma arquitetura distribuída por dois motivos. Primeiro, ela normalmente usa um banco de dados ou apenas alguns, criando pontos de acoplamento na arquitetura em muitas questões diferentes. Segundo, e mais importante, o mecanismo de orquestração age como um ponto de acoplamento gigante, ou seja, nenhuma parte da arquitetura pode ter características diferentes do mediador que orquestra todo o comportamento. Assim, essa arquitetura consegue ter as desvantagens das arquiteturas monolítica e distribuída.

Página 240

Figura 16-5. Classificações da arquitetura orientada a serviços Os objetivos da engenharia moderna, como implementabilidade e testabilidade, são um desastre na pontuação dessa arquitetura, porque têm um suporte ruim e não eram objetivos importantes (ou mesmo atraentes) na época.

Essa arquitetura tinha suporte para alguns objetivos, como elasticidade e escalabilidade, apesar das dificuldades de implementar esses comportamentos, pois os fornecedores da ferramenta se esforçaram bastante para tornar esses sistemas escaláveis, implementando a replicação de sessões em servidores de aplicativos e outras técnicas. Mas sendo uma arquitetura distribuída, o desempenho nunca foi um destaque desse estilo e era muitíssimo ruim porque cada requisição comercial era dividida em grande parte da arquitetura.

Devido a todos esses fatores, a simplicidade e o custo têm uma relação inversa que a maioria dos arquitetos prefere. Essa arquitetura foi um marco importante porque ensinou aos arquitetos a dificuldade das transações distribuídas no mundo real e os limites práticos do particionamento técnico.

Página 241

17. Arquitetura de Microsserviços

História

Página 242

desacoplamento, modelando fisicamente a noção lógica do contexto delimitado.

Topologia

A topologia dos microsserviços é mostrada na Figura 17-1.

Figura 17-1. Topologia do estilo da arquitetura de microsserviços Como mostrado na Figura 17-1, devido à sua natureza de finalidade única, o tamanho do serviço nos microsserviços é muito menor que em outras arquiteturas distribuídas, como a arquitetura orientada a serviços e baseada em orquestração. Os arquitetos esperam que cada serviço inclua todas as partes necessárias para operar de modo independente, inclusive bancos de dados e outros componentes dependentes. As diferentes características são apresentadas nas próximas seções.

Distribuída

Os microsserviços formam uma arquitetura distribuída: cada serviço roda em seu próprio processo, que originalmente implicava um computador físico, mas rapidamente evoluiu para máquinas virtuais e contêineres. Desacoplar os serviços nesse grau permite uma solução simples para um problema comum nas arquiteturas com muita infraestrutura multilocatária para hospedar as aplicações. Por exemplo, usar um serviço do aplicação para gerenciar várias aplicações em execução permite a reutilização operacional da largura de banda da rede, da memória, do espaço em disco e muitos outros benefícios. Porém, se todos as aplicações com suporte continuarem crescendo, por fim algum recurso ficará limitado na infraestrutura compartilhada. Outro problema envolve o isolamento inadequado entre as aplicações compartilhadas.

Página 243

Contexto Delimitado

Granularidade

Página 244

do sistema, ou seja, alguns processos corporativos são mais acoplados que outros. Veja algumas diretrizes que os arquitetos podem usar para ajudar a encontrar os limites certos:

Finalidade O limite mais óbvio conta com a inspiração para o estilo de arquitetura, um domínio. O ideal é que cada microsserviço seja extremamente coeso de modo funcional, contribuindo com um comportamento importante em nome do aplicação em geral.

Transações Os contextos delimitados são fluxos de trabalho corporativos e, muitas vezes, as entidades que precisam cooperar em uma transação mostram aos arquitetos um bom limite de serviço. Como as transações causam problemas nas arquiteturas distribuídas, se os arquitetos conseguem projetar seu sistema para evitá-las, eles geram designs de projeto melhores.

Coreografia Se um arquiteto cria um conjunto de serviços que oferece um excelente isolamento do domínio, mas requer uma grande comunicação para funcionar, o arquiteto pode considerar reagrupar esses serviços em um serviço maior para evitar o sobrecarga (overhead) de comunicação.

A iteração é o único modo de assegurar um bom design de serviço. Raramente os arquitetos descobrem a granularidade, as dependências de dados e os estilos de comunicação perfeitos na primeira vez. Porém, após iterar sobre as opções, um arquiteto tem uma boa chance de aprimorar o design.

Isolamento dos Dados

Outro requisito dos microsserviços, orientado pelo conceito do contexto delimitado, é o isolamento dos dados. Muitos outros estilos usam um banco de dados para a persistência. Mas os microsserviços tentam evitar o acoplamento, inclusive os esquemas e os bancos de dados compartilhados usados como pontos de integração.

O isolamento dos dados é outro fator que um arquiteto deve considerar ao ver a granularidade do serviço. Os arquitetos devem ter cuidado com a armadilha da entidade (vista em “Armadilha da entidade”, no Capítulo 8) e não modelar somente seus serviços para lembrar entidades simples em um BD.

Os arquitetos estão acostumados a usar bancos de dados relacionais para unificar os valores em um sistema, criando uma única fonte confiável, o que não é mais uma opção ao distribuir dados na arquitetura. Assim, eles devem decidir como querem lidar com o problema: identificando um domínio como a fonte confiável para algum fato e coordenar com ela para recuperar os valores ou usando a replicação do BD ou o cache para distribuir as informações.

Embora esse nível de isolamento dos dados crie dores de cabeça, também fornece oportunidades. Agora que as equipes não são forçadas a se unificar em torno de um único BD, cada serviço pode escolher a ferramenta mais adequada, com base no preço, no tipo de armazenamento ou em muitos outros fatores. As equipes têm a vantagem, em um sistema altamente desacoplado, de mudar de ideia e escolher um BD mais adequado (ou outra

Página 245

dependência) sem afetar as outras equipes, que não têm permissão para acoplar os detalhes da implementação.

Camada da API

A maioria das imagens dos microsserviços inclui uma camada da API entre os consumidores do sistema (IUs ou chamadas de outros sistemas), mas é opcional. É comum porque oferece um bom local na arquitetura para realizar tarefas úteis, via indireção como um proxy ou uma ligação nas facilidades operacionais, como serviço de nomenclatura (abrangido em “Reutilização Operacional”).

Embora uma camada da API possa ser usada para várias coisas, ela não deve ser usada como um mediador ou uma ferramenta de orquestração, caso o arquiteto queira se manter fiel à filosofia inerente dessa arquitetura: toda a lógica interessante nessa arquitetura deve ocorrer dentro de um contexto delimitado e colocar a orquestração ou outra lógica em um mediador viola essa regra. Isso também mostra a diferença entre os particionamentos técnico e por domínio na arquitetura: em geral, os arquitetos usam mediadores nas arquiteturas particionadas tecnicamente, já a arquitetura de microsserviços é bem particionados por domínio.

Reutilização Operacional

Como os microsserviços preferem a duplicação ao acoplamento, como os arquitetos lidam com as partes da arquitetura que realmente se beneficiam do acoplamento, como as preocupações operacionais do tipo monitoramento, log e circuit breakers? Uma das filosofias na arquitetura tradicional orientada a serviços era reutilizar o máximo possível de funcionalidades, por domínio e operacional, igualmente. Em microsserviços, os arquitetos tentam dividir essas duas preocupações.

Assim que uma equipe cria vários microsserviços, ela percebe que cada um tem elementos comuns com semelhanças. Por exemplo, se uma organização permite que cada equipe de serviços implemente o monitoramento por si só, como pode assegurar que cada equipe faça isso? E como ela lida com preocupações como upgrades? É de responsabilidade de cada equipe lidar com o upgrade para uma nova versão da ferramenta de monitoramento? E quanto tempo levará?

O padrão sidecar (separado) oferece uma solução para o problema, mostrado na Figura 17-2.

Página 246

Figura 17-2. Padrão sidecar em microsserviços Na Figura 17-2, as preocupações operacionais comuns aparecem em cada serviço como um componente separado, que pode ser de propriedade de equipes individuais ou de uma equipe de infraestrutura compartilhada. O componente sidecar lida com todas as preocupações operacionais que as equipes se beneficiam com um acoplamento. Assim, quando chegar o momento de fazer upgrade da ferramenta de monitoramento, a equipe de infraestrutura compartilhada poderá atualizar o sidecar e cada microsserviço receberá a nova funcionalidade.

Assim que as equipes entendem que cada serviço inclui um sidecar comum, elas podem criar uma malha de serviços, permitindo um controle unificado na arquitetura para preocupações como log e monitoramento. Os componentes sidecar comuns se conectam para formar uma interface operacional consistente em todos os microsserviços, como mostrado na Figura 17-3.

Figura 17-3. O plano do serviço conecta os sidecars em uma malha de serviços

Página 247

Na Figura 17-3, cada sidecar se liga a um plano do serviço, que forma a interface consistente para cada serviço.

A malha de serviços em si forma um console que permite aos desenvolvedores um acesso global aos serviços, como mostrado na Figura 17-4.

Figura 17-4. A malha de serviços forma uma visão global do aspecto operacional dos microsserviços Cada serviço forma um nó na malha global, como na Figura 17-4. A malha de serviços forma um console que permite às equipes controlarem globalmente o acoplamento operacional, como níveis de monitoramento, log e outras preocupações operacionais transversais.

Os arquitetos usam a descoberta de serviços como um modo de incorporar elasticidade nas arquiteturas de microsserviços. Em vez de chamar um único serviço, uma requisição passa por uma ferramenta de descoberta de serviços, que pode monitorar o número e a frequência das requisições, assim como ativar novas instâncias dos serviços para lidar com a escala e a elasticidade. Muitas vezes, os arquitetos incluem a descoberta de serviços na malha de serviços, tornando-a parte de todo microsserviço. A camada da API costuma ser usada para hospedar a descoberta de serviços, permitindo um único lugar para que as interfaces do usuário ou outros sistemas de chamada encontrem e criem serviços de um modo elástico e consistente.

Front-ends

Os microsserviços favorecem o desacoplamento, que englobariam de modo ideal as IUs e as preocupações de back-end. Na verdade, a visão original dos microsserviços incluía a IU como parte do contexto delimitado, fiel ao princípio no DDD. Contudo, os aspectos práticos do particionamento requeridos pelas aplicações web e por outros limites externos dificultaram esse objetivo. Assim, dois estilos de interfaces do usuário aparecem normalmente para as arquiteturas de microsserviços; o primeiro é visto na Figura 17-5.

Página 248

Figura 17-5. Arquitetura de microsserviços com uma IU monolítica Na Figura 17-5, o front-end monolítico apresenta uma IU que faz chamadas atráves da camada da API para atender as requisições do usuário. O front-end pode ser um aplicação avançado para desktop, celular ou web. Por exemplo, muitas aplicações web agora usam a estrutura web do JavaScript para criar uma IU.

A segunda opção para as IUs usa microfront-ends, mostrados na Figura 17-6.

Figura 17-6. Padrão microfront-end em microsserviços Na Figura 17-6, essa abordagem utiliza componentes no nível da IU para criar um nível síncrono de granularidade e isolamento na IU como serviços de back-end. Cada serviço emite a

Página 249

IU para esse serviço, que o front-end coordenada com os outros componentes da IU emitidos.

Usando esse padrão, as equipes conseguem isolar os limites de serviço da IU para os serviços de back-end, unificando o domínio inteiro em uma equipe.

Os desenvolvedores podem implementar o padrão de microfront-end de vários modos, usando uma framework web baseada em componentes, como React, ou usando uma das várias estruturas de fonte aberta com suporte para esse padrão.

Comunicação

Nos microsserviços, arquitetos e desenvolvedores tentam uma granularidade adequada, o que afeta o isolamento dos dados e a comunicação. Encontrar o estilo de comunicação certo ajuda as equipes a manterem os serviços desacoplados, mas ainda coordenados de modos úteis.

Basicamente, os arquitetos devem decidir sobre uma comunicação síncrona ou assíncrona. A comunicação síncrona requer que o solicitante aguarde uma resposta do receptor da chamada.

Em geral, as arquiteturas de microsserviços utilizam a interoperabilidade heterogênea com reconhecimento de protocolo. Vamos explicar esse termo para você:

Protocolo Reconhecido Como os microsserviços normalmente não incluem um hub de integração central para evitar o acoplamento operacional, cada serviço deve saber como chamar os outros.

Assim, é comum que os arquitetos padronizem como certos serviços chamam uns aos outros: certo nível de REST, filas de mensagem etc. Isso significa que os serviços devem saber (ou descobrir) qual protocolo usar para chamar os outros serviços.

Heterogênea Como a arquitetura de microsserviços é uma arquitetura distribuída, cada serviço pode ser escrito em uma stack tecnológico diferente. Heterogênea sugere que os microsserviços suportam totalmente ambientes poliglotas, nos quais diferentes serviços usam diferentes plataformas.

Interoperabilidade Descreve serviços que chamam uns aos outros. Embora os arquitetos nos microsserviços tentem desencorajar as chamadas de métodos transacionais, os serviços normalmente chamam outros serviços via rede para colaborar e enviar/receber informações.

Página 250

Heterogeneidade Forçada Um arquiteto conhecido, pioneiro no estilo de microsserviços, era responsável pela arquitetura em uma startup de gerenciamento de informações pessoais para dispositivos móveis. Como eles tinham um domínio de problema de rápida evolução, o arquiteto queria assegurar que nenhuma equipe de desenvolvimento criasse pontos de acoplamento entre si sem querer, prejudicando a capacidade das equipes de se mover com independência. Acabou que esse arquiteto tinha habilidades técnicas muito variadas nas equipes, designando que cada equipe de desenvolvimento usasse uma stacks tecnológicoss. Se uma equipe usava Java e a outra usava .NET, era impossível compartilhar as classes sem querer!

Essa abordagem é o oposto da maioria das políticas de governança corporativa, que insistem em padronizar em um único stack tecnológico. O objetivo no mundo dos microsserviços não é criar o ecossistema mais complexo possível, mas escolher a tecnologia correta para o escopo específico do problema. Nem todo serviço precisa de um BD relacional de alta capacidade e impor isso a pequenas equipes as deixa lentas, em vez de beneficiá-las. Esse conceito utiliza a natureza altamente desacoplada dos microsserviços.

Para a comunicação assíncrona, os arquitetos costumam usar eventos e mensagens, utilizando internamente uma arquitetura baseada em eventos, vista no Capítulo 14; os padrões do broker e do mediador se manifestam nos microsserviços como coreografia e orquestração.

Coreografia e Orquestração

Coreografia utiliza o mesmo estilo de comunicação de uma arquitetura baseada em eventos do broker, ou seja, não há nenhum coordenador central nessa arquitetura, respeitando a filosofia do contexto delimitado. Assim, os arquitetos acham natural implementar eventos desacoplados entre os serviços.

Isomorfismo do domínio/arquitetura é uma característica principal que os arquitetos devem buscar ao analisarem a adequação de um estilo de arquitetura para certo problema. Esse termo descreve como a forma de uma arquitetura mapeia determinado estilo de arquitetura. Por exemplo, na Figura 8-7, a arquitetura tecnicamente particionada de Silicon Sandwiches suporta estruturalmente a customização, e o estilo de arquitetura de microkernel oferece a mesma estrutura geral. Portanto, os problemas que requerem um alto grau de customização ficam mais fáceis de implementar em um microkernel.

Do mesmo modo, como o objetivo do arquiteto em uma arquitetura de microsserviços favorece o desacoplamento, a forma dos microsserviços lembra o EDA do broker, tornando esses dois padrões simbióticos.

Na coreografia, cada serviço chama outros serviços quando necessário, sem um mediador central. Por exemplo, considere o cenário mostrado na Figura 17-7.

Página 251

Página 252

Página 253

Figura 17-9. Usando coreografia para um processo corporativo complexo Na Figura 17-9, o primeiro serviço chamado deve coordenar muitos outros serviços, basicamente agindo como um mediador, além de suas outras responsabilidades no domínio.

Esse padrão se chama controlador frontal (front controller), em que um serviço coreografado nominalmente se torna um mediador mais complexo para algum problema. A desvantagem desse padrão é a complexidade extra no serviço.

Uma alternativa seria um arquiteto escolher usar a orquestração para os processos corporativos complexos, como na Figura 17-10.

Página 254

Figura 17-10. Usando orquestração para um processo corporativo complexo Na Figura 17-10, o arquiteto cria um mediador para lidar com a complexidade e a coordenação requeridas para o fluxo de trabalho corporativo. Embora isso crie acoplamento entre os serviços, permite que o arquiteto foque a coordenação em um serviço, deixando os outros menos afetados. Muitas vezes, os fluxos de trabalho do domínio são acoplados por natureza, ou seja, o trabalho do arquiteto envolve encontrar a melhor maneira de representar esse acoplamento de modos que deem suporte aos objetivos do domínio e da arquitetura.

Transações e Sagas

Os arquitetos aspiram um extremo desacoplamento nos microsserviços, mas normalmente encontram o problema de como fazer a coordenação transacional nos serviços. Como o desacoplamento na arquitetura encoraja o mesmo nível nos bancos de dados, a atomicidade que era normal nas aplicações monolíticas se torna um problema nos distribuídos.

Criar transações nos limites de serviço viola o princípio básico do desacoplamento na arquitetura de microsserviços (e também cria o pior tipo de conascência dinâmica: a conascência de valor). O melhor conselho para os arquitetos que desejam fazer transações nos serviços é: não faça isso! Corrija os componentes da granularidade. Muitas vezes, os arquitetos que criam arquiteturas de microsserviços e precisam ligá-los com transações foram granulares demais em seu design. Os limites da transação são um dos indicadores comuns de granularidade do serviço.

Página 255

Não faça transações nos microsserviços; pelo contrário, corrija a granularidade!

Sempre há exceções. Por exemplo, pode existir uma situação em que dois serviços diferentes precisam de características da arquitetura muitíssimo diferentes, exigindo limites de serviço distintos, mas ainda precisam de uma coordenação transacional. Nesses casos, existem padrões para lidar com a orquestração da transação, com grandes trade-offs.

Um padrão transacional distribuído popular nos microsserviços é o padrão saga, mostrado na Figura 17-11.

Figura 17-11. Padrão saga na arquitetura de microsserviços Na Figura 17-11, um serviço age como um mediador em várias chamadas de serviço e coordena a transação. O mediador chama cada parte da transação, registra o sucesso ou o fracasso e coordena os resultados. Se tudo ocorre como o planejado, todos os valores nos serviços e seus bancos de dados contidos (contained databases) são atualizados de modo síncrono.

Em uma condição de erro, o mediador deve assegurar que nenhuma parte da transação tenha sucesso se uma parte falha. Considere a situação mostrada na Figura 17-12.

Página 256

Página 257

Por vezes, são necessárias algumas transações nos serviços; se for o recurso dominante da arquitetura, foram cometidos erros!

Classificações das Características da Arquitetura

O estilo da arquitetura de microsserviços mostra vários extremos na escala de classificações padrão, mostrada na Figura 17-13. Uma estrela significa que a característica específica não é bem suportada na arquitetura, já cinco estrelas significam que a característica é um dos recursos mais fortes no estilo. A definição de cada característica identificada na tabela de pontuação pode ser encontrada no Capítulo 4.

É notável o alto suporte para as práticas da engenharia moderna, como implementação automática, teste e outras não listadas. Os microsserviços não existiriam sem a revolução DevOps e a marcha incansável para automatizar as preocupações operacionais.

Como a arquitetura de microsserviços é uma arquitetura distribuída, ele tem muitas das deficiências inerentes nas arquiteturas compostas de partes conectadas durante a execução.

Assim, a tolerância a falhas e a confiabilidade são impactadas quando é usada muita comunicação entre os serviços. Contudo, essas classificações apenas apontam para tendências na arquitetura; os desenvolvedores corrigem muitos problemas com a redundância e a escala via descoberta de serviços. Mas sob circunstâncias normais, serviços independentes com uma finalidade normalmente levam a uma alta tolerância a falhas, daí a alta classificação para essa característica em uma arquitetura de microsserviços.

Página 258

Figura 17-13. Classificações para microsserviços Os pontos altos dessa arquitetura são escalabilidade, elasticidade e ser evolutiva. Alguns dos sistemas mais escaláveis já escritos utilizaram esse estilo com grande sucesso. Do mesmo modo, como a arquitetura conta muito com a automação e a integração inteligente com o DevOps, os desenvolvedores também podem criar um suporte de elasticidade na arquitetura. Como a arquitetura favorece o alto desacoplamento no nível incremental, tem suporte para a prática corporativo moderna da alteração evolutiva, mesmo no nível da arquitetura. O negócio moderno muda rápido e o desenvolvimento de software tenta acompanhar. Criando uma arquitetura com unidades de implementação extremamente pequenas e altamente desacopladas, os arquitetos têm uma estrutura que pode suportar uma taxa de alteração mais rápida.

Performance costuma ser um problema nos microsserviços, ou seja, as arquiteturas distribuídas devem fazer muitas chamadas de rede para concluírem o trabalho, tendo um alto overhead na performance, e devem fazer verificações de segurança para checar a identidade e o acesso para cada extremidade. Existem muitos padrões no mundo dos microsserviços para aumentar a performance, inclusive o cache de dados inteligente e a replicação para evitar um excesso de chamadas da rede.

Página 259

Performance é outro motivo para os microsserviços sempre usarem a coreografia, não a orquestração, pois um menor acoplamento permite uma comunicação mais rápida e menos gargalos.

Com certeza, a arquitetura de microsserviços é uma arquitetura centrada no domínio, em que cada limite do serviço deve corresponder aos domínios. Também tem os quanta mais distintos de qualquer arquitetura moderna; de muitos modos, exemplifica o que a medida quantum avalia. A filosofia condutora do desacoplamento extremo cria muitas dores de cabeça nessa arquitetura, mas produz enormes benefícios quando bem feito. Como em qualquer arquitetura, os arquitetos devem entender as regras para quebrá-las com inteligência.

Referências Adicionais

Embora nosso objetivo neste capítulo tenha sido tocar em alguns aspectos importantes desse estilo de arquitetura, há muitos recursos excelentes para se aprofundar e obter mais detalhes sobre o estilo. Informações adicionais e mais detalhadas podem ser encontradas sobre os microsserviços nas seguintes referências (todos sem publicação no Brasil):

Building Microservices, de Sam Newman Microservices vs. Service-Oriented Architecture, de Mark Richards Microservices AntiPatterns and Pitfalls, de Mark Richards

Página 260

18. Escolhendo o Estilo de Arquitetura Certo

CAPÍTULO 18 Escolhendo o Estilo de Arquitetura Certo Depende! Com todas as opções disponíveis (e novas chegando quase que diariamente), gostaríamos de dizer qual você deveria usar, mas não podemos. Nada é mais contextual segundo vários fatores em uma organização e qual software ela cria. Escolher um estilo de arquitetura representa o ápice da análise e do pensamento sobre trade-offs para as características da arquitetura, considerações do domínio, metas estratégicas e muitas outras coisas.

Por mais contextual que seja a decisão, existe um conselho geral quanto a escolher um estilo de arquitetura certo.

A Mudança de “Moda” na Arquitetura

Os estilos de arquitetura preferidos mudam com o tempo, segundo inúmeros fatores:

Observações do passado Em geral, os novos estilos de arquitetura surgem das observações e dos pontos críticos de experiências anteriores. Os arquitetos têm experiência com sistemas no passado que influenciam seus pensamentos sobre os futuros sistemas. Eles devem contar com sua experiência anterior, pois é essa experiência que permitiu à pessoa se tornar um arquiteto em primeiro lugar. Muitas vezes, os novos designs da arquitetura refletem deficiências específicas dos estilos de arquitetura anteriores. Por exemplo, os arquitetos repensavam seriamente as implicações da reutilização do código após criarem arquiteturas que a representavam, então percebiam os trade-offs negativos.

Mudanças no ecossistema A mudança constante é um recurso confiável do ecossistema de desenvolvimento de software, pois tudo muda o tempo inteiro. A mudança em nosso ecossistema é particularmente caótica, tornando até o tipo de mudança impossível de prever. Por exemplo, há alguns anos, ninguém sabia o que era Kubernetes, e agora há várias conferências no mundo com milhares de desenvolvedores. Dentro de alguns anos, o Kubernetes pode ser substituído por outra ferramenta que não foi escrita ainda.

Novas capacidades Quando surgem novas capacidades, a arquitetura não pode simplesmente substituir uma ferramenta por outra, mas deve mudar para um paradigma inteiramente novo. Por exemplo, alguns arquitetos ou desenvolvedores anteciparam a mudança tectônica causada no mundo de desenvolvimento de software com o advento de contêineres, como Docker. Embora tenha sido uma etapa evolucionária, o impacto que teve em arquitetos, ferramentas, práticas de engenharia e muitos outros fatores surpreendeu grande parte do setor. A mudança constante no ecossistema também entrega uma nova coleção de

Página 261

ferramentas e capacidades com regularidade. Os arquitetos devem ficar de olho não só nas novas ferramentas, mas nos novos paradigmas. A tal coisa pode parecer algo novo que já temos, mas pode incluir sutilezas e outras alterações que faz dela um divisor de águas. Novas capacidades não precisam abalar o mundo inteiro do desenvolvimento; novos recursos podem ser uma pequena mudança que se alinha exatamente com os objetivos de um arquiteto.

Aceleração Não só o ecossistema muda constantemente, mas a taxa de mudança também continua a aumentar. Novas ferramentas criam novas práticas de engenharia, que levam a um novo design e capacidades. Os arquitetos vivem em um estado de fluxo constante porque a mudança é generalizada e constante.

Mudanças no domínio O domínio para o qual os desenvolvedores escrevem software muda e se altera constantemente, porque o negócio continua a evoluir ou por causa de fatores como fusões com outras empresas.

Mudanças na tecnologia Conforme a tecnologia continua a se desenvolver, as organizações tentam acompanhar pelo menos algumas dessas mudanças, sobretudo aquelas com benefícios finais óbvios.

Fatores externos Muitos fatores externos apenas associados perifericamente ao desenvolvimento de software podem orientar a mudança dentro da organização. Por exemplo, arquitetos e desenvolvedores podem estar bem contentes com certa ferramenta, mas o custo da licença se tornou um impedimento, forçando a migração para outra opção.

Independentemente de onde está uma organização em termos de arquitetura atual na moda, um arquiteto deve entender as tendências atuais do setor para tomar decisões inteligentes sobre quando seguir ou fazer exceções.

Critérios de Decisão

Ao escolher um estilo de arquitetura, um arquiteto deve levar em conta todos os vários fatores que contribuem para a estrutura do design de domínio. Basicamente, um arquiteto planeja duas coisas: qualquer domínio que foi especificado e todos os outros elementos estruturais requeridos para tornar o sistema um sucesso.

Os arquitetos devem entrar na decisão de design estando à vontade com o seguinte:

Domínio Os arquitetos devem entender muitos aspectos importantes do domínio, sobretudo os que afetam as características operacionais da arquitetura. Eles não precisam obedecer aos especialistas, mas devem ter pelo menos uma boa compreensão geral dos aspectos maiores do domínio no design.

Características da arquitetura que impactam a estrutura Os arquitetos devem descobrir e elucidar as características da arquitetura necessárias para dar suporte ao domínio e a outros fatores externos.

Página 262

Arquitetura de Dados Arquitetos e DBAs devem colaborador no banco de dados, no esquema e em outras preocupações relacionadas a dados. Não cobrimos muito a arquitetura de dados neste livro; ela tem uma especialização própria. Contudo, os arquitetos devem entender o impacto que o design de dados pode ter em seu design, em particular se o novo sistema precisa interagir com uma arquitetura de dados mais antiga e/ou em uso.

Fatores organizacionais Muitos fatores externos podem influenciar o design. Por exemplo, o custo de fornecedor de serviço em nuvem específico pode impedir o design ideal. Ou talvez a empresa planeje fazer fusões e aquisições, o que encoraja um arquiteto a gravitar em torno de soluções abertas e arquiteturas de integração.

Conhecimento do processo, das equipes e das preocupações operacionais Muitos fatores específicos do projeto influenciam o design de um arquiteto, como processo de desenvolvimento de software, interação (ou falta dela) com DevOps e processo QA. Por exemplo, se uma organização não tem maturidade com práticas de engenharia ágil, os estilos de arquitetura que contam com essas práticas para terem sucesso terão dificuldades.

Isomorfismo do domínio/arquitetura Alguns domínios do problema correspondem à topologia da arquitetura. Por exemplo, o estilo da arquitetura de microkernel é muito adequado para um sistema que requer customização, ou seja, o arquiteto pode planejar customizações como plug-ins. Outro exemplo pode ser a análise do genoma, que requer inúmeras operações distintas e uma arquitetura baseada em espaço, que oferece muitos processos distintos.

Do mesmo modo, alguns domínios do problema podem ser bem inadequados para alguns estilos de arquitetura. Por exemplo, sistemas altamente escaláveis têm problemas com grandes designs monolíticos porque os arquitetos acham difícil dar suporte a muitos usuários simultâneos em uma base de código altamente acoplada. Um domínio do problema que inclui uma grande quantidade de acoplamento semântico combina mal com uma arquitetura altamente desacoplada e distribuída. Por exemplo, uma aplicação de seguradora que consiste em formulários com várias páginas, cada uma baseada no contexto das páginas anteriores, seria difícil de modelar nos microsserviços. Esse é um problema altamente acoplado que trará desafios de design para os arquitetos em uma arquitetura desacoplada; uma arquitetura menos acoplada, como a baseada em serviço, seria mais adequada para esse problema.

Levando tudo isso em conta, o arquiteto deve fazer várias determinações:

Monolítico versus distribuído Usando os conceitos de quantum vistos antes, o arquiteto deve determinar se um conjunto de características da arquitetura será suficiente para o design ou se partes distintas do sistema precisam de características diferentes. Um conjunto implica que um bloco monolítico é adequado (embora outros fatores possam orientar um arquiteto para usar uma arquitetura distribuída), já as diferentes características da arquitetura implicam uma arquitetura distribuída.

Onde os dados devem residir?

Página 263

Se a arquitetura é monolítica, é comum que os arquitetos pressuponham um único ou alguns bancos de dados relacionais. Em uma arquitetura distribuída, o arquiteto deve decidir quais serviços persistem os dados, o que também implica pensar sobre como os dados devem fluir na arquitetura para criar fluxos de trabalho. Os arquitetos devem considerar a estrutura e o comportamento ao planejarem a arquitetura e não ter medo de iterar o design para encontrar combinações melhores.

Qual será o estilo de comunicação entre os serviços? Síncrono ou assíncrono?

Assim que o arquiteto determina o particionamento dos dados, sua próxima consideração no design é a comunicação entre os serviços: síncrona ou assíncrona? A comunicação síncrona é mais conveniente na maioria dos casos, mas pode levar à falta de escalabilidade, confiabilidade e outras características indesejáveis. A comunicação assíncrona pode ter benefícios únicos em termos de desempenho e escala, mas pode apresentar muitas dores de cabeça: sincronização dos dados, impasses, condições de corrida, depuração etc.

Como a comunicação síncrona apresenta menos desafios de design, implementação e depuração, os arquitetos devem usar a síncrona por padrão quando possível e a assíncrona quando necessário.

Use a síncrona por padrão e a assíncrona quando necessário.

A saída desse processo de design é a topologia da arquitetura, levando em conta qual estilo de arquitetura (e hibridizações) o arquiteto escolheu, os registros de decisão da arquitetura sobre as partes do design que precisaram de mais esforço do arquiteto e as funções de aptidão para proteger importantes princípios e características operacionais da arquitetura.

Estudo de Caso Monolítico: Silicon Sandwiches

No kata da arquitetura Silicon Sandwiches, após investigar as características da arquitetura, determinamos que um único quantum era suficiente para implementar o sistema. E mais, é uma aplicação simples sem um grande orçamento, portanto a simplicidade do monolítico agrada.

Contudo, criamos dois designs de componentes diferentes para Silicon Sandwiches: um particionado por domínio e outro particionado tecnicamente. Dada a simplicidade da solução, criaremos designs para cada um e veremos os trade-offs.

Monolítico Modular

Um bloco monolítico modular cria componentes centrados no domínio com um banco de dados, implantado como um quantum; o design monolítico modular para Silicon Sandwiches aparece na Figura 18-1.

É

Página 264

Microkernel

Página 265

Figura 18-2. Implementação microkernel de Silicon Sandwiches Na Figura 18-2, o sistema central consiste nos componentes do domínio e em um banco de dados relacional. Como no design anterior, uma sincronização cuidadosa entre os domínios e o design dos dados permitirá uma futura migração do central para uma arquitetura distribuída.

Cada customização aparece em um plug-in, as comuns em um conjunto de plug-ins (com um banco de dados correspondente) e uma série de plug-ins locais, cada com seus próprios dados.

Como nenhum plug-in precisa ser acoplado a outros plug-ins, eles podem manter seus dados, deixando os plug-ins desacoplados.

Outro elemento de design único aqui utiliza o padrão Back-ends para Front-ends (BFF), tornando a camada da API um adaptador de microkernel fino. Fornece informações gerais do back-end e os adaptadores BFF traduzem as informações genéricas no formato adequado para o dispositivo de front-end. Por exemplo, o BFF para iOS levará a saída genérica do back-end e a personalizará para o que a aplicação iOS nativa espera: formato dos dados, paginação, latência

Página 266

e outros fatores. Criar cada adaptador BFF permite IUs mais ricas e a capacidade de expandir para dar suporte a outros dispositivos no futuro, um dos benefícios do estilo microkernel.

A comunicação na arquitetura Silicon Sandwiches pode ser síncrona, ou seja, a arquitetura não requer um desempenho extremo nem tem requisitos de elasticidade, e nenhuma das operações será demorada.

Estudo de Caso Distribuído: Going, Going, Gone

O kata Going, Going, Gone (GGG) apresenta desafios de arquitetura mais interessantes. Com base na análise do componente em “Estudo de Caso: Going, Going, Gone: Descobrindo os Componentes”, no Capítulo 8, essa arquitetura precisa de características da arquitetura diferentes para partes variadas dela. Por exemplo, características como disponibilidade e escalabilidade diferirão entre as funções, como leiloeiro e proponente.

Os requisitos para GGG também declaram explicitamente certos níveis ambiciosos de escala, elasticidade, desempenho e muitas outras características operacionais capciosas da arquitetura.

O arquiteto precisa escolher um padrão que permita um alto grau de customização em um nível bem granular dentro da arquitetura. Das arquiteturas candidatas distribuídas, a orientada a eventos de baixo nível ou microsserviços correspondem mais às características. Das duas, os microsserviços têm um melhor suporte para as características diferentes da arquitetura operacional; as arquiteturas baseadas puramente em eventos em geral não separam as partes por causa dessas características operacionais, mas são baseadas no estilo de comunicação, orquestrado versus coreografado.

Conseguir o desempenho declarado será um desafio nos microsserviços, mas os arquitetos costumam lidar com qualquer ponto fraco de uma arquitetura planejando sua inclusão. Por exemplo, embora os microsserviços ofereçam altos graus de escalabilidade por natureza, em geral os arquitetos precisam lidar com preocupações específicas de desempenho causadas por um excesso de orquestração, separação de dados excessivamente agressiva etc.

Uma implementação de GGG usando microsserviços é mostrada na Figura 18-3.

Página 267

Página 268

Página 269

Página 270

Parte III. Técnicas e Habilidades Sociais

PARTE III Técnicas e Habilidades Sociais Um arquiteto de software eficiente não deve entender apenas os aspectos técnicos da arquitetura de software, mas também as técnicas básicas e as habilidades sociais necessárias para pensar como arquiteto, orientar as equipes de desenvolvimento e comunicar com eficiência a arquitetura para os vários stakeholders. Esta seção do livro lida com as principais técnicas e habilidades sociais necessárias para se tornar um arquiteto de software eficiente.