用户在下单的时候，会调用我们的后台服务器，我们的后台服务器又会根据不同渠道调用第三方下单接口，完成整个下单流程，但是第三方下单接口可能突然出问题或者不支持，所以目前我们每一种渠道都配置了好几种备用的下单接口，尽可能提高用户下单成功率。
想选择一种更好的方案，来实现同样的效果。
例如： 下单时type = 1 ,后台支持该类型的第三方下单接口有A,B,C。可能A,B,C会突然出问题，或者不支持，或者不稳定等问题。
每次下单轮询A,B,C 3个接口，直到成功为止，此时记录下失败的渠道 ，例如A，当A最近M分钟的失败次数大于N次，则下次下单的时候，只用轮询B,C接口。当最近X分钟内失败的渠道A又开始成功了并且成功次数大于X次，则下单的时候又可以轮询A,B,C，其中A,B,C轮询次数按照优先级排序。
分析：每次都要轮询，但可以保证例如 X= 2 A失败了2次，此时我可以轮询到B去下单，而不会直接失败。
每次下单前直接确定一个接口A或者B或者C，根据优先级最高且最近M分钟内失败次数没有超过N次的。
分析：如果N为10次，那么第11次的时候，才会选择一个合适的渠道，例如B。之所以是N次才剔除掉，是因为避免偶然失败情况。
有没更好的方式，解决多渠道(就类似上面可用的下单接口用A,B,C)下单的问题，尽可能提高下单的成功率，尽可能尝试更多的机会，尽可能让用户成功支付，尽可能预知第三方接口的问题(接口改变、服务器挂了、处理慢、业务类型不支持了等问题)
求大神分享经验。。。
========================================update 2016-7-7============================
需要同步返回给前端是否成功
第三方暂时没提供 比如某个业务类型不支持的错误码
其实大家的回答已经比较接近实际场景了~
感谢~
怪我咯2017-04-18 09:31:21
설명하신 채널 A, B, C와 인터페이스 A, B, C의 차이점을 잘 모르겠습니다.
당신이 직면한 문제는 현재 인터넷 서비스에서 자주 발생하는 서비스 저하 문제에 더 가깝습니다. 즉, 서비스가 사용할 수 없는 다른 서비스에 의존하는 경우 대체 대체 논리가 호출됩니다.
이 회로 차단기 모드는 귀하의 요구 사항을 충족할 수 있습니다.
서비스를 사용할 수 없는 경우(오류율이 특정 기준점에 도달) 자동으로 대체 서비스로 다운그레이드됩니다.
특정 시간이 지나면 이전에 사용할 수 없었던 서비스를 다시 호출합니다. 연속 호출에 성공하면 해당 호출이 실패하면 해당 시간 내에 더 이상 호출되지 않습니다.
자동 다운그레이드 및 자동 복구 기능을 구현하려면 퓨즈 구성 요소가 필요합니다.
다운그레이드 전략을 정의합니다. 예를 들어 통화 오류율이 50%를 넘으면 다운그레이드를 시작합니다.
오류율 수집 기간을 정의합니다. 예를 들어 1분마다 요청의 오류율을 재평가합니다.
차단된 요청이 스레드 리소스를 더 오랫동안 점유하지 않도록 서비스 시간 초과를 정의합니다.
한 인터페이스를 사용할 수 없고 모든 리소스가 이에 의해 차단되어 다른 모든 인터페이스를 사용할 수 없게 되는 서비스 사태를 방지하기 위해 서비스 호출을 격리하기 위해 스레드 풀 사용을 정의합니다.
대체 인터페이스의 통화 성공률을 수집하고, 서비스 호출 시 성공률을 기준으로 요청을 발송합니다.
위의 1,2,3,4는 매우 간단합니다.
5번 항목은 직접 구현해야 합니다.
阿神2017-04-18 09:31:21
포스터의 비즈니스 시나리오는 실제로 일상 업무에서 접한 적이 없지만 분산 서비스 시스템에 비유할 수 있습니다.
A,B,C은 세 가지 주문 서비스와 비교할 수 있습니다. 백엔드 서버는 주문 서비스
A > B > C 등 세 가지 인터페이스의 주문 실패율에 따라 요청이 먼저 A 주문 서비스로 라우팅될 수 있습니다. 주문이 실패하면 자동으로 재시도됩니다N. 🎜>회 후에도 계속 실패하면 N 서비스를 다운그레이드하고(다음 주문은 먼저 A로 라우팅됨) B로 요청을 전달하는 것이 B의 전략입니다. BA
이 다운그레이드된 것을 발견하면 때때로 A 인터페이스를 호출하여 주문할 수 있습니다(필요함). 별도의 프로브를 제공하기 위한 A 인터페이스). Active 인터페이스), A가 성공한 것으로 확인되면(실패율을 기준으로 판단할 수도 있음) A을 온라인으로 전환할 수 있습니다. 다음 요청은 먼저 A 서버 A
또는 데이터베이스에 넣습니다. 백그라운드에서 스레드를 시작하고 천천히 MQ 인터페이스를 통해 이러한 주문을 푸시할 수 있으며 사용자에게 반환되는 프롬프트는 주문이 진행되고 있음을 나타낼 수 있습니다. 여기서 사용되는 주요 이점 중 하나는 모든 인터페이스가 중단되면 동기식 방법이 사용자에게 더 나은 느낌을 준다는 것입니다. 즉, 순서가 계속 실패하고 일정 시간 후에 다시 시도할 수 있다는 것입니다. 타사 인터페이스에 문제가 있는 경우(인터페이스 변경, 서버 중단, 처리 속도 저하, 비즈니스 유형이 지원되지 않음 등) 내결함성 비율이 훨씬 높습니다. 높음A,B,C
ringa_lee2017-04-18 09:31:21
완하제.
이 문제를 다른 각도에서 생각해보면 실제로 负载均衡 문제에 지나지 않습니다. 차이점은 여기의 요인이 상대적으로 무작위적이며 이 경우 부하 상황을 직관적으로 얻을 수 없다는 것입니다. , 순위 메커니즘은 직접 설정할 수 있습니다.
메커니즘은 다음과 같습니다. 下单成功队列
의 마지막 100번을 저장한다고 가정하면 A의 가용성은 53%, B의 가용성은 30%, C의 가용성은 17%입니다. . 그런 다음 A>B>C 우선순위로 순서대로 폴링합니다. 이번에는 A가 실패하고 B가 성공했다고 가정합니다. 가용성은 52%, 31%, 17%가 됩니다.
B의 가용성이 A의 가용성을 초과할 때까지 B에게 우선순위가 부여됩니다. 이 방법은 자동 순위 메커니즘을 구현하고 자동으로 사용량 균형을 조정하여 최적의 전략을 조정할 수 있습니다.
高洛峰2017-04-18 09:31:21
질문자도 어떤 방법을 사용하더라도 통화 실패 문제를 피할 수 있는 방법이 없다는 것을 알고 있으며, 이는 최소한의 횟수로 통화가 성공하려면 대부분의 답변에서도 알 수 있습니다. 통화의 경우 이전 통화 결과를 기반으로 A B C에 우선 순위를 지정하고 통화 시 전략을 채택해야 합니다. 위에 답변이 꽤 많네요. 질문자는 인터페이스 호출 실패 분포를 인위적으로 분석할 수 있습니다. 예를 들어 특정 인터페이스에 대해 한 번 실패하고 계속해서 실패하는지. 그냥 가끔씩 점선으로 실패하는 경우가 있습니다. 예를 들어 특정 전화를 너무 자주 걸면 실패하기 쉽습니다. 이를 바탕으로 합리적인 전략을 세울 수 있으며, 그 효과는 원하는 것에 더 가까워질 것이라고 예측할 수 있습니다.
迷茫2017-04-18 09:31:21
고객이 주문 응답에 대한 요구 사항이 매우 높은 경우 첫 번째 방법을 따를 수 있지만 동시에 세 가지 주문을 할 수 있습니다. 한 가지가 성공하면 나머지 두 가지도 이에 따라 취소됩니다. 그러나 이 방법에는 타사 인터페이스에 대한 요구 사항이 있으며 타사 인터페이스의 다양한 문제가 비즈니스 서비스에 영향을 미칠 수 있습니다. 예를 들어 인터페이스가 응답하지 않으면 비즈니스 서비스 처리 능력이 기하급수적으로 저하됩니다.
고객이 주문 응답 시간에 그다지 민감하지 않은 경우 MQ를 사용하여 주문 작업을 MQ에 맡길 수 있습니다. MQ 소비자는 주문을 하고 성공 후 결과를 비즈니스 서비스에 다시 호출할 수 있습니다.
PHP中文网2017-04-18 09:31:21
원본, 두 번째 해결 방법을 제외한 다른 해결 방법은 문제가 발생할 수 있습니다. 예를 들어 채널 A에 전화를 걸면 채널 A에 시간 초과 또는 기타 오류가 발생하는 경우 이러한 상황은 사용자에게 발생할 수 있습니다. 일반적으로 주문 취소로 알려져 있습니다(수정을 해도 환불을 받을 수 없는 경우가 있으며, 반품 요청만 시작할 수 있음). 일정 지연 후, 이때 사용자를 채널 B로 배분하면 다시 차감됩니다. 이는 제3자 결제에서 자주 발생하는 문제입니다. 다운스트림에 대한 통계를 만드는 것입니다. 품질이 좋은 채널을 우선시하여 포스터를 이렇게 디자인하면 문제가 발생하기 쉽습니다
ps: 위 답변의 대부분은 3자 결제를 해본 적이 없습니다. 원래 포스터처럼 디자인하는 것은 불가능합니다. 분산 서비스와 같은 인터페이스를 호출하면 3자 결제가 불가능합니다. 조심하지 않으면 회사계좌에 소액결제가 되어 헛된 손해를 보게 됩니다