Grails, opción real y escalable para sitios web de alta carga
-
Upload
domingo-suarez-torres -
Category
Technology
-
view
2.516 -
download
0
Transcript of Grails, opción real y escalable para sitios web de alta carga
De cero a 1.7 M de usuarios
Grails, opción real para sitios web de alta carga y escalabilidad.Una experiencia al crear la más grande
plataforma de eCommerce con Grails en Latinoamérica.
Agenda
• Negocio
• Diseño inicial
• Infraestructura
• Problemas
• El futuro
NegocioUna tienda en linea, con una amplia
y creciente gama de servicios y productos
Negocio
• Ventas en grupo
• Cupones.
• Pero no solo cupones...
• Campañas de email masivas.
• Campañas de publicidad masivas.
Diseño inicialGrails, Terracotta, RabbitMQ & mySQL
Grails
• Grails 1.3.4
• GORM
• Servicios
• Controllers y TagLibs
• Jobs
GORM, lo bueno• Facilidad de crear modelos
• Modelos ricos
• Consultas
• Criteria
• DynamicFinders
• Actualización del esquema de base de datos
GORM, lo malo• No es posible probar DynamicFinder y Criteria de forma
unitaria
• Pruebas integrales, a veces toma mucho tiempo
• Es sencillo cometer errores debido a la facilidad
• Olvidar crear indices
• Iterar grandes colecciones
• Dejar que Grails nombre relaciones (tablas o campos)
Servicios, lo bueno
• Lógica de negocio
• Servicios que “escuchan” eventos
• Extensivo uso de Dependency Inyection
• Composición, agregación
• Reglas de negocio flexibles
Servicios, lo malo• Abusar de Dependency Inyection
• Referencias circulares
• No es tema de Grails exclusivamente, con Spring se presenta también.
• Duplicar nombres de Servicios, en diferentes paquetes
• Olvidar quitar la administración transaccional cuando no es necesaria.
Controllers, lo bueno
• Ridículamente simple
• Generar JSON/XML es trivial
• Reglas de mapeo, muy sencillo y flexible (URLMappings)
• Totalmente desacoplado de la vista
Controllers, lo malo
• Nada
TagLibs, lo bueno
• Estúpidamente simple crearlas :)
• Apoyo de Dependency Inyection para acceder a servicios, o a cualquier componente.
• Condicionar la generación de contenido
• Llenar plantillas (fragmentos de una página)
TagLibs, lo malo
• Usarlas como scriptlets
Grails, en general
• Permite que un desarrollador Java, explote su conocimiento.
• Aumenta la productividad debido a el uso de “Convención sobre Configuración”
• Incrementa brutalmente la facilidad de convertir requerimientos de negocio en código ejecutable
Grails
• En mi humilde opinión, la mejor opción para desarrollo web en Java, de cualquier tamaño o requerimiento
• Disclaimer: Es solo mi experiencia personal, no puedo garantizar el mal uso de Grails. También puedo equivocarme. Es mi punto de vista como desarrollador.
Negocio
• En Agosto de 2010 @dvd2k5 me dijo:
• Hey domix; en un año tendremos un millón de usuarios
• @domix
• :O
Escalabilidad y Disponibilidad
Vitales para estar en un negocio muy competitivo
Terracotta• Cache distribuido
• Evitamos accesos a la BD
• Guardamos Objetos Java y HTML
• Entidades de Hibernate
• Páginas completas
• Fragmentos de páginas
Terracotta
• Usamos EhCache como “fachada”
• En desarrollo no usamos Terracotta
• En producción y QA configurado
• El código aplicativo no se ve modificado
Terracotta• IMHO, es una de las mejores piezas de software
jamas escritas en Java
• Robusto, Estable
• Confiable, Ligero
• Casi cero administración
• Configuración muy sencilla
• Uptime de meses en producción
Terracotta
• Lo usamos para clusterizar sesiones HTTP, pero no quedo productivo
• No quería cargar con mas trabajo a Terracotta
• Evitar tener un solo punto de falla
• También lo usamos muy poco tiempo para clusterizar Jobs con Quartz
RabbitMQ• Servicio de mensajería
• Diferente a JMS
• Escrito en Erlang
• Muy robusto, estable
• Casi cero administración
• Desarrollado por vmWare
RabbitMQ
• Procesamiento asíncrono
• Procesos muy tardados
• Envío de email
• Consultas pesadas (reportes financieros)
• Integración con otras aplicaciones
RabbitMQ, lo malo
• No hay muchas herramientas de administración/monitoreo
• Las que hay son poco “amistosas”
• Cuando falla, falla muy duro
• Los logs de error son como Hebreo antiguo o mas bien como lenguaje Orco.
RabbitMQ, lo malo
• No hay muchas herramientas de administración/monitoreo
• Las que hay son poco “amistosas”
• Cuando falla, falla muy duro
• Los logs de error son como Hebreo antiguo o mas bien como lenguaje Orco.
RabbitMQ, nada malo• Antes he usado varios servicios de
mensajería
• Todos ellos basados en Java
• RabbitMQ ha sido al que he visto que se le ha puesto una carga muy grande, sin necesidad de afinar la configuración.
• IMHO. La mejor opción.
RabbitMQ, nada malo• Antes he usado varios servicios de
mensajería
• Todos ellos basados en Java
• RabbitMQ ha sido al que he visto que se le ha puesto una carga muy grande, sin necesidad de afinar la configuración.
• IMHO. La mejor opción.
mySQL
• ¿que puedo decir?
mySQL• Tenemos instalada una versión “tuneada” por
RackSpace
• Una palabra para describirla: Impresionante
• He vivido engañado por muchos años.
• Un pequeño comportandose como nunca he visto un grande.
• Nuestro mySQL ha soportado +15 millones de queries en un día
Infraestructura2 versiones
Cajas Versión 1• 2 WebServers
• 1 Tomcat 6 con AJP = cluster de 2 Tomcats
• Apache HTTPD con mod_proxy
• 1 DBServer
• 1 Firewall físico
• 1 LoadBalancer físico
• Rackspace Londres
Cajas Versión 2• 4 WebServers
• 2 Tomcat 6 con AJP = cluster de 8 Tomcats
• Apache HTTPD con mod_proxy
• 1 DBServer
• 1 Firewall físico
• 1 LoadBalancer físico
Fierros Versión 2• Dual Quad Core Xeon 2.26 HGZ
• 24 GB de RAM
• 300 GB SAS X 3
• RedHat Enterprise Linux 5.6
• En Hospedaje dedicado en Rackspace Chicago
Problemas
• Quartz Jobs clusterizados
• Ahora corren en una instancia propia
• Indices faltantes en la base de datos
• Consultas muy mal escritas
• Mala configuración del log
Solucionar problemas
• Necesitas métricas, indicadores
• Medición
• ¿Profiler?
• ¿JMX?
Competitividad
Datos de Alexa.com del día 21 de Octubre de 2011
¿Como lo logramos?
Negocio
• En Septiembre de 2011 @dvd2k5 me dijo:
• Hey domix; en un año tendremos 5 millones de usuarios
• @domix
• :O
Estrategia actual y futura
• Hacer la webapp actual lo mas estática posible
• Modularizar la aplicación en un conjunto de servicios
• Usar mensajería para comunicarlos
• Usar Scala como lenguaje complementario a Groovy
• Akka para procesamiento asíncrono
• MongoDB como almacén secundario
• Redis como cache recundario
Estrategia actual y futura
• Convirtiendo los servicios en un API Rest
• clickOnero móvil iOS este año
• clickOnero móvil Android próximo año
• Facebook App próximo año
• Apertura del API próximo año
El equipo
¿Preguntas?
Créditos fotos• http://flic.kr/p/e61Pt
• http://flic.kr/p/7cxoek
• http://flic.kr/p/5vSqgq
• http://flic.kr/p/6K9jb8
• http://flic.kr/p/6h8UoU
• http://flic.kr/p/24GsCj
• http://flic.kr/p/2wGvZi
• http://flic.kr/p/7jLN6x
• http://flic.kr/p/2VvzMw
• http://flic.kr/p/9c7z9T
• http://flic.kr/p/J1NKm