|
|
Publicado en 25/9/2019 16:11:58
|
|
|
|
Tradicionalmente, un sistema que gestiona mil millones de transacciones al día podría requerir cientos de máquinas virtuales; PayPal lo hace todo con solo 8 máquinas virtuales y ofrece una respuesta rápida con un 90% de uso de CPU, una densidad de transacciones que PayPal nunca había logrado antes, y el proceso tarda una décima parte del tiempo en lograrlo, ayudando a la organización a mantener el ritmo del crecimiento sin tener que escalar su infraestructura informática mientras reduce costes. ¿Cómo se hace esto?
PayPal ha migrado su sistema al modo Actor basado en Akka. En el artículo Squbs: PayPal adopta un nuevo enfoque reactivo para crear aplicaciones (El inicio de sesión del hipervínculo es visible.PayPal explica los entresijos del proceso. Ahora han hecho Squbs de código abierto y lo han publicado en GitHub (El inicio de sesión del hipervínculo es visible.)。
Cuando un proyecto necesita un enfoque práctico, el modelo de servicio con estado sigue sin recibir suficiente atención. Para saber más sobre los servicios con estado, recomendamos leer las razones para seguir construyendo servicios escalables con estado ahora (El inicio de sesión del hipervínculo es visible.), este artículo se basa en un discurso de Caitie McCaffrey. Si este artículo no te convence, también está WhatsApp, que utiliza el competidor de Akka, Erlang, para un rendimiento extremadamente alto: la arquitectura WhatsApp de Facebook de 19.000 millones de dólares (El inicio de sesión del hipervínculo es visible.)。
La razón para recomendar el artículo anterior es que PayPal no ofrece una introducción detallada a la arquitectura, sino que dedica más tiempo a las razones por las que eligieron Akka y los beneficios de migrar a Akka. Pero este artículo sigue ofreciendo un valioso estímulo y demostración para la práctica de "salir del camino habitual".
¿Qué problema hay en usar un gran número de máquinas virtuales para un servicio?
- Ejecuta el servicio con máquinas virtuales extremadamente pequeñas y de muy bajo rendimiento. La mayor ventaja de los sistemas reactivos basados en actores es que pueden hacer un uso más eficiente de los recursos informáticos, lo que reduce considerablemente el tamaño del sistema y evita el autoescalado "simple y rudimentario" de las prácticas tradicionales.
- Supone mucha presión sobre tu red e infraestructura de enrutamiento. Como los servicios tienden a estar más interconectados, las peticiones pueden necesitar pasar por un gran número de saltos de red, lo que aumenta la latencia y degrada la experiencia del usuario.
- Cuanto más grande es, más caro es. Los servicios con cientos de máquinas virtuales tienen altos costes inherentes en términos de gestión, monitorización y caché ineficaz.
- Cuanto más pequeño es, más ágil es. Desplegar servicios en cientos de máquinas virtuales es un proceso que consume mucho tiempo.
- Saca más provecho de más CPU en cada máquina virtual. Dado que las CPUs no pueden acelerarse más, la infraestructura debe poder hacer un uso más eficiente de más CPUs en cada máquina virtual.
- Los microservicios deben construirse con nanoservicios débilmente acoplados, fáciles de mantener y rápidos de construir. Nadie quiere lidiar con un sistema complejo con muchas capas, y necesitas más visibilidad sobre el papel de los diferentes servicios sin tener que profundizar en capas de código.
Teniendo en cuenta estos factores, PayPal quiso crear un sistema que:
- Escalable, no solo para escalar horizontalmente a cientos de nodos, sino también para escalar a más procesadores y lograr el objetivo de procesar miles de millones de solicitudes al día.
- Baja latencia y se puede controlar con una granularidad extremadamente fina.
- Sé resiliente ante los fracasos.
- Ajuste flexible de los límites de servicio.
- Promover la escalabilidad y la simplicidad mediante modelos de programación y cultura, así como mecanismos de gestión de fallos y errores más sencillos.
No hay duda de que PayPal quiere usar una pila más "delgada", y no quieren que su pila contenga mucha tecnología y piezas móviles a diferentes niveles. En general, los sistemas Akka y basados en estados son adecuados para esta necesidad, lo que permite que la pila de grandes componentes se "descomponga" en una sola tecnología. PayPal eligió Akka en lugar de Erlang porque tienen más experiencia con Java, que funciona sobre Java. Para mucha gente, aprender Erlang desde cero no es realista.
Con Akka pueden:
- Escribe código que sea más fácil de explicar
- Escribe código que sea más fácil de probar
- Los escenarios de error y fallos se gestionan de forma más natural que los modos tradicionales que utilizan la JVM
- Escribe código más rápido, resistente y sencillo para manejar errores con mayor fluidez y reducir el número de errores
PayPal escribió inmediatamente su propio marco basado en Akka, que se llamaba Squbs, que se usaba para rimar con "Cubes". Esto permite crear una capa tecnológica modular para la construcción de un NanoService llamada "Cubo". Los cubos son simétricos, y las dependencias entre diferentes cubos también son simétricas y flexibles, exponiendo solo las interfaces de mensajes que Akka ya proporciona.
También describe las dificultades que pueden encontrar los programadores al adoptar código AKKA, ya que puede que necesites contratar a alguien formado en Akka/Scala.
Dado que la mayoría de los servicios tienen propósitos similares: recibir solicitudes, llamar y leer y escribir bases de datos, llamar a otros servicios, llamar a motores de reglas, obtener datos de cachés, escribir en cachés... Como resultado, los servicios pueden abstraerse mediante patrones como Orchestrator Pattern y Perpetual Stream.
Squbs se ha convertido en una práctica habitual para PayPal para crear aplicaciones reactivas basadas en Akka. Si tu equipo aún no ha considerado sistemas con estado, probablemente merezca la pena probarlo, ya que funciona bien en PayPal, Facebook, Uber y Microsoft.
|
Anterior:Tres factores que me hacen desestimar ChromePróximo:vs crea una carpeta, y al generar la solución, no hay nadie bajo el archivo bin
|
