마이크로서비스가 논쟁을 벌일 때: 회로 차단기가 Spring Boot 시스템을 조용하게 유지하는 방법

이 시나리오를 상상해보세요. 새벽 3시, 갑자기 휴대전화가 진동하기 시작합니다. 알람시계가 아니라 일련의 알람 알림입니다. 특정 핵심 서비스가 다운되어 도미노와 같은 연쇄 반응이 일어나 전체 시스템이 다운되는 것입니다. 당신은 침대에서 벌떡 일어나 모니터 패널의 눈부신 붉은 곡선을 바라보았습니다. 당신의 마음 속에는 단 하나의 생각이 있었습니다. 왜 스스로 멈추지 않았습니까?

이는 아마도 회로 차단기가 없는 마이크로서비스 아키텍처의 일상일 것입니다. Spring Boot로 구축된 분산 세계에서 서비스는 매일 전화를 걸고 메시지를 보냅니다. 대부분의 경우 모든 것이 잘 진행됩니다. 어느 날까지는 서비스 중 하나가 느리게 응답하기 시작하거나 데이터베이스 압력, 네트워크 변동 또는 단순히 코드에 숨겨진 버그로 인해 응답이 중단되었습니다.

이때 무슨 일이 일어날까요? 다른 서비스는 그것이 잘못된 줄 모르고 계속 요청을 보냅니다. 요청은 대기열에 쌓이고 스레드는 점유되며 리소스는 점차적으로 고갈됩니다. 서비스 장애는 전염병처럼 퍼져 결국 시스템 전체를 마비시킨다. 이를 "눈사태 효과"라고 ​​합니다. 전문적인 것처럼 들리지만 기술적인 악몽처럼 느껴집니다.

차단기란 정확히 무엇인가요?

가정용 전기 상자의 안전 스위치처럼 생각하면 됩니다. 회로가 과부하되거나 단락되면 와이어가 과열되거나 화재가 발생하는 것을 방지하기 위해 "트립"되고 전류를 적극적으로 차단합니다. 마이크로서비스에서 회로 차단기는 거의 동일한 작업을 수행합니다. 즉, 서비스의 실패율이 임계값을 초과하는 것을 감지하면 자동으로 "켜지고" 해당 서비스에 대한 요청을 차단합니다.

후속 요청은 더 이상 실패한 서비스로 전송되지 않지만 빠르게 해제되거나 미리 설정된 백업 응답(대체)이 반환됩니다. 시스템의 주요 트래픽이 보호되며 더 이상 지선 장애로 인해 방해를 받지 않습니다. 회로 차단기는 주기적으로 "반 개방" 테스트를 수행하여 비밀리에 대상 서비스에 요청 한두 개를 보내 복구되는지 확인합니다. 복원되면 회로 차단기가 자동으로 "닫히고" 트래픽이 정상적인 흐름을 재개합니다.

전체 프로세스에서 한밤중 3시에 수동으로 개입할 필요가 없습니다. 그것은 자동으로, 침착하게, 합리적으로 일어납니다.

Spring Boot 프로젝트에 특별히 필요한 이유는 무엇입니까?

Spring Boot를 사용하면 마이크로서비스 개발이 매우 쉬워지기 때문입니다. 몇 줄의 주석, 시작 클래스 및 서비스가 온라인에 있습니다. 이러한 편리함 덕분에 누구나 복잡한 서비스 호출 네트워크를 더욱 쉽게 구축할 수 있습니다. 그러나 편리함의 다른 측면은 더 취약한 링크도 있다는 것입니다.

여기서 회로 차단기는 "기능"이 아니라 "탄력적 사고"를 수행합니다. 실패는 일어나기 마련이라는 사실을 인정하고, 더 이상 100% 가용성이라는 환상을 추구하지 않고, 부분적인 실패가 발생하더라도 여전히 핵심 기능을 유지할 수 있는 시스템을 설계합니다. 귀하의 전자상거래 애플리케이션은 결제 서비스를 일시적으로 사용할 수 없을 때 거래를 완료하지 못할 수 있지만 최소한 제품 탐색 및 장바구니에 추가와 같은 기능은 계속 사용할 수 있습니다. 완전히 비어 있는 오류 페이지나 긴 대기 시간 초과 대신 "결제 시스템이 사용 중입니다. 나중에 다시 시도하십시오."라는 메시지가 사용자에게 표시됩니다.

존재하다kpower기술 실무에서 무엇을 보았습니까?

매우 실용적인 변화. 예를 들어, 고객의 백엔드 관리 시스템은 원래 프로모션 기간 동안 주문 서비스 응답이 느려 관리 인터페이스가 완전히 중단되어 고객 서비스에서 문의를 처리할 수 없었습니다. 회로 차단기 정책에 액세스한 후 관리 인터페이스는 주문 서비스 로드가 높을 때 일부 비핵심 쿼리 요청을 자동으로 차단하고 환불 처리 및 고객 주문 쿼리의 우선 순위를 지정합니다. 인터페이스가 약간 느려질 수는 있지만 완전히 중단되지는 않습니다.

또 다른 일반적인 시나리오는 타사 API 호출입니다. 날씨 서비스, 지도 서비스, SMS 게이트웨이 등은 유지 관리하는 것이 아니지만 의존하는 것입니다. 그들의 불안정성은 당신의 불안정성입니다. 회로 차단기 설정을 사용하면 명확한 시간 초과 및 실패 횟수를 설정할 수 있습니다. 타사 서비스가 요구 사항을 충족하지 않으면 시스템은 끝없이 기다리는 대신 자동으로 캐시된 데이터 또는 정적 기본값으로 전환합니다.

이것에 대해 어떻게 생각하기 시작합니까?

아직 수행하지 않았다면 가장 민감한 서비스 중 하나부터 시작하세요. 스스로에게 물어보세요. 이 서비스가 느리거나 작동하지 않으면 무엇이 문제가 될까요? 이를 호출하는 서비스는 무엇을 보호해야 합니까?

구성 자체는 복잡하지 않습니다. Spring Boot 생태계에는 회로 차단기 패턴을 구현하는 성숙한 라이브러리가 있습니다. 주로 몇 가지 매개변수를 결정해야 합니다. 특정 기간 내에서 "실패"로 간주되는 횟수는 몇 번입니까? 회로 차단기를 켠 후 서비스가 복원되었는지 얼마나 자주 테스트하려고 합니까? 대체 응답은 무엇을 반환해야 합니까? 간단한 오류 메시지입니까, 아니면 약간 오래되었지만 사용 가능한 캐시된 데이터 집합입니까?

이러한 결정에 대한 표준적인 답변은 없으며 귀하의 비즈니스가 허용할 수 있는 정도에 따라 달라집니다. 금융 서비스와 콘텐츠 검색 서비스는 허용 범위가 분명히 다릅니다.

천천히, 이 디자인이 팀의 사고 방식을 변화시킨다는 것을 알게 될 것입니다. 모두가 단순히 "기능적 경계"가 아닌 "실패 경계"에 대해 이야기하기 시작했습니다. 서비스 간 계약에는 "성공 시 무엇을 반환할지" 외에 "실패 시 처리 방법"도 포함됩니다. 시스템의 탄력성은 조금씩 엮여 있습니다.

소설의 한 단편 같은 말을 해보세요.

늦은 밤 데이터 센터에서는 서버의 표시등만 정기적으로 깜박입니다. 서비스 A는 평소와 같이 서비스 B에 요청을 보냅니다. 그러나 이번에는 아무런 반응이 없었다. 잠깐만요. 시간이 초과되었습니다. 회로 차단기는 카운터에 자동으로 틱을 추가했습니다. 다섯 번째 실패에서는 약간 "점프"했습니다. 후속 요청은 수문을 만나 조용히 다른 길로 향하는 시냇물과 같습니다. 경보도 없고 당황하지도 않습니다. 아무 일도 일어나지 않은 것처럼 주요 프로세스가 계속됩니다. 모니터링 차트의 작은 메모에만 이러한 간단한 격리가 기록됩니다.

새벽 이후 엔지니어는 로그를 확인하고 해당 기간 동안 서비스 B의 CPU 피크를 찾았습니다. 고장원인을 찾아 수리하였습니다. 그리고 이 모든 일이 발생하더라도 대부분의 사용자는 특이한 점조차 눈치채지 못합니다. 시스템이 스스로 처리했습니다.

기술은 아마도 이런 모습이어야 합니다. 즉, 평온하고, 자기 인식이 뛰어나며, 폭풍우 속에서도 균형을 유지해야 합니다.

2005년에 설립되었으며,kpower는 중국 광둥성 둥관에 본사를 둔 전문 컴팩트 모션 유닛 제조업체에 전념해 왔습니다. 모듈식 드라이브 기술의 혁신을 활용하여,kpower고성능 모터, 정밀 감속기, 멀티 프로토콜 제어 시스템을 통합하여 효율적이고 맞춤형 스마트 드라이브 시스템 솔루션을 제공합니다. Kpower는 스마트 홈 시스템, 자동 전자 장치, 로봇 공학, 정밀 농업, 드론 및 산업 자동화 등 다양한 분야를 포괄하는 제품을 통해 전 세계 500개 이상의 기업 고객에게 전문 드라이브 시스템 솔루션을 제공해 왔습니다.