Currículo de programador Java "pontos positivos", quanto você sabe sobre tecnologia de arquitetura de microsserviço?

Antes de abrir o artigo, direi algumas atitudes em relação aos microsserviços:

Existem muitos padrões arquitetônicos e os microsserviços não são a única opção nem uma solução mágica. A grande maioria das pequenas e médias empresas nacionais persegue cegamente a introdução de microsserviços, podendo-se verificar também que a qualidade da infraestrutura dos engenheiros que fazem este tipo de seleção de tecnologia é insuficiente.

"Você deve ser alto o suficiente para usar microsserviços." A infraestrutura de microsserviços, especialmente a tecnologia de contêiner, implantação automatizada e testes automatizados, está incompleta, e os microsserviços são em vão e não trarão nenhuma melhoria qualitativa.

A chave para a arquitetura de microsserviço não é a implementação específica, mas como dividir razoavelmente o limite do serviço e se a estrutura organizacional corresponde. Listar cegamente os microsserviços, independentemente do tamanho e da composição da equipe de P&D, é uma seleção de tecnologia ruim.

Spring Boot é o encapsulamento superior do balde da família Spring.Não é uma tecnologia totalmente nova, nem é uma tecnologia digna de se tornar seu próprio assassino.

Os componentes do Spring Cloud Netflix no Spring Cloud foram verificados no ambiente de produção, enquanto outros são recomendados para serem escolhidos com cuidado.

O que é um microsserviço

Os microsserviços originaram-se do Micro-Web-Service (Micro-Web-Service) proposto pelo Dr. Peter Rodgers na Cloud Computing Expo em 2005. A ideia fundamental é semelhante ao conceito de design de pipeline do Unix. Em 2014, Martin Fowler e James Lewis propuseram em conjunto o conceito de microsserviços e definiram que o estilo de arquitetura de microsserviços é um método de desenvolvimento de um único aplicativo por meio de um conjunto de pequenos serviços. Cada serviço é executado em seu próprio processo e passa por um mecanismo leve para comunicação (API HTTP). Os três pontos principais são pequenos, automatizados e leves .

Comparados com SOA, os microsserviços podem ser considerados um subconjunto de SOA, um SOA leve, com serviços mais refinados, processos independentes, separação de dados e mais ênfase em agilidade, entrega contínua, DevOps e práticas descentralizadas . O princípio de arquitetura comum :

Responsabilidade única
Separação de preocupação: separação de controle e lógica
Modularidade e dividir e conquistar

Características :

Componentização com serviços
Organize-se em torno dos recursos de negócios
É um produto, não um projeto
Inteligência de endpoint e tubos burros: a lógica de controle está no ponto final, e o tubo é apenas transmissão
Implantação totalmente automatizada
Controle descentralizado de linguagem e dados
Projetar para o fracasso
Design progressivo

Em conjunto, suas vantagens e desvantagens são as seguintes:

Vantagens :

Limites fortes de módulos
Implantação independente
Diversidade de seleção de tecnologia

Desvantagens :

Distribuído traz complexidade de programação e consumo de chamadas remotas
Abandone a consistência forte e alcance a consistência final
A complexidade operacional requer uma operação madura e equipe de manutenção ou infraestrutura de operação e manutenção

Por que adotar microsserviços

A escolha de microsserviços depende da complexidade do sistema que você deseja projetar. Os microsserviços são usados para controlar sistemas complexos, mas com isso vem a introdução da complexidade dos microsserviços. Os problemas enfrentados por outros sistemas distribuídos, incluindo implantação automatizada, monitoramento, processamento tolerante a falhas e eventual consistência, precisam ser resolvidos. Mesmo que haja algumas soluções comumente usadas, ainda existem custos significativos.

A relação entre produtividade e complexidade é mostrada na figura, podendo-se observar que quanto mais complexo o sistema, maiores são os benefícios trazidos pelos microsserviços. Além disso, seja um aplicativo monolítico ou um microsserviço, as habilidades da equipe precisam ser controladas.

Um dos pontos de vista de Martin Fowler é: A menos que o custo de gerenciamento de um único aplicativo já seja muito complicado (muito grande torna difícil modificar e implantar), não considere os microsserviços. A maioria dos aplicativos deve escolher uma arquitetura monolítica e fazer um bom trabalho na modularização de aplicativos monolíticos em vez de dividi-los em serviços.

Portanto, no início , o sistema adota uma arquitetura monolítica e é bem modularizado. Mais tarde, conforme o sistema se torna mais e mais complexo e os limites entre os módulos / serviços tornam-se mais claros, é uma arquitetura razoável para reestruturar em um caminho de arquitetura de microsserviço.

Quatro situações podem ser consideradas para microsserviços :

Muitas pessoas desenvolvem um módulo / projeto e há muitos conflitos frequentemente ao enviar o código.
Os módulos estão fortemente acoplados e dependem uns dos outros. Cada mudança precisa envolver várias equipes. Há muitos requisitos para um único lançamento e o risco é alto.
O negócio principal e o negócio secundário são acoplados e o processo de expansão horizontal é complicado.
O downgrade do fusível depende do if-else.

Os três estágios dos microsserviços :

Microservice 1.0: Use apenas a descoberta de registro e desenvolva com base em SpringCloud ou Dubbo.
Microservice 2.0: usa estratégias de governança de serviço, como disjuntor, limite de corrente e downgrade, e está equipado com ferramentas e plataformas de serviço completas.
Microservice 3.0: Service Mesh leva a governança de serviço como um componente geral e é implementado na camada de plataforma. A camada de aplicativo se concentra apenas na lógica de negócios. A camada de plataforma pode agendar e ajustar parâmetros automaticamente de acordo com o monitoramento de negócios para atingir AIOps e agendamento inteligente.

Arquitetura de microsserviço

pré-requisitos

Recursos de provisionamento rápido de ambiente: conte com computação em nuvem e tecnologia de contêiner para entregar rapidamente o ambiente.
Capacidades básicas de monitoramento: incluindo monitoramento técnico básico e monitoramento de negócios.
Capacidade de implantação rápida de aplicativos: O pipeline de implantação é necessário para fornecer capacidade de implantação rápida.
Cultura Devops: Ela precisa ter boas capacidades de entrega contínua, incluindo rastreamento de link completo, rápida provisão e implantação de ambiente, etc. Ela também precisa de capacidades de resposta rápida (resposta rápida a problemas e falhas) e trabalho colaborativo de desenvolvimento e operação e manutenção .

Além disso, de acordo com a lei de Conway e a lei de Conway inversa (a estrutura técnica força a melhoria da estrutura organizacional), a estrutura organizacional também é um fator muito crítico. Correspondendo à arquitetura de microsserviço, a estrutura organizacional precisa seguir os seguintes princípios:

Um microsserviço é mantido por uma equipe, e os membros da equipe são preferencialmente três.
As tarefas e o desenvolvimento de uma única equipe são independentes e não são afetados por outros fatores.
A equipe é totalmente funcional, full stack, autônoma, plana e autogerenciada.

a infraestrutura

A implementação de microsserviços precisa contar com muitas infraestruturas subjacentes, incluindo o fornecimento de microsserviços de compilação, integração, empacotamento, implantação, configuração, etc., usando a plataforma PaaS para resolver o gerenciamento do ciclo de vida completo de microsserviços desde o desenvolvimento até a operação, enquanto fornece gerenciamento de ambiente heterogêneo, isolamento e intercomunicação de recursos de contêiner, desvio de escala de serviço, atualização e reversão de serviço, fusão e redução de serviço, registro e descoberta de serviço.

A infraestrutura mais básica

Mecanismo de comunicação entre processos: microsserviços são processos independentes e o método de comunicação entre eles precisa ser determinado.
Descoberta de serviço + roteamento de serviço: Fornece um registro de serviço, provedores de serviço e consumidores obtêm informações de serviço por meio de descoberta de serviço para chamar serviços e obter equilíbrio de carga de serviço.
Tolerância a falhas de serviço: na arquitetura de microsserviço, como há muitos serviços, um serviço costuma estar inativo e todo o serviço de link de solicitação é afetado. Portanto, a tolerância a falhas de serviço é necessária. Quando a chamada de serviço falha, ela pode lidar com erros ou falhas rapidamente, incluindo disjuntores., Fallback, nova tentativa, controle de fluxo e isolamento de serviço, etc.
Suporte a transações distribuídas: Como o negócio é dividido em serviços, às vezes é inevitável que haja transações entre serviços, ou seja, o problema das transações distribuídas. O princípio é evitar transações distribuídas tanto quanto possível.Se for inevitável, você pode usar o sistema de mensagens ou soluções de CQRS e Event Sourcing para obter consistência eventual. Se a consistência forte for necessária, existem soluções de transações distribuídas, como two-phase commit, three-phase commit e TCC.

Melhorar a eficiência de encaixe de serviço externo e eficiência de desenvolvimento interno

API Gateway: Responsável pelo acesso a sistemas externos e por trabalhos transversais de nível público, incluindo segurança, registro, controle de permissão, criptografia de transmissão, encaminhamento de solicitação, controle de fluxo, etc. A função típica de gateway é expor um nome de domínio xx.com para o exterior e fazer o roteamento reverso xx.com/user, xx.com/trade de acordo com o diretório de primeiro nível. Cada nível de diretório, como usuário e comércio corresponde a um nome de domínio de serviço. Além disso, o gateway de API também pode ter uma função de orquestração de serviço (não recomendado).
Estrutura da interface: padronize o formato dos dados, o pacote de análise e o documento autoexplicativo usado na comunicação entre os serviços, para que os usuários dos serviços possam começar rapidamente.

Melhorar a eficiência de teste e operação e manutenção

Integração contínua: Esta parte não é específica para microsserviços. Para os aplicativos monolíticos anteriores, esta parte é geralmente necessária. Refere-se principalmente à compilação e construção contínuas do processo de código e testes automatizados por meios automatizados para obter feedback de qualidade rápido e eficaz, garantindo assim a entrega tranquila do código. O teste automatizado inclui teste de unidade em nível de código, teste de integração de um único sistema e teste de interface entre sistemas.
Implementação automatizada: arquitetura de microsserviço, o número de nós pode ser centenas ou milhares, e a implementação automatizada pode aumentar a velocidade e a frequência de implementação, garantindo assim a entrega contínua. Incluindo funções como gerenciamento de versão, gerenciamento de recursos, operações de implantação e operações de reversão. Os métodos de implantação para microsserviços incluem implantação azul-verde, implantação contínua e implantação canário .
Centro de configuração: o gerenciamento de configuração em tempo de execução pode resolver o problema de modificar configurações dinamicamente e entrar em vigor em lotes. Incluindo gerenciamento de versão de configuração, gerenciamento de item de configuração, gerenciamento de nó, sincronização de configuração, etc.
Entrega contínua: incluindo integração contínua, implantação automatizada e outros processos. O objetivo é iterar em pequenas etapas e entregar rapidamente.

Melhorar ainda mais a eficiência de operação e manutenção

Monitoramento de serviço: há um grande número de nós na arquitetura de microsserviço, e o número de máquinas, redes, processos, interfaces etc. que precisam ser monitorados é muito maior. É necessário um sistema de monitoramento poderoso que possa fornecer dados em tempo real coleta de informações para análise e alerta precoce em análises em tempo real. Incluindo tempos de solicitação de serviço de monitoramento , distribuição de tempo de resposta, valor de resposta máximo / mínimo, distribuição de código de erro, etc.
Rastreamento de serviço: Rastreamento do caminho completo de uma solicitação, incluindo tempo de início da solicitação, tempo de resposta, código de resposta, parâmetros de solicitação, resultados de retorno e outras informações, também chamado de rastreamento de link completo. O monitoramento de serviço normal pode ser feito junto com o monitoramento de serviço, as macro informações são apresentadas pelo rastreamento do serviço e as micro informações sobre um único serviço / nó são apresentadas pelo monitoramento do serviço. A teoria de implementação atual de rastreamento de serviço é basicamente o artigo Dapper do Google.
Segurança do serviço: em princípio, as chamadas de microsserviço entre intranets devem ser capazes de acessar e gravar umas nas outras. Geralmente, o controle de permissão não é necessário, mas às vezes limitado aos requisitos de negócios, existem requisitos de controle de segurança para interfaces e dados. Essa parte pode existir no registro de serviço de uma maneira configurável, vincular-se ao serviço e ser controlada pela política de segurança do nó de serviço como o provedor de serviço quando solicitado. A configuração pode ser armazenada no centro de configuração para facilitar a modificação dinâmica.

No caso de um pequeno número de microsserviços, a prioridade da infraestrutura acima diminui de cima para baixo. Caso contrário, confiar apenas na operação manual resultará em uma relação de entrada-saída muito baixa.

Também é preciso mencionar a tecnologia de contêiner Docker. Embora isso não seja necessário para microsserviços, a tecnologia de contêiner é leve, flexível, dependente do aplicativo e protege as diferenças ambientais . As características da entrega contínua são cruciais para a realização da entrega contínua, mesmo para aplicações individuais tradicionais. Traz um aumento substancial em eficiência de entrega.

Padrão de projeto de arquitetura

Após a introdução dos microsserviços, os aplicativos monolíticos tradicionais se tornaram um serviço. A arquitetura anterior, em que um aplicativo fornece diretamente uma interface para acesso do cliente, não é mais aplicável. Na arquitetura de microsserviço, as interfaces para diferentes dispositivos são utilizadas como camada BFF (Backend For Frontend), também chamada de camada de adaptação da experiência do usuário, que é responsável por agregar e orquestrar os dados dos microsserviços e convertê-los nos dados exigidos por a extremidade dianteira. Chamadas entre serviços usam mensagens assíncronas tanto quanto possível quando permitido (permitindo atraso), formando assim um padrão de design de arquitetura de microsserviço orientado para a experiência do usuário . Como mostrado abaixo:

Cliente -> API Gateway -> BFF （Backend para front-end） -> Microsserviços downstream

O back-end adota uma arquitetura de microsserviço, e os microsserviços podem adotar diferentes linguagens de programação e diferentes mecanismos de armazenamento.
A recepção adota o modo BFF para se adaptar às diferentes experiências do usuário (como navegadores de desktop, aplicativo nativo e Web responsiva em tablets).
BFF, API Orchestration Layer, Edge Service Layer, Device Wrapper Layer são os mesmos conceitos.
BFF não pode ser muito, muito vai causar redundância e duplicação da lógica do código.
As funções realizadas pelo gateway, como Geoip, limitação de corrente e autenticação de segurança, podem ser colocadas na mesma camada do BFF. Embora a complexidade da camada BFF seja aumentada, vantagens de desempenho podem ser obtidas.

Divisão de serviço

O elo principal da arquitetura de microsserviço é principalmente a divisão horizontal de serviços . A divisão de serviço refere-se ao desacoplamento de um sistema de negócios completo em serviços. Os serviços exigem responsabilidades únicas, nenhuma relação de acoplamento entre eles e desenvolvimento e manutenção independentes .

A divisão de serviço não é realizada durante a noite e os limites precisam ser continuamente limpos durante o processo de desenvolvimento. Antes de ordenar completamente o serviço, tente adiar a divisão do serviço, especialmente a divisão do banco de dados.

O método de divisão é o seguinte:

Dividir com base na lógica de negócios
Com base na divisão escalonável
Dividir com base na confiabilidade
Dividir com base no desempenho

Dentre eles, para sistemas legados que não podem ser modificados, adota-se o modo de estrangulamento: adicionar novas funções fora do sistema legado para fazer microsserviços, ao invés de modificar diretamente o sistema original, e substituir gradativamente o antigo sistema.

As especificações que precisam ser seguidas durante a divisão são as seguintes:

Primeiro menos e mais, primeiro grosso e depois fino (granularidade)
O serviço pode ser dividido em até três camadas verticalmente e chamado duas vezes: controlador, serviço composto, serviço básico
Chamada unilateral, a chamada cíclica é proibida
As chamadas em série são alteradas para chamadas paralelas ou assíncronas
Interface deve ser idempotente
A definição de dados da interface é estritamente proibida de ser incorporada e transmitida de forma transparente
Nome do projeto padronizado
Divida o serviço primeiro e, em seguida, divida o banco de dados depois que a granularidade do serviço for determinada.

Estrutura de microsserviço

A descrição acima descreve as várias infraestruturas da arquitetura de microsserviço.Se cada infraestrutura precisa ser desenvolvida por si mesma, é um trabalho de desenvolvimento muito grande. Já existem muitas estruturas de microsserviço de código aberto no mercado para escolher.

Spring Boot

Spring Boot é usado para simplificar a configuração inicial e o processo de desenvolvimento de novos aplicativos Spring. Embora não seja uma estrutura de microsserviço, sua intenção original é essencialmente a estrutura subjacente de microaplicativos, por isso é muito adequado para o desenvolvimento de infraestrutura de microsserviço e desenvolvimento de aplicativos de microsserviço. Especialmente para a equipe de pilha de tecnologia Spring, é uma escolha natural desenvolver estruturas de microsserviço e aplicativos baseados em Spring Boot.

Dubbo e Motan

Estrutura de governança de serviço de código aberto de Dubbo Ali. Ele apareceu antes do surgimento do conceito de microsserviços e pode ser considerado uma obra-prima da estrutura SOA. Mas inclui apenas parte das funções da infraestrutura de microsserviços, como disjuntores, rastreamento de serviço, gateways, etc. não implementados.

Motan é uma estrutura RPC de código aberto semelhante ao Dubbo no Weibo, que é mais leve do que o Dubbo.

Descoberta de serviço: publicação de serviço, assinatura, notificação
Estratégia de alta disponibilidade: Failover, Failfast, isolamento de recursos - balanceamento de carga: menos conexões ativas, hash consistente, solicitação aleatória, pesquisa, etc.
Extensibilidade: suporte a extensão SPI (interface do provedor de serviços)
Outros: estatísticas de chamadas, registros de acesso, etc.

Spring Cloud

Spring Cloud é uma estrutura de microsserviço baseada no Spring Boot e também pode ser vista como um conjunto de especificações de implementação de microsserviço. Ele cobre basicamente todos os aspectos da infraestrutura de microsserviço, incluindo gerenciamento de configuração, descoberta de serviço, disjuntores, roteamento inteligente, micragentes, barramentos de controle, bloqueios globais, campanhas de tomada de decisão, sessões distribuídas e gerenciamento de estado de cluster. É baseado na ecologia da primavera e o apoio da comunidade é muito bom. No entanto, muitos de seus componentes não foram verificados no ambiente de produção e precisam ser selecionados cuidadosamente.

Spring Cloud Netflix é um subprojeto da Spring Cloud e é a implementação integrada da Spring do Netflix OSS. Com base no uso em larga escala da Netflix, os componentes que têm sido amplamente usados incluem:

Além disso, outro subprojeto Spring Cloud Alibaba é a estrutura de microsserviço baseada em Spring Boot de código aberto da Alibaba, que oferece suporte principalmente a serviços de nuvem Alibaba.

Eureka: registro de serviço e descoberta de serviço
Faixa de opções: mecanismo de comunicação entre processos e serviços flexível e inteligente, balanceamento de carga do cliente
Hystrix: fusível, fornece isolamento de tolerância a falhas e atraso durante a operação
Zuul: Gateway de Serviço

Malha de serviço

As estruturas de microsserviço mencionadas acima são todas intrusivas e o processo de manutenção requer transformação de código. Service Mesh é a arquitetura de microsserviço de próxima geração, o recurso mais óbvio é não intrusivo. O modelo secundário é usado para resolver os problemas de comunicação e governança entre os serviços depois que a arquitetura do sistema é microsserviços. Como mostrado abaixo:

As principais implementações de código aberto atuais incluem:

Limitada ao custo do atraso de desempenho causado pelo Service Mesh e ao aumento na complexidade da distribuição de sidecars, ela traz uma implantação em larga escala (grande número de microsserviços), arquitetura de microsserviço complexa heterogênea (vários tipos de protocolos de interação / linguagens de desenvolvimento) Os benefícios será maior.

Linkerd e Envoy: considere o sidecar como o núcleo, concentre-se em como fazer um bom proxy e conclua algumas funções gerais do plano de controle. Falta de gerenciamento e controle desses carros laterais.
Istio e Conduit: atualmente, as soluções de implementação de malha de serviço mais populares se concentram em funções de plano de controle mais poderosas (o sidecar é chamado de plano de dados). O primeiro é uma colaboração entre o Google e a IBM e usa o Envoy como a implementação da parte secundária; o último é o trabalho do autor de Linkerd. Em comparação, o Istio tem um histórico gigantesco e é poderoso, mas sua usabilidade e facilidade de uso não eram altas, enquanto o Conduit é relativamente simples e focado em recursos.

Sofastack

Ant Financial abre um conjunto de middleware para construir uma arquitetura distribuída de nível financeiro. Incluindo um conjunto de ferramentas de desenvolvimento de aplicativos distribuídos, como estrutura de desenvolvimento de microsserviço, estrutura RPC, registro de serviço, rastreamento de link completo, monitoramento de serviço e malha de serviço.

Especialmente digno de menção é SOFAMesh. Na verdade, a prática de implementação em larga escala da Service Mesh de arquitetura de microsserviço de próxima geração, com base na melhoria e expansão do Istio, deve ser a solução de Service Mesh de código aberto mais madura da China.

Além disso, precisamos mencionar o Kubernetes (K8s) , que por si só fornece parte do suporte ao recurso de microsserviço (descoberta de serviço por meio do nome de domínio), sem intrusão no código. Mas as chamadas de serviço e os disjuntores precisam ser implementados por si próprios.

Em resumo, a pilha de tecnologia atual da equipe técnica da empresa é Spring, e a implementação de serviços existentes é baseada em Dubbo, então Spring Cloud Netflix é selecionado como a estrutura de microsserviço básica. Para os componentes imaturos ou ausentes, a indústria é mais maduro. Os componentes podem ser substituídos.

Gateway API: Zuul
Registro de serviço: Dubbo
Centro de configuração: disconf
Monitoramento de serviço e rastreamento de link completo: CAT
Estrutura de desenvolvimento de serviço: Spring Boot
Monitoramento e aviso de toras: ELK + Elasalert
Controle de fluxo: Sentinel
Fila de mensagens: Kafka