Header Ads Widget

Ticker

6/recent/ticker-posts

Explorando el marco de gRPC para crear microservicios


 Hay muy pocos nombres tan ubicuos como Google. Si bien Google es más conocido por su motor de búsqueda y por su conjunto de aplicaciones de productividad, parte de su trabajo más poderoso se encuentra en los aspectos funcionales de la World Wide Web y los protocolos que la impulsan. Con este fin, el gRPC de Google es un protocolo poderoso para microservicios. Está diseñado para ser eficiente, rápido y ágil.

En este artículo, vamos a discutir gRPC, el marco de trabajo RPC de código abierto de Google. Nos sumergiremos un poco en la historia de RPC como protocolo y cuál ha sido su uso histórico. También destacaremos algunos beneficios de adoptar gRPC (y de hecho, RPC en su conjunto) y el impacto potencial que tendrá gRPC en el diseño de API . Finalmente, responderemos la pregunta que ha estado en boca de muchos desde que se anunció gRPC: ¿qué significa esto para REST?

RPC: una definición y una historia

gRPC es un nuevo marco ampliamente basado en un mecanismo no tan nuevo llamado RPC, o llamada a procedimiento remoto . Cuando hablamos de RPC, en realidad estamos hablando de una metodología para ejecutar un procedimiento o subrutina . Las subrutinas son simplemente fragmentos de código que escribimos y ejecutamos para llevar a cabo una función utilizada en una función o proceso más grande; donde ocurre esta ejecución es clave para el concepto de RPC.

En la informática tradicional, una subrutina podría ejecutarse en un recurso local . Para simplificar, podemos pensar en estas subrutinas como pensamos en problemas matemáticos simples. Suponga que se le presentó este problema y se esperaba que lo resolviera con lápiz y papel:

1+1+(2+2)

Según las leyes de las matemáticas, primero tendrías que calcular los elementos entre paréntesis antes de continuar con el resto del problema. Las subrutinas funcionan de la misma manera: los cálculos y las solicitudes se realizan en el orden solicitado como parte de un sistema más grande de funciones o solicitudes.

Ahora imagine que en lugar de resolver un simple argumento entre paréntesis, tiene un problema mucho más complejo con múltiples subrutinas. En este caso, podemos enviar un argumento a un matemático con una mejor calculadora. En esta situación, necesitaríamos un medio acordado para resolver el problema y un método eficiente para transmitir los resultados. Esta es la base de RPC : es un protocolo que permite transmitir problemas en el mismo formato, independientemente de si se está calculando localmente o utilizando recursos remotos mejores y más rápidos.

Los primeros modelos informáticos que utilizan llamadas a procedimientos remotos para enmarcar las operaciones de red se remontan a los primeros documentos de ARPANET en la década de 1970, y las aplicaciones prácticas de la tecnología aparecieron en la década de 1980. El término en sí fue acuñado por Bruce Jay Nelson en 1981 y se usó para describir el sistema , diciendo:

Remote procedure call is the synchronous language-level transfer of control between programs in disjoint address spaces whose primary communication medium is a narrow channel. 

Un flujo de trabajo de RPC

RPC es fácil de entender una vez que ve cómo está diseñado . Un proceso básico de RPC se puede dividir en cinco etapas: "origen", "clasificación", "transmisión", "recepción", "procesamiento" y "respuesta".

  • Origen : en esta etapa, el cliente llama a lo que se conoce como "talón de cliente". Este stub es un procedimiento local o un proceso de subrutina que se llama como un proceso local normal. Una vez que se ha llamado a este proceso, se pasa al segundo paso de esta etapa, conocido como "clasificación".
  • Marshaling : el Client Stub, después de haber pasado un conjunto de parámetros, empaqueta la llamada y los parámetros y emite una llamada al sistema para enviar el mensaje.
  • Difusión : con el conjunto empaquetado de llamadas y parámetros, el sistema operativo local envía el mensaje empaquetado del cliente al servidor.
  • Recepción : El servidor recibe el paquete de la llamada y los parámetros del cliente. Estos paquetes de datos se ensamblan y pasan a lo que se denomina "Servidor Stub". Este código auxiliar funciona igual que el código auxiliar del cliente.
  • Procesamiento : ahora que el stub del servidor ha recibido el paquete de datos, se descomprime en un proceso llamado "desagrupamiento". La llamada se extrae junto con los parámetros y luego se considera un proceso o subrutina local.
  • Respuesta : El servidor llama al proceso o subrutina desempaquetada local. A continuación, los resultados se devuelven de la forma opuesta, pasando de Respuesta a Procesamiento y así sucesivamente hasta que se entregan al cliente de la etapa de Originación.

¿Por qué RPC?

Con todo esto dicho, ¿qué hace que RPC sea un concepto tan prometedor para traer de las profundidades de los protocolos de proto-internet? Si bien se ha hablado mucho de REST y otros marcos similares , este trabajo se ha realizado principalmente en un espacio donde la potencia de cálculo tanto en el cliente como en el servidor ha aumentado drásticamente. Desde el advenimiento de RPC, ambos lados de la ecuación se han vuelto cada vez más poderosos, por lo que las soluciones a gran escala y más hambrientas de energía han sido compensaciones aceptables por la potencia que ofrecían.

Sin embargo, hay una enorme llave inglesa en el mecanismo: el IoT o Internet de las cosas . Con tantos pequeños sensores y microdispositivos que utilizan microservicios para calcular cantidades masivas de datos, la necesidad de protocolos pequeños, eficientes en el consumo de energía , pero aún poderosos, ha dado lugar al concepto de RPC una vez más.

El auge del IoT en realidad imita mucho de lo que creó RPC en primer lugar. RPC se concibió inicialmente en un momento en el que un mainframe proporcionaba más potencia de cálculo que todas las computadoras que se conectarían a él combinadas. Lo mismo puede decirse del IoT, donde un dispositivo tiene la potencia de procesamiento suficiente para realizar una pequeña llamada local microscópica.

Aquí es donde brilla RPC: los servicios verdaderamente microscópicos funcionan bien con RPC y es lo que hace que el concepto esté listo para un fuerte regreso. Agregue esto a la gran capacidad de conectar internamente recursos en la nube alojados por el propio Google, y obtendrá un sistema de computación distribuida que es mayor que la suma de sus partes, brindando un peso computacional efectivo y poderoso incluso para los dispositivos más pequeños.

Qué hace que gRPC sea impresionante

Protobufs y compilación

Uno de los mejores puntos de venta de gRPC es el hecho de que se basa en Protocol Buffers , también conocidos como protobufs . Los Protobufs son el “[mecanismo extensible, neutral en cuanto al lenguaje y la plataforma, para serializar datos estructurados” de Google (https://github.com/google/protobuf) ”; el método está diseñado específicamente para ser una metodología liviana que permita la comunicación y el almacenamiento de datos de una manera predecible y analizable.https : // github com google protobuf ) ”; el método está diseñado específicamente para ser una metodología liviana que permita la comunicación y el almacenamiento de datos de una manera predecible y analizable.

Dado que los protobufs están respaldados por una de las empresas de tecnología más grandes del mundo, existen muchos recursos para que la adopción sea perfecta. Google proporciona un conjunto de generadores de código para crear códigos auxiliares para una amplia variedad de idiomas y, con las implementaciones de terceros, esta cantidad de idiomas de soporte crece drásticamente. A partir de "proto3 2.0", la aplicación beta actual del generador de código, los siguientes idiomas son oficialmente compatibles o mediante aplicaciones de terceros:

  • C ++
  • Java
  • Pitón
  • JavaNano
  • Vamos
  • Rubí
  • C objetivo
  • C#
  • javaScript
  • Perl
  • PHP
  • Scala
  • Julia

Idiomático y de código abierto

gRPC fue diseñado específicamente desde cero para generar automáticamente stubs idiomáticos de cliente y servidor. Idiomático es solo una forma elegante de decir "natural y entendido de forma nativa". Ser capaz de ser entendido en el idioma nativo en el que funciona es de suma importancia y puede conducir no solo a una adopción drásticamente mayor, sino a una mejor retención y comprensión.

Por supuesto, existe el hecho de que gRPC también es de código abierto ; Tener un recurso que está abierto a inspección, modulación, mutación y desarrollo a menudo resulta en soluciones más seguras, estables y útiles. Dado que es de código abierto, a medida que el protocolo envejece, las modificaciones de terceros probablemente llenarán cualquier brecha de implementación que exista.

Lea también nuestra Revisión de la gestión de API de código abierto Apiman de Red Hat

Eficiente y escalable

RPC, por diseño, está destinado a ser eficiente . La estructura del protocolo en sí es esbelta, y el procesamiento se produce en la etapa de clasificación y eliminación, lo que requiere muy poco procesamiento y modulación adicionales. Debido a esto, gRPC es intrínsecamente eficiente, mejorado solo por la metodología optimizada que Google ha implementado al construir sobre HTTP / 2 .

HTTP / 2, una revisión moderna de HTTP, permite usos altamente efectivos y eficientes de los recursos de red utilizando metodologías como se define en RFC 7540 . El nuevo marco en HTTP / 2 permite una menor latencia en el cable, una mayor compresión de datos y una minificación eficaz al reducir la cantidad total de código sin reducir una mayor funcionalidad.

Al construir gRPC dentro del marco de HTTP / 2, obtiene el beneficio de RPC magnificado por las ganancias en HTTP / 2, lo que significa datos más pequeños que nunca con la misma funcionalidad. Además, HTTP / 2 permite la transmisión bidireccional en su especificación de transporte, algo que gRPC aprovecha para minimizar el desperdicio de datos y disminuir la latencia general. Lo que se obtiene es una plataforma ajustada que utiliza un sistema de transporte ajustado para entregar bits de código ajustados: una disminución general en la latencia, el tamaño y la demanda que es notable y permite que un hardware más pequeño y menos experto tenga la misma potencia de procesamiento que un hardware más grande y potente. contemporáneos.

Relacionado:  5 protocolos para arquitecturas de API basadas en eventos

Soluciones y soporte de autenticación al horno

gRPC fue diseñado desde cero no solo para tener un sistema de autenticación integrado efectivo , sino para admitir una amplia gama de soluciones de autenticación. En primer lugar, existe el mecanismo admitido que está integrado en el protocolo: SSL / TLS es compatible con y sin los sistemas de autenticación basados ​​en tokens de Google.

De hecho, existe una API de autenticación que se proporciona con gRPC que utiliza un objeto Credentials para otorgar, revocar y controlar tanto las credenciales de canal como las credenciales de llamada. Esta API, además de tener las estructuras de soporte obvias para la solución de token de Google, también proporciona la MetadataCredentialsPluginclase y MetadataCredentialsFromPluginfunción para vincularse con soluciones de autenticación externas.

Esta autenticación también es relativamente ligera. La siguiente es una implementación oficial de autenticación en Ruby usando la autenticación de Google en Ruby:

require 'googleauth'  # from http://www.rubydoc.info/gems/googleauth/0.1.0
...
ssl_creds = GRPC::Core::ChannelCredentials.new(load_certs)  # load_certs typically loads a CA roots file
authentication = Google::Auth.get_application_default()
call_creds = GRPC::Core::CallCredentials.new(authentication.updater_proc)
combined_creds = ssl_creds.compose(call_creds)
stub = Helloworld::Greeter::Stub.new('greeter.googleapis.com', combined_creds)
 

Casos de uso

Ahora que entendemos gRPC, ¿cuáles son algunos casos de uso específicos que se beneficiarían de su implementación? Podemos ver los casos de uso específicos en los beneficios como se señaló anteriormente: livianos, eficientes y escalables .

Cualquier sistema que demande estos atributos se beneficiaría enormemente de RPC, asumiendo que el sistema en cuestión está utilizando recursos externos de forma rutinaria en su función. Los sistemas que requieren baja latencia y escalado rápido y eficiente, como los dispositivos de IoT impulsados ​​por microservicios , pueden usar gRPC con gran efecto y probablemente verían ganancias masivas a corto plazo y beneficios a largo plazo.

Además, los clientes móviles , independientemente de la potencia del dispositivo en un sentido local, pueden usar gRPC para conectarse de manera eficiente con sistemas, servidores y procesos en la nube externos, aprovechando estos mecanismos para el coprocesamiento para que coincida con la capacidad de procesamiento local. Tener la capacidad de descargar el procesamiento de datos mientras se utilizan recursos locales para procesar las necesidades locales de latencia extremadamente baja puede hacer mucho para multiplicar la potencia aparente de dicho dispositivo local, y podría contribuir en gran medida a hacer que los dispositivos móviles sean más livianos, más eficientes en el consumo de energía, pero más eficaz en sus funciones comunes.

REST vs.RPC - ¿Un argumento resuelto?

Entonces, ¿qué significa todo esto para el diseño de API? Y más específicamente, ¿qué significa esto para REST ? El argumento RPC versus REST es antiguo para muchos desarrolladores, pero parece que no entendieron el punto: ambos existen en un espacio específico para un propósito específico.

La diferencia entre REST y RPC es realmente bastante simple: REST expone los datos como recursos sobre los que se debe actuar, mientras que RPC expone las operaciones como un método para actuar sobre los datos . Si bien muchas de las primeras aplicaciones usaban REST y RPC de manera similar, su funcionalidad básica contrasta marcadamente y, como tal, la forma en que construimos con REST y RPC debería estar separada.

El problema es que hemos combinado la funcionalidad. Podemos obtener muchas funciones similares a RPC usando REST, y también podemos obtener muchas funciones similares a REST usando RPC. La mejor manera, entonces, es tratar la discusión entre REST y RPC como una cuestión de alcance y enfoque . Si bien REST es una metodología estándar para lidiar con microservicios entre IoT, a medida que estos dispositivos conectados se vuelven más pequeños y requieren más funcionalidad de los mismos recursos, los protocolos como gRPC se convertirán en una mejor opción para muchos desarrolladores.

En realidad, este no es un argumento sobre REST y RPC; es un argumento sobre dos soluciones sin contexto. El contexto del problema impulsará la solución .

El uso de REST con HTTP, por ejemplo, tiene el beneficio de la predictibilidad proveniente de su verborrea HTTP. RPC no tiene este beneficio, pero a la inversa, soluciones como gRPC hacen un mejor uso de HTTP / 2 y la eficiencia que ofrece para dejar a REST en términos de velocidad bruta y comunicación eficiente.

La conclusión es simplemente esto: su contexto determinará cuál es mejor y, como con cualquier aplicación en el espacio de la API, esto se reducirá a su caso de uso particular.

En resumen

En conclusión, gRPC representa una evolución bienvenida de la estructura clásica de RPC que aprovecha los protocolos modernos para una nueva generación de funcionalidad ajustada y altamente eficiente. A medida que avancemos hacia dispositivos más pequeños con una mayor demanda de procesamiento, es probable que soluciones como gRPC y las bifurcaciones que genera se conviertan en un serio competidor del paradigma del marco de microservicios centrado en REST que, hasta este momento, no ha sido cuestionado.

Publicar un comentario

0 Comentarios