1. Escriba algunas configuraciones que deben cambiarse en el archivo de propiedades
Por ejemplo, el número de subprocesos utilizados cuando alguna ejecución concurrente no está configurada para ser configurable en el archivo de propiedades. Luego, su programa puede ejecutarse sin problemas y sin obstáculos tanto en entornos de desarrollo como en entornos de prueba, pero una vez implementado en PROD y procesados conjuntos de datos más grandes como un programa de múltiples subprocesos, se lanzará una IOException. La razón puede ser que el entorno en línea está causando simultáneamente algo más. Si el número de subprocesos se puede configurar en el archivo Propiedades, es muy fácil convertirlo en una sola aplicación roscada. Ya no necesitamos implementar y probar aplicaciones repetidamente para resolver problemas. Este método también es adecuado para configurar URL, servidores y números de puerto.
Se recomienda usar archivos de atributos para externalizar estas configuraciones, y el formato de archivo está bien con Propiedades, Yaml, Hocon y JSON. La siguiente clase implementa el soporte de inyección de primavera para archivos en estos formatos, incluido el soporte de marcadores de posición.
https://github.com/superhj1987/awesome-libs/blob/master/src/main/java/me/rowkey/libs/spring/config/aweseSpropertyplaceplaceHolderConfiguer.Java
2. Simule el entorno en línea tanto como sea posible durante la prueba
Un escenario típico en el proceso de producción es usar solo 1 a 3 cuentas para las pruebas, y este número debe ser de 1,000 a 2,000. Al realizar pruebas de rendimiento, los datos utilizados deben ser verdaderos y sin cobrar. Las pruebas de rendimiento que no están cerca del entorno real pueden traer problemas de rendimiento, expansión y múltiples lectura impredecible. Aquí también podemos usar el entorno de prelanzamiento para resolver algunos problemas.
3. El procesamiento de fallas tolerantes a los fallas debe hacerse para todas las llamadas externas y servicios internos.
Ya sea que se trate de una llamada RPC o una llamada de servicio de terceros, no podemos dar por sentado que la disponibilidad es del 100%. Los tiempos de espera de llamadas de servicio y el reintento no están permitidos, lo que afectará negativamente la estabilidad y el rendimiento de la aplicación.
4. El sistema debe seguir el principio de los permisos mínimos al diseñar un sistema de seguridad
Los servicios web están en todas partes, lo que permite a los piratas informáticos explotarlo fácilmente para la negación de los ataques de servicio. Por lo tanto, al diseñar un sistema, debe seguir el principio de "permisos mínimos" y adoptar la lista blanca y otros métodos.
5. Se requieren los siguientes documentos
Escriba la documentación de la prueba unitaria y tenga una buena cobertura de código.
Dibujo de diseño de alto nivel: describe todos los componentes, interacciones y estructuras.
Dibujos de diseño detallados: específicos para el diseño de nivel de código y algunos procesos lógicos clave.
Documento de composición del sistema: explica todos los archivos de composición, archivos de configuración, etc. del sistema.
Los documentos DML y DDL a nivel de base de datos, especialmente las declaraciones de consulta SQL, deben pasar por DBA o la revisión de los desarrolladores principales antes de que puedan lanzarse.
No solo para los procesos de desarrollo tradicionales, sino incluso para el desarrollo ágil, estos documentos son esenciales, de lo contrario causará grandes inconvenientes en el mantenimiento y la entrega posteriores.
6. Haga un buen trabajo en el monitoreo, la recuperación de errores, la copia de seguridad y otras funciones clave del sistema
Para algunos módulos funcionales cruciales del sistema, deben ser monitoreados para evitar que afecten la operación del sistema y causen pérdidas no estimadas. Además, si es posible, intente recuperarse después de monitorear la falla y enviar una alarma si la recuperación falla. Para algunos archivos de datos muy importantes, se deben realizar copias de seguridad redundantes para evitar algunas fallas repentinas y pérdida de datos.
7. Diseñe algunas columnas que son fáciles de rastrear el historial y organizarse al diseñar la base de datos.
Por ejemplo, Create_Time y Update_Time pueden indicar la hora de creación y actualización del registro. create_by y update_by puede indicar quién creó y actualizó el registro.
Además, la eliminación de registros a veces no se elimina realmente. En este momento, es necesario diseñar una columna que represente el estado de este registro, como la columna 'Active' o 'Inactive' 'Status'.
8. Haga un plan de reversión del proyecto
Cuando se lanza la nueva función, si no hay un plan de reversión, puede tener prisa y hacer que los servicios en línea no estén disponibles por un período de tiempo. Existe un buen plan de reversión que le permite realizar operaciones relacionadas de manera ordenada y restaurar el sistema a un estado ejecutable dentro de un tiempo controlado.
9. Antes de que se lance el proyecto, se debe realizar un análisis cuantitativo
El análisis cuantitativo debe hacerse para la memoria, la base de datos, los archivos, el caché, etc. utilizados en el proyecto. Estima la ocupación espacial en el futuro y proporciona una referencia para la asignación de la máquina de operación y mantenimiento. Evite ese almacenamiento insuficiente es causado por el rápido crecimiento del volumen de datos. Esto es muy importante, de lo contrario, es fácil hacer que los servicios en línea no estén disponibles.
10. Desarrolle un plan de implementación del sistema.
La plataforma para la implementación del sistema es una parte crucial. La descripción de la plataforma de implementación no se puede limitar a una o dos bases de datos, al menos debe incluir
11. Elija la herramienta/tecnología más adecuada
En muchos casos, los desarrolladores usan un idioma o herramienta que desean aprender en un sistema de producción. Por lo general, esta no es la mejor opción. Por ejemplo, use una base de datos NoSQL para datos que ya sea de hecho una forma relacional. Ya sea un idioma o una herramienta, existen escenarios aplicables. No podemos buscar innovación, ni podemos usar "yo" como estándar.
12. Tener suficientes reservas de conocimiento en algunos campos técnicos clave.
Patrón de diseño
JVM Tuning "Problema de concurrencia" múltiple "Problema de concurrencia"
Problemas de transacción, incluidos los problemas de rendimiento de la transacción distribuida, incluidos GC, computación y otros cachés
A través de este artículo, espero que los amigos que puedan ayudar a desarrollar programas Java, ¡gracias por su apoyo a este sitio web!