O Service Mesh é um padrão arquitetural conhecido para integrar microsserviços e mudar para a infraestrutura em nuvem. Hoje, no mundo dos contêineres na nuvem, é bastante difícil ficar sem ele. Várias implementações de malha de serviço de código-fonte aberto já estão disponíveis no mercado, mas sua funcionalidade, confiabilidade e segurança estão longe de ser sempre suficientes, especialmente quando se trata dos requisitos de grandes empresas financeiras em todo o país. Portanto, na Sbertech decidimos personalizar o Service Mesh e queremos falar sobre o que é interessante no Service Mesh, o que não é muito e o que faremos com ele.
A popularidade do modelo de Malha de Serviço está crescendo com a popularidade da tecnologia em nuvem. É uma camada de infraestrutura dedicada que simplifica a interação entre diferentes serviços de rede. Os aplicativos modernos de nuvem consistem em centenas e até milhares desses serviços, cada um dos quais com milhares de cópias.
A interação entre esses serviços e seu gerenciamento é uma tarefa fundamental do Service Mesh. De fato, este é um modelo de rede de uma variedade de proxies, gerenciados centralmente e executando um conjunto de funções muito úteis.
No nível do proxy (plano de dados):- Atribuir e distribuir políticas de roteamento e balanceamento de tráfego
- Distribuição de chaves, certificados, tokens
- Coleta de telemetria, formação de métricas de monitoramento
- Integração com infraestrutura de segurança e monitoramento
No nível do plano de controle:- Aplicar políticas de roteamento e balanceamento de tráfego
- Gerenciamento de novas tentativas e tempos limite, definição de nós "mortos" (quebra de circuito), gerenciamento de situações de falha (injeção de falhas) e garantia da resiliência dos serviços por meio de outros mecanismos
- Autenticação / Autorização de Chamada
- Descartando métricas (observabilidade)
O círculo de usuários interessados no desenvolvimento dessa tecnologia é muito amplo - desde pequenas startups a grandes corporações de Internet, por exemplo, PayPal.
Para que serve o Service Mesh no setor corporativo?
O uso do Service Mesh traz muitos benefícios óbvios. Antes de tudo, é conveniente para os desenvolvedores:
uma plataforma de tecnologia aparece para escrever código que simplifica significativamente a integração na infraestrutura da nuvem, devido ao fato de a camada de transporte estar completamente isolada da lógica do aplicativo.
Além disso, o
Service Mesh simplifica o relacionamento entre fornecedores e consumidores. Hoje, é muito mais fácil para fornecedores e consumidores da API concordar com interfaces e contratos por conta própria, sem envolver um intermediário de integração especial e um árbitro para isso - um barramento de serviço corporativo. Essa abordagem afeta significativamente dois indicadores. A velocidade de trazer novas funcionalidades ao mercado (time-to-market) está aumentando, mas ao mesmo tempo o custo da solução está aumentando, uma vez que a integração deve ser feita de forma independente. O uso do Service Mesh pelas equipes de desenvolvimento de negócios ajuda a manter o equilíbrio aqui. Como resultado, os provedores de API podem se concentrar exclusivamente no componente de aplicativo de seu serviço e simplesmente publicá-lo no Service Mesh - a API ficará imediatamente disponível para todos os clientes, e a qualidade da integração estará pronta para produção e não exigirá uma única linha de código adicional.
Outra vantagem é que o
desenvolvedor, usando o Service Mesh, concentra-se apenas na funcionalidade do negócio - no produto, e não no componente tecnológico de seu serviço. Por exemplo, você não precisa pensar no fato de que, em uma situação em que o serviço será chamado pela rede, em algum lugar a conexão poderá ser interrompida. Além disso, o Service Mesh ajuda a equilibrar o tráfego entre cópias do mesmo serviço: se uma das cópias "morreu", o sistema alternará todo o tráfego para as cópias ativas restantes.
O Service Mesh é
uma boa base para a criação de aplicativos distribuídos , que oculta ao cliente os detalhes de chamadas para seus serviços, interna e externamente. Todos os aplicativos que usam o Service Mesh são isolados na camada de transporte da rede e um do outro: não há conexão entre eles. Nesse caso, o desenvolvedor obtém controle total sobre seus serviços.
Deve-se observar que a
atualização de aplicativos distribuídos em um ambiente em que o Service Mesh é usado está se tornando mais fácil. Por exemplo, implantação azul / verde, na qual dois ambientes de aplicativos estão disponíveis para instalação, um dos quais não é atualizado e está no modo de espera. A reversão para a versão anterior, no caso de uma versão malsucedida, é realizada por um roteador especial, cuja função o Service Mesh lida perfeitamente
. Você pode usar o
canary release para executar na nova versão - alterne apenas 10% do tráfego ou solicitações do grupo de clientes piloto para a nova versão. O tráfego principal vai para a versão antiga, nada quebra.
O Service Mesh também nos fornece controle de SLA em tempo real . O sistema de proxies distribuídos não permitirá inundar o serviço quando um dos clientes exceder a cota emitida para ele. Se a largura de banda da API for limitada, ninguém poderá estrangulá-la com um grande número de transações: a Malha de Serviço está na frente do serviço e não permite tráfego extra. Simplesmente será melhor na camada de integração, e os próprios serviços continuarão a funcionar sem perceber.
Se a empresa deseja reduzir o custo de desenvolvimento de soluções de integração, o Service Mesh também ajuda:
você pode mudar para sua versão de código aberto a partir de produtos comerciais . Nosso Enterprise Service Mesh é baseado na versão de código aberto do Service Mesh.
Outra vantagem é a
disponibilidade de um único conjunto completo de serviços de integração . Como toda a integração é construída através dessa camada intermediária, podemos gerenciar todo o tráfego de integração e as conexões entre os aplicativos que formam o núcleo de negócios da empresa. É muito conveniente
Por fim, o
Service Mesh leva a empresa a fazer a transição para uma infraestrutura dinâmica. Agora muitos estão olhando para a conteinerização. Vendo um monólito em microsserviços, é bonito implementar tudo - o assunto está em ascensão. Mas quando você tenta transferir para uma nova faixa um sistema que está em produção há muitos anos, você encontra imediatamente vários problemas: colocar tudo em contêineres e implantá-lo na plataforma não é fácil. E a implementação, sincronização e interação desses componentes distribuídos é outro tópico difícil. Como eles vão se comunicar? Haverá falhas em cascata? O Service Mesh permite solucionar alguns desses problemas e facilitar a migração da arquitetura antiga para a nova devido ao fato de você poder esquecer a lógica da troca de rede.
Por que personalizar o Service Mesh
Em nossa empresa, centenas de sistemas e módulos coexistem juntos, e o tempo de execução é muito ocupado. Portanto, um padrão simples, quando um sistema liga para outro e recebe uma resposta, não é suficiente, porque na produção queremos mais. O que mais você precisa de um Service Mesh corporativo?
Serviço de Processamento de Eventos
Imagine que precisamos fazer um processamento de eventos em tempo real - um sistema que analise em tempo real as ações do cliente e possa imediatamente fazer uma oferta relevante para ele. Para implementar essa funcionalidade,
é usado um
padrão de arquitetura chamado EDA (Event-driven Architecture) . Nenhum dos Service Mesh relevantes suporta nativamente esses padrões, mas isso é muito importante, especialmente para o banco!
É estranho que a RPC (Chamada de Procedimento Remoto) ofereça suporte a todas as versões do Service Mesh e elas não sejam amigas do EDA. Como o Service Mesh é uma aparência de integração distribuída moderna, e o EDA é um padrão arquitetural muito relevante que permite que você faça coisas únicas em termos de experiência do cliente.
Nossa malha de serviço corporativo deve resolver esse problema. Além disso, queremos ver nele a implementação de entrega garantida, streaming e processamento de eventos integrado usando uma variedade de filtros e modelos.
Serviço de transferência de arquivos
Além do EDA, seria bom poder transferir arquivos: em uma escala corporativa, muitas vezes apenas a integração de arquivos é possível. Em particular, o padrão ETL arquitetural é usado (Extrair, Transformar, Carregar - “extrair, transformar, carregar”). Nele, como regra geral, todos trocam arquivos exclusivamente: eles usam big data, o que é impraticável para enviar pedidos separados. A capacidade de oferecer suporte nativo às transferências de arquivos no Enterprise Service Mesh fornece a flexibilidade das necessidades dos negócios.
Serviço de orquestração
Nas grandes organizações, quase sempre existem equipes diferentes que produzem produtos diferentes. Por exemplo, em um banco, algumas equipes trabalham com depósitos, enquanto outras trabalham com produtos de crédito, e existem muitos desses casos. São pessoas diferentes, equipes diferentes que fabricam seus produtos, desenvolvem suas APIs e as fornecem a outras pessoas. E muitas vezes há a necessidade da composição desses serviços, bem como a implementação da lógica complexa da chamada seqüencial do conjunto de APIs. Para resolver esse problema, é necessária uma solução na camada de integração, que simplificará toda essa lógica composta (chamando várias APIs, descrevendo a rota das solicitações etc.). Este é o serviço de orquestração no Enterprise Service Mesh.
AI e ML
Quando os microsserviços se comunicam através de uma única camada de integração, o Service Mesh, é claro, sabe tudo sobre as chamadas de cada serviço. Coletamos telemetria: quem ligou para quem, quando, quanto tempo, quantas vezes e assim por diante. Quando existem centenas de milhares desses serviços e bilhões de chamadas, tudo isso acumula e forma Big Data. Esses dados podem ser analisados usando IA, aprendizado de máquina etc. e, em seguida, executam algumas ações úteis com base nos resultados da análise. Seria apropriado transferir pelo menos parcialmente para a inteligência artificial o gerenciamento de todo esse tráfego de rede e chamadas de aplicativos integradas ao Service Mesh.
Serviço de gateway de API
Como regra, o Service Mesh possui proxies e serviços que se acessam dentro do perímetro confiável. Mas também existem contrapartes externas. Os requisitos de API para esse grupo de consumidores são muito mais sérios. Dividimos essa tarefa em duas partes principais.
- Segurança Problemas relacionados a ddos, vulnerabilidade de protocolos, aplicativos, sistemas operacionais e assim por diante.
- A balança . Quando a conta da API que precisa ser entregue aos clientes chega a milhares ou mesmo centenas de milhares, há a necessidade de alguns meios de gerenciar esse conjunto de APIs. Você precisa monitorar constantemente a API: eles funcionam ou não, em qual status, qual tráfego está acontecendo, quais estatísticas etc. O gateway da API deve lidar com essa tarefa, tornando todo o processo gerenciável e seguro. Graças a esse componente, o Enterprise Service Mesh aprende a publicar as APIs internas e externas sem muita dificuldade.
Serviço de suporte para protocolos e formatos de dados específicos (gateway AS)
Atualmente, a maioria das soluções Service Mesh pode trabalhar apenas de forma nativa com tráfego HTTP e HTTP2 ou no modo truncado no nível TCP / IP. O Enterprise Service Mesh possui muitos outros protocolos de transferência de dados muito específicos. Alguns sistemas podem usar intermediários de mensagens, outros são integrados no nível do banco de dados. Se a empresa possui SAP, também pode usar seu próprio sistema de integração. E tudo isso funciona e é uma parte importante do negócio.
Você não pode simplesmente dizer: "Vamos abandonar o legado e criar novos sistemas que possam usar o Service Mesh". Para tornar amigos de todos os sistemas antigos os novos (na arquitetura de microsserviço), os sistemas que podem usar o Service Mesh precisarão de algum tipo de adaptador, intermediário e gateway. Concordo, seria bom se fosse entregue em uma caixa junto com o serviço. O gateway AS pode suportar qualquer opção de integração. Imagine que você acabou de instalar o Enterprise Service Mesh e ele está pronto para interagir com todos os protocolos necessários. Para nós, essa abordagem é muito importante.
É assim que apresentamos a versão corporativa do Service Mesh (Enterprise Service Mesh). A personalização descrita resolve a maioria dos problemas que surgem ao tentar usar versões de código-fonte aberto prontas da plataforma de integração. Tendo aparecido apenas alguns anos atrás, a arquitetura do Service Mesh continua a evoluir e estamos felizes por podermos contribuir para o seu desenvolvimento. Esperamos que nossa experiência seja útil para você.