Parchear código Java en producción sin anestesia

Aquí hablaré sobre el dispositivo de una de las muchas herramientas que ayudan en el desarrollo de varios servicios para el proyecto Odnoklassniki. Dentro de la empresa, lo llamamos "Reemplazo de código activo" (HCR), y esta herramienta está diseñada para corregir errores críticos y sin complicaciones al ejecutar servicios de producción sin detenerlos. Esta es una característica extremadamente importante, ya que le permite evitar el proceso bastante aburrido y lento de diseñar una nueva versión corregida del servicio basura, para evitar la pausa suficiente de la operadora en la disponibilidad de cada host y evitar el vaciado de cachés.

En general, ahorra mucho tiempo y reduce el intervalo desde el momento en que se detecta el error hasta la corrección de horas a minutos. En la mayoría de los casos, como se planeó, se corrigen errores menores en el código, por ejemplo, el programador olvidó verificar si es nulo y para algunos usuarios ciertas acciones en el sitio conducen a un error. Es decir, cuando la corrección se lleva a cabo cambiando varias líneas dentro del método. Y en aras de tales cambios menores, ya no necesita distraer a sus colegas y esperar horas disponibles para la producción.

Por ejemplo:


Puedes arreglarlo fácilmente en:


Por supuesto, puede hacer muchos más cambios, al mismo tiempo agregar nuevas clases, hacer rápidamente los cambios que el administrador solicita al mismo tiempo, sin esperar la próxima actualización. Pero esto ya es así, si Monsieur sabe mucho sobre perversiones.

Además, es posible poner "parches" entre sí y hasta el infinito.

Pero esta herramienta no es omnipotente y se basa en la funcionalidad estándar que ofrece la clase Java: java.lang.instrument.Instrumentation y su método void redefineClasses (ClassDefinition ... definiciones) .

Instrumentation.redefineClasses reemplaza las clases cargadas previamente con un nuevo código de bytes. Puede sobrecargar varias clases con diferentes dependencias al mismo tiempo. La sobrecarga no cambia las instancias de clase existentes, no cambia la herencia y no toca los campos de instancia o clase. Solo puede cambiar el cuerpo del método, el conjunto de constantes y atributos. Puede agregar nuevas clases o subclases. Las firmas de métodos, los campos de instancia y los campos de clase no se pueden cambiar. Si intenta realizar cambios incompatibles, redefineClasses en principio no funcionará y arrojará un error. Debe recordarse que cuando las clases se sobrecargan, la ejecución de la sección de código sobrecargada no se interrumpe, el nuevo bytecode se usará la próxima vez que se llame al mismo método. Y, por lo tanto, si intenta corregir el código de un método que tiene un ciclo infinitamente largo en su interior, el reemplazo real ocurrirá solo después de que termine este ciclo.

Si simplemente: puede cambiar el código solo dentro de los métodos y el punto.

Y aquí hay un ejemplo de un ciclo while, que hasta que se complete el método, no se solucionará.



La principal dificultad fue hacer una herramienta que funcione en el ecosistema Odnoklassniki, una herramienta que se ajuste a todos los procesos de trabajo establecidos. Que interactuará de manera consistente y transparente con todos los servicios en cientos de hosts, además de ser flexible y fácil de usar. Esta herramienta debería hacer frente a docenas de experimentos, trabajos y actualizaciones que ocurren continuamente en la producción.

¿Cómo se ve el proceso de instalación de un parche desde el punto de vista del desarrollador / administrador que trata de corregir un error en la producción, pero para que pueda hacerse usando algún procedimiento estándar y confiable en docenas de servidores? Omitimos el proceso de encontrar y corregir errores en el código.

1. Se crea un brunch por separado en GIT para las correcciones de código. El uso de versiones es muy importante no solo por conveniencia, sino también para posibles investigaciones posteriores.

2. TeamCity lanza el proceso de compilación del parche. Primero, se crea un ensamblaje de proyecto a partir del brunch especificado, y luego se compara el nuevo ensamblaje con el instalado en la producción. Para hacer esto, escribí un complemento para la herramienta de compilación, que extrae todos los archivos de los archivos, compara las discrepancias y selecciona solo aquellos archivos que han cambiado o agregado. En este caso, la versión del compilador de Java en ambos ensamblados debería ser la misma, porque otra versión del compilador creará diferentes archivos y casi todos los archivos del proyecto se incluirán en el parche. Es muy importante crear solo un pequeño archivo, en el que solo se obtendrán los archivos necesarios, porque Esto acelerará significativamente el proceso de entrega del parche a docenas de servidores. El proceso de compilación es adecuado no solo para el parche del código del proyecto, sino que también puede reemplazar la biblioteca parcheada en el proyecto. Al comparar el contenido de dos ensamblajes, se encontrarán diferencias en las bibliotecas (archivos jar).

3. En caso de un ensamblaje exitoso, el parche se envía a un repositorio especial, y en la ventana de resultados se emite una clave (o hash), que es necesaria para identificar de forma única el parche y garantizar que este código llegue a la producción.



Bueno, y de nuevo: puede parchear un número ilimitado de veces y las compilaciones con el mismo número de versión diferirán en un hash.

4. Luego, toda la actividad se transfiere al servicio de configuración, donde en la IU habitual puede especificar para qué servicio, en qué hosts y qué versiones de aplicaciones necesita parchear.



Tal abundancia de parámetros proporciona el nivel necesario de flexibilidad de configuración, que es muy importante en un gran zoológico desde muchos servidores. Digamos que en alguna parte de los servidores el número de versión de la aplicación es diferente y no necesita parchear este código en absoluto. O, para la verificación, Hot Code Rreplace se inicia primero en un servidor o en un grupo de servidores, y luego se distribuye en todas las instancias de la aplicación.

5. A través de un cambio de configuración, los servicios seleccionados reciben información sobre lo que necesita instalar el parche, su versión y el hash de verificación. La idea es que todos los servicios reciban el comando "instalar el parche" y luego actuar de forma independiente. Comparan independientemente su propia versión y solo si la versión coincide y falta el hash del parche o es diferente, descargan independientemente el ensamblaje del parche desde el repositorio. El proceso de descarga en sí se realiza a través de HTTP, y puede cambiar rápidamente la dirección del repositorio, el número de intentos de descarga y el período de espera entre reintentos.

6. Cada aplicación comprueba localmente el hash del ensamblado y lo desempaqueta. En este caso, se comprueba la presencia de cada archivo en la matriz entre los devueltos por Instrumentation.getAllLoadedClasses (), todas las clases y archivos nuevos se escriben en uno nuevo: una ruta de clase temporal, y esta ruta de clase se agrega a través de Instrumentation.appendToSystemClassLoaderSearch (), y las clases existentes se leen en la memoria y pasar por el método redefineClasses.

7. Todo el proceso: la llegada de una señal sobre la necesidad de parchear la aplicación, su descarga, verificación, desempaquetado y aplicación se registra en detalle, tanto en el registro general con la aplicación como en el propio, para que pueda monitorear el proceso rápidamente y sin gestos innecesarios.

8. Después de que el parche se aplica con éxito, el proceso finaliza cambiando la versión de la aplicación a la parcheada agregando una línea especialmente compuesta que incluye el hash del parche. En el caso de que para algún host la versión no haya cambiado a la esperada, vamos al registro de Reemplazo de código activo para ese host y veremos qué sucedió allí. Si se tratara de problemas de comunicación, puede repetir con seguridad el comando de revisión y el host deseado lo intentará nuevamente.

¿Qué posibles problemas pueden evitar que la aplicación parchee? Hay bastantes de ellos, y entre ellos la funcionalidad de la clase Instrumentation que pondría en último lugar. Hasta ahora, el código torcido que no cumple con las estrictas condiciones de redefineClasses siempre ha sido actualizado por la JVM sin ninguna consecuencia para la aplicación. Al aplicar el método redefineClasses, la JVM detiene completamente la aplicación, pero este proceso lleva una fracción de segundo. Porque no da nada de miedo.

El momento más arriesgado es la entrega del parche al servidor, que se decidió mediante reentrenamientos adicionales. Pero si las retransmisiones no ayudan, puede repetir el comando para llamar al parche y cada uno de los hosts intentará repetir el proceso, pero instale el parche solo si es necesario, es decir. el parche no se ha instalado previamente o si la clave hash ha cambiado.

Otro problema potencial es cuando la solución corrige un error y agrega uno nuevo. Para minimizar este riesgo, primero cargamos el parche en un número limitado de servidores, miramos los registros, gráficos y monitoreamos el resultado. Y solo entonces implementamos correcciones a otros hosts.

¿Qué hacer al reiniciar una aplicación o servidor? Esto ya está incrustado en la lógica de todas las aplicaciones classmate: una de las primeras en cualquier aplicación es el módulo HCR. Y si durante la inicialización se nota información sobre la necesidad de parchear la aplicación, primero se aplicará el parche.

Y ahora un poco sobre en qué consiste Hot Code Replace.

1. Nuestro JavaAgent. JavaAgent, si alguien lo ha olvidado , este es un archivo * .jar separado, especialmente formado, que JVM recoge cuando la aplicación comienza a usar un parámetro adicional, por ejemplo: -javaagent: /path/to/lib/my-agent.jar Gracias a las características adicionales de Javaagent- y es posible usar magia de reemplazo de código. Es en el agente donde está disponible la clase java.lang.instrument.Instrumentation. Pero, no lo obstruí (el agente) con código extra, porque La actualización del agente es una tarea no trivial, pero simplemente movió la instancia de la clase Instrumentation al campo estático de la clase de utilidad. Por lo tanto, todas las manipulaciones pueden iniciarse desde cualquier lugar de la aplicación.
2. Servicio de configuración: es responsable de la configuración de cualquiera de nuestras aplicaciones y, por lo tanto, se inicializa primero en cada aplicación. Es allí donde se oculta la funcionalidad principal de Hot Code Replace. Al iniciar la aplicación o al cambiar la configuración de HCR para una aplicación en particular, se verifica la compatibilidad de la versión y se realizan todas las manipulaciones anteriores.
3. TeamCity y scripts de creación: para crear convenientemente "parches" y guardar solo clases y recursos modificados o agregados en ellos.

¿Cuáles son las ventajas que tenemos de esta herramienta? El primero es la velocidad de corregir errores críticos en el producto. Desde los registros, veo que los colegas gradualmente comenzaron a usar HCR cada vez más a menudo, en lugar de esperar a que se publicaran. Lo siguiente es la velocidad de aplicación. No es necesario detener la aplicación, la JVM solo se congela por una fracción de segundo y todos sus objetos permanecen en sus lugares y continúan funcionando.

Y nuestros desarrolladores se curaron libre y felizmente y corrigieron sus errores de forma inmediata e independiente directamente en producción sin tener en cuenta la cantidad de servidores y la carga.