Ha pasado meses rediseñando su monolito para convertirlo en microservicios y finalmente todos se han unido para activar el interruptor. Vas a la primera página web... y no pasa nada. Lo vuelves a cargar y nuevamente nada bueno, el sitio es tan lento que no responde durante varios minutos. ¿Qué pasó?
En su charla, Jimmy Bogard realizará una “autopsia” de un desastre de microservicios de la vida real. Mostrará los problemas de modelado, desarrollo y producción que descubrió, y cómo su equipo transformó lentamente el nuevo monolito distribuido en la imagen final de la cordura. Si bien es imposible evitar por completo los errores de diseño, al menos se pueden identificar los problemas en las primeras etapas del proceso de diseño para garantizar que el producto final se convierta en un sistema distribuido confiable.
Hola a todos, soy Jimmy y hoy escucharán cómo evitar megadesastres al crear microservicios. Esta es la historia de una empresa para la que trabajé durante aproximadamente un año y medio para ayudar a evitar que su barco chocara con un iceberg. Para contar esta historia correctamente, tendremos que retroceder en el tiempo y hablar sobre dónde comenzó esta empresa y cómo ha crecido su infraestructura de TI con el tiempo. Para proteger los nombres de los inocentes en este desastre, he cambiado el nombre de esta empresa a Bell Computers. La siguiente diapositiva muestra cómo era la infraestructura de TI de dichas empresas a mediados de los años 90. Esta es una arquitectura típica de un gran servidor HP Tandem Mainframe universal tolerante a fallos para operar una tienda de hardware informático.
Necesitaban crear un sistema para gestionar todos los pedidos, ventas, devoluciones, catálogos de productos y base de clientes, por lo que eligieron la solución mainframe más común en ese momento. Este sistema gigante contenía toda la información sobre la empresa, todo lo posible, y cada transacción se realizaba a través de esta computadora central. Mantuvieron todos sus huevos en una sola canasta y pensaron que eso era normal. Lo único que no se incluye aquí son los catálogos de pedidos por correo y la realización de pedidos por teléfono.
Con el tiempo, el sistema se hizo cada vez más grande y en él se acumuló una gran cantidad de basura. Además, COBOL no es el lenguaje más expresivo del mundo, por lo que el sistema terminó siendo una gran pieza monolítica de basura. En el año 2000, vieron que muchas empresas tenían sitios web a través de los cuales realizaban absolutamente todos sus negocios y decidieron crear su primer sitio web comercial puntocom.
El diseño inicial se veía bastante bien y consistía en un sitio de nivel superior bell.com y varios subdominios para aplicaciones individuales: catalog.bell.com, cuentas.bell.com, pedidos.bell.com, búsqueda de productos search.bell. com. Cada subdominio utilizó el marco ASP.Net 1.0 y sus propias bases de datos, y todos hablaron con el backend del sistema. Sin embargo, todas las órdenes continuaron procesándose y ejecutándose dentro de una única computadora central enorme, en la que permanecía toda la basura, pero la interfaz eran sitios web separados con aplicaciones individuales y bases de datos separadas.
Entonces, el diseño del sistema parecía ordenado y lógico, pero el sistema real era como se muestra en la siguiente diapositiva.
Todos los elementos abordaron llamadas entre sí, accedieron a API, dlls de terceros integrados y similares. A menudo sucedía que los sistemas de control de versiones tomaban el código de otra persona, lo metían dentro del proyecto y luego todo se estropeaba. MS SQL Server 2005 utilizó el concepto de servidores de enlace, y aunque no mostré las flechas en la diapositiva, cada una de las bases de datos también hablaba entre sí, porque no hay nada de malo en construir tablas basadas en datos obtenidos de varias bases de datos.
Dado que ahora tenían cierta separación entre diferentes áreas lógicas del sistema, esto se convirtió en manchas de suciedad distribuidas, y la pieza de basura más grande aún permanecía en el backend del mainframe.
Lo curioso fue que esta computadora central fue construida por competidores de Bell Computers y aún era mantenida por sus consultores técnicos. Convencida del insatisfactorio rendimiento de sus aplicaciones, la empresa decidió deshacerse de ellas y rediseñar el sistema.
La aplicación existente había estado en producción durante 15 años, lo que es un récord para las aplicaciones basadas en ASP.Net. El servicio aceptó pedidos de todo el mundo y los ingresos anuales de esta aplicación alcanzaron los mil millones de dólares. Una parte importante de las ganancias la generó el sitio web bell.com. El Black Friday, el número de pedidos realizados a través del sitio alcanzó varios millones. Sin embargo, la arquitectura existente no permitía ningún desarrollo, ya que las rígidas interconexiones de los elementos del sistema prácticamente no permitían realizar cambios en el servicio.
El problema más grave fue la imposibilidad de realizar un pedido desde un país, pagarlo en otro y enviarlo a un tercero, a pesar de que este esquema comercial es muy común en las empresas globales. El sitio web existente no permitía nada como esto, por lo que tuvieron que aceptar y realizar estos pedidos por teléfono. Esto llevó a la empresa a pensar cada vez más en cambiar la arquitectura, en particular en cambiar a microservicios.
Hicieron lo más inteligente al mirar a otras empresas para ver cómo habían resuelto un problema similar. Una de estas soluciones fue la arquitectura de servicios de Netflix, que consta de microservicios conectados mediante una API y una base de datos externa.
La dirección de Bell Computers decidió construir una arquitectura de este tipo, adhiriéndose a ciertos principios básicos. Primero, eliminaron la duplicación de datos mediante el uso de un enfoque de base de datos compartida. No se enviaba ningún dato, al contrario, todo aquel que lo necesitaba debía acudir a una fuente centralizada. A esto le siguió el aislamiento y la autonomía: cada servicio era independiente de los demás. Decidieron utilizar la API web para absolutamente todo: si deseaba obtener datos o realizar cambios en otro sistema, todo se hacía a través de la API web. La última gran novedad fue una nueva computadora central llamada "Bell on Bell", a diferencia de la computadora central "Bell" basada en el hardware de la competencia.
Entonces, en el transcurso de 18 meses, construyeron el sistema en torno a estos principios básicos y lo llevaron a preproducción. Al regresar al trabajo después del fin de semana, los desarrolladores se reunieron y activaron todos los servidores a los que estaba conectado el nuevo sistema. 18 meses de trabajo, cientos de desarrolladores, el hardware Bell más moderno... ¡y ningún resultado positivo! Esto ha decepcionado a mucha gente porque han ejecutado este sistema en sus portátiles muchas veces y todo iba bien.
Fueron inteligentes al invertir todo su dinero en resolver este problema. Instalaron los racks de servidores más modernos con conmutadores, utilizaron fibra óptica gigabit, el hardware de servidor más potente con una cantidad increíble de RAM, lo conectaron todo, lo configuraron y, de nuevo, ¡nada! Luego comenzaron a sospechar que el motivo podría ser los tiempos de espera, por lo que ingresaron en todas las configuraciones web, todas las configuraciones de API y actualizaron toda la configuración de tiempos de espera a los valores máximos, de modo que todo lo que podían hacer era sentarse y esperar a que sucediera algo. al sitio. Esperaron y esperaron y esperaron durante 9 minutos y medio hasta que finalmente se cargó el sitio web.
Después de eso, se dieron cuenta de que la situación actual necesitaba un análisis exhaustivo y nos invitaron. Lo primero que descubrimos fue que durante los 18 meses de desarrollo, no se creó ni un solo "micro" real: todo se hizo más grande. Después de esto, comenzamos a escribir una autopsia, también conocida como “regretrospectiva”, o “retrospectiva triste”, también conocida como “tormenta de culpas”, similar a una “lluvia de ideas”, para comprender la causa del desastre.
Teníamos varias pistas, una de las cuales era la saturación total del tráfico en el momento de la llamada a la API. Cuando utiliza una arquitectura de servicio monolítica, puede comprender inmediatamente qué salió mal exactamente porque tiene un seguimiento de pila único que informa todo lo que podría haber causado el error. En el caso de que varios servicios accedan simultáneamente a la misma API, no hay forma de rastrear el rastro excepto usar herramientas de monitoreo de red adicionales como WireShark, gracias a las cuales puede examinar una sola solicitud y descubrir qué sucedió durante su implementación. Así que tomamos una página web y pasamos casi dos semanas juntando las piezas del rompecabezas, haciendo una variedad de llamadas y analizando a qué conducía cada una de ellas.
Mira esta imagen. Muestra que una solicitud externa solicita al servicio que realice muchas llamadas internas que regresan. Resulta que cada llamada interna realiza saltos adicionales para poder atender esta solicitud de forma independiente, porque no puede acudir a ningún otro lugar para obtener la información necesaria. Esta imagen parece una cascada de llamadas sin sentido, ya que la solicitud externa llama a servicios adicionales, que a su vez llaman a otros servicios adicionales, y así sucesivamente, casi hasta el infinito.
El color verde en este diagrama muestra un semicírculo en el que los servicios se llaman entre sí: el servicio A llama al servicio B, el servicio B llama al servicio C y vuelve a llamar al servicio A. Como resultado, obtenemos un "punto muerto distribuido". Una sola solicitud creaba mil llamadas API de red y, dado que el sistema no tenía tolerancia a fallas ni protección de bucle integradas, la solicitud fallaría si fallaba incluso una de estas llamadas API.
Hicimos algunos cálculos. Cada llamada API tenía un SLA de no más de 150 ms y un tiempo de actividad del 99,9 %. Una solicitud provocó 200 llamadas diferentes y, en el mejor de los casos, la página se pudo mostrar en 200 x 150 ms = 30 segundos. Naturalmente, esto no fue bueno. Multiplicando el 99,9 % de tiempo de actividad por 200, obtuvimos un 0 % de disponibilidad. Resulta que esta arquitectura estuvo condenada al fracaso desde el principio.
Preguntamos a los desarrolladores cómo no pudieron reconocer este problema después de 18 meses de trabajo. Resultó que solo contaban el SLA del código que ejecutaban, pero si su servicio llamaba a otro servicio, no contaban ese tiempo en su SLA. Todo lo que se lanzó dentro de un proceso mantuvo el valor de 150 ms, pero el acceso a otros procesos de servicio aumentó muchas veces el retraso total. La primera lección aprendida fue: "¿Tiene usted el control de su SLA o el SLA tiene el control de usted?" En nuestro caso, fue lo último.
Lo siguiente que descubrimos fue que conocían el concepto de computación distribuida, formulado por Peter Deitch y James Gosling, pero ignoraron la primera parte. Afirma que las afirmaciones "la red es confiable", "latencia cero" y "rendimiento infinito" son conceptos erróneos. Otros conceptos erróneos incluyen las afirmaciones "la red es segura", "la topología nunca cambia", "siempre hay un solo administrador", "el costo de la transferencia de datos es cero" y "la red es homogénea".
Cometieron un error porque probaron su servicio en máquinas locales y nunca se conectaron a servicios externos. Al desarrollar localmente y utilizar un caché local, nunca encontraron saltos de red. En los 18 meses de desarrollo, nunca se preguntaron qué pasaría si los servicios externos se vieran afectados.
Si observa los límites del servicio en la imagen anterior, puede ver que todos son incorrectos. Hay muchas fuentes que aconsejan sobre cómo definir los límites de los servicios y la mayoría lo hace mal, como Microsoft en la siguiente diapositiva.
Esta imagen es del blog de MS sobre el tema "Cómo crear microservicios". Esto muestra una aplicación web simple, un bloque de lógica empresarial y una base de datos. La solicitud llega directamente, probablemente haya un servidor para la web, un servidor para el negocio y otro para la base de datos. Si aumenta el tráfico, la imagen cambiará un poco.
Aquí viene un balanceador de carga para distribuir el tráfico entre dos servidores web, un caché ubicado entre el servicio web y la lógica de negocios, y otro caché entre la lógica de negocios y la base de datos. Esta es exactamente la arquitectura que Bell utilizó para su aplicación de equilibrio de carga e implementación azul/verde a mediados de la década de 2000. Hasta algún tiempo todo funcionó bien, ya que este esquema estaba destinado a una estructura monolítica.
La siguiente imagen muestra cómo MS recomienda pasar de un monolito a microservicios, simplemente dividiendo cada uno de los servicios principales en microservicios separados. Fue durante la implementación de este plan que Bell cometió un error.
Dividieron todos sus servicios en diferentes niveles, cada uno de los cuales constaba de muchos servicios individuales. Por ejemplo, el servicio web incluía microservicios para la representación y autenticación de contenido, el servicio de lógica empresarial consistía en microservicios para procesar pedidos e información de cuentas, la base de datos estaba dividida en un grupo de microservicios con datos especializados. Tanto la web como la lógica empresarial y la base de datos eran servicios sin estado.
Sin embargo, esta imagen era completamente errónea porque no mapeaba ninguna unidad de negocio fuera del grupo de TI de la empresa. Este esquema no tenía en cuenta ninguna conexión con el mundo exterior, por lo que no estaba claro cómo, por ejemplo, obtener análisis comerciales de terceros. Observo que también inventaron varios servicios simplemente para desarrollar las carreras de empleados individuales que buscaban administrar a la mayor cantidad de personas posible para obtener más dinero por ello.
Creían que pasar a los microservicios era tan fácil como tomar su infraestructura interna de capa física de N niveles y colocar Docker en ella. Echemos un vistazo a cómo se ve la arquitectura tradicional de N niveles.
Consta de 4 niveles: el nivel de interfaz de usuario UI, el nivel de lógica empresarial, el nivel de acceso a datos y la base de datos. Más progresivo es DDD (Domain-Driven Design), o arquitectura orientada a software, donde los dos niveles intermedios son objetos de dominio y un repositorio.
Intenté observar diferentes áreas de cambio, diferentes áreas de responsabilidad en esta arquitectura. En una aplicación típica de N niveles, se clasifican diferentes áreas de cambio que impregnan la estructura verticalmente de arriba a abajo. Estos son el catálogo, los ajustes de configuración realizados en computadoras individuales y las comprobaciones de pago, que fueron manejadas por mi equipo.
La peculiaridad de este esquema es que los límites de estas áreas de cambio afectan no solo al nivel de la lógica empresarial, sino que también se extienden a la base de datos.
Veamos qué significa ser un servicio. Hay 6 propiedades características de una definición de servicio: es un software que:
- creado y utilizado por una organización específica;
- es responsable del contenido, procesamiento y/o provisión de cierto tipo de información dentro del sistema;
- se puede construir, implementar y ejecutar de forma independiente para satisfacer necesidades operativas específicas;
- se comunica con consumidores y otros servicios, proporcionando información basada en acuerdos o garantías contractuales;
- se protege a sí mismo del acceso no autorizado y a su información contra pérdidas;
- maneja las fallas de tal manera que no provoquen daños en la información.
Todas estas propiedades se pueden expresar en una palabra "autonomía". Los servicios funcionan independientemente unos de otros, cumplen ciertas restricciones y definen contratos sobre cuya base las personas pueden recibir la información que necesitan. No mencioné tecnologías específicas, cuyo uso es evidente.
Ahora veamos la definición de microservicios:
- un microservicio es de tamaño pequeño y está diseñado para resolver un problema específico;
- El microservicio es autónomo;
- Al crear una arquitectura de microservicios, se utiliza la metáfora del urbanismo. Esta es la definición del libro de Sam Newman, Building Microservices.
La definición de contexto acotado está tomada del libro Domain-Driven Design de Eric Evans. Este es un patrón central en DDD, un centro de diseño arquitectónico que trabaja con modelos arquitectónicos volumétricos, dividiéndolos en diferentes contextos delimitados y definiendo explícitamente las interacciones entre ellos.
En pocas palabras, un contexto acotado denota el alcance en el que se puede utilizar un módulo en particular. Dentro de este contexto hay un modelo lógicamente unificado que se puede ver, por ejemplo, en su ámbito empresarial. Si preguntas "quién es un cliente" al personal involucrado en los pedidos, obtendrás una definición, si preguntas a los involucrados en las ventas, obtendrás otra y los artistas te darán una tercera definición.
Entonces, Bounded Context dice que si no podemos dar una definición clara de lo que es un consumidor de nuestros servicios, definamos los límites dentro de los cuales podemos hablar sobre el significado de este término y luego definamos los puntos de transición entre estas diferentes definiciones. Es decir, si hablamos de un cliente desde el punto de vista de realizar pedidos, esto significa esto y aquello, y si desde el punto de vista de las ventas, esto significa esto y aquello.
La siguiente definición de microservicio es la encapsulación de cualquier tipo de operaciones internas, evitando la "fuga" de los componentes del proceso de trabajo al medio ambiente. Luego viene la “definición de contratos explícitos para interacciones externas o comunicaciones externas”, que está representada por la idea de contratos que regresan de los SLA. La última definición es la metáfora de una celda, o celda, que significa la encapsulación completa de un conjunto de operaciones dentro de un microservicio y la presencia en él de receptores para la comunicación con el mundo exterior.
Entonces les dijimos a los muchachos de Bell Computers: "No podemos solucionar el caos que han creado porque simplemente no tienen el dinero para hacerlo, pero arreglaremos un solo servicio para que todo funcione". sentido." En este punto, comenzaré contándoles cómo arreglamos nuestro único servicio para que respondiera a las solicitudes en menos de 9 minutos y medio.
22:30 min
Continuará muy pronto...
Algo de publicidad
Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendándonos a amigos, , un análogo único de servidores de nivel de entrada, que fue inventado por nosotros para usted: (disponible con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? Solo aqui ¡en los Paises Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $99! Leer acerca de
Fuente: habr.com