Análisis del código de aplicación

Puede ejecutar el analizador de código para analizar el código y crear una versión instrumentada del código fuente. Este análisis es el primer paso para refactorizar sus aplicaciones monolíticas Java® en particiones.

Analizador de código

El analizador de código recopila datos estáticos del código de aplicación de las aplicaciones monolíticas Java que se utilizan como entrada para el motor de IA, que genera recomendaciones de partición. Estos datos estáticos también son necesarios como entrada para el instrumenter binario, que recopila datos de tiempo de ejecución de las aplicaciones desplegadas. A medida que el analizador de código explora el código Java , genera cuatro archivos. Los archivos JSON contienen metadatos sobre las clases exploradas y la configuración para el instrumentador binario. Los metadatos incluyen información como nombres de clase, sus atributos de miembro especificados, constructores, métodos con argumentos de entrada y tipos de retorno y ubicaciones de archivo de origen de las clases.

El analizador de código también puede instrumentar el código fuente de las aplicaciones monolíticas de Java para que los rastreos de tiempo de ejecución se recopilen cuando se ejecuten estas aplicaciones. El analizador de código explora todas las clases Java de una aplicación para insertar sentencias de instrumentación en forma de System.err.println("Entering...") y System.err.println("Exiting...") en todos los métodos de clase, incluidos los constructores. Después de completar la instrumentación de código con el analizador de código, vuelva a crear y a desplegar la aplicación monolítica Java .

La instrumentación de código fuente es una característica en desuso del analizador de código. El instrumentador binario es la opción recomendada para la recopilación de rastreos de tiempo de ejecución mientras se ejecutan casos de uso de negocio, lo que elimina la necesidad de volver a crear y volver a desplegar la aplicación monolítica Java .

Requisitos previos

Asegúrese de cumplir los requisitos del sistema.

Procedimiento

  1. Coloque el archivo de archivado binario de la aplicación monolítica Java en una estructura de directorios.

    Los formatos de archivo de archivado Java válidos incluyen .cba, .class, .ear, .eba, .jary .war. También son válidos los archivos .rar y .zip que contienen los archivos binarios de archivado Java .

  2. Ejecute el analizador de código en el archivo binario de la aplicación.

    Ejecute el mandato analyze. Para obtener ayuda sobre el mandato, añada la opción -h .

    mono2micro analyze -a <binary-file-path>

    La siguiente información explica la sintaxis del mandato:

    • La variable <binary-file-path> es el nombre de vía de acceso para el archivo binario de la aplicación que se va a analizar. De forma predeterminada, el mandato analyze crea un directorio denominado binary-file-mono2micro en el directorio de trabajo del usuario con varios archivos JSON.

      Puede añadir la opción -o para especificar la vía de acceso del directorio de salida para los archivos JSON generados. El usuario que ejecuta el analizador de código debe tener acceso de lectura y escritura al directorio /<output-dir-path>/ .

      mono2micro analyze -a <binary-file-path> -o <output-dir-path>
    • Puede generar la configuración para el instrumentador binario que envía los rastreos a la corriente de salida estándar. De forma predeterminada, la instrumentación binaria instrumenta el código Java con sentencias System.err.println() para generar rastreos de tiempo de ejecución de IBM Mono2Micro en la corriente de errores estándar. El establecimiento de la opción --instrumentation-target en el valor out también se aplica a la instrumentación de origen si se ha utilizado el mandato mono2micro instrument .

Ejemplos de rutas de salida estándar y de error estándar

Para la ruta de errores estándar, ejecute el mandato siguiente:

mono2micro analyze -a /apps/daytrader-ee7.ear

Para la ruta de salida estándar, ejecute el mandato siguiente:

mono2micro analyze -a /apps/daytrader-ee7.ear --instrumentation-target out

Control de la lista de paquetes Java para el análisis binario

El analizador binario inspecciona todas las clases Java dentro del archivo binario excepto los paquetes excluidos de forma predeterminada. Puede comprobar la lista predeterminada de paquetes excluidos con la opción -h .

Las opciones siguientes se utilizan exclusivamente para controlar los paquetes Java que se van a analizar con el analizador binario. Ninguna de las opciones persiste porque el analizador no guarda ninguna lista o preferencia de usuario. Por lo tanto, debe especificar las opciones deseadas para cada ejecución. Para las opciones, especifique una lista separada por comas sin espacios vacíos, por ejemplo:
com.test.app,org.xyz.lib,edu.abc
--add-to-exclude-packages
Añade paquetes a la lista predeterminada de paquetes que se van a excluir. El análisis binario excluye los paquetes de lista predeterminados y también excluye la lista de paquetes especificados por esta opción.
--exclude-packages
Excluye la lista de paquetes especificados por esta opción del análisis binario. Se analizan todas las clases excepto las de estos paquetes especificadas por el usuario, lo que significa que se ignora la lista de paquetes predeterminada.
--include-packages
Analiza sólo la lista de paquetes especificados por esta opción durante el análisis binario. Puesto que sólo se analizan las clases de estos paquetes, se ignora la lista de paquetes predeterminada.
--analyze-all
Fuerza el análisis de todas las clases y paquetes.

Resultados

Al finalizar correctamente el análisis, si no se especifica un directorio de salida, el analizador de código crea un directorio llamado binary-file-mono2micro en el directorio de trabajo del usuario con varios archivos, donde binary-file es el nombre del archivo binario Java analizado. Por ejemplo, si el archivo binario es daytrader-ee7.ear, el analizador de código crea un directorio con el nombre daytrader-ee7-mono2micro en el directorio de trabajo del usuario. Si se especifica la opción de salida, los archivos JSON se colocan en el directorio proporcionado.

Después del análisis, el directorio contiene los archivos siguientes:

  • symTable.json
  • refTable.json
  • instrumenter-config.json
  • recommender-config.properties

Los archivos symTable.json y refTable.json contienen metadatos sobre clases exploradas, como sus nombres, ubicaciones, nombres de atributos, constructores y métodos. El archivo instrumenter-config.json proporciona configuración para el instrumenter binario. El archivo recommender-config.properties especifica la ubicación del archivador de aplicación Java en el disco y los paquetes que se han excluido o incluido durante el análisis.

Si la instrumentación de origen se ha habilitado en el analizador de código, el directorio de igual también contiene una copia del código fuente que se instrumenta con sentencias System.err.println() que se utilizan posteriormente para generar rastreos de tiempo de ejecución de IBM Mono2Micro .

La instrumentación del analizador de código nunca imprime el valor de ninguna variable de la aplicación. El propósito de la instrumentación es registrar los flujos temporales a través de varios métodos y constructores de clases, y no los valores de ninguna variable durante el tiempo de ejecución.

Limitaciones actuales

  • Al compilar el código instrumentado por el analizador de código, es posible que se encuentre con elunreachable codeerror de compilación. En algunos casos periféricos, la instrumentación del analizador de código puede insertar sentencias de instrumentación, que el compilador Java detecta como inalcanzables.

    Para superar el problema, elimine o comente estas sentencias inalcanzables. Su eliminación no afecta a la generación de rastreos en tiempo de ejecución de ninguna manera.

  • Al ejecutar el analizador de código, es posible que se encuentre con un error de falta de memoria del proceso Java . Para resolver el problema, establezca la variable de entorno --java-opts especificando un tamaño de almacenamiento dinámico máximo grande como valor.

    Por ejemplo, para especificar un tamaño máximo de almacenamiento dinámico Java de 512 megabytes, ejecute uno de los mandatos siguientes.

    mono2micro analyze -s <src-dir-path>  --java-opts "-Xmx512m"
    mono2micro instrument -s <src-dir-path>  --java-opts "-Xmx512m"
  • Cuando el analizador binario encuentra más de una clase Java con el mismo nombre y el mismo nombre de paquete, analiza la primera identificada e ignora las demás con el mismo nombre y el mismo nombre de paquete. Se pueden producir nombres duplicados si la misma clase está empaquetada en varios archivos binarios dentro del archivador binario. En este caso, se registra un aviso para informar de los duplicados encontrados. En la mayoría de los casos, esto no es un problema, especialmente si las clases encontradas son idénticas. Sin embargo, puede ser un problema si las clases encontradas tienen diferencias en su estructura.

Qué hacer a continuación

Si desea obtener recomendaciones de particionamiento basadas en la lógica empresarial de la aplicación, ejecute las aplicaciones monolíticas Java con instrumentación para generar archivos de rastreo de tiempo de ejecución. Si, por el contrario, desea obtener recomendaciones más rápidamente, basadas únicamente en el análisis estático de su aplicación, compruebe los datos recopilados y, a continuación, ejecute el motor de IA. Se utiliza la información del analizador de código y, opcionalmente, del instrumentador binario y del registrador de casos de uso, como entrada para el motor de IA, que genera recomendaciones de partición. Es importante mantener el archivo de archivado de aplicación Java en la misma ubicación en el disco para que el motor de IA pueda analizarlo más a fondo durante el paso de recomendación de partición.

Si elige recopilar archivos de rastreo de tiempo de ejecución a través de la instrumentación de origen, después de que el analizador de código complete correctamente el proceso de instrumentación, puede crear y desplegar la aplicación instrumentada en entornos no de producción pero representativos. Siga el proceso exacto que utiliza para crear y desplegar la aplicación original. En función de los entornos, las aplicaciones y sus versiones instrumentadas pueden estar en máquinas bare metal, máquinas virtuales o contenedores.