Aprenda arquitetura do zero - Padrões de arquitetura extensíveis

Idéias básicas e padrões de padrões de arquitetura escaláveis

A maior diferença entre um sistema de software e um sistema de hardware e construção é que o software é escalável. Uma peça de hardware não será alterada depois de produzida e sua estrutura geral não será alterada após a conclusão de uma construção. Por exemplo, um A CPU será instalada após sua produção
. Em um PC, não há como voltar à fábrica para usinagem para adicionar novos recursos; a pirâmide permaneceu por mil anos e resistiu, mas sua estrutura é a mesma agora de quando foi construído.
Em contraste, os sistemas de software são o completo oposto.Um sistema de software verdadeiramente viável está em constante iteração e desenvolvimento. Um sistema operacional típico como o Windows, do Windows 3.0 ao Windows 95 ao Windows XP, até agora o Windows 10, está em constante desenvolvimento com o desenvolvimento da tecnologia. Se um sistema de software é desenvolvido sem atualizações e ajustes, significa que o sistema de software não tem desenvolvimento e vitalidade.
Essa extensibilidade natural e inerente dos sistemas de software é um encanto e uma dificuldade.

• O charme se reflete no fato de podermos continuamente fazer com que o sistema de software tenha mais funções e recursos por meio de modificações e ampliações, para atender a novas necessidades ou acompanhar a tendência do desenvolvimento tecnológico.
• A dificuldade está em como expandir o sistema com o menor custo, pois em muitos casos, envolve todo o corpo e, ao expandir, pode ser necessário mudar em todos os lugares, derrubar tudo e começar de novo. O risco de fazer isso é evidente: quanto mais mudanças são feitas, maior o investimento e maior a possibilidade de erros.

Portanto, como evitar uma gama muito grande de mudanças durante a expansão é a principal consideração no projeto de escalabilidade da arquitetura de software.

A ideia básica de extensibilidade

Existem muitas maneiras de projetar arquiteturas escaláveis, mas elas permanecem as mesmas. A ideia básica por trás de todos os projetos de arquitetura escalável pode ser resumida em uma palavra: demolição!
A demolição é dividir o sistema unificado original em várias partes de pequena escala, e modificar apenas uma parte dele ao expandir, sem alterar todo o sistema em todos os lugares. Dessa forma, o escopo das mudanças e o risco de mudanças podem ser reduzidos.
Diante dos sistemas de software, desmontar não é tão simples, pois não queremos destruir um sistema de software, mas sim tornar o sistema de software mais bonito (com melhor escalabilidade) através do desmonte. Em termos figurados, a "demolição" em um sistema de software é construtiva, então a dificuldade é muito maior.
Dividir o sistema de software de acordo com diferentes ideias resultará em diferentes arquiteturas. Existem três ideias divididas comuns, como segue:

• Divisão orientada ao processo: Divida todo o processo de negócios em vários estágios, cada estágio como uma parte
• Divisão orientada a serviços: divide os serviços fornecidos pelo sistema, cada serviço como uma parte
• Divisão orientada a função: divisão das funções fornecidas pelo sistema, cada função como uma parte

A chave para entender essas três ideias está em como entender a conexão e a diferença entre "processo", "serviço" e "função".
Do ponto de vista do escopo, a ordem do grande para o pequeno é: processo > serviço > função. Pode ser difícil entender simplesmente pela explicação conceitual, mas na verdade fica muito claro depois de examinar alguns casos. Pegue o TCP
/ Pilha de protocolo IP como exemplo:

• Processo
  Corresponde ao modelo TCP/IP de quatro camadas, porque o processo de comunicação de rede TCP/IP é: camada de aplicação → camada de transporte → camada de rede → física + camada de enlace de dados, não importa qual seja a camada de aplicação superior, este processo não mudar.
• Serviços
  Correspondentes a HTTP, FTP, SMTP e outros serviços na camada de aplicação, HTTP fornece serviços web, FTP fornece serviços de arquivo, SMTP fornece serviços de correio e assim por diante
• Funcionalidade
  Cada serviço fornece uma função correspondente. Por exemplo, o serviço HTTP fornece funções GET e POST, FTP fornece funções de upload e download e SMTP fornece funções de envio e recebimento de e-mail.
  Tomando como exemplo um sistema simples de gerenciamento de informações de alunos, o método split é:

1. Camada de apresentação dividida orientada a processos
   → camada de negócios → camada de dados → camada de armazenamento, o significado de cada camada é:
   camada de apresentação : responsável pelo design da página do usuário, empresas diferentes têm páginas diferentes.
   Por exemplo, camadas de negócios como página de login, página de registro, página de gerenciamento de informações e página de configuração de segurança : responsáveis ​​pelo processamento da lógica de negócios específica.
   Por exemplo, camadas de dados de negócios , como login, registro, gerenciamento de informações e modificação de senha : responsáveis ​​por concluir o acesso aos dados. Por exemplo, adicionar, excluir, modificar e consultar dados no banco de dados, registrar eventos em arquivos de log, etc.
   Camada de armazenamento : responsável pelo armazenamento de dados. Por exemplo, a arquitetura final do banco de dados relacional MySQL e do sistema de cache Memcache
   é a seguinte,
   

2. Divisão orientada a serviços
   Dividir o sistema em serviços como registro, login, gerenciamento de informações, configurações de segurança, etc. O diagrama de arquitetura final é o seguinte:
   

3. Divisão orientada a função
   Cada serviço pode ser dividido em mais serviços de registro: fornece várias maneiras de registro, incluindo três funções: registro de número de telefone celular, registro de carteira de identidade e registro de caixa postal do aluno.
   Serviço de login : incluindo login de número de celular, login de cartão de identificação e login de e-mail.
   Serviço de gerenciamento de informações : incluindo gerenciamento de informações básicas, gerenciamento de informações do curso, gerenciamento de informações de conquistas e outras funções.
   Serviço de configuração de segurança : incluindo funções refinadas, como alteração de senhas, proteção de telefones celulares, recuperação de senhas, etc., por exemplo:
   

Através do caso do sistema de gerenciamento de informações do aluno, pode-se constatar que os diagramas de estrutura são muito diferentes em diferentes métodos de divisão. Mas parece que de qualquer forma, é alcançável no final. Sendo esse o caso, por que deveríamos nos preocupar em escolher, apenas escolher um ao acaso?

Claro, você não pode escolher aleatoriamente, caso contrário, o projeto de arquitetura não terá sentido e o arquiteto perderá o emprego. A razão é que diferentes métodos de divisão determinam essencialmente como o sistema se expande.

Maneira escalável

Quando falamos em escalabilidade, muitos alunos vão ter uma dúvida: Mesmo que o sistema não seja dividido, desde que o design e o código sejam bem feitos, não haverá problema de mudar em todos os lugares? Por exemplo, no caso de divisão orientada a serviços, adicionar "registro de número de aluno" pode controlar o escopo da modificação, mesmo que não seja dividida em serviços, então por que temos que gastar muito tempo para dividir o sistema?
Em um ambiente ideal, sua equipe está cheia de especialistas, cada programador é muito bom e familiarizado com o negócio, e novos colegas saberão rapidamente todos os detalhes... Então não há problema se não houver divisão. Mas a realidade é: há programadores novatos na equipe, mudar A para realizar a função ou mudar B para realizar a função depende inteiramente do que ele acha fácil de mudar; alguns programadores são descuidados; Ótimo; novos colegas não não sei porque uma determinada linha de código da história é tão "nojenta", então facilmente mudam para ficar mais bonita... Todos esses problemas podem aparecer, e você vai descobrir nessa hora que uma divisão razoável, pode ser reforçado para garantir que, mesmo que o programador cometa erros, o escopo dos erros não seja muito amplo e o impacto não seja muito grande.A
seguir estão as vantagens de diferentes métodos de divisão ao lidar com a expansão.

1. Divisão orientada ao processo
   Na maioria dos casos, apenas uma camada precisa ser modificada ao expandir e, em alguns casos, as duas camadas associadas podem ser modificadas. Não parecerá que todas as camadas precisam ser modificadas ao mesmo tempo - por
   exemplo , o sistema de gerenciamento de informações do aluno, se expandirmos a camada de armazenamento do MySQL Para oferecer suporte ao MySQL e ao Oracle ao mesmo tempo, apenas a camada de armazenamento e a camada de dados precisam ser expandidas, e a camada de apresentação e a camada de negócios não precisam ser alterado
2. Divisão orientada a serviços
   Para expandir um determinado serviço, ou adicionar um novo serviço, basta expandir os serviços relacionados sem modificar todos os serviços.
   Tome também como exemplo o sistema de gerenciamento de alunos, se precisarmos adicionar um " "Cadastro de Número do Aluno ", você só precisa modificar o "Serviço de Registro" e "Serviço de Login", e os serviços "Serviço de Gerenciamento de Informações" e "Configurações de Segurança" não precisam ser modificados
3. Divisão por função
   Para expandir uma determinada função, ou para adicionar novas funções, você só precisa expandir as funções relevantes sem modificar todos os serviços.
   Tome também como exemplo o sistema de gerenciamento de alunos. Se adicionarmos a função "registro de número de aluno", então você só precisa adicionar um novo módulo funcional ao sistema e modificar o módulo "função de login" ao mesmo tempo, e outras funções não serão afetadas. Diferentes
   métodos de divisão resultarão em diferentes arquiteturas de sistema. Arquiteturas de sistema escalonáveis ​​típicas incluem:

• Divisão orientada a processos: arquitetura em camadas
• Divisão orientada a serviços: SOA, microsserviços
• Divisão Orientada a Função: Arquitetura de Microkernel

Obviamente, essas arquiteturas de sistema não são um ou outro, mas podem ser usadas em combinação no projeto de arquitetura de sistema. Tomando o sistema de gerenciamento de alunos como exemplo, podemos finalmente projetar a arquitetura assim:
o sistema geral adota a arquitetura de "microsserviço" na divisão orientada a serviços e a divide em "serviço de registro", "serviço de login", " serviço de gerenciamento de informações" e "serviço de segurança". Cada serviço é um subsistema executado de forma independente.
O próprio subsistema "serviço de registro" adota uma arquitetura em camadas para divisão de processos.
O subsistema "login service" adota a arquitetura "microkernel" orientada para divisão de funções.

Padrões tradicionais de arquitetura escalável: arquitetura em camadas e SOA

Comparado com o rápido desenvolvimento de padrões de arquitetura de alto desempenho e alta disponibilidade nas últimas décadas, pode-se dizer que o desenvolvimento de padrões de arquitetura escaláveis ​​está vacilando
. desenvolvimento de modelos escaláveis. Isso também levou ao fato
de que, quando falamos de escalabilidade, devemos falar de microsserviços, e até mesmo a arquitetura de microsserviços se tornou uma bala de prata para o design de arquitetura. Alto desempenho também usa microsserviços e alta disponibilidade também usa microsserviços
. Parece alto, mas na verdade viola o "princípio adequado" e o "princípio simples" do design de arquitetura.
Na prática, é melhor projetar uma arquitetura escalável. Em seguida, apresentaremos vários padrões de arquitetura escalável e apontaremos as vantagens de cada padrão de arquitetura. Pontos-chave e prós e contras.

arquitetura em camadas

A arquitetura em camadas é um padrão arquitetônico muito comum, também é chamada de arquitetura N-tier, geralmente, N é de pelo menos 2 camadas. Por exemplo, arquitetura C/S, arquitetura B/S. As mais comuns são arquitetura de 3 camadas (por exemplo, arquitetura MVC, MVP), arquitetura de 4 camadas e arquitetura de 5 camadas são relativamente raras. Geralmente, sistemas mais complexos podem atingir ou exceder 5 camadas, como o kernel do sistema operacional arquitetura.
Ao projetar de acordo com a arquitetura em camadas, uma variedade de diferentes arquiteturas em camadas pode ser obtida de acordo com diferentes dimensões e objetos de divisão

• 
  O objeto da arquitetura C/S e da arquitetura B/S é todo o sistema de negócios, e a dimensão da divisão é a interação do usuário, ou seja, a parte que interage com os usuários é separada em uma camada, e o plano de fundo que suporta a interação do usuário é outra camada . Por exemplo, o seguinte é um diagrama de estrutura de arquitetura C/S
  

• O objeto da arquitetura MVC e da arquitetura MVP
  é um único subsistema de negócios, e a dimensão da divisão é a responsabilidade.As diferentes responsabilidades são divididas em camadas independentes, mas as dependências de cada camada são mais flexíveis. Por exemplo, as camadas na arquitetura MVC interagem em pares:
  

• Arquitetura em camadas lógicas
  O objeto da divisão pode ser um único subsistema de negócios ou todo o sistema de negócios, e a dimensão da divisão também é de responsabilidade. Embora todas sejam baseadas na divisão de responsabilidades, a diferença entre a arquitetura lógica em camadas e a arquitetura MVC e a arquitetura MVP é que as camadas na arquitetura lógica em camadas são dependentes de cima para baixo. Arquitetura típica do kernel do sistema operacional e arquitetura TCP/IP. Por exemplo, o seguinte é o diagrama da arquitetura do sistema operacional Android:
  
  A típica arquitetura do sistema J2EE também é uma arquitetura lógica em camadas. O diagrama da arquitetura é o seguinte: O
  
  diagrama da arquitetura para camadas lógicas de todo o sistema de negócios é o seguinte:
  
  O ponto central é garantir que as diferenças entre as camadas sejam claras o suficiente e os limites sejam claros o suficiente, para que as pessoas possam entender toda a arquitetura depois de ver o diagrama de arquitetura , e é por isso que as camadas não podem ser divididas em muitas camadas. Caso contrário, se a diferença entre as duas camadas não for óbvia, o programador Xiao Ming pensa que uma determinada função deve ser colocada na camada A, mas o programador Lao Wang pensa que a mesma função deve ser colocada na camada B, o que irá levar à confusão de camadas. Se essa arquitetura for colocada em desenvolvimento real, as camadas A e B se tornarão uma bagunça e o significado de camadas será perdido.

A razão pela qual a arquitetura em camadas pode suportar melhor a expansão do sistema está no isolamento dos interesses (separação de interesses), ou seja, os componentes em cada camada processarão apenas a lógica dessa camada.
Por exemplo, a camada de apresentação só precisa processar a lógica de apresentação, e a camada de negócios só precisa processar a lógica de negócios, de modo que quando expandimos uma determinada camada, outras camadas não serão afetadas. Dessa forma, o sistema pode ser expandido rapidamente em uma determinada camada. Por exemplo, se você deseja adicionar um novo sistema de arquivos ao kernel do Linux, você só precisa modificar a camada de armazenamento de arquivos e outras camadas do kernel não precisam ser alteradas.

É claro que camadas simples não são suficientes para isolar preocupações e suportar uma expansão rápida. Ao fazer camadas, é necessário garantir que as dependências entre as camadas sejam estáveis ​​para realmente suportar uma expansão rápida. Por exemplo, para suportar diferentes formatos de sistema de arquivos, o kernel do Linux abstrai a interface do sistema de arquivos VFS. O diagrama de arquitetura é o seguinte. Se não houver VFS, sistemas de arquivos como ext2, ext3

e reiser são simplesmente divididos em " camadas do sistema de arquivos", então esta camada não atinge o objetivo de suportar a escalabilidade. Porque depois de adicionar um novo sistema de arquivos, todas as funções baseadas no sistema de arquivos devem se adaptar à nova interface do sistema de arquivos; com VFS, apenas o VFS precisa se adaptar à nova interface do sistema de arquivos e outras funções baseadas no sistema de arquivos É VFS e irá não seja afetado.

Outra característica da estrutura em camadas é a transferência camada por camada, ou seja, uma vez determinada a estratificação, todo o processo de negócios é transferido em sequência de acordo com a camada, não sendo possível pular entre as camadas.

Na estrutura C/S mais simples, o usuário deve primeiro usar a camada C e, em seguida, a camada C é passada para a camada S, e o usuário não pode acessar diretamente a camada S. Na arquitetura tradicional J2EE 4-tier, após o recebimento da requisição, a requisição deve ser entregue da seguinte forma:

A vantagem dessa restrição da estrutura hierárquica é que as dependências hierárquicas são forçadas a serem limitadas a dependências pareadas, o que reduz a complexidade geral do sistema.

Por exemplo,
a camada de persistência é a seguinte,

public class AvatarDao {
    
    
    public static String getAvatarUrl(int userId){
    
    
        // 具体实现代码 略
        return "http://avatar.csdn.net/xxx.jpg";
    }
}

A camada de negócios é a seguinte,

public class AvatarBizz {
    
    
    public static String getAvatarUrl(int userId){
    
    
        return AvatarDao.getAvatarUrl(userId);
    }
}

A camada de apresentação é a seguinte,

public class AvatarView {
    
    
    public void displayAvatar(int userId) {
    
    
        String url = AvatarBizz.getAvatarUrl(userId);
        // 渲染代码略
        return;
    }
}

Por exemplo, a Camada de Negócios depende da Camada de Apresentação e depende apenas da Camada de Persistência. Mas o preço da estrutura em camadas é a redundância, ou seja, por mais simples que seja o negócio, cada camada deve participar do processamento, e até mesmo uma simples função wrapper pode ser escrita para cada camada. A vantagem da arquitetura em camadas é que as dependências aos pares são impostas e limitadas pelas camadas. Uma vez que as camadas são escolhidas livremente, a arquitetura se tornará caótica com o tempo.

Por exemplo, a camada de apresentação acessa diretamente a camada de persistência, e a camada de negócios acessa diretamente a camada de banco de dados. Ao fazer isso, o significado da arquitetura em camadas é perdido e também leva à incapacidade de controlar o escopo do impacto durante subseqüentes expansões. Afeta todo o corpo e não pode suportar uma expansão rápida.
Além disso, embora a implementação da arquitetura em camadas pareça um pouco prolixa e redundante em alguns cenários, a complexidade é muito baixa.
Outra desvantagem típica da arquitetura em camadas é o desempenho, pois cada solicitação de negócios precisa passar por toda a arquitetura em camadas, algumas coisas são redundantes e haverá algum desperdício de desempenho

A chamada desvantagem de desempenho aqui é apenas uma análise teórica. Na verdade, a perda de desempenho causada por camadas pode ser óbvia na década de 1980, mas agora,
o desempenho de hardware e redes deu um salto qualitativo. Na verdade, camadas O desempenho perda na teoria do modo é insignificante na maioria dos cenários em aplicações práticas

SOA

O nome completo de SOA é Service Oriented Architecture, e a tradução chinesa é "Service Oriented Architecture". O pano de fundo do surgimento da SOA é a construção repetida e a baixa eficiência dos sistemas de TI dentro da empresa, que se refletem principalmente em:

• Cada departamento da empresa possui sistemas de TI independentes, como sistemas de recursos humanos, sistemas financeiros e sistemas de vendas.Todos esses sistemas podem envolver gerenciamento de pessoal e cada sistema de TI precisa repetir as funções de gerenciamento de desenvolvedores. Por exemplo, depois que um funcionário sai da empresa, é necessário excluir a permissão do funcionário nos três sistemas acima, respectivamente.
• Cada sistema de TI independente pode ser adquirido de diferentes fornecedores com diferentes tecnologias de implementação, e é improvável que a própria empresa reconstrua com base nesses sistemas.
• Com o desenvolvimento do negócio, a complexidade está ficando cada vez maior, e mais processos e negócios requerem a cooperação de vários sistemas de TI. Como não existe um método de implementação padrão para cada sistema de TI independente (por exemplo, o sistema de recursos humanos é desenvolvido em Java e fornece RPC para o exterior; enquanto o sistema financeiro é desenvolvido em C# e fornece o protocolo SOAP para o exterior), cada sempre que um novo processo e negócio são desenvolvidos, a coordenação é necessária. Um grande número de sistemas de TI é customizado e desenvolvido ao mesmo tempo, o que é muito ineficiente.

Em resposta aos problemas dos sistemas tradicionais de TI, SOA propõe 3 conceitos-chave

Servir

Todas as funções de negócios são um serviço, e serviço significa fornecer recursos abertos para o mundo externo.Quando outros sistemas precisam usar essa função, não há necessidade de desenvolvimento personalizado. Os serviços podem ser grandes ou pequenos, simples ou complexos.
Por exemplo, o gerenciamento de recursos humanos pode ser um serviço, incluindo gerenciamento básico de informações de pessoal, gerenciamento de licenças, gerenciamento de estrutura organizacional e outras funções.
O gerenciamento básico de informações de pessoal também pode ser usado como um serviço independente.
O Org Structure Management também está disponível como um serviço independente.
Se é dividido em serviços de granularidade grossa ou serviços de granularidade precisa ser julgado de acordo com a situação real da empresa.

ESB

O nome completo do ESB é Enterprise Service Bus, e a tradução chinesa é "Enterprise Service Bus".
Como pode ser visto pelo nome, ESB refere-se ao conceito de barramento de computador.
O barramento no computador conecta os vários dispositivos e o ESB conecta os vários serviços na empresa.
Como cada serviço independente é heterogêneo, se não houver um padrão unificado, as interfaces fornecidas por cada sistema heterogêneo são diversas.
SOA usa ESB para proteger sistemas heterogêneos de fornecer vários métodos de interface externa, de modo a obter interconexão e intercomunicação eficientes entre serviços.

fracamente acoplada

O objetivo do baixo acoplamento é reduzir a dependência e a influência mútua entre vários serviços.
Porque depois de adotar a arquitetura SOA, cada serviço é executado de forma independente um do outro, e nem fica claro o quanto um determinado serviço depende de outros serviços.
Se o baixo acoplamento não for alcançado, assim que um determinado serviço for atualizado, todos os outros serviços que dependem dele falharão, o que definitivamente não atenderá às necessidades do negócio.
Na verdade, não é tão fácil conseguir um acoplamento fraco, mas é uma tarefa complicada conseguir compatibilidade total com versões anteriores.

A arquitetura SOA é um conceito de design de arquitetura de nível relativamente alto. Geralmente, podemos dizer que uma empresa adota a arquitetura SOA para construir sistemas de TI, mas não podemos dizer que um sistema independente adota a arquitetura SOA. SOA resolve a duplicação de sistemas de TI tradicionais
. problema de ineficiência na construção e dimensionamento, mas isso por si só introduz mais complexidade. O SOA mais criticado é o ESB, que precisa implementar funções como conversão de protocolo, conversão de dados e roteamento dinâmico transparente com vários sistemas. A figura abaixo é o fluxograma do ESB convertendo JSON para Java.

Na figura abaixo, o ESB converte o protocolo REST em dois protocolos diferentes: RMI e AMQP:

Embora o ESB seja poderoso, existem muitos protocolos na realidade, como JMS, WS , HTTP, RPC, etc. Também existem muitos formatos de dados, como XML, JSON, binário, HTML, etc. O
ESB precisa concluir a conversão mútua de tantos protocolos e formatos de dados, a carga de trabalho e a complexidade são muito grandes e esta conversão requer muito esforço. desempenho de computação.
Quando o ESB carrega muitas mensagens, o próprio ESB se torna o gargalo de desempenho de todo o sistema.