Diseño del sistema de la aplicación Uber: arquitectura del sistema Uber

Es realmente fácil tocar un botón en nuestro teléfono móvil y tener el taxi disponible en pocos minutos cuando y donde queramos.  
Uber/Ola/Lyft … usar estas aplicaciones y obtener el servicio de transporte sin complicaciones es realmente simple, pero también es simple crear estas aplicaciones gigantesque tienen cientos de ingenieros de software trabajando en él durante una década…? definitivamente no. Estos sistemas tienen una arquitectura mucho más compleja y hay muchos componentes unidos internamente para brindar servicios de conducción en todo el mundo. Diseñar Uber (o OLA o Lyft) es una pregunta bastante común en el diseño del sistema en las entrevistas. Muchos candidatos tienen más miedo de esta ronda que de la ronda de codificación porque no tienen la idea de qué temas y compensaciones deben cubrir dentro de este período de tiempo limitado. En primer lugar, recuerde que la ronda de diseño del sistema es extremadamente abierta y no existe una respuesta estándar. Incluso para la misma pregunta, tendrá una discusión totalmente diferente con diferentes entrevistadores. 

En este blog, discutiremos cómo diseñar servicios de transporte compartido como Uber/Ola/Lyft, pero antes de continuar, queremos que lea el artículo “ ¿Cómo descifrar el diseño del sistema en las entrevistas? ”. Le dará una idea de cómo es esta ronda, qué se espera que haga y qué errores debe evitar frente al entrevistador. 

Arquitectura del sistema Uber

Todos estamos familiarizados con los servicios de Uber. Un usuario puede solicitar un viaje a través de la aplicación y, en unos minutos, un conductor llega cerca de su ubicación para llevarlo a su destino. Anteriormente, Uber se construyó sobre el modelo de arquitectura de software » monolítico «. Tenían un servicio de backend, un servicio de frontend y una sola base de datos. Usaron Python y sus marcos y SQLAlchemy como la capa ORM para la base de datos. Esta arquitectura estaba bien para una pequeña cantidad de viajes en algunas ciudades, pero cuando el servicio comenzó a expandirse en otras ciudades, el equipo de Uber comenzó a enfrentar el problema con la aplicación. Después del año 2014, el equipo de Uber decidió cambiar a la » arquitectura orientada al servicio » y ahora Uber también maneja la entrega de alimentos y la carga. 

1. Habla sobre los desafíos

Una de las tareas principales en el servicio de Uber es hacer coincidir al pasajero con los taxis, lo que significa que necesitamos dos servicios diferentes en nuestra arquitectura, es decir  

• Servicio de Suministro (para taxis)
• Servicio de demanda (para pasajeros)

Uber tiene un sistema de Despacho (Optimización de Despacho/DISCO) en su arquitectura para hacer coincidir la oferta con la demanda. Este sistema de despacho utiliza teléfonos móviles y asume la responsabilidad de emparejar a los conductores con los pasajeros (oferta a demanda). 

2. ¿Cómo funciona el sistema de despacho?

DISCO debe tener estos objetivos…  

• Reduzca la conducción adicional.
• Tiempo mínimo de espera
• ETA general mínima

El sistema de despacho funciona completamente con mapas y datos de ubicación/GPS, por lo que lo primero que es importante es modelar nuestros mapas y datos de ubicación. 

• La Tierra tiene una forma esférica, por lo que es difícil resumir y aproximar utilizando la latitud y la longitud. Para solucionar este problema, Uber utiliza la biblioteca Google S2 . Esta biblioteca divide los datos del mapa en celdas diminutas (por ejemplo, 3 km) y proporciona una identificación única a cada celda. Esta es una manera fácil de difundir datos en el sistema distribuido y almacenarlos fácilmente.
• La biblioteca S2 brinda la cobertura para cualquier forma dada fácilmente. Suponga que desea averiguar todos los suministros disponibles en un radio de 3 km de una ciudad. Usando las bibliotecas S2, puede dibujar un círculo de 3 km de radio y filtrará todas las celdas con ID que se encuentran en ese círculo en particular. De esta manera, puede hacer coincidir fácilmente al pasajero con el conductor y puede averiguar fácilmente la cantidad de automóviles (oferta) disponibles en una región en particular. 

3. ¿Servicio de suministro y cómo funciona?

• En nuestro caso los taxis son los servicios de abastecimiento y serán rastreados por geolocalización (latitud y longitud). Todos los taxis activos continúan enviando la ubicación al servidor una vez cada 4 segundos a través de un firewall de aplicación web y un balanceador de carga. La ubicación precisa del GPS se envía al centro de datos a través de las API Rest de Kafka una vez que pasa por el balanceador de carga. Aquí usamos Apache Kafka como centro de datos.
• Una vez que Kafka actualiza la última ubicación, pasa lentamente a través de la memoria principal de las notas de los trabajadores correspondientes.
• También se enviará una copia de la ubicación (máquina de estado/ubicación más reciente de los taxis) a la base de datos y a la optimización de despacho para mantener actualizada la ubicación más reciente.
• También necesitamos realizar un seguimiento de algunas cosas más, como la cantidad de asientos, la presencia de un asiento de automóvil para niños, el tipo de vehículo, si se puede colocar una silla de ruedas y la asignación (por ejemplo, un taxi puede tener cuatro asientos, pero dos de ellos están ocupados .) 

4. ¿Servicio de demanda y cómo funciona?

• El servicio Demand recibe la solicitud del taxi a través de un socket web y rastrea la ubicación GPS del usuario. También recibe diferentes tipos de requisitos, como la cantidad de asientos, el tipo de automóvil o el automóvil de la piscina.
• La demanda proporciona la ubicación (identificación de la celda) y los requisitos del usuario para suministrar y solicitar los taxis. 

5. ¿Cómo el sistema de despacho hace coincidir a los pasajeros con los conductores?

• Hemos discutido que DISCO divide el mapa en pequeñas celdas con una identificación única. Este ID se utiliza como clave de fragmentación en DISCO. Cuando el suministro recibe la solicitud de la demanda, la ubicación se actualiza utilizando la identificación de la celda como clave de partición. Las responsabilidades de estas diminutas células se dividirán en diferentes servidores que se encuentran en múltiples regiones (hashing consistente). Por ejemplo, podemos asignar la responsabilidad de 12 celdas diminutas a 6 servidores diferentes (2 celdas para cada servidor) en 6 regiones diferentes. 

• Supply envía la solicitud al servidor específico en función de los datos de ubicación del GPS. Después de eso, el sistema dibuja el círculo y filtra todos los taxis cercanos que cumplen con los requisitos del pasajero.
• Posteriormente, la lista del taxi se envía a ETA para calcular la distancia entre el conductor y el taxi, no geográficamente sino por el sistema de carreteras.
• Luego, la ETA clasificada se envía de vuelta al sistema de suministro para ofrecérsela a un conductor.

Si necesitamos manejar el tráfico de la ciudad recién agregada, entonces podemos aumentar la cantidad de servidores y asignar las responsabilidades de las identificaciones de celda de las ciudades recién agregadas a estos servidores.  

6. ¿Cómo escalar el sistema de despacho?

• El sistema de despacho (incluido el suministro, la demanda y el socket web) se basa en NodeJS . NodeJS es el marco asíncrono y basado en eventos que le permite enviar y recibir mensajes a través de WebSockets cuando lo desee.
• Uber usa un ringpop de código abierto para hacer que la aplicación sea cooperativa y escalable para tráfico pesado. Ring pop tiene principalmente tres partes y realiza la siguiente operación para escalar el sistema de despacho. 
  1. Mantiene el hashing coherente para asignar el trabajo entre los trabajadores. Ayuda a fragmentar la aplicación de una manera escalable y tolerante a fallas.
  2. Ringpop utiliza el protocolo RPC (llamada a procedimiento remoto) para realizar llamadas de un servidor a otro servidor.
  3. Ringpop también utiliza un protocolo de membresía SWIM/protocolo de chismes que permite a los trabajadores independientes descubrir las responsabilidades de los demás. De esta forma cada servidor/Node conoce la responsabilidad y el trabajo de otros Nodes.
  4. Ringpop detecta los Nodes recién agregados al clúster y el Node que se elimina del clúster. Distribuye las cargas uniformemente cuando se agrega o elimina un Node. 

7. ¿Cómo define Uber una región del mapa?

Antes de lanzar una nueva operación en una nueva área, Uber incorpora la nueva región a la pila de tecnología de mapas. En esta región del mapa, definimos varias subregiones etiquetadas con los grados A, B, AB y C. 

Grado A: Esta subregión es responsable de cubrir los centros urbanos y áreas de tránsito. Alrededor del 90 % del tráfico de Uber se cubre en esta subregión, por lo que es importante crear el mapa de la más alta calidad para la subregión A. 

Grado B: esta subregión cubre las áreas rurales y suburbanas que están menos pobladas y menos transitadas por los clientes de Uber. 

Grado AB: Unión de subregiones de grado A y B. 

Grado C: Abarca el conjunto de corredores viales que conectan varios Territorios Uber.  

8. ¿Cómo construye Uber el mapa?

Uber utiliza un proveedor de servicios de mapas de terceros para crear el mapa en su aplicación. Anteriormente, Uber estaba usando los servicios de Mapbox , pero luego Uber cambió a la API de Google Maps para rastrear la ubicación y calcular las ETA. 

1. Cobertura de seguimiento: la cobertura de seguimiento detecta los segmentos de carretera que faltan o la geometría de la carretera incorrecta. El cálculo de la cobertura de rastreo se basa en dos entradas: datos de mapas que se están probando y rastreos históricos de GPS de todos los viajes de Uber realizados durante un cierto período de tiempo. Cubre esos rastros de GPS en el mapa, comparándolos y combinándolos con segmentos de carretera. Si encontramos segmentos de carretera que faltan (no se muestra ninguna carretera) en los seguimientos de GPS, tomamos algunas medidas para solucionar la deficiencia. 

2. Precisión del punto de acceso preferido (recogida): Obtenemos el punto de recogida en nuestra aplicación cuando reservamos el taxi en Uber. Los puntos de recogida son una métrica realmente importante en Uber, especialmente para lugares grandes como aeropuertos, campus universitarios, estadios, fábricas o empresas. Calculamos la distancia entre la ubicación real y todos los puntos de recogida y entrega utilizados por los conductores. 

Luego se calcula la distancia más corta (punto de recogida más cercano) y establecemos el pin en esa ubicación como punto de acceso preferido en el mapa. Cuando un ciclista solicita la ubicación indicada por el pin del mapa, el mapa guía al conductor al punto de acceso preferido. El cálculo continúa con las últimas ubicaciones reales de recogida y entrega para garantizar la frescura y precisión de los puntos de acceso preferidos sugeridos. Uber utiliza el aprendizaje automático y diferentes algoritmos para determinar el punto de acceso preferido. 

9. ¿Cómo se calculan las ETA?

ETA es una métrica extremadamente importante en Uber porque afecta directamente la coincidencia de viajes y las ganancias. La ETA se calcula en función del sistema de carreteras (no geográficamente) y hay muchos factores involucrados en el cálculo de la ETA (como el tráfico pesado o la construcción de carreteras). Cuando un pasajero solicita un taxi desde una ubicación, la aplicación no solo identifica los taxis libres/inactivos, sino que también incluye los taxis que están a punto de terminar un viaje. Es posible que uno de los taxis que está a punto de terminar el viaje esté más cerca de la demanda que el taxi que está más lejos del usuario. Muchos súper autos en la carretera envían ubicaciones GPS cada 4 segundos, por lo que para predecir el tráfico podemos usar los datos de ubicación GPS de la aplicación del conductor. 

Podemos representar toda la red de carreteras en un gráfico para calcular las ETA. Podemos usar algoritmos simulados de IA o el algoritmo simple de Dijkstra para encontrar la mejor ruta en este gráfico. En ese gráfico, los Nodes representan intersecciones (taxis disponibles) y los bordes representan segmentos de carretera. Representamos la distancia del segmento de carretera o el tiempo de viaje a través del peso del borde. También representamos y modelamos algunos factores adicionales en nuestro gráfico, como calles de sentido único, costos de giro, restricciones de giro y límites de velocidad. 

Una vez que se decide la estructura de datos, podemos encontrar la mejor ruta utilizando el algoritmo de búsqueda de Dijkstra, que es uno de los mejores algoritmos de enrutamiento modernos en la actualidad. Para un rendimiento más rápido, también necesitamos usar OSRM (Máquina de enrutamiento de código abierto), que se basa en jerarquías de contracción . Los sistemas basados ​​en jerarquías de contracción tardan solo unos pocos milisegundos en calcular una ruta, al preprocesar el gráfico de enrutamiento.  

10. Bases de datos

Uber tuvo que considerar algunos de los requisitos de la base de datos para una mejor experiencia del cliente. Estos requisitos son… 

• La base de datos debe ser escalable horizontalmente. Puede agregar capacidad linealmente agregando más servidores.
• Debería poder manejar muchas lecturas y escrituras porque una vez cada 4 segundos, los taxis enviarán la ubicación del GPS y esa ubicación se actualizará en la base de datos.
• El sistema nunca debe dar tiempo de inactividad para ninguna operación. Debe estar altamente disponible sin importar la operación que realice (expandir el almacenamiento, realizar copias de seguridad, cuando se agregan nuevos Nodes, etc.).

Anteriormente, Uber estaba usando la base de datos RDBMS PostgreSQL, pero debido a problemas de escalabilidad, uber cambió a varias bases de datos. Uber utiliza una base de datos NoSQL (sin esquema) construida sobre la base de datos MySQL.  

• Redis tanto para el almacenamiento en caché como para la cola. Algunos están detrás de Twemproxy (proporciona escalabilidad de la capa de almacenamiento en caché). Algunos están detrás de un sistema de agrupamiento personalizado.
• Uber usa schemales (construido internamente sobre MySQL), Riak y Cassandra. Schemaless es para el almacenamiento de datos a largo plazo. Riak y Cassandra cumplen con las demandas de alta disponibilidad y baja latencia.
• Base de datos mysql.
• Uber está construyendo su propia tienda de columnas distribuidas que está orquestando un montón de instancias de MySQL.

11. Análisis

Para optimizar el sistema, minimizar el costo de la operación y mejorar la experiencia del cliente, Uber recopila y analiza registros. Uber utiliza diferentes herramientas y marcos para el análisis. Para el análisis de registros, Uber utiliza varios clústeres de Kafka. Kafka toma datos históricos junto con datos en tiempo real. Los datos se archivan en Hadoop antes de que caduquen de Kafka. Los datos también se indexan en una pila de búsqueda de Elastic para realizar búsquedas y visualizaciones. La búsqueda elástica realiza algunos análisis de registros mediante Kibana/Graphana. Algunos de los análisis realizados por Uber utilizando diferentes herramientas y marcos son… 

• Seguimiento de las API de HTTP
• Administrar perfil
• Recopile comentarios y calificaciones
• Promoción y cupones, etc.
• Detección de fraude
• Fraude de pago
• Abuso de incentivos por parte del conductor
• Cuentas comprometidas por hackers. Uber utiliza datos históricos del cliente y alguna técnica de aprendizaje automático para abordar este problema.

12. ¿Cómo manejar la falla del centro de datos?

La falla del centro de datos no ocurre muy a menudo, pero Uber aún mantiene un centro de datos de respaldo para realizar el viaje sin problemas. Este centro de datos incluye todos los componentes, pero Uber nunca copia los datos existentes en el centro de datos de respaldo. 

Entonces, ¿cómo aborda Uber la falla del centro de datos? 

En realidad, utiliza los teléfonos de los conductores como fuente de datos de viaje para abordar el problema de la falla del centro de datos. 
Cuando la aplicación del teléfono del conductor se comunica con el sistema de despacho o la llamada API se produce entre ellos, el sistema de despacho envía el resumen de estado cifrado (para realizar un seguimiento de la información/datos más recientes) a la aplicación del teléfono del conductor. Cada vez que la aplicación del teléfono del conductor reciba este resumen de estado. En caso de falla del centro de datos, el centro de datos de respaldo (DISCO de respaldo) no sabe nada sobre el viaje, por lo que solicitará el resumen de estado de la aplicación del teléfono del conductor y se actualizará con la información de resumen de estado recibida por el teléfono del conductor. aplicación 

Curso de diseño de sistemas GeeksforGeeks

¿Quiere conseguir un trabajo de desarrollador/ingeniero de software en una empresa de tecnología líder? o ¿Quiere hacer una transición sin problemas de SDE I a SDE II o perfiles de desarrollador sénior? En caso afirmativo, ¡entonces debe sumergirse profundamente en el mundo del diseño de sistemas! Un dominio decente sobre los conceptos de diseño de sistemas es muy esencial, especialmente para los profesionales que trabajan, para obtener una ventaja muy necesaria sobre los demás durante las entrevistas técnicas. 

Y es por eso que GeeksforGeeks le brinda un Diseño de sistemas en vivo centrado en una entrevista en profundidad que lo ayudará a prepararse para las preguntas relacionadas con Diseños de sistemas para Google, Amazon, Adobe, Uber y otras empresas basadas en productos.