El objetivo es crear una nueva startup altamente cargada en condiciones modernas. Consideraremos la creaci贸n de arquitectura utilizando el ejemplo de
Billingolang , un proyecto de facturaci贸n universal para fines generales escrito en golang. El proyecto incluye acceso a trav茅s de API, sitio web, integraci贸n en sistemas de contabilidad, informes y gr谩ficos.
Los sistemas de un solo hilo fueron inicialmente rechazados. Tuve que elegir entre Erlang, Golang y Rust. Se eligi贸 a Golang como el lenguaje de programaci贸n principal, porque es dif铆cil encontrar programadores de Erlang, aunque la estabilidad y el c贸digo de intercambio en caliente fueron una ventaja para Erlang. El 贸xido, a pesar de la falta formal de condiciones de carrera, es a煤n m谩s adecuado no para escribir aplicaciones, sino para conductores y sistemas operativos.
La mensajer铆a entre los componentes del sistema no se produce en el
RabbitMQ cl谩sico, sino en
NATS : este 煤ltimo mostr贸 puntos de referencia en el servidor que se est谩 utilizando actualmente, mensajes de 1M (+ 360K para la agrupaci贸n) por segundo frente a 40K para una liebre. S铆, y se agrupa m谩s r谩pido y m谩s f谩cil que RabbitMQ.
Base de datos:
MySQL InnoDB Cluster 7.6 (servidor MySQL 8.0). Hermosa herramienta de comunidad de depuraci贸n y dise帽o
MySQL Workbench .
API: escrito en
Swagger (OpenAPI 2.0). Esto evita errores de diferentes programadores, genera c贸digo limpio y bien documentado y documentaci贸n API. Desafortunadamente, Swagger usa
gorilla / mux para rootear de manera predeterminada , pero despu茅s de generar toda la API, la ra铆z se volver谩 a hacer para
kataras / muxie , es m谩s r谩pido.
Frontend: de los marcos disponibles: Iris, Beego y Revel - Revel est谩 seleccionado. M谩s lento que Iris, pero todo est谩 listo para usar, incluida la integraci贸n con gr谩ficos. La carga principal seguir谩 siendo soportada por la API.
Escalado: todos los componentes del sistema se ensamblan en contenedores LXC, mientras que delante de ellos se encuentra el equilibrador
HAProxy . La idea de escalar se reduce a, a medida que los clientes crecen, cambiar secuencialmente a servidores m谩s potentes mientras mantienen la estructura del contenedor, y luego distribuir los contenedores a servidores separados, reemplazando HAProxy con NATS. Adem谩s del escalado cl谩sico por hardware, siempre existe la posibilidad de aumentar el n煤mero de gorutinas dentro de los controladores de contenedores para solicitar la API y el sitio. Aunque este proceso, como lo ha demostrado la pr谩ctica, tiene limitaciones l贸gicas.
En general, la idea principal del art铆culo y mi profunda convicci贸n es que la arquitectura inicial de los proyectos de alta carga, en condiciones modernas, no tiene sentido construir en sistemas de un solo subproceso, a pesar de sus a帽os de infraestructura desarrollada y la presencia de una gran cantidad de programadores disponibles. Y todo el esquema del proyecto debe crearse inicialmente colocando una transferencia f谩cil a equipos m谩s potentes y distribuidos. Esto har谩 posible en el futuro encontrar f谩cilmente un equilibrio entre escalar hardware y c贸digo, sin multiplicar los costos.
Un error com煤n y m谩s com煤n cometido por las nuevas startups es un pobre desarrollo inicial de la arquitectura. De acuerdo con el principio: "comience a escribir r谩pidamente y luego lo resolveremos". Como regla general, como resultado, esto lleva al colapso del proyecto.
Como dicen: "el 90% del 茅xito es la preparaci贸n". No tengas miedo de gastar inicialmente en crear una arquitectura competente y reflexiva, valdr谩 la pena.
Buena suerte