Service Mesh — um padrão arquitetônico conhecido para a integração de microsserviços e transição para infraestrutura em nuvem. Hoje em dia, é bastante difícil operar no mundo da nuvem e containers sem ele. No mercado, já estão disponíveis várias implementações open-source de service mesh, mas sua funcionalidade, confiabilidade e segurança nem sempre são suficientes, especialmente quando se trata das exigências de grandes empresas financeiras em nível nacional. Portanto, decidimos na Sbertech personalizar o Service Mesh e queremos falar sobre o que é interessante nele, o que não é tão bom e o que pretendemos fazer a respeito.
A popularidade do padrão Service Mesh cresce com a popularidade das tecnologias em nuvem. Ele representa uma camada de infraestrutura dedicada, que simplifica a interação entre diversos serviços de rede. Aplicativos modernos em nuvem consistem em centenas e até milhares desses serviços, cada um dos quais pode ter milhares de cópias.
A interação entre esses serviços e sua gestão é a tarefa central do Service Mesh. Na verdade, é um modelo de rede composto por múltiplos proxies, gerenciado de maneira centralizada e realizando um conjunto de funções bastante úteis.
No nível do proxy (data plane):
- Designação e distribuição de 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 a infraestrutura de segurança e monitoramento
No nível do plano de controle (control plane):
- Aplicação de políticas de roteamento e balanceamento de tráfego
- Gerenciamento de repetições e timeouts, detecção de nós "mortos" (circuit breaking), gerenciamento de situações de falha (injecting faults) e garantia de resiliência dos serviços através de outros mecanismos
- Autenticação/autorização de chamadas
- Descarte de métricas (observability)
O público interessado no desenvolvimento desta tecnologia é bastante amplo — desde pequenas startups até grandes corporações da internet, como o PayPal.
Para que serve o Service Mesh no setor corporativo
O uso do Service Mesh traz uma série de vantagens evidentes. Antes de tudo, é muito conveniente para os desenvolvedores: para a escrita de código surge uma plataforma tecnológica, que simplifica significativamente a integração na infraestrutura em nuvem, uma vez que a camada de transporte está completamente isolada da lógica de aplicação.
Além disso, O Service Mesh facilita as relações entre fornecedores e consumidores. Hoje em dia, é muito mais fácil para fornecedores e consumidores de API acertar interfaces e contratos de forma independente, sem a necessidade de um intermediário de integração especializado ou árbitro – a barragem de serviços corporativos. Essa abordagem afeta significativamente dois indicadores. Aumenta a velocidade de lançamento de novas funcionalidades no mercado (time-to-market), mas, em contrapartida, aumenta o custo da solução, já que a integração deve ser feita de forma autônoma. O uso do Service Mesh pelas equipes de desenvolvimento de funcionalidades de negócios permite manter o equilíbrio. No final, os fornecedores de API podem se concentrar exclusivamente na parte de aplicação de seu serviço e simplesmente publicá-lo no Service Mesh – a API estará imediatamente disponível para todos os clientes, e a qualidade da integração será adequada para produção, não exigindo nenhuma linha de código adicional.
Uma das próximas vantagens é que o desenvolvedor, ao usar o Service Mesh, se concentra exclusivamente na funcionalidade de negócios — no aspecto do produto e não no aspecto tecnológico de seu serviço. Por exemplo, não é mais necessário se preocupar com a possibilidade de uma interrupção de conexão quando o serviço for chamado pela rede. Além disso, o Service Mesh ajuda a equilibrar o tráfego entre cópias do mesmo serviço: se uma das cópias ‘falhar’, o sistema redirecionará todo o tráfego para as cópias restantes que ainda estão ativas.
Service Mesh — é uma boa base para a criação de aplicativos distribuídos, que oculta do cliente os detalhes de como as chamadas para seus serviços são feitas, tanto interna quanto externamente. Todos os aplicativos que utilizam o Service Mesh estão isolados em nível de transporte, tanto da rede quanto uns dos outros: não há conexão entre eles. Ao mesmo tempo, o desenvolvedor tem controle total sobre seus serviços.
Não se pode deixar de notar que a atualização de aplicativos distribuídos em um ambiente onde o Service Mesh é utilizado se torna mais simples. Por exemplo, a implantação blue/green, na qual duas ambientes de aplicativo estão disponíveis para instalação, um dos quais não é atualizado e fica em modo de espera. O rollback para a versão anterior em caso de falha na liberação é feito por um roteador especial, papel que é bem desempenhado pelo Service Mesh.. Para testar a nova versão, você também pode usar o release canário — direcionar apenas 10% do tráfego ou solicitações de um grupo piloto de clientes para a nova versão. O tráfego principal vai para a versão antiga, nada falha.
Além disso O Service Mesh nos dá controle de SLA em tempo real. O sistema de proxies distribuídos não permitirá que o serviço falhe quando algum cliente ultrapassar o limite concedido a ele. Se a largura de banda da API estiver limitada, ninguém poderá sobrecarregá-la com um grande número de transações: o Service Mesh fica na frente do serviço e não permite o tráfego excessivo. Ele simplesmente vai ser barrado na camada de integração, enquanto os próprios serviços continuam funcionando sem perceber.
Se a empresa quer reduzir os custos de desenvolvimento de soluções de integração, o Service Mesh também é útil: é possível migrar de produtos comerciais para sua versão open-source. Nossa Enterprise Service Mesh é baseada na versão open-source do Service Mesh.
Outra vantagem é a presença de um 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 relações entre os aplicativos que formam o núcleo do negócio da empresa. Isso é muito conveniente.
(para salvar as alterações). O Service Mesh impulsiona a empresa a migrar para uma infraestrutura dinâmica. Agora, muitos estão olhando para a containerização. Dividir monólitos em microsserviços e implementar tudo isso de forma bela — o tema está em ascensão. Mas quando você tenta levar um sistema que já está em produção há muitos anos para novos rumos, você logo se depara com uma série de problemas: encaixar tudo isso em contêineres e implantar na plataforma não é fácil. E a implementação, sincronização e interação desses componentes distribuídos — é outro tema bastante complicado. Como eles irão se comunicar? Haverá falhas em cascata? O Service Mesh permite resolver parte desses problemas e facilitar a migração da arquitetura antiga para a nova, permitindo que você esqueça a lógica de troca de rede.
Por que é necessária a personalização do Service Mesh
Na nossa empresa, centenas de sistemas e módulos coexistem, e o runtime está bastante sobrecarregado. Portanto, o padrão simples, onde um sistema chama outro e recebe uma resposta, não é suficiente, pois em produção queremos mais. O que mais é necessário de um Service Mesh corporativo?
Serviço de processamento de eventos
Suponha que precisamos implementar um processamento de eventos em tempo real — um sistema que analisa as ações do cliente em tempo real e pode imediatamente fazer uma oferta relevante. Para implementar tal funcionalidade, é utilizado um padrão arquitetônico chamado arquitetura orientada a eventos (EDA). Nenhum dos Service Mesh atuais suporta esses padrões nativamente, e isso é muito importante, especialmente para um banco!
É bastante estranho que o 'chamado remoto' Remote Procedure Call (RPC) seja suportado por todas as versões do Service Mesh, enquanto com EDA eles não se dão bem. Porque o Service Mesh é uma espécie de integração distribuída moderna, enquanto EDA é um padrão arquitetônico 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, processamento de eventos em fluxo e abrangente usando diversos filtros e modelos.
Serviço de transferência de arquivos
Além do EDA, seria bom ter a capacidade de transferir arquivos: em uma escala empresarial, muitas vezes a única integração possível é a através de arquivos. Especificamente, utiliza-se o padrão arquitetônico ETL (Extract, Transform, Load — 'extração, transformação, carregamento'). Nele, normalmente, todos trocam exclusivamente arquivos: utilizam-se grandes dados que não são viáveis de enviar em solicitações separadas. A capacidade de suporte nativo à transferência de arquivos no Enterprise Service Mesh oferece a flexibilidade necessária para os negócios.
Serviço de orquestração
Nas grandes organizações, quase sempre há diferentes equipes que desenvolvem produtos distintos. Por exemplo, em um banco, algumas equipes trabalham com depósitos, enquanto outras lidam com produtos de crédito, e existem muitos desses casos. São pessoas diferentes, equipes diferentes, que criam seus produtos, desenvolvem suas APIs e as disponibilizam para outros. E frequentemente surge a necessidade de compor esses serviços, bem como implementar a lógica complexa de chamadas sequenciais de um conjunto de APIs. Para resolver esse problema, é necessária uma solução no nível de integração, que simplifique toda essa lógica composta (chamada de várias APIs, descrição da rota das solicitações etc.). Isso é o que chamamos de serviço de orquestração no Enterprise Service Mesh.
IA e ML
Quando microsserviços se comunicam por meio de uma camada de integração única, o Service Mesh, naturalmente, conhece todas as chamadas a cada serviço. Coletamos telemetria: quem chamou quem, quando, quanto tempo, quantas vezes e assim por diante. Quando esses serviços somam centenas de milhares e as chamadas chegam a bilhões, toda essa informação se acumula e forma os Big Data. Esses dados podem ser analisados com ferramentas de IA, aprendizado de máquina e similares, e a partir dos resultados da análise, realizar ações úteis. Seria apropriado, ao menos parcialmente, transferir ao inteligência artificial o controle de todo esse tráfego de rede e das chamadas de aplicativos integrados no Service Mesh.
Serviço API Gateway
Normalmente, no Service Mesh, existem proxies e serviços que se comunicam entre si dentro de um perímetro confiável. Mas também há partes externas. As exigências para as APIs fornecidas a esse grupo de consumidores são muito mais rigorosas. Dividimos essa tarefa em duas partes principais.
- Segurança. Questões relacionadas a ddos, vulnerabilidades de protocolos, aplicativos, sistemas operacionais, etc.
- Escalabilidade. Quando o número de APIs que precisa ser disponibilizado aos clientes chega a milhares ou mesmo centenas de milhares, surge a necessidade de algum meio de gerenciar esse conjunto de APIs. É preciso monitorar constantemente as APIs: se estão funcionando ou não, qual é o status, qual é o tráfego, quais são as estatísticas, etc. O API Gateway 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 tanto APIs internas quanto externas sem complicações desnecessárias.
Serviço de suporte a protocolos e formatos de dados específicos (gateway AS)
Atualmente, a maioria das soluções de Service Mesh só consegue trabalhar nativamente com tráfego HTTP e HTTP2 ou em um modo reduzido no nível TCP/IP. Com o Enterprise Service Mesh, surgem muitos outros protocolos de transmissão de dados bastante específicos. Alguns sistemas podem usar brokers de mensagens, enquanto outros estão integrados no nível de bancos de dados. Se a empresa possui SAP, ele também pode usar seu próprio sistema de integração. E tudo isso funciona e é uma parte importante do negócio.
Não se pode simplesmente dizer: "Vamos abandonar o legado e criar novos sistemas que possam usar Service Mesh". Para integrar todos os sistemas antigos com os novos (baseados em microserviços), os sistemas que podem utilizar Service Mesh precisarão de algum adaptador, intermediário ou gateway. Concorda que seria interessante se isso já viesse incluso na caixa com o serviço? O gateway AS pode de fato suportar qualquer tipo de integração. Imagine que você simplesmente instala o Enterprise Service Mesh e ele já está pronto para interagir com todos os protocolos que você precisa. Para nós, essa abordagem é muito importante.
É 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 open-source prontas da plataforma de integração. Apenas alguns anos após seu surgimento, a arquitetura Service Mesh continua a evoluir, e estamos felizes em poder contribuir para seu desenvolvimento. Esperamos que nossa experiência seja útil para você.
Fonte: habr.com
