Desde datos hasta aplicaciones de modelos grandes, el 25 de noviembre se celebró la Conferencia Hangzhou Yuanchuang para compartir consejos de desarrollo.

1. Antecedentes del proyecto

Por qué es necesaria una actualización de la arquitectura

El envejecimiento de la promesa consta de dos subsistemas: el sistema de cálculo del envejecimiento del núcleo (el núcleo del sistema es el cálculo del envejecimiento) y el sistema de envejecimiento de los componentes (el núcleo del sistema es el procesamiento empresarial complejo y la agregación de múltiples negocios antiguos, y realiza el flujo de proceso dorado). de órdenes de liquidación). Este último se basa en el primero, apoyado respectivamente por dos grupos de equipos técnicos; debido a la penetración de algunas empresas, la frontera entre los dos sistemas se ha vuelto cada vez más confusa; algunas necesidades requieren la participación total de dos grupos de Equipos de I+D desde la revisión del PRD hasta el lanzamiento del proyecto, lo que consume mucha mano de obra;
La lógica empresarial del cálculo del envejecimiento de la promesa se ha vuelto cada vez más compleja después de años de acumulación. Hay mucha lógica empresarial en el sistema de cálculo antiguo, lo que hace que el núcleo informático deba actualizarse con frecuencia para seguir la demanda;
El cálculo de la puntualidad se divide en cita y no cita, antes y después de realizar el pedido, puntualidad de la página de liquidación y puntualidad de la página de detalles comerciales. Hay puntos en común pero también diferencias, lo que da como resultado una gran cantidad de código redundante y repetido mientras se comparte una parte de los cálculos centrales, lo que requiere el mantenimiento y almacenamiento simultáneo de dos datos en caché para cálculos urgentes.
Varios servicios proporcionan interfaces dedicadas desde el sistema del núcleo, lo que provoca graves daños en el sistema.
Hay algunas dependencias que no utilizan el método RPC, por lo que los interruptores de cálculo de tiempo y dependencia del paquete jar deben configurarse en el sistema de tiempo en componentes, lo que afecta la eficiencia del desarrollo y la depuración conjunta.

En resumen, se decide que esta reconstrucción impulsada por la tecnología requiere actualizaciones de arquitectura para resolver los problemas existentes en el sistema.

Objetivos de refactorización

Los límites comerciales son más claros

El límite de la demanda después de la reconstrucción se puede determinar desde el lado del producto. Si es necesario modificar las nuevas reglas de cálculo de la puntualidad de la distribución del almacén o agregar un nuevo cálculo central, los requisitos de otras empresas se pueden modificar en la puntualidad del componente básico;

La lógica empresarial es más agregada

Integrar la lógica empresarial en la componenteización;

La lógica informática del kernel es más pura

Un conjunto de caché de cálculo urgente ahorra la mitad del costo de recursos de hardware;

Aumentar la reutilización del sistema. Un conjunto de modos de cálculo admite modos de reserva y no reserva, y admite liquidación y negociación, antes y después de realizar el pedido. Mantenga un conjunto de código lógico de cálculo central, separado de negocios específicos, ahorrando dinero. más recursos humanos;

2. Diseño del esquema

Revisión del negocio de computación kernel

Interfaces comerciales existentes:

Calendario de subida estándar: teniendo en cuenta el control de pedidos, la capacidad de producción, la prohibición de volumen, el calendario de subida estándar
Calendario Jingzunda: teniendo en cuenta el control de pedidos y la capacidad de producción, el Calendario Jingzunda está prohibido en grandes cantidades
Calendario de vehículos autónomos: Calendario de vehículos autónomos Recogida en almacén/Calendario de vehículos no tripulados
Calendario de autorecogida de almacén: Calendario de autorecogida de almacén, calendario de autorecogida de almacén/vehículos autónomos sin tomar líneas troncales
Calendario de autorecogida: obtenga la dirección de cuarto nivel del punto de autorecogida, considere el control de pedidos, la capacidad de producción y los estándares de prohibición de grandes cantidades para cumplir con el calendario.
Calendario Vxp: considerando control de pedidos, festivos, prohibición de granel, independientemente de la capacidad de producción, número máximo de días fijo y calendario estándar de días opcionales.
7Calendario nuevo: una vez completado el cálculo del calendario estándar, la ola del calendario se reemplaza por el calendario estándar de acuerdo con la ola de la tienda.
Calendario global de impuestos sobre compras: agregue el búfer de preparación de impuestos sobre compras globales y luego calcule el calendario estándar .
Calendario B2B: Cálculo del calendario B2B
Calendario de la Isla del Tesoro: Cálculo del Calendario de la Isla del Tesoro

De acuerdo con las características comerciales, los 8 tipos originales de interfaces de cálculo de puntualidad comercial se agregan en 3 interfaces informáticas generales centrales, eliminando las interfaces de procesamiento especiales de 5 tipos de negocios. Redefinir y diseñar nuevas interfaces informáticas centrales: puntualidad Jingzunda, puntualidad estándar y puntualidad de recogida en almacén. Reduce una gran cantidad de código duplicado, evita cambiar muchos lugares idénticos para cambiar un requisito y facilita la gestión unificada.

Los tres métodos de interfaz centrales del nuevo sistema central pueden proporcionar servicios para múltiples sistemas comerciales.

El negocio relacionado con la reconstrucción del sistema se muestra en la siguiente figura,

Principales cambios:

Agregación de interfaces centrales, adaptación del sistema de componentes y procesamiento complementario de información previa;
Antes de la reconstrucción, la llamada de la interfaz de control de pedidos y la lógica de capacidad de producción estaban dispersas en los sistemas base y antiguos en componentes. Después de la reconstrucción, la capacidad de producción proporciona una nueva interfaz, y el control de pedidos y la lógica de capacidad de producción se separan de la sistema central y centralizado en el sistema de envejecimiento en componentes;
La lógica empresarial, como productos a granel, almacenes secundarios, despacho de aduanas de compras globales y días festivos de VXP, se traslada al sistema en componentes, lo que reduce el tamaño del mensaje y la complejidad de la interfaz entre sistemas;

Negocio de reconstrucción de sistemas.

3. Implementación del proyecto

Clasificación de negocios basada en componentes

Considere la capacidad de producción
Considere las órdenes de control
Considere tomar líneas troncales
Determinar si es a granel
Se agregó tiempo de despacho de aduanas de compras globales más buffer
Agregar nueva lista blanca de capacidad
Marcado de lista blanca de capacidad agregada
Se agregó conversión de formato de onda de recogida automática.
Se agregó una nueva integración de información de parámetros de almacén secundario.
Nueva interfaz principal para el tipo de documento.
El subsidio al ahorro de energía aumenta el colchón de incumplimiento
Conversión por ola de 7 tiendas de productos frescos
Se agregó lógica de protección de posiciones largas de compra global.

Adapte nuevas interfaces en componentes antiguos y contrólelas con interruptores de volumen

4. Garantía de estabilidad

¿Cómo garantizar la seguridad y precisión de la reconstrucción del sistema? Hay dos formas principales de verificar la coherencia antes y después de la reconstrucción antes de conectarse: cobertura de prueba única y verificación de reproducción de tráfico; después de conectarse, control a través de interruptores de corte multidimensionales para garantizar la estabilidad del sistema.

Antes de conectarse

Cobertura de escenario de prueba única

Más de 1700 casos de prueba, que cubren la mayoría de los escenarios empresariales individuales y algunos escenarios empresariales combinados.

Verificación de reproducción de tráfico

Al desviar el tráfico en línea en tiempo real, se puede reproducir en el sistema reconstruido. Se descubrieron diferencias durante la reproducción del tráfico, se analizaron causas específicas y se descubrieron problemas de escenarios complejos no cubiertos por múltiples casos de prueba de refactorización.

Por ejemplo, escenarios en los que los productos de compras globales satisfacen la distribución de la ciudad y se convierten al límite de tiempo ordinario y adoptan un límite de tiempo al por mayor: la lógica normal es ① los productos de compra global cumplen con la lógica de distribución de la ciudad; ② la compra global no admite el límite de tiempo y las necesidades de distribución de la ciudad para convertirse al límite de tiempo ordinario; ③ después de cambiar al límite de tiempo ordinario Vuelva al escenario de las grandes empresas. Al refactorizar, pasamos de ① a ③. La puntualidad de la distribución urbana y la puntualidad masiva son mutuamente excluyentes, por lo que no se pueden convertir en puntualidad masiva. Después de ajustar la lógica de conversión, la puntualidad es inconsistente con la de antes de la refactorización. Este escenario implica una gran cantidad de configuración empresarial, que es muy difícil. A través de la cobertura de casos de prueba, la verificación de reproducción de tráfico es una buena solución de verificación.

Diferencias de comparación personalizadas de reproducción de tráfico

Debido a los ajustes de la arquitectura del sistema y las diferencias entre el diseño de la nueva interfaz y la arquitectura anterior, la fecha del calendario inicial devuelta en escenarios comerciales como adquisiciones, compras globales y control de pedidos es inconsistente. El calendario y la ola disponibles reales son consistentes, por lo que esto es lo esperado. Las diferencias dentro de los datos dan como resultado una tasa de diferenciación más alta durante la reproducción del tráfico, y los campos ignorados configurados en la página no pueden satisfacer nuestras necesidades;

Por primera vez, se utiliza un script personalizado para comparar diferencias, y las configuraciones de clasificación e ignorar elementos se personalizan para ignorar los objetos de diferencia que no afectan la puntualidad y reducen la interferencia de diferencias.

Confirmación del plan de negocios

Para aquellos que no pasaron la prueba y las diferencias en la reproducción del tráfico, la prueba de I + D creará una lista separada. Los equipos de I + D, pruebas y productos se comunicarán, revisarán el estado del sistema y el alcance del impacto comercial y determinarán la solución final.

Una vez que se verifican y reparan los problemas descubiertos durante la prueba y se confirma que se cumplen los requisitos comerciales y los estándares en línea, se puede iniciar la versión en escala de grises .

Después de conectarse

Cuando se lance la escala de grises, solo se accederá a una pequeña parte del tráfico, y los registros en línea y las alarmas de monitoreo se rastrearán y analizarán de manera oportuna, y los problemas se resolverán de manera oportuna siguiendo los comentarios de los usuarios. Cuando el nuevo sistema se estabilice, aumente gradualmente el alcance de la liberación en escala de grises y el tráfico de acceso, mientras continúa rastreando los registros en línea y monitoreando las alarmas.

Verificación de lista blanca

Utilice usuarios de la lista blanca para verificar después de conectarse.

Control de conmutación de flujo

Una vez que el sistema se conecta, admite el porcentaje del PIN del usuario para la medición y la verificación en escala de grises para lograr una transición sin problemas.

interruptor de componente

Los componentes lógicos nuevos y antiguos se pueden cambiar con un solo clic. Si se encuentran problemas, puede volver rápidamente a la lógica original para detener rápidamente las pérdidas y garantizar la seguridad del sistema en línea;

5. Valor del proyecto

Optimización del sistema

Como se esperaba en el proyecto, se implementó una interfaz informática del kernel nueva y puramente sensible al tiempo, y el sistema del kernel tiene una mayor reutilización;
Reorganice parte de la lógica en el sistema en componentes y agregue lógica empresarial flotante. La lógica del sistema es más agregada, lo que mejora la legibilidad y reduce los costos de mantenimiento del sistema;
Después de reducir los riesgos en línea y remodelar los límites comerciales, la lógica del sistema interactivo está más centralizada, lo que reduce las configuraciones interdependientes y facilita el control de los riesgos;
Al refactorizar, reparar casos de prueba y verificar el desvío, se descubrieron y corrigieron múltiples errores en línea para garantizar y mejorar la estabilidad del sistema;

◦El caso de prueba encontró 5 ERRORES y solucionó problemas como la falta de lógica empresarial perimetral y errores de lógica de procesamiento;

◦ Se encontraron 7 errores en la reproducción del tráfico y se corrigieron errores en línea como la marca 530 y el tipo de envejecimiento Beijing Zunda;

Se corrigieron más de 40 casos de prueba;

problemas actuales

La reconstrucción del sistema siempre deja una profunda impresión: no sólo se enfrentan a desafíos técnicos, sino que también hay que pensar qué solución es más razonable, sino que también se topan con una lógica empresarial que es difícil de resolver y hay que cambiar los productos, la investigación y el desarrollo y probar juntos. Recordar el pasado; también encontrará "errores" en la historia, lo que hace que la gente se pregunte si "corregir"; lleva mucho tiempo.

1. Durante la etapa de reproducción del tráfico, debido al cambio en el método de llenado de los datos de los parámetros de salida, es imposible comparar, lo que se puede solucionar personalizando el script.

2. No se puede admitir la nueva arquitectura de escenarios de múltiples almacenes con tiempo limitado de recogida automática. Colabore con productos y empresas para optimizar el método de procesamiento de escenarios de múltiples almacenes originales, que no solo resuelve el problema sino que también optimiza la lógica de procesamiento en línea .

resumen del proyecto

La refactorización favorece la solidez y la racionalización del proyecto. En la vida diaria, se debe desarrollar un buen hábito de refactorización, " caminar rápido en pequeños pasos " y tratar de evitar retener la idea de una refactorización uniforme. Acumular mucha deuda técnica costará mucha energía y tiempo, y los riesgos también serán mucho mayores. Si la tarea de refactorización es ardua, es necesario hacer un plan de iteración con anticipación. Al comienzo del diseño del plan de refactorización, es necesario considerar cómo implementarlo en etapas. La estrategia de separar capas en pequeños pasos es Equivale a construir andamios en la obra, que es una forma de controlar los riesgos.Medios eficaces dentro de un rango aceptable. Preste más atención al " valor del mañana ", cuando encuentre una buena estructura de datos, una buena idea o incluso un nombre de variable o nombre de método, reescriba el código escrito anteriormente;

Cuándo refactorizar es mejor seguir las " Tres reglas ". Si es necesario hacer algo una o dos veces, no tiene que preocuparse por la refactorización, pero si es necesario repetirlo tres veces o más, es hora de considerar la refactorización. para mantener el sistema limpio estado de salud.

El negocio de la empresa se está desarrollando rápidamente y durante la reconstrucción del sistema, es necesario continuar manteniendo la velocidad de iteración de las necesidades comerciales y aumentar el personal de manera adecuada.

Antes de la reconstrucción del sistema, debe estar familiarizado con el negocio (incluido el negocio de borde). Durante la reconstrucción, puede encontrar la misma situación que al mirar el código reconstruido. El orden de ejecución del código real afecta las dependencias o prioridades del negocio. y finalmente afecta la producción de resultados.Es difícil encontrar problemas en procesos comerciales complejos.

Después de conectarse, realice un seguimiento de los cambios reales en el rendimiento, el consumo de recursos y la estabilidad del sistema. Durante la reconstrucción, se descubrió que existe una lógica de procesamiento comercial similar en el sistema y que la lógica relacionada con la distribución urbana es demasiado compleja. En el siguiente paso, si se puede agilizar la comunicación con el negocio de productos, la reconstrucción no es el final, sino más como el punto de partida.

Autor: JD Logística Cui Haijun

Fuente: Comunidad de desarrolladores de JD Cloud Ziyuanqishuo Tech Indique la fuente al reimprimir

Implementación e implementación del plan de actualización de la arquitectura de puntualidad de la promesa | Equipo técnico de JD Logistics