Como sabes, Uber todavía está evolucionando, en realidad no se adhieren a un solo tipo de estructura. Muchas de las elecciones arquitectónicas que Uber ha hecho [en el pasado o lo hará en el futuro] son en realidad una consecuencia directa de crecer tan rápido y tratar de moverse lo más rápido posible. Es por eso que se ha utilizado mucha tecnología en el backend de Uber porque su objetivo principal es lograr que la velocidad de ingeniería sea lo más rápida posible.
Hasta donde yo sé [todo basado en Google], Uber está utilizando la Biblioteca de Geometría S2 de Google en este momento.
¿Qué es la biblioteca de geometría S2?
- ¿Cómo funciona un servidor HTTP y para qué se utiliza?
- ¿Cuánto gasta su startup tecnológica en costos de servidor (tráfico + almacenamiento) por mes?
- Servidores: ¿Cómo construyo un 'back-end'?
- ¿Cómo funciona una transacción de servidor a servidor entre dos bancos?
- Las reglas de presupuesto dicen que solo puedo comprar servidores locales y no servicio / almacenamiento en la nube, ¿qué servidor (es) debo solicitar? ¿Nuestras principales necesidades son el intercambio de archivos dentro de nuestro grupo de trabajo (~ 50 GB) y el almacenamiento de la base de datos (~ 100 GB, 1B de E / S por mes)?
La Biblioteca de Geometría S2 es una biblioteca de geometría esférica que es muy útil para manipular regiones en la esfera (comúnmente en la Tierra) e indexar datos geográficos. Es capaz de dividir una esfera en celdas, cada una con una ID. La Tierra es más o menos esférica, por lo que S2 puede representar cada centímetro cuadrado con un número entero de 64 bits.
¿Cómo Uber está haciendo uso de S2?
Tiene dos propiedades importantes para Uber. Es posible
– define la resolución de cada celda
– Encuentra las celdas que cubren un área determinada.
Como resultado, Uber utiliza celdas de 3,31 km2 para compartir sus datos. Todos estos nuevos datos permiten a Uber reducir los tiempos de espera, la conducción adicional por parte de los socios y los tiempos estimados generales de llegada (ETA).
Entonces, ¿qué sucede cuando un ciclista quiere usar Uber?
Uber utiliza la ubicación del conductor y la función de cobertura de área de S2 para buscar conductores que puedan combinarse con un conductor. Uber luego elige la ETA más corta, teniendo en cuenta no solo los conductores que están disponibles, sino también aquellos que estarán disponibles a tiempo para recoger al conductor.
Descripción general de la arquitectura de Uber:
El sistema de despacho está construido principalmente con NodeJS, lo que significa que tiene un solo subproceso. Uber quiere aprovechar todos los núcleos de una máquina, pero también necesita agregar nuevos nodos al sistema con facilidad. Uber está tratando todos los procesos de envío de la misma manera, ya sea que se ejecuten en la misma máquina o no. Han construido ringpop para manejar este problema.
Ringpop usa un anillo hash consistente, también utilizado por Amazon Dynamo, memcached o Riak, para distribuir el estado entre los nodos. Para administrar la membresía del clúster y la detección de fallas, ringpop utiliza SWIM, que significa Protocolo de membresía de grupo de proceso de estilo de infección débilmente consistente . Es el mismo protocolo de chismes que utiliza el Servidor de Hashicorp. Ringpop usa TChannel, también construido por Uber, como su protocolo RPC.
TChannel está inspirado en el protocolo RPC multiplex de Finagle, Mux, que fue construido por Twitter. Uber sintió la necesidad de crear su propio protocolo principalmente porque necesitaba soportar múltiples lenguajes (JavaScript y Python), rastreo y encapsulación.
La mayoría de las opciones arquitectónicas de Uber dependen de la disponibilidad y el rendimiento, ya que es fácil para los conductores y los conductores recurrir a la competencia. En Uber, todo tiene que ser reintentable, por lo tanto, idempotente y matable, incluidas sus bases de datos. Cada parte del sistema debe construirse asumiendo que la única forma de cerrar un proceso es bloquearse. Todas estas restricciones también favorecen los servicios pequeños, de modo que si alguno falla, la interrupción está contenida.
La proliferación de servicios pequeños y su distribución extrema pueden tener un impacto en el rendimiento: la latencia general de una solicitud es mayor o igual que la latencia del componente más lento.
¡Son realmente, muy, muy inteligentes!
Porque el enfoque de Uber ante la falla del centro de datos es ingenioso. No se replican datos en los centros de datos, ya que eso impone muchas restricciones en cuanto a disponibilidad y consistencia. Uber usa los teléfonos del conductor para distribuir los datos. Dado que los teléfonos del conductor publican actualizaciones de ubicación en el servidor cada cuatro segundos, el servidor responde periódicamente con un resumen de estado cifrado. Si un centro de datos falla, el controlador se comunicará con un nuevo centro de datos para publicar una actualización de ubicación. El nuevo centro de datos no sabe nada sobre este controlador en particular, por lo que solicita el resumen del estado y lo recoge desde allí.
Toda su lógica de negocios está escrita en Python. Uber está construyendo su propio almacén de datos distribuidos orientado a columnas, pero también usan Postgres, Redis, MySQL y Riak.
Fuente:
– s2-geometry-library – Una biblioteca para matemáticas esféricas – Google Project Hosting
– Desarrollador y socio certificado de SugarCRM
– Blog Rolustech
