Você passou meses redesenhando seu monólito em microsserviços e, finalmente, todos se uniram para mudar a situação. Você vai para a primeira página da web... e nada acontece. Você o recarrega - e novamente nada de bom, o site é tão lento que não responde por vários minutos. O que aconteceu?
Em sua palestra, Jimmy Bogard conduzirá uma “post-mortem” sobre um desastre de microsserviços na vida real. Ele mostrará os problemas de modelagem, desenvolvimento e produção que descobriu e como sua equipe transformou lentamente o novo monólito distribuído na imagem final de sanidade. Embora seja impossível evitar completamente erros de design, você pode pelo menos identificar os problemas no início do processo de design para garantir que o produto final se torne um sistema distribuído confiável.
Olá a todos, meu nome é Jimmy e hoje vocês vão saber como evitar mega desastres ao construir microsserviços. Esta é a história de uma empresa onde trabalhei durante cerca de um ano e meio para ajudar a evitar que o seu navio colidisse com um iceberg. Para contar esta história adequadamente, teremos que voltar no tempo e falar sobre onde esta empresa começou e como a sua infra-estrutura de TI cresceu ao longo do tempo. Para proteger os nomes dos inocentes neste desastre, mudei o nome desta empresa para Bell Computers. O próximo slide mostra como era a infraestrutura de TI dessas empresas em meados dos anos 90. Esta é uma arquitetura típica de um grande servidor HP Tandem Mainframe universal tolerante a falhas para operar um armazenamento de hardware de computador.
Eles precisavam criar um sistema para gerenciar todos os pedidos, vendas, devoluções, catálogos de produtos e base de clientes, por isso escolheram a solução de mainframe mais comum na época. Esse sistema gigante continha todas as informações sobre a empresa, tudo o que era possível, e todas as transações eram realizadas por meio desse mainframe. Eles mantinham todos os ovos na mesma cesta e achavam que isso era normal. A única coisa que não está incluída aqui são catálogos de pedidos por correspondência e pedidos por telefone.
Com o tempo, o sistema tornou-se cada vez maior e uma enorme quantidade de lixo se acumulou nele. Além disso, COBOL não é a linguagem mais expressiva do mundo, então o sistema acabou sendo um grande e monolítico pedaço de lixo. Em 2000, eles perceberam que muitas empresas tinham sites por meio dos quais conduziam absolutamente todos os seus negócios e decidiram construir seu primeiro site pontocom comercial.
O design inicial parecia muito bom e consistia em um site de nível superior bell.com e vários subdomínios para aplicativos individuais: catalog.bell.com, accounts.bell.com, order.bell.com, pesquisa de produtos search.bell. com. Cada subdomínio usava o framework ASP.Net 1.0 e seus próprios bancos de dados, e todos se comunicavam com o backend do sistema. No entanto, todos os pedidos continuaram a ser processados e executados dentro de um único mainframe enorme, no qual todo o lixo permanecia, mas o front-end eram sites separados com aplicativos individuais e bancos de dados separados.
Portanto, o design do sistema parecia ordenado e lógico, mas o sistema real era mostrado no próximo slide.
Todos os elementos endereçavam chamadas entre si, acessavam APIs, DLLs de terceiros incorporadas e assim por diante. Muitas vezes acontecia que os sistemas de controle de versão pegavam o código de outra pessoa, colocavam-no dentro do projeto e então tudo quebrava. O MS SQL Server 2005 utilizou o conceito de servidores de link, e embora eu não tenha mostrado as setas no slide, cada um dos bancos de dados também conversava entre si, pois não há nada de errado em construir tabelas com base em dados obtidos de vários bancos de dados.
Como agora havia alguma separação entre as diferentes áreas lógicas do sistema, isso se transformou em bolhas de sujeira distribuídas, com o maior pedaço de lixo ainda permanecendo no back-end do mainframe.
O engraçado é que esse mainframe foi construído por concorrentes da Bell Computers e ainda era mantido por seus consultores técnicos. Convencida do desempenho insatisfatório de suas aplicações, a empresa decidiu se desfazer delas e redesenhar o sistema.
O aplicativo existente estava em produção há 15 anos, o que é um recorde para aplicativos baseados em ASP.Net. O serviço aceitou pedidos de todo o mundo e a receita anual deste único aplicativo atingiu um bilhão de dólares. Uma parcela significativa do lucro foi gerada pelo site bell.com. Nas Black Fridays, o número de pedidos feitos através do site chegou a vários milhões. No entanto, a arquitectura existente não permitia qualquer desenvolvimento, uma vez que as rígidas interligações dos elementos do sistema praticamente não permitiam quaisquer alterações ao serviço.
O problema mais grave era a impossibilidade de fazer uma encomenda de um país, pagá-la noutro e enviá-la para um terceiro, apesar de tal esquema comercial ser muito comum em empresas globais. O site existente não permitia nada parecido, então eles tiveram que aceitar e fazer esses pedidos por telefone. Isto levou a empresa a pensar cada vez mais em mudar a arquitetura, em particular na mudança para microsserviços.
Eles fizeram a coisa certa ao olhar para outras empresas para ver como haviam resolvido um problema semelhante. Uma dessas soluções foi a arquitetura de serviços Netflix, que consiste em microsserviços conectados por meio de uma API e um banco de dados externo.
A administração da Bell Computers decidiu construir exatamente essa arquitetura, aderindo a certos princípios básicos. Primeiro, eliminaram a duplicação de dados usando uma abordagem de banco de dados compartilhado. Nenhum dado foi enviado; pelo contrário, todos que precisaram deles tiveram que ir a uma fonte centralizada. Seguiu-se isolamento e autonomia – cada serviço era independente dos demais. Eles decidiram usar a API Web para absolutamente tudo – se você quisesse obter dados ou fazer alterações em outro sistema, tudo seria feito através da API Web. A última grande novidade foi um novo mainframe chamado “Bell on Bell”, em oposição ao mainframe “Bell” baseado no hardware dos concorrentes.
Assim, ao longo de 18 meses, construíram o sistema em torno destes princípios fundamentais e levaram-no para a pré-produção. Voltando ao trabalho após o fim de semana, os desenvolvedores se reuniram e ligaram todos os servidores aos quais o novo sistema estava conectado. 18 meses de trabalho, centenas de desenvolvedores, o mais moderno hardware Bell - e nenhum resultado positivo! Isso decepcionou muitas pessoas porque elas executaram esse sistema em seus laptops muitas vezes e estava tudo bem.
Eles foram espertos em gastar todo o seu dinheiro para resolver esse problema. Eles instalaram os mais modernos racks de servidores com switches, usaram fibra óptica gigabit, o hardware de servidor mais poderoso com uma quantidade absurda de RAM, conectaram tudo, configuraram - e de novo, nada! Então eles começaram a suspeitar que o motivo poderia ser o tempo limite, então eles acessaram todas as configurações da web, todas as configurações da API e atualizaram toda a configuração do tempo limite para os valores máximos, para que tudo o que pudessem fazer fosse sentar e esperar que algo acontecesse. para o site. Eles esperaram e esperaram e esperaram 9 minutos e meio até que o site finalmente carregasse.
Depois disso, perceberam que a situação atual precisava de uma análise aprofundada e nos convidaram. A primeira coisa que descobrimos foi que durante todos os 18 meses de desenvolvimento, nenhum “micro” real foi criado - tudo só ficou maior. Depois disso, começamos a escrever uma post-mortem, também conhecida como “retrospectiva”, ou “retrospectiva triste”, também conhecida como “tempestade de culpas”, semelhante a uma “tempestade cerebral”, para entender a causa do desastre.
Tínhamos várias pistas, uma delas era a saturação completa do tráfego no momento da chamada da API. Ao usar uma arquitetura de serviço monolítica, você pode entender imediatamente o que exatamente deu errado porque tem um único rastreamento de pilha que relata tudo o que poderia ter causado a falha. No caso em que vários serviços acessam simultaneamente a mesma API, não há como rastrear o rastreamento, exceto usando ferramentas adicionais de monitoramento de rede como o WireShark, graças às quais você pode examinar uma única solicitação e descobrir o que aconteceu durante sua implementação. Então pegamos uma página da web e passamos quase duas semanas juntando as peças do quebra-cabeça, fazendo diversas ligações para ela e analisando o que cada uma delas levou.
Olhe para essa foto. Isso mostra que uma solicitação externa solicita que o serviço faça muitas chamadas internas que retornam. Acontece que cada chamada interna faz saltos adicionais para poder atender de forma independente essa solicitação, pois não pode recorrer a nenhum outro lugar para obter as informações necessárias. Essa imagem parece uma cascata de chamadas sem sentido, pois a solicitação externa chama serviços adicionais, que chamam outros serviços adicionais, e assim por diante, quase ad infinitum.
A cor verde neste diagrama mostra um semicírculo no qual os serviços chamam uns aos outros - o serviço A chama o serviço B, o serviço B chama o serviço C e chama novamente o serviço A. Como resultado, obtemos um “impasse distribuído”. Uma única solicitação criava mil chamadas de API de rede e, como o sistema não tinha tolerância a falhas e proteção de loop integradas, a solicitação falharia se pelo menos uma dessas chamadas de API falhasse.
Fizemos algumas contas. Cada chamada de API tinha um SLA de no máximo 150 ms e 99,9% de tempo de atividade. Uma solicitação causou 200 chamadas diferentes e, na melhor das hipóteses, a página poderia ser mostrada em 200 x 150 ms = 30 segundos. Naturalmente, isso não foi bom. Multiplicando 99,9% de tempo de atividade por 200, obtivemos 0% de disponibilidade. Acontece que esta arquitetura estava fadada ao fracasso desde o início.
Perguntamos aos desenvolvedores como eles não conseguiram reconhecer esse problema após 18 meses de trabalho. Descobriu-se que eles contavam apenas o SLA para o código executado, mas se o serviço chamasse outro serviço, eles não contavam esse tempo no SLA. Tudo o que foi lançado dentro de um processo aderiu ao valor de 150 ms, mas o acesso a outros processos de serviço aumentou muitas vezes o atraso total. A primeira lição aprendida foi: “Você está no controle do seu SLA ou o SLA está no controle de você?” No nosso caso, foi o último.
A próxima coisa que descobrimos foi que eles conheciam o conceito de conceitos errôneos de computação distribuída, formulados por Peter Deitch e James Gosling, mas ignoraram a primeira parte dele. Afirma que as afirmações “a rede é confiável”, “latência zero” e “taxa de transferência infinita” são equívocos. Outros equívocos incluem as afirmações “a rede é segura”, “a topologia nunca muda”, “há sempre apenas um administrador”, “o custo da transferência de dados é zero” e “a rede é homogênea”.
Eles cometeram um erro porque testaram seus serviços em máquinas locais e nunca se conectaram a serviços externos. Ao desenvolver localmente e usar um cache local, eles nunca encontraram saltos de rede. Em todos os 18 meses de desenvolvimento, nunca se perguntaram o que poderia acontecer se os serviços externos fossem afectados.
Se você observar os limites de serviço na imagem anterior, verá que estão todos incorretos. Existem muitas fontes que aconselham sobre como definir limites de serviço, e a maioria faz isso de maneira errada, como a Microsoft no próximo slide.
Esta imagem é do blog da MS sobre o tópico “Como construir microsserviços”. Isso mostra um aplicativo Web simples, um bloco de lógica de negócios e um banco de dados. A solicitação vem diretamente, provavelmente existe um servidor para a web, um servidor para o negócio e outro para o banco de dados. Se você aumentar o tráfego, o quadro mudará um pouco.
Aí vem um balanceador de carga para distribuir o tráfego entre dois servidores web, um cache localizado entre o serviço web e a lógica de negócios e outro cache entre a lógica de negócios e o banco de dados. Essa é exatamente a arquitetura que a Bell usou para seu aplicativo de balanceamento de carga e implantação azul/verde em meados dos anos 2000. Até algum tempo tudo funcionou bem, já que este esquema se destinava a uma estrutura monolítica.
A imagem a seguir mostra como a MS recomenda mudar de um monólito para microsserviços - simplesmente dividindo cada um dos serviços principais em microsserviços separados. Foi durante a implementação deste esquema que Bell cometeu um erro.
Eles dividiram todos os seus serviços em diferentes níveis, cada um consistindo em muitos serviços individuais. Por exemplo, o serviço web incluía microsserviços para renderização de conteúdo e autenticação, o serviço de lógica de negócios consistia em microsserviços para processamento de pedidos e informações de contas, o banco de dados era dividido em um grupo de microsserviços com dados especializados. Tanto a web quanto a lógica de negócios e o banco de dados eram serviços sem estado.
No entanto, esta imagem estava completamente errada porque não mapeava nenhuma unidade de negócio fora do cluster de TI da empresa. Este esquema não teve em conta qualquer ligação com o mundo exterior, pelo que não ficou claro como, por exemplo, obter análises empresariais de terceiros. Observo que eles também inventaram vários serviços simplesmente para desenvolver as carreiras de funcionários individuais que buscavam administrar o maior número possível de pessoas para conseguir mais dinheiro com isso.
Eles acreditavam que migrar para microsserviços era tão fácil quanto pegar sua infraestrutura interna de camada física de N camadas e colocar o Docker nela. Vamos dar uma olhada na aparência da arquitetura tradicional de N camadas.
Consiste em 4 níveis: o nível da interface do usuário da UI, o nível da lógica de negócios, o nível de acesso aos dados e o banco de dados. Mais progressista é o DDD (Domain-Driven Design), ou arquitetura orientada a software, onde os dois níveis intermediários são objetos de domínio e um repositório.
Tentei observar diferentes áreas de mudança, diferentes áreas de responsabilidade nesta arquitetura. Em uma aplicação típica de N camadas, são classificadas diferentes áreas de mudança que permeiam a estrutura verticalmente de cima para baixo. São Catálogo, configurações de configuração realizadas em computadores individuais e verificações de Checkout, que foram gerenciadas por minha equipe.
A peculiaridade desse esquema é que os limites dessas áreas de mudança afetam não apenas o nível da lógica de negócios, mas também se estendem ao banco de dados.
Vejamos o que significa ser um serviço. Existem 6 propriedades características de uma definição de serviço - é um software que:
- criado e usado por uma organização específica;
- é responsável pelo conteúdo, processamento e/ou disponibilização de determinado tipo de informação dentro do sistema;
- podem ser construídos, implantados e executados de forma independente para atender a necessidades operacionais específicas;
- comunica-se com consumidores e outros serviços, fornecendo informações baseadas em acordos ou garantias contratuais;
- protege-se contra acesso não autorizado e suas informações contra perda;
- lida com falhas de forma que elas não causem danos às informações.
Todas essas propriedades podem ser expressas em uma palavra “autonomia”. Os serviços funcionam de forma independente uns dos outros, satisfazem certas restrições e definem contratos com base nos quais as pessoas podem receber as informações de que necessitam. Não mencionei tecnologias específicas, cuja utilização é evidente.
Agora vamos dar uma olhada na definição de microsserviços:
- um microsserviço é pequeno e projetado para resolver um problema específico;
- O microsserviço é autônomo;
- Ao criar uma arquitetura de microsserviços, a metáfora do planejamento urbano é usada. Esta é a definição do livro de Sam Newman, Building Microservices.
A definição de Contexto Limitado foi retirada do livro Domain-Driven Design de Eric Evans. Este é um padrão central no DDD, um centro de design de arquitetura que trabalha com modelos arquitetônicos volumétricos, dividindo-os em diferentes contextos limitados e definindo explicitamente as interações entre eles.
Simplificando, um Contexto Limitado denota o escopo no qual um módulo específico pode ser usado. Dentro deste contexto está um modelo logicamente unificado que pode ser visto, por exemplo, no seu domínio de negócio. Se você perguntar “quem é cliente” ao pessoal envolvido nos pedidos, obterá uma definição, se perguntar aos envolvidos nas vendas, obterá outra, e os executores lhe darão uma terceira definição.
Assim, o Contexto Limitado diz que se não podemos dar uma definição clara do que é um consumidor dos nossos serviços, vamos definir os limites dentro dos quais podemos falar sobre o significado deste termo, e depois definir os pontos de transição entre estas diferentes definições. Ou seja, se estamos falando de um cliente do ponto de vista de fazer pedidos, isso significa isso e aquilo, e se do ponto de vista de vendas, isso significa isso e aquilo.
A próxima definição de microsserviço é o encapsulamento de qualquer tipo de operação interna, evitando o “vazamento” dos componentes do processo de trabalho para o ambiente. Em seguida vem a “definição de contratos explícitos para interações externas, ou comunicações externas”, que é representada pela ideia de contratos retornando de SLAs. A última definição é a metáfora de uma célula, ou célula, que significa o encapsulamento completo de um conjunto de operações dentro de um microsserviço e a presença nele de receptores para comunicação com o mundo exterior.
Então dissemos ao pessoal da Bell Computers: “Não podemos consertar nada do caos que vocês criaram porque vocês simplesmente não têm dinheiro para fazer isso, mas consertaremos apenas um serviço para que tudo dê certo. senso." Neste ponto, começarei contando como consertamos nosso único serviço para que ele respondesse às solicitações em menos de 9 minutos e meio.
22:30 min
Continuará muito em breve...
Um pouco de publicidade
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com