설명하신 채널 A, B, C와 인터페이스 A, B, C의 차이점을 잘 모르겠습니다.

당신이 직면한 문제는 현재 인터넷 서비스에서 자주 발생하는 서비스 저하 문제에 더 가깝습니다. 즉, 서비스가 사용할 수 없는 다른 서비스에 의존하는 경우 대체 대체 논리가 호출됩니다.

이 회로 차단기 모드는 귀하의 요구 사항을 충족할 수 있습니다.

• 서비스를 사용할 수 없는 경우(오류율이 특정 기준점에 도달) 자동으로 대체 서비스로 다운그레이드됩니다.

• 특정 시간이 지나면 이전에 사용할 수 없었던 서비스를 다시 호출합니다. 연속 호출에 성공하면 해당 호출이 실패하면 해당 시간 내에 더 이상 호출되지 않습니다.

자동 다운그레이드 및 자동 복구 기능을 구현하려면 퓨즈 구성 요소가 필요합니다.

1. 다운그레이드 전략을 정의합니다. 예를 들어 통화 오류율이 50%를 넘으면 다운그레이드를 시작합니다.

2. 오류율 수집 기간을 정의합니다. 예를 들어 1분마다 요청의 오류율을 재평가합니다.

3. 차단된 요청이 스레드 리소스를 더 오랫동안 점유하지 않도록 서비스 시간 초과를 정의합니다.

4. 한 인터페이스를 사용할 수 없고 모든 리소스가 이에 의해 차단되어 다른 모든 인터페이스를 사용할 수 없게 되는 서비스 사태를 방지하기 위해 서비스 호출을 격리하기 위해 스레드 풀 사용을 정의합니다.

5. 대체 인터페이스의 통화 성공률을 수집하고, 서비스 호출 시 성공률을 기준으로 요청을 발송합니다.

위의 1,2,3,4는 매우 간단합니다.

5번 항목은 직접 구현해야 합니다.

포스터의 비즈니스 시나리오는 실제로 일상 업무에서 접한 적이 없지만 분산 서비스 시스템에 비유할 수 있습니다.

1. A,B,C은 세 가지 주문 서비스와 비교할 수 있습니다. 백엔드 서버는 주문 서비스

를 호출합니다.

2. A > B > C 등 세 가지 인터페이스의 주문 실패율에 따라 요청이 먼저 A 주문 서비스로 라우팅될 수 있습니다. 주문이 실패하면 자동으로 재시도됩니다N. 🎜>회 후에도 계속 실패하면 N 서비스를 다운그레이드하고(다음 주문은 먼저 A로 라우팅됨) B로 요청을 전달하는 것이 B의 전략입니다. BA

   과 동일
3. 은 정기적으로 활동을 감지하기 위해 백그라운드 스레드를 시작합니다. 예를 들어

   이 다운그레이드된 것을 발견하면 때때로 A 인터페이스를 호출하여 주문할 수 있습니다(필요함). 별도의 프로브를 제공하기 위한 A 인터페이스). Active 인터페이스), A가 성공한 것으로 확인되면(실패율을 기준으로 판단할 수도 있음) A을 온라인으로 전환할 수 있습니다. 다음 요청은 먼저 A 서버 A

   로 라우팅됩니다.
4. 아마도 내 계획은 작가의 계획 1이나 계획 2와 비슷할 것 같은데, 포스터의 계획 1과 계획 2는 매우 모호해 보인다(명확하지 않음)

5. 이러한 종류의 인터페이스는 타사 인터페이스에 연결되어 있으며 인터페이스가 불안정합니다. 사용자가 주문을 하고 서버를 호출하면 먼저 요청의 일부 매개변수를 저장할 수 있습니다.

   또는 데이터베이스에 넣습니다. 백그라운드에서 스레드를 시작하고 천천히 MQ 인터페이스를 통해 이러한 주문을 푸시할 수 있으며 사용자에게 반환되는 프롬프트는 주문이 진행되고 있음을 나타낼 수 있습니다. 여기서 사용되는 주요 이점 중 하나는 모든 인터페이스가 중단되면 동기식 방법이 사용자에게 더 나은 느낌을 준다는 것입니다. 즉, 순서가 계속 실패하고 일정 시간 후에 다시 시도할 수 있다는 것입니다. 타사 인터페이스에 문제가 있는 경우(인터페이스 변경, 서버 중단, 처리 속도 저하, 비즈니스 유형이 지원되지 않음 등) 내결함성 비율이 훨씬 높습니다. 높음A,B,C

6. 재시도 메커니즘에는 함정이 있습니다. 주문이 성공적으로 이루어졌으나 인터페이스가 실패를 반환하므로 타사 판매자의 중복 제거 전략에 의존해야 할 수도 있습니다

완하제.
이 문제를 다른 각도에서 생각해보면 실제로 负载均衡 문제에 지나지 않습니다. 차이점은 여기의 요인이 상대적으로 무작위적이며 이 경우 부하 상황을 직관적으로 얻을 수 없다는 것입니다. , 순위 메커니즘은 직접 설정할 수 있습니다.
메커니즘은 다음과 같습니다. 下单成功队列
의 마지막 100번을 저장한다고 가정하면 A의 가용성은 53%, B의 가용성은 30%, C의 가용성은 17%입니다. . 그런 다음 A>B>C 우선순위로 순서대로 폴링합니다. 이번에는 A가 실패하고 B가 성공했다고 가정합니다. 가용성은 52%, 31%, 17%가 됩니다.
B의 가용성이 A의 가용성을 초과할 때까지 B에게 우선순위가 부여됩니다. 이 방법은 자동 순위 메커니즘을 구현하고 자동으로 사용량 균형을 조정하여 최적의 전략을 조정할 수 있습니다.

질문자도 어떤 방법을 사용하더라도 통화 실패 문제를 피할 수 있는 방법이 없다는 것을 알고 있으며, 이는 최소한의 횟수로 통화가 성공하려면 대부분의 답변에서도 알 수 있습니다. 통화의 경우 이전 통화 결과를 기반으로 A B C에 우선 순위를 지정하고 통화 시 전략을 채택해야 합니다. 위에 답변이 꽤 많네요. 질문자는 인터페이스 호출 실패 분포를 인위적으로 분석할 수 있습니다. 예를 들어 특정 인터페이스에 대해 한 번 실패하고 계속해서 실패하는지. 그냥 가끔씩 점선으로 실패하는 경우가 있습니다. 예를 들어 특정 전화를 너무 자주 걸면 실패하기 쉽습니다. 이를 바탕으로 합리적인 전략을 세울 수 있으며, 그 효과는 원하는 것에 더 가까워질 것이라고 예측할 수 있습니다.

activemq를 사용하면 만족할 것 같아요

고객이 주문 응답에 대한 요구 사항이 매우 높은 경우 첫 번째 방법을 따를 수 있지만 동시에 세 가지 주문을 할 수 있습니다. 한 가지가 성공하면 나머지 두 가지도 이에 따라 취소됩니다. 그러나 이 방법에는 타사 인터페이스에 대한 요구 사항이 있으며 타사 인터페이스의 다양한 문제가 비즈니스 서비스에 영향을 미칠 수 있습니다. 예를 들어 인터페이스가 응답하지 않으면 비즈니스 서비스 처리 능력이 기하급수적으로 저하됩니다.
고객이 주문 응답 시간에 그다지 민감하지 않은 경우 MQ를 사용하여 주문 작업을 MQ에 맡길 수 있습니다. MQ 소비자는 주문을 하고 성공 후 결과를 비즈니스 서비스에 다시 호출할 수 있습니다.

원본, 두 번째 해결 방법을 제외한 다른 해결 방법은 문제가 발생할 수 있습니다. 예를 들어 채널 A에 전화를 걸면 채널 A에 시간 초과 또는 기타 오류가 발생하는 경우 이러한 상황은 사용자에게 발생할 수 있습니다. 일반적으로 주문 취소로 알려져 있습니다(수정을 해도 환불을 받을 수 없는 경우가 있으며, 반품 요청만 시작할 수 있음). 일정 지연 후, 이때 사용자를 채널 B로 배분하면 다시 차감됩니다. 이는 제3자 결제에서 자주 발생하는 문제입니다. 다운스트림에 대한 통계를 만드는 것입니다. 품질이 좋은 채널을 우선시하여 포스터를 이렇게 디자인하면 문제가 발생하기 쉽습니다

ps: 위 답변의 대부분은 3자 결제를 해본 적이 없습니다. 원래 포스터처럼 디자인하는 것은 불가능합니다. 분산 서비스와 같은 인터페이스를 호출하면 3자 결제가 불가능합니다. 조심하지 않으면 회사계좌에 소액결제가 되어 헛된 손해를 보게 됩니다