Service Mesh é um padrão arquitetônico bem conhecido para integração de microsserviços e migração para infraestrutura em nuvem. Hoje, no mundo dos contêineres em nuvem, é muito difícil viver sem ele. Diversas implementações de service mesh de código aberto já estão disponíveis no mercado, mas sua funcionalidade, confiabilidade e segurança nem sempre são suficientes, principalmente quando se trata das necessidades de grandes empresas financeiras em todo o país. É por isso que nós da Sbertech decidimos customizar o Service Mesh e queremos falar sobre o que é legal no Service Mesh, o que não é tão legal e o que faremos a respeito.
A popularidade do padrão Service Mesh está crescendo com a popularidade das tecnologias de nuvem. É uma camada de infraestrutura dedicada que simplifica a interação entre diferentes serviços de rede. Os aplicativos modernos em nuvem consistem em centenas ou até milhares desses serviços, cada um dos quais pode ter milhares de cópias.
A interação e o gerenciamento desses serviços é uma tarefa fundamental do Service Mesh. Na verdade, este é um modelo de rede de muitos proxies, gerido 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, geração de métricas de monitoramento
- Integração com infraestrutura de segurança e monitoramento
No nível do plano de controle:
- Aplicando políticas de roteamento e balanceamento de tráfego
- Gerenciando novas tentativas e timeouts, detectando nós “mortos” (quebra de circuito), gerenciando a injeção de falhas e garantindo a resiliência do serviço através de outros mecanismos
- Autenticação/autorização de chamada
- Descartando métricas (observabilidade)
A gama de usuários interessados no desenvolvimento desta tecnologia é muito ampla - desde pequenas startups até grandes corporações de Internet, por exemplo, o PayPal.
Por que o Service Mesh é necessário no setor corporativo?
Há muitos benefícios claros em usar um Service Mesh. Em primeiro lugar, é simplesmente conveniente para desenvolvedores: para escrever código uma plataforma tecnológica aparece, o que simplifica significativamente a integração na infraestrutura em nuvem devido ao fato de a camada de transporte estar completamente isolada da lógica da aplicação.
Além disso, Service Mesh simplifica o relacionamento entre fornecedores e consumidores. Hoje, é muito mais fácil para os provedores e consumidores de API chegarem a acordo sobre interfaces e contratos por conta própria, sem envolver um intermediário e árbitro de integração especial - o barramento de serviço empresarial. Esta abordagem afecta significativamente dois indicadores. A velocidade de lançamento de novas funcionalidades no mercado (time-to-market) aumenta, mas ao mesmo tempo aumenta o custo da solução, uma vez que a integração tem de ser feita de forma independente. O uso do Service Mesh pelas equipes de desenvolvimento de funcionalidades de negócios ajuda a manter o equilíbrio aqui. Como resultado, os provedores de API podem se concentrar exclusivamente no componente de aplicação 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á um único linha de código adicional.
A próxima vantagem é que o desenvolvedor, usando Service Mesh, concentra-se exclusivamente na funcionalidade de negócios — no produto e não na componente tecnológica do seu serviço. Por exemplo, você não precisa mais pensar no fato de que em uma situação em que um serviço é chamado pela rede, pode ocorrer uma falha de conexão em algum lugar. Além disso, o Service Mesh ajuda a equilibrar o tráfego entre cópias do mesmo serviço: se uma das cópias “morrer”, o sistema transferirá todo o tráfego para as cópias ativas restantes.
malha de serviço - esta é uma boa base para criar aplicativos distribuídos, que oculta do cliente os detalhes do atendimento de chamadas para seus serviços tanto interna quanto externamente. Todas as aplicações que utilizam Service Mesh são isoladas no nível de transporte tanto da rede quanto entre si: não há comunicação entre elas. Nesse caso, o desenvolvedor recebe controle total sobre seus serviços.
Deve-se notar que A atualização de aplicativos distribuídos em um ambiente de service mesh fica mais fácil. Por exemplo, uma implantação azul/verde, na qual dois ambientes de aplicativos estão disponíveis para instalação, um dos quais não está atualizado e está em modo de espera. A reversão para a versão anterior em caso de lançamento malsucedido é realizada por um roteador especial, cuja função o Service Mesh cumpre bem. Para testar a nova versão, você pode usar lançamento canário — mudar para a nova versão apenas 10% do tráfego ou solicitações de um grupo piloto de clientes. O tráfego principal vai para a versão antiga, nada quebra.
Também Service Mesh nos dá controle de SLA em tempo real. O sistema proxy distribuído não permitirá que o serviço falhe quando um dos clientes exceder a cota atribuída a ele. Se o rendimento da API for limitado, ninguém conseguirá sobrecarregá-lo com um grande número de transações: o Service Mesh fica na frente do serviço e não permite tráfego desnecessário. Ele simplesmente reagirá na camada de integração e os próprios serviços continuarão a funcionar sem perceber.
Se uma empresa deseja reduzir custos para desenvolvimento de soluções de integração, o Service Mesh também ajuda: Você pode mudar para sua versão de código aberto de produtos comerciais. Nosso Enterprise Service Mesh é baseado na versão de código aberto do Service Mesh.
Outra vantagem - disponibilidade de um único conjunto completo de serviços de integração. Como toda integração é construída através deste middleware, podemos gerenciar todo o tráfego de integração e conexões entre aplicações que formam o núcleo de negócios da empresa. É muito confortável.
E finalmente Service Mesh incentiva uma empresa a migrar para uma infraestrutura dinâmica. Agora, muitos estão buscando a conteinerização. Cortar um monólito em microsserviços, implementar tudo isso lindamente - o assunto está em alta. Mas quando você tenta transferir um sistema que está em produção há muitos anos para uma nova plataforma, você imediatamente encontra vários problemas: não é fácil colocar tudo em contêineres e implantá-lo na plataforma. E a implementação, sincronização e interação desses componentes distribuídos é outro tema muito complexo. Como eles se comunicarão entre si? Haverá falhas em cascata? O Service Mesh permite resolver alguns desses problemas e facilitar a migração da arquitetura antiga para a nova, pois você pode esquecer a lógica de troca de rede.
Por que você precisa da personalização do Service Mesh?
Em nossa empresa coexistem centenas de sistemas e módulos e o tempo de execução é muito carregado. Portanto, um simples padrão de um sistema chamando outro e recebendo uma resposta não é suficiente, porque na produção queremos mais. O que mais você precisa de uma malha de serviço empresarial?
Serviço de processamento de eventos
Vamos imaginar que precisamos fazer um processamento de eventos em tempo real - um sistema que analisa as ações do cliente em tempo real e pode imediatamente fazer-lhe uma oferta relevante. Para implementar funcionalidade semelhante, use padrão arquitetônico chamado arquitetura orientada a eventos (EDA). Nenhum dos Service Meshes atuais suporta nativamente tais padrões, mas isso é muito importante, especialmente para um banco!
É bastante estranho que a Chamada de Procedimento Remoto (RPC) seja suportada por todas as versões do Service Mesh, mas não é compatível com EDA. Porque o Service Mesh é um tipo de integração distribuída moderna e o EDA é um padrão de arquitetura muito relevante que permite fazer coisas únicas em termos de experiência do cliente.
Nosso Enterprise Service Mesh deve resolver esse problema. Além disso, queremos ver nele a implementação de entrega garantida, streaming e processamento complexo de eventos usando uma variedade de filtros e modelos.
Serviço de transferência de arquivos
Além do EDA, seria bom poder transferir arquivos: em escala empresarial, muitas vezes apenas a integração de arquivos é possível. Em particular, o padrão arquitetônico ETL (Extract, Transform, Load) é usado. Nele, via de regra, todos trocam arquivos exclusivamente: utiliza-se big data, o que é inviável para enviar solicitações separadas. A capacidade de oferecer suporte nativo a transferências de arquivos no Enterprise Service Mesh oferece a flexibilidade que sua empresa precisa.
Serviço de orquestração
As grandes organizações quase sempre têm equipes diferentes produzindo produtos diferentes. Por exemplo, em um banco, algumas equipes trabalham com depósitos, enquanto outras trabalham com produtos de empréstimo, e há muitos casos assim. São pessoas diferentes, equipes diferentes que fabricam seus produtos, desenvolvem suas APIs e as fornecem a terceiros. E muitas vezes há necessidade de compor esses serviços, bem como implementar lógica complexa para chamar sequencialmente um conjunto de APIs. Para resolver este problema, é necessária uma solução na camada de integração que simplifique toda essa lógica composta (chamar diversas APIs, descrever a rota da solicitação, etc.). Este é o serviço de orquestração no Enterprise Service Mesh.
IA e ML
Quando os microsserviços se comunicam por meio de uma única camada de integração, o Service Mesh naturalmente sabe tudo sobre as chamadas de cada serviço. Coletamos telemetria: quem ligou para quem, quando, por quanto tempo, quantas vezes e assim por diante. Quando existem centenas de milhares desses serviços e bilhões de ligações, tudo isso se acumula e forma Big Data. Esses dados podem ser analisados usando IA, aprendizado de máquina, etc., e então algumas coisas úteis podem ser feitas com base nos resultados da análise. Seria apropriado entregar, pelo menos parcialmente, o controle de todo esse tráfego de rede e chamadas de aplicativos integrados ao Service Mesh para a inteligência artificial.
Serviço de gateway de API
Normalmente, um Service Mesh possui proxies e serviços que se comunicam dentro de um perímetro confiável. Mas também existem contrapartes externas. Os requisitos para APIs expostas a este grupo de consumidores são muito mais severos. Dividimos esta tarefa em duas partes principais.
- segurança. Questões relacionadas a ddos, vulnerabilidade de protocolos, aplicativos, sistemas operacionais e assim por diante.
- Escala. Quando o número de APIs que precisam ser atendidas aos clientes chega a milhares ou mesmo centenas de milhares, há necessidade de algum tipo de ferramenta de gerenciamento para esse conjunto de APIs. Você precisa monitorar constantemente a API: se ela está funcionando ou não, qual é seu status, qual tráfego está fluindo, quais estatísticas, etc. Um gateway de API deve realizar essa tarefa e, ao mesmo tempo, tornar todo o processo gerenciável e seguro. Graças a este componente, o Enterprise Service Mesh aprende a publicar facilmente APIs internas e externas.
Serviço de suporte para protocolos e formatos de dados específicos (AS gateway)
Atualmente, a maioria das soluções Service Mesh pode funcionar nativamente apenas com tráfego HTTP e HTTP2 ou em modo reduzido no nível TCP/IP. O Enterprise Service Mesh está surgindo com muitos outros protocolos de transferência de dados muito específicos. Alguns sistemas podem utilizar corretores de mensagens, outros são integrados no nível do banco de dados. Caso a empresa possua SAP, ela também poderá utilizar seu próprio sistema de integração. Além disso, 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 Service Mesh”. Para conectar todos os sistemas antigos com os novos (em uma arquitetura de microsserviços), os sistemas que podem usar Service Mesh precisarão de algum tipo de adaptador, intermediário, gateway. Concordo, seria bom se viesse em uma caixa junto com o serviço. O gateway AC pode suportar qualquer opção de integração. Imagine só, você acabou de instalar o Enterprise Service Mesh e ele está pronto para interagir com todos os protocolos que você precisa. Essa abordagem é muito importante para nós.
É mais ou menos assim que imaginamos a versão corporativa do Service Mesh (Enterprise Service Mesh). A customização descrita resolve a maioria dos problemas que surgem ao tentar usar versões prontas de código aberto da plataforma de integração. Introduzida há apenas alguns anos, a arquitetura Service Mesh continua a evoluir e estamos entusiasmados por poder contribuir para o seu desenvolvimento. Esperamos que nossa experiência seja útil para você.
Fonte: habr.com