Habilidades avançadas em design de arquitetura de sistema · Teoria e prática de design de arquitetura nativa de nuvem

Índice de artigos da série
1. A conotação da arquitetura nativa da nuvem
2. Tecnologias relacionadas à arquitetura nativa da nuvem

Insira a descrição da imagem aqui

1. A conotação da arquitetura nativa da nuvem

1.1 Definição

A arquitetura nativa da nuvem é uma coleção de princípios arquitetônicos e padrões de design baseados em tecnologia nativa da nuvem. Tem como objetivo maximizar a remoção de partes de código não comerciais em aplicativos em nuvem, permitindo que as instalações da nuvem assumam um grande número de recursos não funcionais originais em aplicativos (como elasticidade, resiliência, segurança e partes de código são eliminadas ao máximo, para que as instalações da nuvem possam assumir um grande número de recursos não funcionais originais (como elasticidade, resiliência, segurança, observabilidade, escala de cinza, etc.) .) no aplicativo, para que o negócio não tenha mais problemas com interrupções de negócios não funcionais, ele é leve, ágil e altamente automatizado.

1.2 Recursos

Os recursos do aplicativo baseados na arquitetura nativa da nuvem incluem:

(1) A estrutura do código sofreu grandes mudanças : não é mais necessário dominar os arquivos e sua tecnologia de processamento distribuído, e não é mais necessário dominar várias tecnologias de rede complexas. A simplificação torna o desenvolvimento do negócio mais ágil e rápido.
(2) Um grande número de recursos não funcionais são confiados à arquitetura nativa da nuvem para resolver : como alta disponibilidade, recuperação de desastres, recursos de segurança, operabilidade, facilidade de uso, testabilidade, recursos de liberação em escala de cinza, etc.
(3) Entrega de software altamente automatizada : A entrega automatizada de software baseada na nuvem nativa pode implantar aplicativos automaticamente em milhares de nós.

1.3 Princípios do nativo da nuvem

O nativo da nuvem tem os seguintes princípios:

(1) Princípio de servitização : módulos separados de diferentes ciclos de vida por meio da arquitetura de servitização e condução de iterações de negócios separadamente.
(2) Princípio da elasticidade : Elasticidade significa que a escala de implantação do sistema pode expandir e contrair automaticamente à medida que o volume de negócios muda.
(3) Princípio de observabilidade : Por meio de logs, rastreamento e medição de links, os valores e parâmetros de retorno demorados de múltiplas chamadas de serviço são claramente visíveis.
(4) Princípio da resiliência : A capacidade do software de resistir quando ocorrem várias anormalidades nos componentes de software e hardware dos quais o software depende.
(5) Princípios de automação de todos os processos : permitir que as ferramentas de automação entendam as metas de entrega e as diferenças ambientais para realizar a automação de toda a entrega, operação e manutenção do software.
(6) Princípio de confiança zero : Nenhuma pessoa/dispositivo/sistema dentro ou fora da rede deve ser confiável, e a base de confiança do controle de acesso precisa ser reconstruída com base na autenticação e autorização.
(7) Princípio da evolução contínua da arquitetura : A arquitetura tem a capacidade de continuar a evoluir.

1.4 Principais padrões arquitetônicos

Os principais padrões arquitetônicos envolvidos no nativo da nuvem.

1.4.1 Modelo de arquitetura orientada a serviços

É necessário dividir um software aplicativo na granularidade dos módulos de aplicativo, definir relações comerciais mútuas com contratos de interface (como IDL), garantir interconexão mútua com protocolos padrão (HTTP, gRPC, etc.) e combiná-lo com Domain Driven Design (DDD), Test Driven Design (TDD) e implantação em contêineres melhoram a qualidade do código e a velocidade de iteração de cada interface.

1.4.2 Modelo de arquitetura de malha

A arquitetura mesh separa a estrutura de middleware (como RPC, cache, mensagens assíncronas, etc.) do processo de negócios, desvinculando ainda mais o SDK do middleware do código de negócios, de modo que a atualização do middleware não tenha impacto no processo de negócios e até mesmo migre para outra O middleware de uma plataforma também é transparente para o negócio.

1.4.3 Modo sem servidor

Quando o tráfego de negócios chega ou ocorre um evento de negócios, a nuvem iniciará ou agendará um processo de negócios iniciado para processamento. Após a conclusão do processamento, a nuvem fechará/agendará automaticamente o processo de negócios e aguardará o próximo gatilho. Os desenvolvedores não precisam se preocupar com o local de execução do aplicativo, sistema operacional, configuração de rede, desempenho da CPU, etc., e confiar toda a operação do aplicativo à nuvem. O modo sem servidor é adequado para tarefas de computação de dados orientadas a eventos, aplicativos de solicitação/resposta com tempo de computação curto e tarefas de ciclo longo sem chamadas mútuas complexas.

1.4.4 Modo de armazenamento e separação de cálculo

A dificuldade do CAP num ambiente distribuído é principalmente para aplicações com estado.Uma vez que a consistência (Consistência, C), a disponibilidade (Disponível, A) e a tolerância de partição (Tolerância de Partição, P) não podem ser satisfeitas ao mesmo tempo, no máximo dois dos eles podem ficar satisfeitos. Portanto, aplicações sem estado não possuem dimensão de consistência e podem alcançar boa disponibilidade e tolerância a falhas de partição, alcançando assim melhor elasticidade.

1.4.5 Modo de transação distribuída

Como a empresa precisa acessar vários microsserviços, surgirão problemas de transação distribuída, caso contrário, os dados serão inconsistentes. Portanto, os arquitetos precisam escolher modos de transação distribuídos apropriados de acordo com diferentes cenários.Os comumente usados são:
(1) Modo XA: Como a especificação XA é o padrão para realizar o processamento de transações distribuídas, confirmação em dois estágios (2 Prepare Commit, 2PC) é normalmente usado. O método tem forte consistência, mas requer duas interações de rede, portanto o desempenho é ruim.
(2) Consistência eventual baseada em mensagens (BASE): Quando a disponibilidade e a consistência entram em conflito, para pesar as duas, a BASE propõe que, desde que a disponibilidade básica (BA) e a consistência eventual (E) sejam atendidas, o software que aceita dados estado ou estado indeterminado (S) para priorizar o desempenho, portanto esse tipo de sistema costuma ter alto desempenho. Porém, devido às características da aplicação, opta-se por um compromisso entre disponibilidade e consistência, resultando em pouca versatilidade.
(3) Modelo TCC: Usando o modelo de dois estágios Try-Confirm-Cancel, o isolamento da transação é controlável e eficiente, mas requer código de aplicativo para dividir o modelo de negócios em dois estágios, por isso é altamente intrusivo para o negócio e o custo de design, desenvolvimento e manutenção é alta.
(4) Modo SAGA: Cada transação a termo corresponde a uma transação de compensação. Se a transação a termo não for executada, a transação de compensação será executada para reversão. Portanto, os custos de desenvolvimento e manutenção são altos.
(5) Modo AT do projeto de código aberto SEATA: Ele delega a segunda fase do modo TCC à estrutura de código subjacente e cancela bloqueios de linha, portanto, tem desempenho muito alto e não tem carga de trabalho de desenvolvimento de código, e pode executar automaticamente a reversão operações, mas existem algumas restrições de cenário de uso.

1.4.6 Arquitetura Observável

A arquitetura observável inclui registro em log, rastreamento e métricas. O registro em log fornece vários níveis de rastreamento, como INFO/DEBUG/WARNING/ERROR; o rastreamento coleta a agregação de logs de acesso do front-end ao back-end de uma solicitação para formar um relatório completo rastreamento de link de chamada; Métricas fornece medição multidimensional de quantificação do sistema, incluindo simultaneidade, consumo de tempo, tempo disponível, capacidade, etc.

1.4.7 Arquitetura orientada a eventos

Event Driven Architecture (EDA) é um padrão de arquitetura integrado entre aplicativos/componentes. Adequado para aprimorar a resiliência do serviço, notificação de alteração de dados, criação de interfaces abertas, processamento de fluxo de eventos e separação de responsabilidade de consulta de comando (Command Query Responsibility Segregation, CQRS). Os comandos que afetam o status do serviço são iniciados usando eventos sem afetar o status do serviço. A consulta usa apenas a interface API que é chamada de forma síncrona.

1.5 Antipadrões típicos da arquitetura nativa da nuvem

O design da arquitetura às vezes requer a escolha de métodos diferentes com base em diferentes cenários de negócios. Os antipadrões nativos da nuvem comuns incluem:

(1) Enorme aplicação única : falta de isolamento de dependências, acoplamento de código, limites pouco claros entre responsabilidades e módulos, falta de governança de interfaces entre módulos, difusão de mudanças, dificuldade em coordenar o progresso do desenvolvimento e o tempo de lançamento entre diferentes módulos e instabilidade de um submódulo Como resultado, toda a aplicação fica lenta. Ao expandir, a capacidade só pode ser expandida como um todo e os módulos que atingem o gargalo não podem ser expandidos individualmente.
(2) "Divisão rígida" de aplicativos monolíticos em microsserviços : Divisão forçada de módulos com alto grau de acoplamento e baixa qualidade de código em serviços; após a divisão, os dados do serviço são fortemente acoplados; após a diferenciação, tornam-se chamadas distribuídas, o que afeta seriamente o desempenho .
(3) Microsserviços sem capacidade de automação : O número de módulos por pessoa responsável aumenta, a carga de trabalho por pessoa aumenta e o custo de desenvolvimento de software também aumenta.

2. Tecnologias relacionadas à arquitetura nativa da nuvem

1.1 Tecnologia de contêineres

Como uma unidade básica de software padronizado, os contêineres empacotam e liberam aplicativos e suas dependências. Como as dependências são completas, os aplicativos não são mais restritos pelo ambiente e podem ser lidos rapidamente e executados de maneira confiável em diferentes ambientes de computação .

Comparação do modo de implantação de contêiner com outros modos, conforme mostrado na figura, comparação dos modos tradicional, de virtualização e de implantação de contêiner:
Insira a descrição da imagem aqui

1.2 Tecnologia de orquestração de contêineres

A tecnologia de orquestração de contêineres inclui agendamento de recursos, implantação e gerenciamento de aplicativos, reparo automático, descoberta de serviços e balanceamento de carga, escalabilidade elástica, API declarativa, arquitetura de escalabilidade e portabilidade .

1.3 Microsserviços

O modelo de microsserviço divide o aplicativo monolítico de back-end em vários subaplicativos fracamente acoplados, cada subaplicativo é responsável por um conjunto de subfunções. Essas subaplicações tornam-se "microsserviços" e vários "microsserviços" juntos formam um sistema de microsserviços distribuído fisicamente independente, mas logicamente completo. Este microsserviço é relativamente independente e melhora a eficiência geral da iteração ao desacoplar os processos de desenvolvimento, teste e implantação.

As restrições de design de microsserviços são as seguintes:

(1) Restrições individuais de microsserviços: Para
um aplicativo de microsserviços bem projetado, as funções concluídas devem ser independentes umas das outras em termos de divisão do domínio de negócios. Comparado com um único aplicativo que é forçosamente vinculado a uma pilha de linguagem e tecnologia, a vantagem disso é que diferentes domínios de negócios têm diferentes opções de tecnologia.Por exemplo, o sistema de recomendação usando Python pode ser muito mais eficiente que Java. Do ponto de vista organizacional, os microsserviços correspondem a equipes menores e maior eficiência de desenvolvimento. “Uma equipe de microsserviços pode comer duas pizzas em uma refeição” e “uma aplicação de microsserviços deve ser capaz de completar uma iteração pelo menos a cada duas semanas” são metáforas e padrões sobre como dividir corretamente os limites dos microsserviços em domínios de negócios. Em resumo, o “micro” dos microsserviços não é ser micro por ser micro, mas sim dividir razoavelmente uma única aplicação de acordo com o domínio do problema. Além disso, os microsserviços também devem ter características de decomposição ortogonal, focando em negócios específicos e fazendo-os bem em termos de divisão de responsabilidades, que é o Princípio da Responsabilidade Única (SRP) no princípio SOLID. Se um microsserviço for modificado ou lançado, isso não deverá afetar a interação comercial de outro microsserviço no mesmo sistema.

(2) Relações horizontais entre microsserviços.
Depois de dividir razoavelmente as fronteiras entre microsserviços, as relações horizontais entre serviços são tratadas principalmente a partir da descoberta e interatividade dos microsserviços. A descoberta dos microsserviços significa que quando o serviço A é lançado, expandido ou reduzido, como o serviço B, que depende do serviço A, pode detectar automaticamente as alterações no serviço A sem liberá-lo novamente? Um serviço de terceiros precisa ser introduzido aqui Centro de registro para atender à descoberta de serviços; especialmente para clusters de microsserviços em grande escala, os recursos de envio e expansão do centro de registro de serviços são particularmente críticos. A interatividade dos microsserviços refere-se à forma como o serviço A pode chamar o serviço B. Devido às restrições de autonomia do serviço, as chamadas entre serviços precisam usar protocolos de chamada remota independentes de idioma. Por exemplo, o protocolo REST satisfaz bem os dois fatores importantes de "independente de idioma" e "padronização". No entanto, em alto desempenho cenários, um protocolo binário baseado em IDL pode ser uma escolha melhor. Além disso, a maioria das práticas atuais de microsserviços no setor muitas vezes não alcançam a chamada REST heurística HATEOAS, e os serviços precisam concluir a chamada por meio de uma interface pré-acordada. Para realizar ainda mais a dissociação entre os serviços, o sistema de microsserviços precisa de um centro de metadados independente para armazenar as informações de metadados do serviço. O serviço consulta o centro para entender os detalhes da chamada. À medida que os links de serviço continuam a crescer, todo o sistema de microsserviços torna-se cada vez mais frágil.Portanto,
o princípio do design orientado a falhas é particularmente importante no sistema de microsserviços. Para aplicações de microsserviços individuais, mecanismos para aumentar a resiliência do serviço, como limitação de corrente, disjuntor, isolamento e balanceamento de carga, tornaram-se padrão. A fim de melhorar ainda mais o rendimento do sistema e aproveitar ao máximo os recursos da máquina, isso pode ser alcançado por meio de corrotinas, modelos Rx, chamadas assíncronas, contrapressão e outros meios.

(3) Restrições verticais entre microsserviços e camada de dados

No campo dos microsserviços, é adotado o princípio da Segregação de Armazenamento de Dados (DSS), ou seja, os dados são o bem privado do microsserviço, e o acesso aos dados deve ser feito por meio da API fornecida pelo microsserviço atual. Caso contrário, causará acoplamento na camada de dados, violando o princípio de alta coesão e baixo acoplamento. Ao mesmo tempo, por razões de desempenho, geralmente é adotada a separação leitura-gravação (CQRS). Da mesma forma, devido ao impacto imprevisível do agendamento de contêineres na estabilidade das instalações subjacentes, o projeto de microsserviços deve tentar seguir o princípio de design sem estado, o que significa que o aplicativo superior e a infraestrutura subjacente são desacoplados, e os microsserviços podem ser agendados livremente entre recipientes diferentes. . Para microsserviços que têm acesso a dados (ou seja, com estado), a separação entre computação e armazenamento é geralmente usada para afundar os dados no armazenamento distribuído. Dessa forma, um certo grau de apatridia pode ser alcançado.

(4) Restrições distribuídas de microsserviços de uma perspectiva global
. Desde o início do projeto do sistema de microsserviços, os seguintes fatores devem ser considerados: operação e manutenção eficientes de todo o sistema e preparação técnica de um pipeline de CI/CD totalmente automatizado para atender à demanda. para a eficiência do desenvolvimento. e, com base nisso, apoia diferentes estratégias de lançamento, como azul-verde e canário, para atender à demanda por estabilidade de lançamento comercial. Diante de sistemas complexos, as capacidades de observação multidimensional, de link completo e em tempo real tornaram-se padrão. Para evitar vários riscos de operação e manutenção de forma oportuna e eficaz, os dados relevantes precisam ser coletados e analisados a partir de múltiplas fontes de eventos no sistema de microsserviços e, em seguida, exibidos de maneira multidimensional em um sistema de monitoramento centralizado. À medida que os microsserviços continuam a ser divididos, a pontualidade na detecção de falhas e a precisão das causas raízes sempre foram as principais demandas do pessoal de desenvolvimento, operação e manutenção.

1.4 Tecnologia sem serviço

Características da tecnologia sem serviço:

(1) Serviços de computação totalmente gerenciados, os clientes só precisam escrever código para construir aplicativos e não precisam prestar atenção ao desenvolvimento, operação e manutenção homogêneo e oneroso, segurança, alta disponibilidade e outros trabalhos baseados em servidores e outras infraestruturas;

(2) A versatilidade, combinada com os recursos da API BaaS em nuvem, pode suportar todos os tipos importantes de aplicativos na nuvem;

(3) O escalonamento elástico automático elimina a necessidade de os usuários planejarem antecipadamente a capacidade para uso de recursos;

(4) O faturamento pré-pago permite que as empresas reduzam efetivamente os custos de uso sem ter que pagar por recursos ociosos.

1.5 Rede de serviços

Service Mesh é uma nova tecnologia desenvolvida para aplicativos distribuídos com base na arquitetura de software de microsserviços. Seu objetivo é incorporar funções comuns, como conexão, segurança, controle de fluxo e observabilidade entre microsserviços, na infraestrutura da plataforma. Conseguir a dissociação de aplicativos e infraestrutura de plataforma . Esta dissociação significa que os desenvolvedores não precisam prestar atenção às questões de governança relacionadas aos microsserviços e focar na própria lógica de negócios, melhorando a eficiência do desenvolvimento de aplicações e acelerando a exploração e inovação dos negócios. Em outras palavras, a malha de serviço permite a simplificação da aplicação de uma forma não intrusiva, porque uma grande quantidade de não funcionalidades é transferida dos processos de negócios para outros processos.

Conforme mostrado na figura, a arquitetura típica da rede de serviços:

Insira a descrição da imagem aqui

Neste diagrama de arquitetura, todas as solicitações do serviço A para chamar o serviço B são interceptadas pelo proxy de serviço abaixo dele. O serviço proxy A completa a descoberta de serviço, disjuntor, limitação de corrente e outras estratégias para o serviço B. O controle geral dessas estratégias é Configurar no plano de controle.