Header Ads Widget

Ticker

6/recent/ticker-posts

Estudio de caso: Arquitectura de API Edge Gateway de Uber

 

A veces, las herramientas tecnológicas y la terminología pueden parecer en gran parte académicas y abstractas hasta que pueda verlas en acción. Cuando encontramos una nueva herramienta por primera vez, puede ser como si alguien le entregara un manual de instrucciones de 200 páginas como introducción. Puede ser difícil visualizar la utilidad de esa herramienta hasta que la vea en acción.

Para las API, eso puede dejarlo en una posición en la que parecen muy cerebrales o como si fueran algún tipo de juguete. Ver una API en acción puede marcar la diferencia, especialmente cuando comienza a trabajar con ellas.

Recientemente, Uber ha estado destacando algunos de sus proyectos de desarrollo en su blog Uber Engineering . El equipo ha descrito la creación y evolución de su API Edge Gateway , así como algunas de las formas en que se usa dentro de su organización. El resultado sirve como una clase magistral sobre el diseño, el crecimiento y el mantenimiento de un catálogo de API para una enorme corporación global. También ofrece algunos buenos ejemplos de diseño de API primero para que pueda ver ese patrón de diseño en acción.

Primera generación
Cuando Uber estaba comenzando, su infraestructura estaba dividida en dos componentes. El despacho se encargaba de conectar un conductor y un conductor. El componente API es donde se almacenó la información sobre el conductor, el pasajero y el viaje.

Tanto el usuario como las aplicaciones del conductor accedieron al servicio de despacho a través de un único punto final, que estaba alojado en /. El punto final tenía un campo especial llamado messageTypeen su cuerpo. Cuando el controlador consultaba ese punto final, la respuesta se entregaba a través de una carga útil JSON.

El componente del controlador podía aceptar comandos RPC, 15 de los cuales debían determinar los estados del controlador. Algunos de los comandos eran aceptar viajes, rechazar viajes y uno para que el pasajero solicitara un viaje.

La primera generación de la API de Uber es un ejemplo de un servicio monolítico que aún logró ser útil para el público y la empresa. Sin embargo, este sistema no duró mucho, ya que rápidamente superó esta configuración rudimentaria.

API de Uber Edge Gateway: 2.a generación
Uber fue uno de los primeros en adoptar microservicios . Para 2019, todos los servicios de Uber funcionaban con más de 2200 microservicios. Entre los años 2015 y 2019, Uber desarrolló RTAPI, o API en tiempo real , que comenzó como una única API RESTful para alimentar a más de 20 clientes móviles diferentes. Este fue el comienzo de API Gateway en serio.

Algunos de los objetivos de la segunda generación de la API de Uber Gateway fueron:

Desacoplamiento
Con las API de Uber explotando y creciendo a un ritmo exponencial, las cosas se estaban saliendo de control rápidamente. La API de Uber Gateway permitió que una cantidad indefinida de desarrolladores trabajaran en nuevas funciones para la API de forma independiente sin dejar de respetar los contratos de API existentes.

Transformación de protocolos
Antes de la segunda generación de la API de puerta de enlace de Uber, todas las transacciones se manejaban a través de HTTP y JSON. Luego, se dio a conocer un nuevo protocolo en el backend de Uber. Esto creó una dicotomía que requirió una capa de traducción adicional.

Viajes de ida y vuelta reducidos
La segunda generación de la API de Uber Gateway también redujo la cantidad de viajes de ida y vuelta desde el frontend al backend. La API de puerta de enlace consolida todas las llamadas a la API y consultas MICROSERVICE en un punto central para reducir la cantidad de viajes de ida y vuelta al backend. Esto es particularmente importante en áreas con conectividad limitada o planes de datos costosos.

Desafíos técnicos para la API de Uber Gateway de segunda generación
Algunos de los desafíos con los que se encontraron los desarrolladores de Uber durante la segunda generación de la API de Uber Gateway ilustran algunos de los desafíos que enfrentan la mayoría de las empresas cuando su API alcanza un tamaño particular.

En primer lugar, Uber tuvo que decidir qué marco usaría para la API de Gateway. Anteriormente, los desarrolladores de Uber trabajaban exclusivamente con Node.js. Sin embargo, esto estaba resultando ser problemático, ya que a veces había que realizar hasta 50.000 pruebas cada vez que se actualizaba el código. La actualización de Node.js podría requerir la actualización de más de 2500 bibliotecas NPM como un desafío adicional.

En esta etapa, Uber también cambió a gRPC, que tampoco era compatible con Node.js. Estos desafíos hicieron evidente que su arquitectura de API tendría que ser reconsiderada durante la próxima generación de la API de Gateway.

API de Uber Gateway: tercera generación
Para 2018, Uber había presentado un nuevo conjunto de servicios, desde la entrega de alimentos hasta el transporte de mercancías. Esto hizo que la API de Uber fuera más un ecosistema que un producto inclusivo. Esto creó las condiciones que hicieron posible la API de Edge Gateway de hoy.

Edge Layer consolidó la mayoría de las funciones desarrolladas durante la segunda generación. También se implementó una 'Capa de Presentación', que permitió que los diferentes productos mantuvieran su propia apariencia. También permitió a los consumidores personalizar sus pantallas.

También se dio a conocer una capa de producto en la tercera generación de la API de Gateway. Esto creó una API que describe las aplicaciones individuales disponibles, lo que hace posible desarrollar nuevos productos utilizando esas API.

La 3.ª generación de la API de Gateway abordó algunas de las limitaciones técnicas de la 2.ª generación. Estas revisiones permitieron implementar una puerta de enlace Edge pura en la tercera generación. Estas revisiones también hicieron que la API fuera más escalable, ya que los componentes individuales se transformaron en microservicios.

La tercera generación de la API de Uber Gateway es también cuando se introdujo Edge Gateway como un producto independiente.

Ingrese a Edge Gateway
Edge Gateway es un servicio simple de Golang con una interfaz de usuario integrada. Su propósito es servir como capa de administración de API. Esto brinda a los desarrolladores de Uber un único destino para crear, configurar y modificar API.

Ahora, profundicemos en algunas de las características de Edge Gateway en sí para aprender cómo la capa de administración de API se ocupa de algunos problemas comunes en el desarrollo y mantenimiento de API.

Gestión de API
La mayoría de las aplicaciones que superan un cierto nivel de complejidad consumen varias API para cumplir su propósito previsto. Esto significa que todos los servicios de backend deben ser manejados por una sola capa. Esta es la capa de gestión de API. La gestión de API es el nombre para la creación, configuración, edición, eliminación y control de versiones de las API, en particular las API de puerta de enlace.

La existencia de una capa de administración de API ayuda a estandarizar lo que los desarrolladores incluyen en sus API, lo que también lo prepara para ser consumido por otras aplicaciones de Uber. La capa de gestión de API declara una API:

  • Sendero
  • Tipo de datos
  • Tipo de respuesta
  • Número máximo de llamadas permitidas
  • Encabezados
  • Mapeo de campo
  • Aplicaciones permitidas
Protocolos de transferencia
Una vez que se determina la configuración de una API, la capa de administración de API crea API funcionales basadas en estas restricciones. También crea los SDK que permiten que una aplicación los consuma.

Echemos un vistazo debajo del capó para ver qué sucede durante una llamada a la API. Esto ayudará a ilustrar cómo Gateway Edge API agiliza la creación y el consumo de API.

Administrador de protocolo
El primer paso en la capa de administración de API es el Administrador de protocolos. Esto desacopla una carga útil de su formato de archivo. El Administrador de protocolos funciona en gran medida con archivos JSON, ya que eso es lo que se encuentra más comúnmente en las API, pero también puede funcionar con archivos Thrift y Protobuf.

Middleware
El middleware es el paso entre el backend y el endpoint final. Algunas funciones comunes manejadas por middleware incluyen:

  • Autorización
  • Limitación de velocidad
  • Autenticación
La API de Edge Gateway también tiene varias funciones de middleware que realiza automáticamente. Esto hace que las llamadas a la API individuales no tengan que implementarlas cada vez.

Controlador de punto final
La capa del controlador del punto final valida las solicitudes, transforma las cargas útiles y convierte la solicitud del punto final en un objeto de solicitud del cliente. La capa Endpoint Handler actúa esencialmente como un traductor, convirtiendo las acciones detrás de escena del backend, convirtiendo el objeto devuelto al formato especificado por el esquema.

Cliente
Por último, Edge Gateway tiene una capa de cliente para administrar las interacciones del cliente. Los usuarios pueden especificar formatos de solicitud, transformaciones necesarias para solicitudes y respuestas, validación de esquemas, gestión de plazos y cronogramas, y manejo de errores.

Lo que hemos aprendido de la API Edge Gateway de Uber
Como dijimos al principio, una de las corporaciones más grandes del mundo que revela algo sobre la forma en que usan la tecnología es motivo de celebración. Para los usuarios de API, las notas detalladas que Uber ha publicado sobre la evolución de su API Edge Gateway son especialmente informativas y valiosas, ya que Uber ha estado utilizando API durante años . Esto significa que han hecho todo el ensayo y error por usted. Seguir la evolución de Edge Gateway puede ayudar a revelar qué no hacer al diseñar una API. Es una lección invaluable sobre las trampas que se deben evitar.

La principal conclusión del estudio de Edge Gateway es cómo hacer que una API sea escalable . Uber debe tener uno de los ecosistemas de API más exigentes y resistentes del planeta, que a veces maneja millones de llamadas a la API por segundo de todo el planeta.

La API de Edge Gateway de Uber ilustra cómo una puerta de enlace de API, o algún tipo de capa de abstracción, prepara su API para la escalabilidad . Incluso si sus demandas de API son actualmente modestas, seguir estas prácticas u otras similares hará que desarrollar y mantener su API sea lo más eficiente y sencillo posible. La adopción de una configuración similar a un microservicio hace que pueda tener varios equipos de desarrollo trabajando en su API simultáneamente sin tener que preocuparse por romper nada o esperar retrasos.

Edge Gateway también ilustra cómo su API debe estar lista para cualquier cosa . Es un tutorial sobre el uso de capas de abstracción, puertas de enlace de API y esquemas para configurar los recursos de API para cualquier consumidor.

Las notas del blog de ingeniería de Uber también son una clase magistral en diseño de API. Es un excelente ejemplo de cómo pensar en el panorama general y los componentes individuales más pequeños que hacen posible ese panorama. Es muy común inventar cosas sobre la marcha al iniciar un negocio o desarrollar un nuevo producto.

Como puede ver en las diferentes generaciones de Edge Gateway, es muy común que este enfoque dé como resultado un retraso en el servicio hasta que se vuelvan extremadamente ineficientes o dejen de funcionar por completo. Es una ilustración del dilema del microservicio . Un poco de previsión y una planificación cuidadosa deberían ayudarlo a decidir el tamaño y el alcance correctos de cada componente, potencialmente incluso antes de comenzar su proyecto. Esto también evitará que las funciones se rompan, ahorrándole a usted y a su audiencia mucho dolor e innumerables dolores de cabeza en el proceso. Finalmente, Edge Gateway de Uber es un ejemplo de cómo una API bien diseñada podría impulsar una flota completa de servicios adicionales o incluso convertirse en un servicio en sí mismos. El cielo es el límite cuando desbloqueas todo el potencial de las API.


Publicar un comentario

0 Comentarios