Introdução: Com o desenvolvimento da arquitetura de sistema de software, passamos de um único aplicativo a um sistema distribuído, e gradualmente passamos para a nuvem nativa. Dentre eles, a arquitetura de microsserviço é a mais representativa, mas existem vários tipos de design de microsserviço. todos os tipos de problemas, espero que este artigo possa ajudá-lo a fornecer ideias e orientação no design da arquitetura de microsserviço.
Prefácio e histórico
Antes de começar a história, deixe-me contar uma história. Nos últimos anos, com o desenvolvimento da arquitetura de sistema de software, passamos de um único aplicativo a um sistema distribuído, e gradualmente avançamos para o nativo da nuvem. Entre eles, a arquitetura de microsserviço é o mais representativo., Mas há vários problemas no design de microsserviços. Por exemplo, se a granularidade dos microsserviços for muito fina e a profundidade das chamadas entre os serviços for muito longa, pode ser necessário reorganizar o negócio e considerar o fusão de serviços. Nesse momento, alguém vai perguntar: " Por que você desmontou e recombinou microsserviços? " Você disse a ele que estamos " Construindo uma Central "; então, com a rápida expansão do negócio, o uso de recursos não pode mais aguarde e devemos considerar a desmontagem do sistema. Às vezes, alguém perguntará: " Por que você combinou e desmontou os microsserviços novamente? " Você diz a ele que estamos " desmontando a estação intermediária "; então, é claro, após a desmontagem, é constatou que alguns serviços estão desarmados de maneira não razoável, talvez esteja prestes a se fundir novamente. Nesse momento, alguém pergunta: " O que diabos você está fazendo? " Você pode responder como um velho: "O mundo está na tendência geral. Se dividimos por muito tempo, devemos nos unir. Se ficarmos juntos por muito tempo, devemos nos dividir. Qin. Após a extinção de Qin, Chu e Han foram divididos e fundidos em Han. O imperador de Han governou o mundo, e mais tarde Guangwu Zhongxing foi dividido em três estações intermediárias ... "
Muitas pessoas podem sentir o mesmo na aplicação real do design de microsserviço nos cenários semelhantes acima. Como dividir e projetar microsserviços de maneira razoável? Se existem padrões e normas relevantes para referência, a resposta é sim, mas apenas a metodologia. Do ponto de vista filosófico, não existe uma solução universal, mas alguns métodos podem ser resumidos e abstraídos como um guia com base na experiência, mas após abstração excessiva, é muito obscuro e difícil de entender, e a implementação não é uma tarefa fácil.
Uma breve história do desenvolvimento de microsserviços
Em primeiro lugar, vamos revisar o processo de desenvolvimento da arquitetura do sistema de software: Arquitetura monolítica -> Arquitetura distribuída / cluster -> Arquitetura orientada a serviços (SOA orientada a serviços) -> Arquitetura de microsserviço -> Arquitetura de Gridização / Unitização
Em geral, a arquitetura de microsserviço inclui todas as características da arquitetura anterior, implantação de cluster distribuída, design orientado a serviço e microsserviços prestam mais atenção à granularidade da divisão de serviço, ou seja: quão grande um serviço deve ser dividido . No entanto, com o aumento no volume de negócios do sistema, a escala de serviços também se tornou cada vez maior e novos problemas correspondentes surgiram, como problemas de recursos do sistema subjacentes, problemas de comunicação e governança entre serviços e problemas gerais de operação e manutenção de serviços. SpringCloud, frameworks de Microservice como Dubbo só podem resolver problemas no nível de desenvolvimento de software. No início dos microsserviços, as pessoas se concentravam no nível de desenvolvimento de software. Nos últimos anos, com a maturidade e a promoção de tecnologias de operação e manutenção, como a tecnologia de gerenciamento de contêineres Docker e a tecnologia de orquestração de contêineres Kubernetes, o sistema de microsserviços mudou do foco original no desenvolvimento. Gradualmente evoluiu para um modelo de gerenciamento DevOps integrando design, desenvolvimento, operação e manutenção.
Por meio do processo de desenvolvimento da arquitetura de serviço, podemos ver que os microsserviços alcançam o desacoplamento entre os serviços, mas também causam muitos problemas não comerciais. Por exemplo: descoberta de serviço, limitação de corrente de serviço, monitoramento de serviço, controle de permissão de serviço, controle de versão de serviço, etc. Spring Cloud e outras estruturas de microsserviço, embora nos forneçam, por exemplo: Eurek, um registro para resolver problemas de descoberta de serviço, Hystrix, um disjuntor para resolver problemas de limitação atuais e Ribbon, Fegin e outras tecnologias para resolver serviços problemas de invocação, mas vamos ver se são. Como é usado? Importe dependências de dependência, empacote-as e implante-as com nosso código de negócios, o que significa que Spring Cloud é uma solução "intrusiva". Embora simplifique a dificuldade de lidar com problemas não comerciais, os desenvolvedores ainda precisam lidar com essa parte. ser entendido.
Esperamos que os desenvolvedores de negócios se preocupem apenas com o desenvolvimento de código de negócios, em vez de gastar sua energia no desenvolvimento de código não comercial. A tecnologia Service Mesh (malha de serviço) é a personificação dessa ideia, que pode ajudar a remover funções não comerciais do O processo de remoção de mídia remove toda a comunicação de rede entre os serviços e a transfere para o nível de infraestrutura, como: descoberta de serviço, balanceamento de carga, controle de versão, implantação azul-verde e outros problemas.
Voltemos ao problema fundamental a ser resolvido no design de microsserviços, a saber: como projetar e dividir microsserviços. Aqui estão alguns princípios e metodologia comumente usados no design de arquitetura de microsserviço:
- Princípio de divisão AKF
- Princípios de Separação de Negócios
- Design Orientado por Domínio
- Projeto de arquitetura em camadas
Princípio de divisão AKF
Vamos primeiro falar sobre os princípios mais básicos do design de microsserviços : AKF Scalability Cube
AKF Scalability Cube é um modelo escalável proposto no livro "Arquitetura é o futuro". Este cubo tem três eixos, e cada eixo descreve a extensão. Uma dimensão de sexo . Em teoria, de acordo com esses três modos de expansão, um único sistema pode ser expandido infinitamente.
- Eixo X: refere-se à cópia horizontal. É fácil entender que é para executar mais algumas instâncias do sistema único para fazer um cluster mais o modo de balanceamento de carga. Para oferecer melhor suporte a essa escalabilidade horizontal, o sistema é mais bem projetado para separar o front-end e o back-ends e fornecer serviços sem estado. Esse tipo de capacidade de expansão tem o menor custo e a implementação mais simples, é adequada para o estágio inicial de desenvolvimento e tem baixa complexidade de negócios.O aumento da capacidade do sistema pode resolver a maioria dos problemas.
- Eixo Y: refere-se à divisão de responsabilidades no aplicativo. Essa parte é o que costumamos chamar de modo de divisão de microsserviço, que é dividido com base em diferentes negócios. Este tipo de capacidade de expansão que pertence ao desacoplamento de negócios pode tornar a equipe mais focada e resolver o problema de complexidade do código, mas envolverá inevitavelmente o isolamento e a transmissão dos dados subjacentes, então o grau de dificuldade é relativamente grande, o que é adequado para negócios complexos e volume de dados. Cena de equipe grande e em grande escala.
- Eixo Z: refere-se ao particionamento baseado em serviços ou dados, como particionamento por região. Este é o método de expansão mais caro. Geralmente, sistemas muito grandes têm requisitos semelhantes. Por exemplo, quando um sistema de Internet aumenta repentinamente em volume de usuários e um único modelo de cluster pode não ser capaz de carregá-lo, ele precisa ser atendido de acordo com região do usuário e partição de dados. Diferente da tabela de sub-banco de dados tradicional ou multilocatário logicamente, várias partições precisam ser fisicamente separadas, semelhante à arquitetura unificada do setor financeiro nos últimos anos e à ideia de vários data centers. É adequado para o rápido crescimento exponencial de usuários e pode ser particionado de acordo com certas regras.
Ao mesmo tempo que prestamos atenção na divisão dos três eixos do AKF, também precisamos pensar nos princípios 3S, a saber: Segurança (segurança), Escala (escala), Velocidade (velocidade)
Princípios de Separação de Negócios
A seguir, da perspectiva dos negócios do sistema, fale sobre a divisão e os princípios de design dos microsserviços.
Esclareça a separação de microsserviços e princípios de design; realize microsserviços com necessidades de negócios como o centro, alta autonomia e evolução contínua como objetivo.
Para chamadas de serviço cruzado, primeiro considere a partir de uma perspectiva de negócios, obtenha alta coesão, baixo acoplamento e minimize a ocorrência de tal acoplamento por meio do princípio de divisão.
Design Orientado por Domínio
Domain-Driven Design (DDD: Domain-Driven Design) é um conjunto de métodos de modelagem orientados a objetos mais avançados para análise e design de sistemas de software. É muito diferente da arquitetura tradicional centrada em design orientada a dados.O design orientado a domínio presta mais atenção ao modelo de domínio, então o que é um domínio? Para ser franco, um campo se refere, na verdade, a uma área de negócios . O design orientado para o domínio visa construir a relação entre a empresa e a empresa, bem como a lógica interna da empresa .
No design orientado a domínio, a primeira e mais importante etapa é chegar a um consenso. A equipe, incluindo técnicos, especialistas em domínio, gerentes de produto, etc., pode chegar a um consenso sobre o conhecimento de negócios relacionado ao campo, para que todos possam ser simples, claro e preciso. Descreva o significado do negócio e as regras deste campo, esta é a linguagem unificada (Ubiquitous Language) . É uma maneira eficaz de resolver a complexidade dos negócios em alguns sistemas de software de médio e grande porte, chegando a esse consenso.
Depois de ter uma linguagem comum, como organizar e implementar o modelo de negócio, esta parte é a fase de Model-Driven Design (Model-Driven Design) . O DDD divide este processo de design de modelo em duas etapas:
- Desenho estratégico
- Design tático
O chamado design estratégico, também conhecido como design de alto nível, refere-se à separação do sistema em diferentes domínios, ou seja: quais são os domínios centrais (competitividade central), que são os domínios gerais (não centrais compartilhados , disponível externamente), e qual é o domínio de suporte (não exclusivo para o núcleo e pode ser terceirizado).
O chamado design tático refere-se a como organizar especificamente diferentes modelos de negócios, ou seja: quais papéis (entidades, objetos de valor) são esses modelos? Qual é a relação entre esses modelos (agregação, raiz de agregação)? Como esses modelos colaboram e evoluem (eventos de domínio, serviços de domínio, fábricas, depósitos, serviços de aplicativo)?
Em seguida, o modelo de domínio é dividido em contextos de fronteira e as dependências entre eles são identificadas para formar um design de modelo de domínio semelhante à figura acima e, finalmente, o contexto de fronteira ou o modelo de domínio nele é mapeado em microsserviços.
O design orientado a domínio, um método de design orientado a negócios, se encaixa naturalmente nos sistemas de desenvolvimento ágil e arquitetura de microsserviço de hoje.
Projeto de arquitetura em camadas
Finalmente, com base nos princípios e métodos de design acima, vamos dar uma olhada no design da arquitetura em camadas. Acho que todos devem estar familiarizados com o design em camadas, mas como criar camadas na arquitetura de microsserviço, você pode consultar a seguinte construção de estágio intermediário cenários:
聚合域：聚合中台业务完成业务流程
业务域：提供中台业务能力接口
通用域：提供数据的原子操作接口
A vantagem da arquitetura em camadas é que ela pode tornar a relação entre os serviços mais clara. Tente não chamar uns aos outros no mesmo nível e evite chamadas entre níveis. A profundidade de toda a cadeia de chamadas também deve ser controlada dentro de um determinado intervalo .
Considerações finais
Não existe melhor modo de design e esquema de arquitetura, apenas otimização contínua e evolução do sistema. É necessário encontrar o gargalo de desempenho do sistema, encontrar o local corrompido no design da arquitetura, encontrar o método viável e, então, otimizar e melhorar continuamente a qualidade do sistema., O encanto da arquitetura reside aqui.
"Cada linha de código que você escreve é o seu cartão de visita e cada bug corrigido é contado. Esta não é uma técnica de programação, é a arte da programação." - Tribute to "Flying Life"