Les guides suivants sont toutes des personnes qui ont marché ou qui ont découvert les fosses sur lesquelles des collègues de mon entourage ont réellement marché. J'espère apporter des éclaircissements et de l'aide à ceux qui sont sur le point de se lancer dans le secteur des paiements financiers et électroniques et à d'autres secteurs connexes, ainsi qu'à ceux qui viennent d'entrer dans le secteur des douanes. !
1. Le système financier utilise bigdecimal pour traiter le montant et spécifie la décimale
Pour ceux qui ont une expérience financière, vous saurez que lorsque vous traitez des montants, essayez de ne pas utiliser le double ou le flottant car la précision sera perdue, ce qui peut entraîner des erreurs de calcul. Vous devez utiliser bigdecimal, mais cela ne vous empêche toujours pas de marcher sur la fosse, car vous l'êtes aussi yang trop simple!
En fait, l'utilisation abusive de bigdecimal est toujours la perte de précision (ne donnez pas d'exemple de recherche en ligne, beaucoup!), Ici je veux vous dire comment y faire face: " désigner des décimales "!, J'espère que vous ne marcherez plus dessus!
2. Confirmez à plusieurs reprises l'unité de montant pour le champ montant de l'interface
Il y a toujours des gens qui n'aiment pas utiliser leur cerveau, haha, après avoir obtenu l'interface (comme l'interface de paiement), ils n'y pensent même pas, alors ils passent le montant dans le champ montant de l'interface. Ils ne savent pas qu'ils demandent de passer le yuan, vous l'avez donné. Ce sont des points! ! ! Vous avez mis 500 points dans l'interface, et les trois parties ont payé 500 yuans. L'utilisateur a pensé (si heureux ...)
Je vous préviens donc que lorsque vous voyez une interface avec un montant, vous devez confirmer l'unité du montant (y compris le montant retourné)!
3. Pour le statut de l'interface de transaction, il est nécessaire de confirmer à plusieurs reprises le statut de transaction de quel code de champ
Par exemple, le message de retour d'interface à trois parties suivant
{ "success": true, "result": { "status": "0", "amt": "100.00" ..... } }
status = 0 signifie l'échec de l'entreprise
Si la personne qui se connecte à l'interface ne confirme pas dans quelles circonstances le service de code a réussi, elle pense que succès = vrai est une réussite et renvoie le message ci-dessus en tant qu'échec du service, ce qui peut éventuellement entraîner une perte en capital.
Le retour ci-dessus, après confirmation avec le fournisseur d'interface, le champ de réussite ne représente que le statut de communication de cette demande, pas le statut commercial. Si cette demande est une demande de déduction pour l'achat d'un produit, pensez-y, l'argent n'a pas été déduit. Pour l'utilisateur, le produit peut avoir été expédié! ! !
4. Pour l'interface qui renverra le montant de la transaction, assurez-vous de confirmer si la transaction sera partiellement réussie
Dans certains scénarios commerciaux, il y aura des cas où le montant de la demande ne correspond pas au montant confirmé (cela peut être partiellement réussi). À ce stade, si nous appelons l'interface à trois (deux) parties, nous ne prêtons pas attention au montant retourné par l'interface et utilisons directement l'interface pour que l'état de la transaction aboutisse. Pour déterminer le traitement ultérieur, il est facile de provoquer une perte en capital.
S'il est confirmé que l'interface de transaction ne sera pas partiellement réussie, mais que l'interface renvoie le champ de montant, nous pouvons vérifier à nouveau le montant de la demande une fois que la logique métier confirme que le statut de l'entreprise est réussi et s'il est cohérent avec le montant confirmé pour garantir que la transaction est complètement réussie!
5. L'interface de transaction doit être idempotente!
C'est très très important! ! ! , Si vous ne savez pas ce qu'est l' idempotence, allez sur Baidu (pas de Google)! Pensez-y si une transaction n'est pas idempotente, s'il s'agit d'un paiement (retrait) dans un scénario simultané, elle s'appelle N fois, et le résultat est payé à l'utilisateur N fois, pense l'utilisateur (tellement heureux ...)
À l'avenir, que vous ajustiez l'API d'autres personnes ou que vous souhaitiez fournir des API à d'autres, n'oubliez pas de vous assurer que l'interface est idempotente, de sorte que "bonjour c'est bon". . .
6. L'interface de rappel asynchrone doit être idempotente!
C'est aussi très important! ! ! , Ne croyez jamais qu '"une transaction ne sera rappelée qu'une seule fois ou une transaction échouée ne sera pas rappelée". Parce qu'il y aura plusieurs demandes de rappel pour une transaction!
1). Idempotent à faire 2). Si l'appelant dit que l'échec ne rappellera pas, nous devons ajouter la logique du rappel d'échec 3). Si l'appelant dit que le succès ne rappellera pas, nous devons ajouter la logique du rappel de réussite
7. Mécanisme de compensation des commandes anormales (réapprovisionnement des requêtes)
Pendant l'appel d'interface, il est normal que des problèmes tels que des exceptions et des délais d'attente se produisent. Dans certains scénarios, nous pouvons effectuer un traitement de compensation, comme l'interrogation et le réapprovisionnement des commandes.
L'interrogation de l'ordre de réapprovisionnement signifie qu'une anomalie se produit dans la commande pendant la transaction et un état intermédiaire avec des résultats de transaction inconnus est produit. À ce stade, vous pouvez utiliser l'interface de requête fournie par les trois parties (deux parties) pour reconfirmer le résultat de la commande d'origine et faire quelque chose en fonction du résultat. Opérations de compensation telles que les commandes de réapprovisionnement. Un point important ici est de vérifier si l'interface de requête à trois parties a une limite de temps de requête . Certaines interfaces à trois parties ne peuvent pas être interrogées immédiatement après la transaction. Vous devrez peut-être attendre quelques minutes avant l'opération (peut-être un problème de synchronisation). Interrogation à l'avance, l'interface renvoie une réponse indiquant que la commande n'existe pas, ce qui entraîne des erreurs de traitement ultérieur!
8. Il est interdit de demander des interfaces tripartites, bipartites ou d'imbriquer des logiques complexes et chronophages dans des interfaces avec des transactions
Parfois, la mise à jour et d'autres opérations de la méthode de transaction doivent demander aux trois parties avant d'utiliser les résultats renvoyés par les trois parties pour effectuer la mise à jour. Cela se produira. Si les performances de l'interface à trois parties sont problématiques, la transaction entière ne peut pas être soumise pendant longtemps et la connexion à la base de données ne sera pas libérée. Lorsque le nombre de demandes est important, les ressources de la base de données ne sont pas suffisantes, ce qui peut entraîner un temps d'arrêt du système.
9. Mise à jour continue. . . .