Grigory Petrov: trabalhando com uma rede em Ruby

Em 28 de setembro, na conferência Evrone RubyRussia DevRel, Grigory Petrov falará sobre como os microsserviços se comunicam. Na entrevista de hoje, Ivan Solovyov conversou com Grigory sobre o tópico de seu próximo discurso e não apenas sobre isso.



Conte-nos sobre você, o que você está fazendo na Evrone?

Estou envolvido em relações com desenvolvedores - isso é algo entre o DevRel e o evangelista de tecnologia, um desenvolvedor que pode falar em conferências. Trabalhe como Robin Hood: comunique-se com as equipes de desenvolvimento da empresa, colete várias coisas interessantes sobre o que elas fazem e converse sobre isso em conferências. Ruby Russia será uma das primeiras conferências em que falarei em nome da empresa.

Conheço você como um dos organizadores de várias conferências em Python. Diga-me como você veio ao mundo do Ruby?

Eu nunca deixei o mundo de Ruby. Uma das minhas primeiras palestras foi Python vs Ruby. Muitos anos atrás, quando escrevi em C ++, eu precisava de mecanismos de automação de alto nível para qualquer teste e geração de documentação. Então eu escrevi em Python e Ruby, e um pouco em PHP. Eu estava procurando as melhores maneiras de resolver os problemas que eu tinha.

Quanto seu relatório será emprestado das equipes de desenvolvimento da empresa? Eu sei que você escreveu em várias línguas: Ruby, Python, PHP, TypeScript, JavaScript, C ++ e não apenas.

O relatório será sobre a comunicação de microsserviços entre si pela rede, os protocolos utilizados para isso e as dificuldades emergentes. De fato, tenho um longo relacionamento com a rede. Eu fiz Radmin, esta é uma ferramenta de rede para controle remoto. O projeto NPTV (no qual também trabalhei com o DevRel) é uma televisão interativa que usou ativamente a grade e controlou o Ruby. O Voximplant (onde estudei o DevRel novamente) é uma telefonia programável onde conheci o VoIP. A grade está muito perto de mim. Eu poderia fazer um relatório com base na minha experiência, mas dessa maneira não traria o valor máximo aos convidados da conferência, mas quero trazer o benefício máximo. Durante a preparação inicial do relatório, entrevistei várias equipes da Evrone. A empresa está envolvida no desenvolvimento personalizado de software complexo e de alta qualidade, muitas equipes estão trabalhando em vários projetos. Ligamos para o Zoom e conversamos por uma hora ou mais. Eles discutiram o que e como eles fazem, quais dificuldades, quais pilhas eles usam. Meu relatório será metade sobre a grade, protocolos de rede, complexidade e aplicação e metade sobre como é usado no Ruby por diferentes equipes.

Você tem muita comunicação com os desenvolvedores. Quão específico você acha que é trabalhar com uma rede no Ruby?

A rede consiste em várias partes. Primeiro de tudo, o trabalho da linguagem de programação e seu ecossistema diretamente com os bytes transmitidos pela rede. A pilha de rede de nível mais baixo. Por exemplo, o mesmo JS e nó usam libuv , um modelo assíncrono. Existe um fluxo principal e você trabalha com a rede eventualmente. Você tem rotinas para isso. Você faz muitas expectativas, espera para receber os dados, espera para que os dados sejam enviados. Esse encadeamento único fornece milhares e dezenas de milhares de consultas por segundo.

Sobre essa base, as estruturas são desenvolvidas, sejam elas quais forem. Por exemplo, JS não possui estruturas sérias para trabalhar com a grade (pela qual você pode parabenizá-lo!). Com exceção do express.js, que dificilmente é uma estrutura completa. O Python mudou para um modelo semelhante, e o framework Django mais popular permaneceu no modelo anterior. Agora, há um tipo de discórdia - uma estrutura síncrona que está tentando se propagar bloqueando threads, processos com um GIL pendendo sobre ela e, ao lado, há algumas coisas novas que tentam trabalhar em um modelo assíncrono, por exemplo, Django Channels. Ruby ainda está no modelo síncrono e propagado por processos. Portanto, aqui está o ecossistema correspondente, abordagens e posições muito fortes do Rails.

Qual é o poder do Ruby? Primeiro de tudo, no DSL, idioma específico do domínio. Quando falamos sobre o grid, Ruby joga melhor no campo onde é o mais forte. Quando usamos o GraphQL, isso significa que as bibliotecas para uso do GraphQL estão por toda parte. No Ruby, eles usarão uma sintaxe DSL muito boa para definir o esquema. E a integração entre essa sintaxe DSL e a sintaxe DSL ORM no ActiveRecord. É exatamente isso que podemos esperar do Ruby. Ao mesmo tempo, não teremos operações assíncronas (aguardar), seremos escalados pelos processos e teremos os requisitos de servidor correspondentes.

Seu relatório afirmou vários protocolos de interação. O mesmo JSON: API e assim por diante. De que maneira você vê mais desenvolvimento, todos nós vamos deslizar para o GraphQL?

Uma pergunta muito ressonante. Na minha opinião, começou com o fato de a grade ser lenta. As aplicações no início são simples. Como regra, todos os aplicativos, Ruby, Python e Node, usam terminais HTTP regulares para comunicação. Dentro, eles usam algum tipo de carga útil. Anteriormente XML, agora JSON. Eles estão indo bem nos primeiros meses ou anos, como se tivessem sorte. Em seguida, o negócio começa a fazer perguntas complexas. Por exemplo, você precisa obter alguns usuários e para cada usuário obter uma lista de empresas nas quais ele trabalha. Aqui surge o problema: se você apenas usar o ponto de extremidade, haverá várias dezenas ou centenas de solicitações, e a grade será tranqüila: solicitação, resposta, pacotes perdidos. Será monstruosamente lento e muitos dados precisarão ser transmitidos pela rede. 100 vezes mais que os dados necessários. Nosso sistema entra em colapso, à medida que grandes sistemas de automação comercial entram em colapso com essas solicitações, que em 10 anos se transformam em monstros, onde uma pergunta difícil da interface pode levar minutos, horas. Durante todo esse tempo, o banco de dados no back-end elaborará um monte de solicitações idênticas, e várias solicitações idênticas perseguirão a rede. Tentamos resolvê-lo de diferentes maneiras.

Dê exemplos reais de tais problemas?

O Facebook se destacou particularmente, eles têm esse problema muito agudo: há muitos dados sobre os quais eles gostam de fazer consultas complexas. Por exemplo: mostre-me aqueles que comentaram esta postagem e seus amigos. Para não fazer milhões de solicitações, o Facebook usa opções diferentes. Por exemplo, FQL, Facebook Query Language. Depois de coletar toda a sua experiência, eles criaram o GraphQL - algo que permite fazer consultas semelhantes a SQL no cliente. Mas isso não é SQL, porque não podemos ser anexados a bancos de dados, mas uma consulta em termos da API de back-end. Você envia uma solicitação e recebe uma (ou como vai) a resposta.

O segundo grande problema é o que fazer se queremos obter muitos dados do back-end. Por exemplo, cinco mil usuários ou um logon em 10mb. É assustador fazer tudo isso com um pedido de resposta http. Como se a malha cair, a solicitação terá que ser repetida por inteiro, e isso pode durar para sempre. Voltando ao Facebook: eles criaram o GraphQL, uma muleta sobre a grade. E outras pessoas fizeram o HTTP / 2, o que resolve o problema da grade. O HTTP / 2 faz uma conexão assíncrona, na qual podemos fazer muitos pedidos pequenos. O HTTP / 2 combate o GraphQL se o servidor GraphQL não tiver muita mágica para otimizar o número de consultas ao banco de dados no back-end. E na conversa, falaremos sobre o que Ruby oferece para essa mágica. Com o HTTP / 2, o GraphQL pode não ser necessário. Podemos fazer 100 solicitações HTTP / 2 para nosso terminal e, do ponto de vista dos bytes, isso não será uma sobrecarga maior do que se usarmos o GraphQL. Os buffers de protocolo do Google e o gRPC abordam esse problema do terceiro lado. Eles usam protocolos de transporte binário, principalmente HTTP / 2, oferecem um certo esquema para API. Aqui eles competem com o REST usual.

Na prática, na maioria das empresas que usam JSON, o programador Vasya senta e escreve esse JSON com as mãos. Seis meses depois, Vasya descobre que a data e a hora podem ser transmitidas de centenas de maneiras diferentes. O horror começa! Mas se bons desenvolvedores estão na empresa, eles escrevem não apenas JSON, mas usam algum tipo de padrão. Usando o OpenAPI ou JSON Schema, todas essas coisas interessantes que competem com o gRPC. Todo esse zoológico moderno resolve alguns problemas expressos. E o que acontecerá com esse zoológico no futuro, não posso prever nada. Mas convido os desenvolvedores a virem discutir esta questão: o que nos espera no próximo ano, 3, 5, 10 e qual é a disposição das forças agora.

Vamos falar sobre o futuro do Ruby como uma linguagem de programação?

É difícil prever o futuro. Eu realmente gostaria de ver bons tipos em Ruby. O Ruby 3 está agora no estágio inicial da implementação do tipo. Eu gostaria que essa sintaxe fosse bonita. Eu vi as propostas, meu lugar careca estava em pé com elas. Sintaxe horrível e muito detalhada que ninguém vai usar.

Por que você acha isso?

Eu sou um neurofisiologista amador. O pensamento intuitivo de que todo mundo gosta de tomar todo tipo de decisões estranhas. Se, por exemplo, você precisa escrever muitas letras, isso é ruim. Esses tipos podem ser mega-legais, mas, como você precisa escrever uma vez e meia mais código, sentiremos a emoção "não quero". E somos muito sensíveis às nossas emoções, para que ninguém a use. Eu realmente gosto da maneira como os tipos foram transmitidos no Python e TypeScript: através dos dois pontos. Isso fornece uma sobrecarga mínima. Nós escrevemos um identificador - olhou. Eu tenho certeza que haverá um número, você precisa colocar uma armadilha. O desenvolvedor escreve dois pontos e é isso, a armadilha está instalada. Depois de algumas semanas, quando ele passa uma lista ou linha acidentalmente, a armadilha funcionará e salvará o desenvolvedor várias horas ou semanas de depuração.

O que mais você gostaria de ver em Ruby?

Nos últimos anos, tenho visto muita assíncrona com corotinas. Eu realmente gosto disso porque o código assíncrono com corotinas é fácil de ler. É compreensível, permite que você coloque coisas complexas em uma sintaxe simples. Isso está bem implementado no Python mais recente e bem implementado no JavaScript. Eu realmente gostaria que Ruby trouxesse algo assim ... Na verdade, Ruby tem fibra. Seria legal adicionar algo como Node para que você possa escrever aplicativos Ruby assíncronos usando fibras ou outras primitivas. E sob o capô, ele próprio usaria o libuv ou alguns outros primitivos do sistema operacional para trabalhar com a grade.

Ou colocaria algo nos fluxos. Usaria algo para atender competitivamente a todos esses pedidos de rede, banco de dados e sistema de arquivos. E eu escreveria apenas a rotina no nível de pequenos pedaços de código que são executados em uma solicitação ou timer de entrada, depois daria comandos e aguardava sua execução. Além disso, muita magia, tudo isso é feito em paralelo, consome um enorme carro da Amazon em 100% e tem dezenas de milhares de solicitações por segundo. No caso do Go, centenas de milhares de consultas por segundo.

Voltar para os tipos. Provavelmente será a introdução gradual de tipos, digitação gradual?

A Gradual Typing é um mega foguete que foi adicionado pela primeira vez ao Python. Nós fizemos isso para que os tipos possam ser adicionados um pouco. Na minha opinião, todo um paradigma de desenvolvimento surgiu quando, no início, o código é escrito muito rapidamente sem tipos e, em seguida, quando o desenvolvedor vê que parte do código se estabilizou, os tipos começam a ser adicionados a essa parte do código. É onde se estabilizou e é necessário montar armadilhas para que no futuro nada seja quebrado sobre essa estabilizada. Seria legal se eles fizessem algo semelhante para Ruby.

Que pergunta você quer fazer a Yukihiro Matsumoto na conferência?

Eu estudo japonês há 4 anos, e meu japonês provavelmente é suficiente para dizer "obrigado" a ele. Eu vou treinar!

Vejo você no RubyRussia!

Registre-se , o próximo aumento de preço é esperado após 15 de setembro, 700 participantes já estão conosco.

E tradicional graças às empresas que nos apoiam:

Organizador - Evrone
Parceiro Geral - Toptal
Parceiro Gold - Gett
Parceiros Silver - JetBrains , Bookmate e Cashwagon
Parceiro Bronze - InSales