Sistema de pago-Resumen del sistema de cuenta

Tabla de contenido

 

Diagrama de arquitectura de OnePayment:

   1.1 Responsabilidades del módulo de capa de transacciones de PayPal:

   1.2 Responsabilidades de las pasarelas de pago:

   1.3 Responsabilidades del sistema de cuentas:

Dos diagrama de flujo principal

Diseño de tres entidades

    2.1 El diseño de la entidad del sistema de cuentas: 

    2.2 El diseño físico del sistema de caja registradora:

Cuatro funciones destacadas


 

Otro artículo:  Sistema de pago-Resumen del sistema de caja

Dirección original de este artículo:  Sistema de pago-Resumen del sistema de cuenta

Diagrama de arquitectura de OnePayment:

 

 

 

 

   1.1 Responsabilidades del módulo de capa de transacciones de PayPal:

         & Acepta el pago de pedidos desde el sistema empresarial. Solicitud de recarga

        & Transferencia entre cuentas

        & Aceptar la solicitud de retiro del sistema empresarial

        & Aceptar la solicitud de reembolso del sistema empresarial (para las distintas empresas mencionadas anteriormente)

   1.2 Responsabilidades de las pasarelas de pago:

           Responsable de interactuar con canales (Alipay, WeChat, UnionPay), registrar números de serie y conciliar cuentas

   1.3 Responsabilidades del sistema de cuentas:

         & Registrar la información de la cuenta

         & Garantizar la atomicidad y la naturaleza transaccional de los cambios de cuenta.

         & Registrar el flujo de cambio de cuenta

Dos diagrama de flujo principal

1. Recarga

    Hay una devolución de llamada de pago

 

2. Transferencia

 

 

2. Retirar

  Primero reduzca los fondos y luego retire el efectivo. No aumentar los fondos

 

 

 

 

Diseño de tres entidades

    2.1 El diseño de la entidad del sistema de cuentas: 

  

 

          Información de la cuenta de la tabla de cuentas.

          Account_statement: 1. Registre los registros de flujo de cambio de cuenta. 2. Control idempotente por método de preservación

    2.2 El diseño físico del sistema de caja registradora:

        

 

 

 

         Tabla de transacciones: registre el número de serie externo y el número de serie interno ingresado externamente

 

 

Cuatro funciones destacadas

      1. El control del monto de la transferencia se pasa a través de variables.

              Si la transferencia permanece en el enlace del medio, vuelva a intentar la lógica Cuenta unilateral.

              En las tarjetas de crédito tradicionales, el límite de cada usuario es diferente y el límite se aumenta agregando dinero a la tarjeta.  (  1. El  aumento del límite y el aumento de la cuenta mantienen la transacción constante. 2. La disminución del límite y la disminución de la cuenta mantienen la transacción consistente y la reducción puede fallar. Si este usuario lo ha usado mucho).

      2. El cambio de cuenta y el almacenamiento del flujo están en la misma transacción.

              Recuerde las anotaciones de transacciones de primavera, las excepciones deben configurarse como arrojables

      3. Retiro:

            * Deduzca la cuenta antes de cobrar.

            * El banco tiene un historial de reembolsos repugnante

     

      4. Cuentas bilaterales

            Las cuentas más y menos se abren por separado.

            4.1 La operación se divide en bloqueo y desbloqueo.

            4.1.1 Cuentas corporativas externas: los fondos de aumento están bloqueados y las deducciones no están bloqueadas. 

            4.1.2 Cuentas corporativas internas: Las sumas y restas no están bloqueadas. Se agrega un juicio de reducción arriba. Retiro manual.

            4.1.3 Los usuarios habituales que necesiten comprobar su saldo de vez en cuando deben bloquearlo. 

           La escalabilidad se logra mediante la expansión distribuida.

      5. Diseño de cuenta con alto cambio simultáneo:

                 Las cuentas con alta concurrencia se deducen de vez en cuando.

      6. La cuestión de los pedidos aduaneros sensibles al tiempo en transacciones no distribuidas.

           En pocas palabras: en  cualquier escenario, no puede cerrar el pedido arbitrariamente  sin conocer el resultado ( estado final: cerrado o exitoso ) ; de lo contrario, para el pago, puede provocar la pérdida del usuario o la experiencia del usuario del retiro no es buena. puede causar la pérdida de los activos de la plataforma. Los retiros no deben cerrarse con anticipación y no pueden responder al código. En su lugar, deben responder al "estado". El código cambia constantemente, el estado converge y la
          optimización de bajo riesgo  : cerrar el pedido lo antes posible. 

        Escenario timeOut: Informe un   error al usuario y deje que el usuario vuelva a intentarlo. (Consejos incorrectos para optimizar la idea,  primero cierre el downstream, cierre correctamente y luego cierre usted mismo . El pago puede dar lugar a reembolsos. El retiro puede provocar una pérdida de capital, porque no hay interfaz de cierre entre sistemas, el enlace descendente tiene que tratar con el "problema de suspensión similar a la TCC distribuido escenario transacción" vacío o "problema orden de exclusión mutua", que hace que el sistema complicado y no una solución buena.)
        hay es código:
          solución 1: 
 si hay un número de pedido y si el estado es Inicial, es un mensaje en espera de ser procesado, no significa que la aceptación no sea exitosa.Cierre directamente el pedido, la cuenta y otros negocios. la verificación es anormal y solicita al usuario, y el reintento del usuario es inútil. (Necesita cumplimiento posterior, incluso si se procesa la excepción, la canalización se devolverá. Lógica de número y estado, interfaz síncrona. Interfaz asíncrona, el flujo de procesamiento se ejecuta asincrónicamente. No afecta.) Si no puede volver a intentarlo, primero apague el flujo descendente y luego apáguelo usted mismo (punto de riesgo, si el sistema descendente tiene un error, se ha recibido una excepción pero no se devuelve ningún error Código, que puede conducir a la pérdida de capital, también es necesario prestar atención a la "orden de exclusión mutua" (similar al "problema de suspensión" en la transacción distribuida tcc, la realización de "pre vacío") problema, mencione el problema "anti-reembolso" en la escena ) Problema de reembolso de Alipay

           Opción 2: En la  Opción 1, debe depender en gran medida de un buen manejo de casos de excepción y en sentido descendente. La optimización de la Opción 2 no es depender del retorno síncrono. Para un código específico, el estado no existe a través de su propia interfaz (puede ser causado por transacciones no confirmadas "Lectura vacía") o cerrado, apague el downstream, apague usted mismo y avise al usuario de manera anormal. Otros errores están esperando el mensaje de sincronización o el estado de conciliación después de 1 día para determinar el estado. (Evite el transacción no se ha enviado, "problema de lectura vacío" )

            Solución 3:  Distinguir los escenarios. 3.1 Proceso de pago fuera de línea, cada vez que se genera un nuevo número de serie. Si el usuario quiere volver a intentarlo, volverá a intentarlo. Lo más importante es pagar más y reembolsar. Lo más importante es 3.2 Pago en línea, utilice el mismo número de serie A. 3.3 Retiro: Utilice el mismo número de serie para informar a los usuarios que, en situaciones especiales, el resultado del retiro tardará 30 minutos más tarde. De lo contrario, habrá problemas con la devolución el saldo antes de cerrar la orden.

      

     7. Cuando hay muchos sistemas descendentes. Debido a que cada sistema tiene una configuración de inquilino diferente o metadatos de motor de reglas, 1.  Si un esquema se basa en una correlación de dos a dos, cada nivel debe solicitar los inquilinos por separado, y directamente en sentido ascendente y descendente. Configuración asociada de inquilinos; 2. Una forma es usar todos los niveles abiertos para penetrar en la información de inquilinos más ascendente. Sin embargo, debido a las diferentes rutas ascendentes, los dominios de identificación se mantienen por separado, lo que puede llevar a lo mismo. ser un unificado El campo de identificación de este campo de identificación es para identificar un tipo de inquilino, en un enlace, información de inquilino diferente, algunos se pueden reutilizar, otros no se pueden reutilizar. Siempre que haya una configuración de sistema diferente, debe usar uno nuevo inquilinos. la nueva aplicación para una identificación de identificación de dominio conducirá a cambios en el negocio al mismo tiempo, toda la configuración del sistema descendente deberá proporcionar mano de obra para agregar y modificar (es posible que la configuración del sistema no se abra ), la vista No hay datos en segundo plano y las necesidades de todas las personas con investigación Ver si los datos correspondientes son correctos. La configuración + los parámetros de la interfaz son todos cambios. La prueba después del cambio es muy importante. La prueba de comparación es muy importante. Debe ser de la perspectiva del usuario, no desde la perspectiva del sistema. Por ejemplo, la cuenta puede mantenerse en un sistema diferente después del cambio, pero el usuario consulta cuando se trata de una consulta agregada. Si solo compara la entrada y la salida del sistema, el la comparación debe haber fallado, pero la situación general es normal.

    Por lo tanto, para cualquier cambio, si el enlace del sistema y la interfaz permanecen sin cambios, simplemente agregue nuevas capacidades, simplemente compare y pruebe, y la mayoría de los datos de comparación de la interfaz permanecerán sin cambios.

     Si se trata de una migración del sistema, verifique: información del lado del usuario + verificación del sistema de vista de fondos dos.

   problema:

  El sistema se está volviendo cada vez más complejo y hay cada vez más partes de acceso ascendentes. Por un lado, hay demasiadas capacidades, parámetros y configuraciones que deben entenderse para cada acceso. Por otro lado, la plataforma configura la configuración de acceso y la depuración conjunta.

  solución:

   1. La configuración se produce y la parte empresarial la configura por sí misma.

      Carga de trabajo: la inserción y la replicación de la configuración deben estar interconectadas.

      Desventajas: El sistema aguas abajo se está volviendo cada vez más complejo y es necesario comprender todos los parámetros cada vez que se conecta.

   2. Configure la producción, clasifique y estratifique , fusione de acuerdo con la similitud comercial (estación intermedia de seguro, estación intermedia xx) (plantilla o fondo de configuración del paquete propio de la estación intermedia), encapsulación capa por capa, la persona superior solo necesita configurar una pequeña cantidad Configuración Si hay un nuevo cambio de demanda, si la configuración existente no puede satisfacer la demanda, entonces la demanda se propone y se comunica capa por capa. El problema finalmente se resuelve.

     Carga de trabajo: la inserción y la replicación de la configuración deben estar interconectadas.

  3. Parametrización de la configuración

      Desventajas: grandes cambios en el código del sistema existente

    8. Cuando hay muchos sistemas de activos, existen múltiples sistemas de cuentas internas. El sistema de intercambio de activos ascendente no puede simplemente utilizar la semántica de tres interfaces de pago, transferencia y retiro para distinguir diferentes comportamientos de transferencia. Es necesario utilizar el tipo de pagador. , Se distingue el tipo de cuenta del beneficiario, y el tipo final es producto cartesiano. El pagador es una cuenta externa, que se puede dividir en pago de usuario en caja y pago de protocolo, que requiere diferentes campos. Los diferentes sistemas de cuenta conducen a diferentes espacios de dominio de identificación. Para configurar diferentes tipos.

 

apéndice:

   Desventajas del concepto de dos códigos y un número similar al traceId de seguimiento de enlaces utilizado en el sistema empresarial:

   1. Se usa para limitar el conjunto de configuración
        Desventajas: n sistemas, siempre que la configuración de un sistema deba ser diferente. Todo el enlace debe configurarse nuevamente. Si usa el conjunto de configuración de mapeo por pares, solo necesita agregar el conjunto de configuración id del sistema ascendente Eso es todo. 
   2. Escenario de puerta de enlace

       Por ejemplo, el escenario de facturación. La tarjeta la abre la parte comercial. 1. La tarjeta se carga desde la puerta de enlace. El código final debe transmitirse como el código de producto de la puerta de enlace. La granularidad puede ser relativamente grande y no lo suficientemente fina. .? En este momento, no es posible llegar a la factura más descendente Qué tipo de negocio se distingue La pasarela no puede subdividir los dos códigos.

     El sistema downstream debe subdividir el escenario comercial de acuerdo con la información de configuración y finalmente entregar la factura. En este momento, solo se puede usar el campo comercial. De lo contrario, se modifica el campo de dos códigos, lo que viola la definición de los dos. -Libro de códigos: el código final se inicia desde el sistema más ascendente. 

   3. Escenario empresarial de devolución de llamada: 
        igual que el anterior.

     

  

Registros de escoria personal, solo para búsqueda

Supongo que te gusta

Origin blog.csdn.net/fei33423/article/details/112602888
Recomendado
Clasificación