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

チャネル A、B、C と、あなたが説明したインターフェイス A、B、C の違いがよくわかりません。

あなたが遭遇した問題は、現在のインターネット サービスでよく発生する サービスの低下 問題に近いものです。つまり、サービスが利用できない別のサービスに依存している場合、フォールバックの代替ロジックが呼び出されます。

このサーキット ブレーカー モードはニーズを満たす可能性があります:

• サービスが利用できない場合 (エラー率が特定のしきい値に達した場合)、自動的に代替サービスにダウングレードされます。

• 一定の時間枠が経過すると、以前は利用できなかったサービスを再度呼び出します。連続呼び出しが成功すると、そのサービスは復元されます。呼び出しが失敗した場合、その時間枠内では失敗したサービスは呼び出されなくなります。

自動ダウングレードおよび自動回復機能を実装するには、ヒューズ コンポーネントが必要です。

1. ダウングレード戦略を定義します。たとえば、通話エラー率が 50% を超えたときにダウングレードを開始します

2. エラー率収集の時間枠の長さを定義します。たとえば、1 分ごとにリクエストのエラー率を再評価します。

3. ブロックされたリクエストがスレッド リソースを長時間占有することを防ぐために、サービス タイムアウトを定義します。

4. サービス呼び出しを分離するためのスレッド プールの使用を定義して、1 つのインターフェイスが使用できなくなり、すべてのリソースがそのインターフェイスによってブロックされ、他のすべてのインターフェイスが使用できなくなるサービス アバランシェを回避します。

5. 代替インターフェースの呼び出し成功率を収集し、サービス呼び出し時の成功率に基づいてリクエストをディスパッチします。

Netflix の Hystrix を使用すると、上記の 1、2、3、4 は非常に簡単です。

ポイント 5 は自分で実装する必要があります。

Answer 2

投稿者のビジネス シナリオは、日常業務では実際に遭遇したことはありませんが、分散サービス システムにたとえることができます。

1. A,B,C は 3 つの順序付けサービスと比較できます。バックエンド サーバーは順序付けサービス

を呼び出します。

2. A > B > C などの 3 つのインターフェースの注文失敗率に従って、リクエストは最初に A 注文サービスにルーティングされます。注文が失敗した場合は、自動的に再試行されます N。 N 回経っても失敗する場合は、A サービスをダウングレードし (次の注文は最初に B にルーティングされます)、その後リクエストを B に転送します。 BA

   と同じ
3. は、アクティビティを定期的に検出するためにバックグラウンド スレッドを開始します。たとえば、

   がダウングレードされたことに気付いた場合は、時々 A インターフェイスを呼び出して注文を試みることができます (必要に応じて)。 A インターフェースを使用して別のプローブを提供します)。アクティブなインターフェース)、A が成功したことが判明した場合 (失敗率に基づいて判断することもできます)、A をオンラインにすることができます。次のリクエストは最初に A サーバーにルーティングされます A

4. おそらく私の計画は著者の計画 1 または計画 2 に似ていますが、投稿者の計画 1 と計画 2 は非常に曖昧です (あまり明確ではありません)

5. この種のインターフェイスはサードパーティのインターフェイスに接続されており、インターフェイスは不安定です。ユーザーが注文してサーバーを呼び出すことをお勧めします。サーバーはリクエストのいくつかのパラメーターを保存できます。それを

   またはデータベースに置きます)、バックグラウンドでスレッドを開始し、MQ インターフェイスを通じてこれらの注文をゆっくりとプッシュできます。また、ユーザーに返されるプロンプトは、注文が行われていることを示すことができます。非同期メソッドです。ここで使用されている主な利点の 1 つは、すべてのインターフェイスがハングアップした場合に、同期メソッドの方がユーザーに良い印象を与えることです。つまり、注文は失敗し続けますが、3 番目の時間が経過すると、非同期メソッドで再試行できるようになります。サードパーティのインターフェイスに問題がある場合 (インターフェイスの変更、サーバーのハング、処理の遅さ、ビジネス タイプがサポートされていないなど)、フォールト トレランス率はさらに高くなります。 HighA,B,C

6. 注文は正常に行われる可能性がありますが、インターフェイスが失敗を返すため、サードパーティ販売者の重複排除戦略に依存する必要がある場合があります。
   >

Answer 3

下剤。
この問題を別の角度から考えると、実際には 负载均衡 の問題にすぎません。違いは、ここでの要因が比較的ランダムであり、この場合、負荷状況を直感的に取得することができないことです。 、ランクメカニズムは自分でのみ設定できます。
のメカニズムは次のとおりです。下单成功队列
の過去 100 回が保存されると仮定すると、A の可用性は 53%、B の可用性は 30%、C の可用性は 17% です。 。次に、A>B>C の優先順位で順番にポーリングします。今回は A が失敗し、B が成功したとします。可用性は 52%、31%、17% になります。
B の可用性が A の可用性を超えるまで、この方法では自動ランキング メカニズムを実装し、使用量のバランスを自動的に調整して最適な戦略を調整できます。

Answer 4

質問者はまた、どのような方法を使用しても、通話失敗の問題を回避する方法がないことを知っています。また、最小限の数で通話を成功させるには、ほとんどの回答からもわかります。通話の場合は、以前の通話結果に基づいて A B C に優先順位を割り当て、通話時に戦略を採用する必要があります。上記には非常に多くの答えがありますが、質問者は、たとえば、特定のインターフェイスの が一度失敗したのか、それとも失敗し続けたのかを人為的に分析できます。時折、点状に失敗することがあります。たとえば、特定の呼び出しを頻繁に行うと失敗しやすくなります。これらに基づいて、合理的な戦略を立て、期待する効果に近づくと推定できます。

Answer 5

activemq を使用すれば満足できると思います

Answer 6

顧客が注文に対する応答に対して非常に高い要求を持っている場合は、最初の方法に従うことができますが、同時に 3 つの注文を行うことができ、1 つが成功すれば、残りの 2 つはそれに応じてキャンセルされます。ただし、この方法にはサードパーティ インターフェイスの要件があり、たとえばインターフェイスが応答しない場合、ビジネス サービスの処理能力が急激に低下するなど、サードパーティ インターフェイスに関するさまざまな問題がビジネス サービスに影響を与える可能性があります。
顧客が注文の応答時間にそれほど敏感でない場合は、MQ を使用して注文タスクを MQ に任せることができ、注文を行って、成功後に結果をビジネス サービスに呼び出すことができます。

Answer 7

本来、2 番目のオプションを除いて、他のオプションでは、たとえば、チャネル A にタイムアウトまたはその他のエラーが発生した場合、ユーザーは確実に減点されます。おそらく、ユーザーが差し引かれている、一般に 注文の欠落 として知られています (場合によっては、修正を行っても返金を受けられない場合があります。ユーザーが返品リクエストを開始できるかどうかのみ確認できます)。補充注文クエリを通じて正常に支払われた後、この時点でユーザーをチャネル B に振り分けると、ユーザーは再び差し引かれます。これは、サードパーティの支払いでよく発生する問題です。下流チャンネルの統計を取り、品質の良いチャンネルを優先して配信するため、投稿者がこのようにデザインすると問題が発生しやすくなります。

ps: 上記の回答のほとんどは、三者間の支払いを行ったことはありません。分散型サービスのようなインターフェイスを呼び出して三者間の支払いを行うことはできません。気をつけないと、会社口座の支払いが不足し、無駄にお金を失うことになります