Grigory Petrov: trabajando con una red en Ruby

El 28 de septiembre, en la conferencia Evrone RubyRussia DevRel, Grigory Petrov hablará sobre cómo se comunican los microservicios. En la entrevista de hoy, Ivan Solovyov habló con Grigory sobre el tema de su próximo discurso y no solo sobre eso.



Cuéntanos sobre ti, ¿qué haces en Evrone?

Estoy involucrado en las relaciones con los desarrolladores: esto es algo entre DevRel y Technology Evangelist, un desarrollador que puede hablar en conferencias. Trabaje como Robin Hood: comuníquese con los equipos de desarrollo dentro de la empresa, recopile varias cosas interesantes de lo que hacen y hable sobre esto en las conferencias. Ruby Russia será una de las primeras conferencias donde hablaré en nombre de la empresa.

Te conozco como uno de los organizadores de varias conferencias de Python. ¿Dime cómo llegaste al mundo de Ruby?

Nunca he dejado el mundo de Ruby. Una de mis primeras conferencias fue Python vs Ruby. Hace muchos años, cuando escribí en C ++, necesitaba mecanismos de automatización de alto nivel para cualquier prueba, generación de documentación. Luego escribí en Python y Ruby, y un poco en PHP. Estaba buscando las mejores formas de resolver los problemas que tenía.

¿Cuánto se tomará prestado su informe de los equipos de desarrollo dentro de la empresa? Sé que escribiste en muchos idiomas: Ruby, Python, PHP, TypeScript, JavaScript, C ++ y no solo.

El informe tratará sobre la comunicación de microservicios entre ellos a través de la red, los protocolos utilizados para esto y las dificultades emergentes. De hecho, tengo una larga relación con la red. Hice Radmin, esta es una herramienta de red para control remoto. El proyecto NPTV (en el que también trabajé DevRel) es una televisión interactiva que utilizaba activamente la red y controlaba Ruby. Voximplant (donde estudié DevRel nuevamente) es una telefonía programable donde conocí a VoIP. La cuadrícula está muy cerca de mí. Podría hacer un informe basado en mi experiencia, pero de esta manera no aportaría el máximo valor a los invitados de la conferencia, pero quiero tener el máximo beneficio. Durante la preparación inicial del informe, entrevisté a varios equipos de Evrone. La compañía se dedica al desarrollo personalizado de software complejo y de alta calidad, muchos equipos están trabajando en varios proyectos. Llamamos a Zoom y hablamos durante una hora o más. Discutieron qué y cómo lo hacen, qué dificultades, qué pilas usan. Mi informe será la mitad sobre la cuadrícula, los protocolos de red, la complejidad y la aplicación, y la mitad sobre cómo es utilizado en Ruby por diferentes equipos.

Tienes mucha comunicación con los desarrolladores. ¿Qué tan específico crees que es trabajar con una red en Ruby?

La red consta de varias partes. En primer lugar, el trabajo del lenguaje de programación y su ecosistema directamente con bytes transmitidos a través de la red. La pila de red de nivel más bajo. Por ejemplo, el mismo JS y Node usan libuv , un modelo asincrónico. Hay una transmisión principal, y eventualmente trabajas con la red. Tienes corutinas para esto. Haces muchas expectativas, esperas para recibir los datos, haces la espera para que se envíen los datos. Este hilo único proporciona miles y decenas de miles de consultas por segundo.

Sobre esta base, se desarrollan marcos, cualesquiera que sean. Por ejemplo, JS no tiene marcos serios para trabajar con la grilla (¡por lo cual puedes felicitarlo!). Con la excepción de express.js, que difícilmente es un marco completo. Python cambió a un modelo similar, y el framework Django más popular permaneció en el modelo anterior. Ahora hay una especie de discordia: un marco sincrónico que intenta propagarse mediante el bloqueo de subprocesos, procesos con un GIL sobresaliendo y, por otro lado, hay algunas cosas nuevas que intentan funcionar en un modelo asincrónico, por ejemplo, los canales Django. Ruby todavía está en el modelo síncrono y se propaga por procesos. Por lo tanto, aquí está el ecosistema correspondiente, los enfoques y las posiciones muy fuertes de Rails.

¿Cuál es el poder de Ruby? En primer lugar, en DSL, lenguaje específico de dominio. Cuando hablamos de la grilla, Ruby juega mejor en el campo donde es más fuerte. Cuando usamos GraphQL, significa que las bibliotecas para usar GraphQL están en todas partes. En Ruby, usarán una muy buena sintaxis DSL para definir el esquema. Y la integración entre estas sintaxis DSL y la sintaxis ORM DSL en ActiveRecord. Esto es exactamente lo que podemos esperar de Ruby. Al mismo tiempo, no tendremos ninguna operación asincrónica (espera), seremos escalados por los procesos y tendremos los requisitos del servidor correspondientes.

Su informe indicó varios protocolos de interacción. El mismo JSON: API, etc. ¿De qué manera ve un mayor desarrollo, todos nos deslizaremos en GraphQL?

Una pregunta muy resonante. En mi opinión, comenzó con el hecho de que la cuadrícula es lenta. Las aplicaciones al principio son simples. Como regla general, todas las aplicaciones, tanto Ruby, Python como Node, usan puntos finales HTTP regulares para la comunicación. En el interior usan algún tipo de carga útil. Anteriormente XML, ahora JSON. Les va bien durante los primeros meses o años, como si tuvieran suerte. Luego, el negocio comienza a hacer preguntas complejas. Por ejemplo, necesita obtener algunos usuarios y para cada usuario obtener una lista de las empresas en las que trabaja. Aquí surge el problema: si solo usa el punto final, entonces serán varias decenas o cientos de solicitudes, y la cuadrícula es pausada: solicitud, respuesta, paquetes perdidos. Será monstruosamente lento y será necesario transmitir muchos datos a través de la red. 100 veces más que los datos requeridos. Nuestro sistema colapsa, a medida que los sistemas de automatización de grandes empresas colapsan bajo tales solicitudes, que en 10 años se convierten en monstruos, donde minutos, horas pueden ser una pregunta complicada desde la interfaz. Todo este tiempo, la base de datos en el back-end resolverá un montón de solicitudes idénticas, y un montón de solicitudes idénticas perseguirá a través de la red. Tratamos de resolverlo de diferentes maneras.

¿Dar ejemplos reales de tales problemas?

Facebook fue particularmente distinguido, tienen este problema es muy grave: hay muchos datos sobre los que les gusta hacer consultas complejas. Por ejemplo: muéstrame a los que comentaron esta publicación y a sus amigos. Para no hacer millones de solicitudes, Facebook usa diferentes opciones. Por ejemplo, FQL, Facebook Query Language. Habiendo recopilado toda su experiencia, crearon GraphQL, algo que le permite hacer consultas similares a SQL en el cliente. Pero esto no es SQL, porque no podemos adjuntarnos a bases de datos, sino una consulta en términos de la API de back-end. Envías una solicitud y obtienes una respuesta (o cómo va).

El segundo gran problema es qué hacer si queremos obtener una gran cantidad de datos del backend. Por ejemplo, cinco mil usuarios o un registro en 10mb. Es aterrador hacerlo todo con una solicitud-respuesta http. Porque si la malla se colapsa, la solicitud tendrá que repetirse en su totalidad, y esto puede durar para siempre. Volviendo a Facebook: hicieron GraphQL, una muleta sobre la red. Y luego otras personas hicieron HTTP / 2, lo que resuelve el problema de la red. HTTP / 2 realiza una conexión asincrónica, dentro de la cual podemos hacer muchas solicitudes pequeñas. HTTP / 2 combate GraphQL si el servidor GraphQL no tiene mucha magia para optimizar el número de consultas a la base de datos en el back-end. Y en la charla, hablaremos sobre lo que Ruby ofrece para esta magia. Con HTTP / 2, GraphQL puede no ser necesario. Podemos hacer 100 solicitudes HTTP / 2 a nuestro punto final, y desde el punto de vista de bytes, esto no será una sobrecarga mayor que si usamos GraphQL. Google Protocol Buffers y gRPC abordan este problema desde el tercer extremo. Utilizan protocolos de transporte binarios, principalmente HTTP / 2, ofrecen un cierto esquema para api. Aquí compiten con el RESTO habitual.

En la práctica, en la mayoría de las empresas que usan JSON, el programador Vasya se sienta y escribe este JSON con sus manos. Seis meses después, Vasya se entera de que la fecha y la hora se pueden transmitir de cien maneras diferentes. ¡Comienza el horror! Pero si los buenos desarrolladores se sientan en la empresa, escriben no solo JSON, sino que usan algún tipo de estándar. Usando OpenAPI o JSON Schema, todas estas cosas interesantes que compiten con gRPC. Todo este zoológico moderno resuelve algunos problemas expresados. Y lo que sucederá con este zoológico en el futuro, no puedo predecirlo en absoluto. Pero invito a los desarrolladores a que vengan y discutan este tema: lo que nos espera en el próximo año, 3, 5, 10 y cuál es la disposición de las fuerzas ahora.

¿Hablemos sobre el futuro de Ruby como lenguaje de programación?

Es difícil predecir el futuro. Realmente me gustaría ver buenos tipos en Ruby. Ruby 3 se encuentra ahora en la etapa inicial de implementación de tipos. Me gustaría que esta sintaxis sea hermosa. Vi las propuestas, mi calva se puso de punta. Horrible, sintaxis muy detallada que nadie usará.

¿Por qué piensas eso?

Soy un neurofisiólogo aficionado. El pensamiento intuitivo que todos tienen le gusta tomar todo tipo de decisiones extrañas. Si, por ejemplo, necesita escribir muchas cartas, entonces esto es malo. Estos tipos pueden ser mega-geniales, pero debido al hecho de que tiene que escribir una vez y media más código, sentiremos la emoción "No quiero". Y somos muy sensibles a nuestras emociones, por lo que nadie lo usará. Realmente me gusta la forma en que se transmitieron los tipos en Python y TypeScript: a través de los dos puntos. Esto da una sobrecarga mínima. Escribimos un identificador - buscado. Sé con certeza que habrá un número, debes poner una trampa. El desarrollador escribe dos puntos y eso es todo, la trampa está instalada. Después de un par de semanas, cuando accidentalmente pasa una lista o línea allí, la trampa funcionará y ahorrará al desarrollador varias horas o semanas de depuración.

¿Qué más te gustaría ver en Ruby?

En los últimos años, he visto mucha asincronía con las rutinas. Realmente me gusta esto porque el código asíncrono con corutinas es fácil de leer. Es comprensible, le permite agrupar cosas complejas en una sintaxis simple. Esto está bien implementado en el último Python y bien implementado en JavaScript. Realmente me gustaría que Ruby trajera algo así ... En realidad, Ruby tiene fibra. Sería genial agregar algo como Node para que pueda escribir aplicaciones asíncronas de Ruby utilizando fibras u otras primitivas. Y bajo el capó, usaría libuv u otras primitivas del sistema operativo para trabajar con la red.

O pondría algo en las corrientes. Usaría algo para cumplir competitivamente todas estas solicitudes de red, solicitudes de bases de datos, solicitudes de sistema de archivos. Y solo escribiría corutina al nivel de pequeños trozos de código que se ejecutan en una solicitud o temporizador entrante, luego daría comandos y esperaría su ejecución. Más allá del capó, mucha magia, todo esto se hace en paralelo, consume un enorme automóvil de Amazon en un 100% y tiene decenas de miles de solicitudes por segundo. En el caso de Go, cientos de miles de consultas por segundo.

De vuelta a los tipos. Probablemente sea la introducción gradual de tipos, ¿Gradual Typing?

Gradual Typing es un mega cohete que se agregó por primera vez a Python. Lo hicimos para que los tipos se puedan agregar un poco. En mi opinión, ha surgido todo un paradigma de desarrollo cuando al principio el código se escribe muy rápidamente sin tipos, y luego, cuando el desarrollador ve que alguna parte del código se ha estabilizado, los tipos comienzan a agregarse a esta parte del código. Es donde se ha estabilizado y es necesario colocar trampas para que en el futuro no se rompa nada sobre esta estabilizada. Sería genial si hicieran algo similar para Ruby.

¿Qué pregunta quieres hacerle a Yukihiro Matsumoto en la conferencia?

He estado estudiando japonés durante 4 años, y mi japonés probablemente sea suficiente para decirle "gracias". Voy a entrenar!

¡Nos vemos en RubyRussia!

Regístrese , se espera el próximo aumento de precios después del 15 de septiembre, 700 participantes ya están con nosotros.

Y gracias tradicionales a las empresas que nos apoyan:

Organizador - Evrone
Socio general - Toptal
Gold Partner - Gett
Silver Partners - JetBrains , Bookmate y Cashwagon
Socio de bronce - InSales