java - 调用多个第三方接口哪一种方案更好？

Question

目的

用户在下单的时候，会调用我们的后台服务器，我们的后台服务器又会根据不同渠道调用第三方下单接口，完成整个下单流程，但是第三方下单接口可能突然出问题或者不支持，所以目前我们每一种渠道都配置了好几种备用的下单接口，尽可能提高用户下单成功率。

问题

想选择一种更好的方案，来实现同样的效果。

方案

例如： 下单时type = 1 ,后台支持该类型的第三方下单接口有A,B,C。可能A,B,C会突然出问题，或者不支持，或者不稳定等问题。

1. 每次下单轮询A,B,C 3个接口，直到成功为止，此时记录下失败的渠道 ，例如A，当A最近M分钟的失败次数大于N次，则下次下单的时候，只用轮询B,C接口。当最近X分钟内失败的渠道A又开始成功了并且成功次数大于X次，则下单的时候又可以轮询A,B,C，其中A,B,C轮询次数按照优先级排序。
   分析：每次都要轮询，但可以保证例如 X= 2 A失败了2次，此时我可以轮询到B去下单，而不会直接失败。

2. 每次下单前直接确定一个接口A或者B或者C，根据优先级最高且最近M分钟内失败次数没有超过N次的。
   分析：如果N为10次，那么第11次的时候，才会选择一个合适的渠道，例如B。之所以是N次才剔除掉，是因为避免偶然失败情况。

3. 有没更好的方式，解决多渠道(就类似上面可用的下单接口用A,B,C)下单的问题，尽可能提高下单的成功率，尽可能尝试更多的机会，尽可能让用户成功支付，尽可能预知第三方接口的问题(接口改变、服务器挂了、处理慢、业务类型不支持了等问题)

求大神分享经验。。。

========================================update 2016-7-7============================

1. 需要同步返回给前端是否成功

2. 第三方暂时没提供 比如某个业务类型不支持的错误码

其实大家的回答已经比较接近实际场景了~

感谢~

Answer 1

Je ne comprends pas très bien la différence entre les canaux A, B, C et les interfaces A, B, C que vous avez décrites, je vais simplement la traiter comme la même chose.

Le problème que vous avez rencontré est plus proche du problème de

dégradation de service souvent rencontré dans les services Internet actuels, à savoir : lorsqu'un service dépend d'un autre service qui est indisponible, la logique alternative de repli est appelée.

Ce mode disjoncteur peut répondre à vos besoins :

• Lorsque le service est indisponible (le taux d'erreur atteint un certain seuil), il sera automatiquement rétrogradé vers le service alternatif
  .
• Après une certaine fenêtre de temps, rappelez le service précédemment indisponible. Si l'appel continu réussit, il sera rétabli. Si l'appel échoue, le service défaillant ne sera plus appelé dans la fenêtre de temps.

Vous avez besoin d'un composant fusible pour mettre en œuvre les fonctions de rétrogradation automatique et de récupération automatique :

1. Définissez la stratégie de downgrade, par exemple : commencez le downgrade lorsque le taux d'erreur d'appel atteint plus de 50 %

2. Définissez la durée de la fenêtre temporelle de collecte du taux d'erreur. Par exemple : toutes les minutes, réévaluez le taux d'erreur de la demande.

3. Définissez le délai d'expiration du service pour empêcher les requêtes bloquées d'occuper les ressources du thread plus longtemps.

4. Définissez l'utilisation de pools de threads pour isoler les appels de service afin d'éviter une avalanche de services, où une interface est indisponible et toutes les ressources sont bloquées par elle, entraînant l'indisponibilité de toutes les autres interfaces

5. Collectez le taux de réussite des appels des interfaces alternatives et envoyez les demandes en fonction du taux de réussite lors de l'appel du service.

Vous pouvez utiliser Hystrix de Netflix pour y parvenir. Les 1,2,3,4 ci-dessus sont assez simples.

Le point 5 doit être mis en œuvre par vous-même.

Answer 2

Le scénario commercial de l'affiche n'a en effet jamais été rencontré dans le travail quotidien, mais il peut être comparé à un système de services distribués.

1. A,B,C peut être comparé à trois services de commande. Le serveur backend appellera le service de commande

.

2. Selon le taux d'échec des commandes des trois interfaces, telles que A > B > C, la demande peut d'abord être acheminée vers le service de commande A Si la commande échoue, elle sera automatiquement réessayée N. fois,< S'il échoue toujours après 🎜> fois, rétrogradez le service N (la prochaine commande sera d'abord acheminée vers A), puis transférez la demande vers B La stratégie de B est la. pareil que BA

3. démarre un fil de discussion en arrière-plan pour détecter régulièrement l'activité. Par exemple, si vous constatez que

   a été rétrogradé, vous pouvez essayer d'appeler l'interface A pour passer une commande de temps en temps (vous en avez besoin). l'interface A pour fournir une sonde distincte). Interface active), s'il s'avère que A réussit (cela peut également être jugé en fonction du taux d'échec), alors A peut être mis en ligne, puis la prochaine requête sera d'abord acheminée vers le A serveur A

4. Peut-être que mon plan est similaire au plan 1 ou au plan 2 de l'auteur, mais le plan 1 et le plan 2 de l'affiche semblent très vagues (pas très clairs)

5. Ce type d'interface est connecté à une interface tierce, et l'interface est instable. Il est recommandé à l'utilisateur de passer une commande et d'appeler le serveur. Le serveur peut d'abord stocker certains paramètres de la requête (. mettez-le dans

   ou dans la base de données), et l'arrière-plan peut démarrer le fil et transmettre lentement ces commandes via l'interface MQ, et l'invite renvoyée à l'utilisateur peut indiquer que la commande est en cours de passation. utilisé ici. L'un des principaux avantages est que si toutes les interfaces raccrochent, la méthode synchrone donnera à l'utilisateur un meilleur sentiment. C'est-à-dire que la commande continue d'échouer et que vous pouvez réessayer de manière asynchrone après un certain temps. partie a des problèmes avec l'interface tierce (changements d'interface, blocages du serveur, traitement lent, type d'entreprise non pris en charge, etc.), le taux de tolérance aux pannes est encore plus élevé. ÉlevéA,B,C

6. Il existe un écueil dans le mécanisme de nouvelle tentative. La commande peut être passée avec succès, mais l'interface renvoie un échec, vous devrez donc peut-être vous fier à la stratégie de déduplication du commerçant tiers

Answer 3

Laxatif.
Si vous réfléchissez à ce problème sous un autre angle, ce n'est en fait rien de plus qu'un 负载均衡 problème. La différence est que les facteurs ici sont relativement aléatoires et qu'il n'est pas possible d'obtenir intuitivement la situation de charge dans ce cas. , vous ne pouvez définir le mécanisme de classement que vous-même. Le mécanisme
est le suivant, en supposant que les 100 dernières fois de 下单成功队列
sont enregistrées, où la disponibilité de A est de 53 %, la disponibilité de B est de 30 % et la disponibilité de C est de 17 % . Ensuite, interrogez-les dans l'ordre avec la priorité A>B>C. Supposons que A échoue cette fois et que B réussisse. La disponibilité devient 52 %, 31 % et 17 %.
Jusqu'à ce que la disponibilité de B dépasse celle de A, B sera prioritaire. Cette méthode peut mettre en œuvre un mécanisme de classement automatique et équilibrer automatiquement l'utilisation pour ajuster la stratégie optimale.

Answer 4

La personne qui pose la question sait également que quelle que soit la méthode utilisée, il n'y a aucun moyen d'éviter le problème de l'échec de l'appel. Il ressort également de la plupart des réponses que si l'appel doit réussir avec le nombre minimum d'appels. appels, il doit être basé sur les résultats de l’appel précédent. Attribuez des priorités à A B C et adoptez des stratégies lors des appels. Il y a beaucoup de réponses ci-dessus. Laissez-moi vous donner quelques idées. Le questionneur peut analyser artificiellement la répartition des échecs d'appel d'interface, par exemple, pour une certaine interface, est-ce qu'elle échoue une fois puis continue d'échouer, ou. est-ce juste Parfois, cela échoue de manière pointillée, par exemple, il est facile d'échouer lorsque vous passez un certain appel trop fréquemment . Sur cette base, vous pouvez élaborer une stratégie raisonnable et estimer que l’effet sera plus proche de celui que vous souhaitez.

Answer 5

Je pense qu'utiliser activemq devrait vous satisfaire

Answer 6

Si le client a des exigences très élevées quant à la réponse à la commande, vous pouvez suivre la première méthode, mais vous pouvez passer trois commandes en même temps. Tant que l'une réussit, les deux autres seront annulées en conséquence. Cependant, cette méthode Il existe des exigences pour les interfaces tierces, et divers problèmes avec les interfaces tierces peuvent affecter vos services métier. Par exemple, si l'interface ne répond pas, les capacités de traitement de vos services métier diminueront de façon exponentielle.
Si le client n'est pas très sensible au temps de réponse de la commande, vous pouvez utiliser MQ pour le faire et laisser la tâche de commande à MQ. Les consommateurs MQ peuvent passer la commande et rappeler le résultat au service commercial après succès.

Answer 7

Original, à l'exception de la deuxième solution, d'autres solutions poseront des problèmes. Les utilisateurs seront certainement déduits à plusieurs reprises. Par exemple, si vous appelez le canal A, si le canal A a un délai d'attente ou d'autres erreurs, mais cette situation est peut-être l'utilisateur. a été déduite, communément appelée commande abandonnée (parfois, vous ne pouvez pas obtenir de remboursement même si vous effectuez une correction, vous ne pouvez lancer qu'une demande de retour. Vous pouvez uniquement vérifier si l'utilisateur a payé avec succès via). la requête de commande de réapprovisionnement. Après un certain délai, si vous répartissez l'utilisateur sur le canal B à ce moment-là, l'utilisateur sera à nouveau déduit. C'est un problème qui se produit souvent dans les paiements tiers. Notre approche consiste à faire des statistiques en aval. chaînes et donner la priorité aux chaînes de bonne qualité. Pour la distribution, il est facile de causer des problèmes si l'affiche la conçoit de cette façon

ps : La plupart des réponses ci-dessus n'ont jamais fait de paiement à trois. Il est impossible de le concevoir comme l'affiche ne peut pas être effectuée en appelant des interfaces comme les services distribués. Les questions impliquant de l'argent sont très sensibles. vous ne faites pas attention, il y aura un court paiement sur le compte de l'entreprise et vous perdrez de l'argent en vain