Las siguientes guías son todas las personas que han pisado o aprendido sobre los pozos que los colegas que me rodean han pisado. Espero proporcionar algo de iluminación y ayuda para aquellos que están a punto de ingresar al pago financiero y de comercio electrónico y otras industrias relacionadas, y aquellos que acaban de ingresar a la industria aduanera. !
1. El sistema financiero usa bigdecimal para procesar la cantidad y especifica el lugar decimal
Para aquellos con experiencia relacionada con las finanzas, sabrán que cuando se trata de cantidades, trate de no usar double o float porque se perderá la precisión, lo que puede causar errores de cálculo. Debe usar bigdecimal, pero esto aún no le impide pisar el hoyo, porque está demasiado yang demasiado simple!
De hecho, el uso indebido de bigdecimal sigue siendo la pérdida de precisión (¡no des un ejemplo de búsqueda online, mucho!), Aquí quiero decirte cómo lidiar con ello: ¡" designar decimales " !, ¡espero que no vuelvas a pisarlo!
2. Confirme la unidad de cantidad repetidamente para el campo de cantidad de la interfaz
Siempre hay algunas personas a las que no les gusta usar su cerebro, jaja, después de obtener la interfaz (como la interfaz de pago), ni siquiera lo piensan, por lo que pasan la cantidad al campo de cantidad de la interfaz. No saben que están pidiendo pasar el yuan, usted da ¡Son puntos! ! ! Pusiste 500 puntos en la interfaz y las tres partes pagaron 500 yuanes. El usuario pensó (muy feliz ...)
Así que te advierto que cuando veas una interfaz con una cantidad, ¡debes confirmar la unidad de la cantidad (incluida la cantidad devuelta)!
3. Para el estado de la interfaz de transacción, es necesario confirmar repetidamente el estado de la transacción de qué código de campo
Por ejemplo, el siguiente mensaje de retorno de interfaz de tres partes
{ "éxito": verdadero, "resultado": { "estado": "0", "amt": "100,00" ..... } }
estado = 0 significa fracaso empresarial
Si la persona que conecta la interfaz no confirma bajo qué circunstancias el servicio de código es exitoso, piensa que éxito = verdadero como éxito y devuelve el mensaje anterior como una falla del servicio, lo que eventualmente puede conducir a una pérdida de capital.
La devolución anterior, después de confirmar con el proveedor de la interfaz, el campo de éxito solo representa el estado de comunicación de esta solicitud, no el estado de la empresa. Si esta solicitud es una solicitud de deducción por la compra de un producto, piénselo, el dinero no ha sido deducido Para el usuario, ¡el producto puede haber sido enviado! ! !
4. Para la interfaz que devolverá el monto de la transacción, asegúrese de confirmar si la transacción será parcialmente exitosa
En algunos escenarios comerciales, habrá casos en los que el monto de la solicitud no coincida con el monto confirmado (puede ser parcialmente exitoso). En este momento, si llamamos a la interfaz de tres (dos) partes, no prestamos atención al monto devuelto por la interfaz y usamos directamente la interfaz para que el estado de la transacción sea exitoso. Para determinar el procesamiento posterior, es fácil causar una pérdida de capital.
Si se confirma que la interfaz de la transacción no será parcialmente exitosa, pero la interfaz devuelve el campo de monto, podemos verificar el monto de la solicitud nuevamente después de que la lógica comercial confirme que el estado del negocio es exitoso y si es consistente con el monto confirmado para garantizar que la transacción sea completamente exitosa.
5. ¡La interfaz de transacciones debe ser idempotente!
¡Esto es muy, muy importante! ! ! , Si no sabe qué es la idempotencia, vaya a Baidu (No Google). Piénselo si una transacción no es idempotente, si es un pago (retiro) en un escenario concurrente, se llama N veces, y el resultado se paga al usuario N veces, el usuario piensa (tan feliz ...)
En el futuro, ya sea que ajuste la API de otras personas o desee proporcionar una API a otros, recuerde asegurarse de que la interfaz sea idempotente, de modo que "hola es bueno". . .
6. ¡La interfaz de devolución de llamada asíncrona debe ser idempotente!
¡Esto también es muy importante! ! ! , Nunca crea que "una transacción solo será devuelta una vez o una transacción fallida no será devuelta". ¡Porque habrá varias solicitudes de devolución de llamada para una transacción!
1). Idempotente para hacer 2). Si la persona que llama dice que la falla no devolverá la llamada, debemos agregar la lógica de la devolución de llamada de falla 3). Si la persona que llama dice que el éxito no devolverá la llamada, debemos agregar la lógica de la devolución de llamada exitosa
7. Mecanismo de compensación por pedidos anormales (consultar pedidos de reabastecimiento)
Durante el proceso de llamada de la interfaz, es normal que ocurran problemas como excepciones y tiempos de espera de llamadas. En algunos escenarios, podemos realizar algún procesamiento de compensación, como consultar y reabastecer pedidos.
Consultar el pedido de reabastecimiento significa que se produce una anomalía en el pedido durante la transacción y se produce un estado intermedio con resultados de transacción desconocidos. En este momento, puede utilizar la interfaz de consulta proporcionada por tres partes (dos partes) para volver a confirmar el resultado del pedido original y hacer algo en función del resultado Operaciones de compensación como pedidos de reabastecimiento. Un punto importante aquí es confirmar si la interfaz de consulta de tres partes tiene un límite de tiempo de consulta . Algunas interfaces de tres partes no se pueden consultar inmediatamente después de la transacción. Es posible que deba esperar unos minutos antes de la operación (puede ser un problema de sincronización). Consulta con anticipación, la interfaz devuelve una respuesta de que el pedido no existe, lo que genera errores en el procesamiento posterior.
8. Está prohibido solicitar interfaces tripartitas o bipartitas, o anidar lógica compleja y lenta en interfaces con transacciones.
A veces, la actualización y otras operaciones en el método de transacción deben solicitar a las tres partes antes de utilizar los resultados devueltos por las tres para realizar la actualización. Esto sucederá. Si el rendimiento de la interfaz de tres partes es problemático, la transacción completa no se puede enviar durante mucho tiempo y la conexión a la base de datos no se liberará. Cuando la cantidad de solicitudes es grande, los activos de la base de datos no son suficientes, lo que puede causar tiempo de inactividad del sistema.
9. Actualización continua. . . .