이 기사는 Huawei Cloud PaaS 서비스 Xiaozhi의 Huawei Cloud 커뮤니티 " Huawei Cloud FunctionGraph를 사용한 고가용성 시스템 구축 실습 "에서 공유되었습니다.
소개
매년 인터넷에는 XXX 시스템이 비정상적으로 작동하지 않아 고객에게 막대한 경제적 손실이 발생한다는 보도가 나오고 있습니다. 클라우드 서비스는 고객 기반이 더 넓습니다. 문제가 발생하면 고객과 서비스 자체에 큰 영향을 미칩니다. 이 글에서는 Huawei Cloud FunctionGraph의 자체 사례를 바탕으로 고객과 플랫폼 모두가 윈윈(win-win)할 수 있는 고가용성 서버리스 컴퓨팅 플랫폼을 구축하는 방법을 자세히 소개합니다.
고가용성 소개
IT 용어 인 고가용성[1](영어: high Availability, 약어로 HA)은 시스템이 중단 없이 기능을 수행할 수 있는 능력을 말하며 시스템의 가용성을 나타냅니다 . 시스템을 설계할 때 기준 중 하나입니다.
업계에서는 일반적으로 SLA 지표를 사용하여 시스템 가용성을 측정합니다.
서비스 수준 계약[2](영어: 서비스 수준 계약, 약어 SLA)은 서비스 수준 계약, 서비스 수준 계약이라고도 알려져 있으며 서비스 제공업체와 고객 간에 정의된 공식적인 약속 입니다 . 서비스 제공자와 서비스를 받는 고객은 약속된 서비스 지표인 품질, 가용성 및 책임에 구체적으로 도달했습니다. 예를 들어, 서비스 제공자가 99.99%의 SLA를 약속한다면 연간 최대 서비스 실패 시간은 5.26분(365*24*60*0.001%)입니다.
FunctionGraph는 시스템 가용성의 두 가지 황금 지표인 SLI와 대기 시간을 직관적으로 측정합니다. SLI는 시스템의 요청 성공률 지표이고 대기 시간은 시스템 처리 성능입니다.
고가용성 과제
Huawei Cloud의 하위 서비스인 FunctionGraph는 자체 기능을 구축하는 동시에 시스템 자체의 견고성뿐만 아니라 주변 종속 서비스의 견고성도 고려해야 합니다(예: 종속 신원 인증 서비스를 사용할 수 없음, 트래픽 전달을 위한 게이트웨이) 서비스 서비스가 다운되었거나 스토리지 개체에 대한 서비스 액세스가 실패하는 등). 또한, 시스템이 의존하는 하드웨어 자원에 장애가 발생하거나 시스템이 갑자기 트래픽 등의 공격을 받아 이러한 통제할 수 없는 비정상적인 상황에 직면하게 되면 시스템이 높은 비즈니스 가용성을 유지할 수 있는 자체 기능을 구축하는 것이 큰 과제가 됩니다. 그림 1은 FunctionGraph의 주변 상호 작용을 보여줍니다.
그림 1 FunctionGraph의 주변 장치 상호 작용
일반적인 문제의 경우 표 1과 같이 4가지 주요 범주로 분류되었습니다.
표 1 FunctionGraph에서 자주 묻는 질문 요약
이러한 문제에 대응하여 우리는 다음과 같은 일반적인 거버넌스 방법을 요약했습니다.
- 트래픽 돌연변이 관리: 과부하 보호 + 탄력적 확장 및 수축 + 회로 차단기 + 비동기 피크 클리핑 + 모니터링 및 경고 방어 설계 개념을 기반으로 과부하 보호 + 회로 차단기는 시스템의 모든 리소스를 제어하고 이를 기반으로 합니다. 기본적으로 대규모 트래픽을 충족할 수 있는 최고의 확장 용량을 제공하고 적합한 고객 시나리오에서는 비동기식 피크 감소를 권장하여 시스템 압력을 줄이고 경보를 모니터링하여 과부하 문제를 적시에 감지합니다.
- 시스템 서비스 예외 관리: 재해 복구 아키텍처 + 재시도 + 격리 + 모니터링 및 경보 재해 복구 아키텍처는 전체 시스템 다운타임을 방지하며, 재시도는 시스템 이상 지점을 신속하게 제거하여 장애 확산을 방지합니다. 알람 모니터링을 통해 시스템 서비스 이상 징후를 신속하게 발견합니다.
- 시스템 종속 서비스 예외 관리: 재해 복구 아키텍처 + 캐시 다운그레이드 + 모니터링 및 경고 재해 복구 아키텍처는 종속 서비스의 단일 실패 지점을 줄여 종속 서비스 오류 후에도 시스템이 계속 정상적으로 실행될 수 있도록 합니다. 종속 서비스 예외를 감지합니다.
- 변경으로 인한 거버넌스: 그레이스케일 업그레이드 + 프로세스 제어 + 모니터링 및 경보 그레이스케일 업그레이드를 통해 공식 고객에 대한 비정상적인 시스템 업그레이드로 인한 글로벌 장애를 방지할 수 있습니다. 프로세스 제어를 통해 인적 변화의 위험을 최소화할 수 있습니다. 모니터링 및 알람을 통해 변경 후 변경됩니다.
FunctionGraph 시스템 설계 실습
표 1의 문제를 해결하기 위해 FunctionGraph는 아키텍처 재해 복구, 흐름 제어, 재시도, 캐시, 그레이스케일 업그레이드, 모니터링 및 경보, 관리 프로세스 등 여러 측면을 최적화했으며 사용성이 크게 향상되었습니다. 다음은 FunctionGraph의 일부 예외 지향적 설계 방식을 주로 소개하며 당분간 탄력적 기능, 시스템 기능 등을 확장하지 않습니다.
재해 복구 아키텍처
Huawei Cloud Disaster Recovery 1.1 아키텍처(예: 서비스 AZ 수준 장애 도메인, 클러스터 간 AZ 자가 치유 기능, AZ 수준 서비스 종속성 격리)를 구현하기 위해 여러 세트의 FunctionGraph 관리 플레인 및 데이터 플레인 클러스터가 배포되고 각 세트 의 클러스터는 동일한 지역 내에서 AZ 재해 복구를 달성하기 위해 AZ 격리되어 있습니다. 그림 2에서 볼 수 있듯이 FunctionGraph는 여러 세트의 데이터 플레인 클러스터(비즈니스를 실행하는 FunctionGraph 기능 수행)와 디스패처 스케줄링 클러스터(FunctionGraph의 트래픽 클러스터 스케줄링 작업 수행)를 배포하여 시스템 용량과 재해 복구를 늘립니다. Yuanrong 클러스터 중 하나가 비정상적인 경우 디스패처 예약 구성 요소는 결함이 있는 클러스터를 즉시 제거하고 트래픽을 다른 여러 클러스터에 분산할 수 있습니다.
그림 2 FunctionGraph 단순 아키텍처 다이어그램
분산형 분산 아키텍처 설계로 유연한 수평 확장 및 축소 지원
이 전략은 논리적 멀티 테넌시 서비스 설계의 핵심이며, 분산화 및 구성 요소 확장 및 축소 이후의 재조정 문제를 해결해야 합니다.
정적 데이터 관리의 분산화: 논리적 멀티 테넌트 서비스의 메타데이터는 초기 단계의 양이 적기 때문에 모두 동일한 미들웨어 세트에 저장할 수 있습니다. 고객의 볼륨이 증가함에 따라 이후의 대량 데이터 읽기 및 쓰기와 신뢰성 압박에 대처하기 위해 데이터 샤딩을 지원하는 데이터 분할 계획을 설계해야 합니다.
트래픽 스케줄링 기능의 분산화: 구성 요소 기능 설계는 분산화(공통 중앙 집중식 종속성: 잠금, 흐름 제어 값, 스케줄링 작업 등)를 지원합니다. 트래픽이 증가한 후 구성 요소 복사본 수가 자체적으로 확장될 수 있습니다. 균형 조정 전략. 트래픽 재로드를 완료합니다.
다차원 흐름 제어 전략
FunctionGraph의 클라이언트 기능 트래픽이 최종적으로 런타임에 도달하기 전에 여러 링크를 통과하며 각 링크에는 전달 임계값을 초과하는 트래픽이 있을 수 있습니다. 따라서 각 링크의 안정성을 보장하기 위해 FunctionGraph는 각 링크에 서로 다른 흐름 제어 전략을 방어적으로 추가합니다. 기본 원칙은 컴퓨팅(CPU), 저장소(디스크, 디스크 I/0) 및 네트워크(http 연결, 대역폭)의 기능 세분화에 따른 리소스 격리를 다룹니다.
함수 트래픽은 클라이언트 측에서 트리거되며 최종적으로 실행되는 링크 흐름 제어는 그림 3과 같습니다.
그림 3 FunctionGraph 흐름 제어
게이트웨이 APIG 흐름 제어
APIG는 FunctionGraph의 트래픽 입구로, Region 수준의 전체 트래픽 제어를 지원하며 해당 지역의 비즈니스 바쁜 상황에 따라 유연하게 확장할 수 있습니다. 동시에 APIG는 고객 수준의 트래픽 제어를 지원합니다. 비정상적인 고객 트래픽이 감지되면 APIG 측을 통해 고객 트래픽을 신속하게 제한하여 개별 고객이 시스템 안정성에 미치는 영향을 줄일 수 있습니다.
시스템 업무 흐름 제어
API 수준의 흐름 제어
고객 트래픽이 APIG를 통과한 후 FunctionGraph의 시스템 측으로 이동합니다. APIG 흐름 제어가 실패하는 시나리오를 기반으로 FunctionGraph는 자체 흐름 제어 전략을 구축합니다. 현재는 노드 수준 흐름 제어, 고객 API 전체 흐름 제어, 기능 수준 흐름 제어가 지원됩니다. 고객 트래픽이 FunctionGraph의 전송 용량을 초과하면 시스템은 이를 직접 거부하고 고객에게 429를 반환합니다.
시스템 자원 흐름 제어
FunctionGraph는 논리적 멀티 테넌시 서비스입니다. 컨트롤 플레인과 데이터 플레인 리소스는 불법 고객의 악의적인 공격으로 인해 시스템이 불안정해질 수 있습니다. FunctionGraph는 공유 리소스에 대한 동시 요청 수를 기반으로 고객 흐름 제어를 구현하여 고객이 사용할 수 있는 리소스를 엄격하게 제한합니다. 또한 공유 자원의 자원 풀링을 통해 공유 자원의 총량을 제어할 수 있어 시스템 가용성이 보장됩니다. 예: http 연결 풀, 메모리 풀, 코루틴 풀.
동시성 제어: 동시 요청 수를 기준으로 FunctionGraph 함수 세분화를 기반으로 흐름 제어 전략을 구성합니다. FunctionGraph의 클라이언트 함수 실행 시간은 밀리초, 초, 분, 시간 등 다양한 유형이 있습니다. 기존의 QPS 요청 당 흐름 제어 전략은 다음과 같습니다. 두 번째로 처리됩니다. 매우 오랜 시간 동안 실행되는 요청에는 본질적인 단점이 있으며 동시에 고객이 점유하는 시스템 공유 리소스를 제한할 수 없습니다. 동시성 수에 따른 제어 전략은 동시에 요청 수를 엄격하게 제한하며, 요청 수가 해당 수를 초과할 경우 시스템의 공유 리소스를 보호하기 위해 직접 거부합니다.
http 연결 풀: 높은 동시성 서비스를 구축할 때 긴 http 연결 수를 합리적으로 유지하면 http 연결 리소스 수를 제어할 수 있게 하여 시스템 성능을 향상시키는 동시에 시스템 보안을 보장하면서 http 연결의 리소스 오버헤드 시간을 최소화할 수 있습니다. 업계에서는 http2의 연결 재사용과 fasthttp 내의 연결 풀 구현을 참조할 수 있습니다. 원칙은 http 수를 최소화하고 기존 리소스를 재사용하는 것입니다.
메모리 풀: 고객의 요청 및 응답 메시지가 특히 크고 동시성이 특히 높은 시나리오에서는 단위 시간당 차지하는 시스템 메모리가 크므로 임계값을 초과하면 쉽게 시스템 메모리 오버플로가 발생하고 시스템이 다시 시작될 수 있습니다. . 이 시나리오를 기반으로 FunctionGraph는 요청 입력 및 응답 종료 시 시스템 메모리를 보호하고 제어하기 위해 고객 요청 메시지가 임계값을 초과하는지 확인하여 메모리 풀에 대한 통합 제어를 추가했습니다.
코루틴 풀: FunctionGraph는 클라우드 네이티브 플랫폼에 구축되었으며 go 언어를 사용합니다. 각 요청마다 코루틴을 사용하여 로그 및 표시기를 처리하는 경우 대규모 동시 요청이 오면 동시에 많은 수의 코루틴이 실행되어 시스템 전체 성능이 크게 저하됩니다. FunctionGraph는 go의 코루틴 풀을 도입하고 로그 및 표시기 처리 작업을 개별 작업으로 변환하여 코루틴 풀에 제출합니다. 그런 다음 코루틴 풀이 이를 균일하게 처리하므로 코루틴 폭발 문제가 크게 완화됩니다.
비동기식 소비율 제어: 비동기식 함수가 호출되면 FunctionGraph의 Kafka에 먼저 배치됩니다. 고객의 Kafka 소비율을 합리적으로 설정하여 함수 인스턴스가 항상 충분한지 확인하고 과도한 함수 호출로 인해 기본 리소스가 중단되는 것을 방지합니다. 빨리 소모될 것.
함수 인스턴스 제어
- 고객 인스턴스 할당량: 총 고객 할당량을 제한함으로써 악의적인 고객이 모든 기본 리소스를 소비하는 것을 방지하여 시스템 안정성을 보장합니다. 고객의 비즈니스에 꼭 필요한 경우 작업 주문을 신청하여 고객 할당량을 빠르게 확장할 수 있습니다.
- 기능 인스턴스 할당량: 기능 할당량을 제한하면 단일 고객의 기능이 모든 고객의 인스턴스를 소비하는 것을 방지할 수 있으며, 또한 고객의 할당량이 무효화되어 단기간에 많은 양의 리소스를 소비하는 것을 방지할 수 있습니다. 또한, 고객의 업무가 데이터베이스, Redis 등 미들웨어를 사용하는 경우에는 함수 인스턴스 할당량 제한을 통해 고객 미들웨어 연결 수를 통제 가능한 범위 내에서 보호할 수 있습니다.
효율적인 리소스 탄력성 기능
흐름 제어는 조기 차단을 통해 시스템 과부하 위험을 줄이는 방어 설계 개념입니다. 고객의 정상적인 비즈니스가 갑자기 증가하여 많은 양의 리소스가 필요할 때 가장 먼저 해결해야 할 것은 리소스 탄력성 문제입니다. 고객의 비즈니스 성공을 전제로 흐름 제어 전략을 사용하여 시스템 이상을 커버하고 예방할 수 있습니다. 폭발의 확산. FunctionGraph는 클러스터 노드의 빠른 탄력성, 고객 기능 인스턴스의 빠른 탄력성, 고객 기능 인스턴스의 지능적인 예측 탄력성 등 다양한 탄력성 기능을 지원하여 고객 비즈니스가 갑자기 증가하는 경우에도 FunctionGraph를 정상적으로 사용할 수 있도록 보장합니다.
재시도 전략
FunctionGraph는 적절한 이점을 갖춘 재시도 전략을 설계함으로써 예외가 발생했을 때 고객의 요청이 궁극적으로 성공적으로 실행되도록 보장할 수 있습니다. 그림 4에 표시된 것처럼 재시도 전략에는 종료 조건이 있어야 합니다. 그렇지 않으면 재시도 폭풍이 발생하고 시스템의 로드 제한을 더 쉽게 돌파하게 됩니다.
그림 4 재시도 전략
함수 요청 재시도 실패
- 동기 요청: 고객이 실행을 요청하고 시스템 오류가 발생하면 FunctionGraph는 요청을 다른 클러스터로 전달하고 가끔 클러스터 예외가 발생하더라도 고객의 요청이 다른 클러스터에서 실행될 수 있도록 최대 3번 재시도합니다.
- 비동기식 요청: 비동기식 기능은 실시간 요구 사항이 높지 않기 때문에 클라이언트 기능 실행에 실패한 후 시스템은 실패한 요청에 대해 보다 정교한 재시도 전략을 구현할 수 있습니다. 현재 FunctionGraph에서는 시스템 오류로 인해 함수가 비정상적으로 종료되는 경우 2, 4, 8, 16의 방법에 따라 함수가 지수적으로 백오프됩니다. 간격이 20분으로 백오프되면 이후 재시도가 수행됩니다. 기능 요청 재시도 시간은 20분을 기준으로 합니다. 기능 요청 재시도 시간은 최대 6시간까지 지원하며, 이를 초과할 경우 요청 실패로 처리되어 고객에게 반환됩니다. 바이너리 지수 백오프를 통해 고객 비즈니스의 안정성을 최대한 보장할 수 있습니다.
종속 서비스 간 재시도
- 미들웨어의 재시도 메커니즘: Redis를 예로 들면, 시스템이 가끔씩 Redis를 읽고 쓰는 데 실패하면 일정 시간 동안 절전 모드로 전환된 후 Redis의 읽기 및 쓰기 작업을 반복합니다. 최대 재시도 횟수는 3회입니다. 타임스.
- http 요청 재시도 메커니즘: 네트워크 변동으로 인해 http 요청에서 eof 및 io 시간 초과와 같은 오류가 발생하면 일정 시간 동안 절전 모드로 전환된 후 최대 3회 재시도 횟수로 http 전송 작업을 반복합니다.
은닉처
캐싱은 데이터 액세스 속도를 높일 수 있을 뿐만 아니라 캐시된 데이터를 사용하여 종속 서비스가 실패할 경우 시스템 가용성을 보장할 수도 있습니다. 기능 범주로 나누어서 FunctionGraph가 캐시해야 하는 두 가지 유형의 구성 요소가 있습니다. 첫 번째는 미들웨어이고 두 번째는 종속 클라우드 서비스입니다. 시스템은 캐시된 데이터에 액세스하는 데 우선 순위를 부여하고 동시에 로컬 캐시 데이터를 정기적으로 새로 고칩니다. 미들웨어 및 종속 클라우드 서비스. 방법은 그림 5에 나와 있습니다.
- 캐시 미들웨어 데이터: FunctionGraph는 미들웨어 데이터의 변경 사항을 모니터링하고 이를 게시 및 구독을 통해 적시에 로컬 캐시에 업데이트합니다. 미들웨어에 이상이 있는 경우에도 로컬 캐시를 계속 사용하여 시스템 안정성을 유지할 수 있습니다.
- 캐시 키 종속 서비스 데이터: Huawei Cloud의 신원 인증 서비스 IAM을 예로 들어 보겠습니다. FunctionGraph는 고객이 첫 번째 요청을 시작하면 IAM이 중단되면 만료 시간이 24시간인 토큰을 로컬로 캐시합니다. up하면 이전 요청에는 영향을 미치지 않습니다. FunctionGraph 시스템을 사용합니다. 다른 주요 클라우드 서비스는 주요 데이터를 로컬 메모리에 임시로 캐싱하는 방식을 사용합니다.
그림 5 FunctionGraph의 캐싱 측정
퓨즈
위의 조치는 고객의 비즈니스의 원활한 운영을 보장할 수 있습니다. 그러나 고객의 비즈니스가 비정상적이어서 복구할 수 없거나 악의적인 고객이 계속해서 FunctionGraph 플랫폼을 공격하는 경우 비정상적인 트래픽으로 인해 시스템 리소스가 낭비되어 일반 고객의 리소스를 점유하게 됩니다. , 비정상적인 트래픽으로 인해 지속적으로 높은 부하가 발생하는 경우 시스템이 실패할 수도 있습니다. 이 시나리오에서 FunctionGraph는 함수 호출 볼륨 모델을 기반으로 자체 회로 차단기 전략을 구축했습니다. 그림 6과 같이 고객 업무의 원활한 진행과 시스템의 안정성을 보장하기 위해 통화량의 장애율을 기반으로 다단계 차단기를 구현합니다.
그림 6 회로 차단기 전략 모델
격리
- 비동기 함수 비즈니스 격리: FunctionGraph는 비동기 요청 카테고리에 따라 Kafka의 소비자 그룹을 Timed Trigger Consumer 그룹, 독점 소비자 그룹, 일반 소비자 그룹으로 나누고, 비동기 메시지 재시도 소비자 그룹도 동일한 방식으로 피어 카테고리로 나눕니다. . 소비자 그룹과 토픽을 세분화하고, 예약된 트리거 서비스를 트래픽이 많은 서비스에서 분리하고, 일반 서비스를 재시도 요청 서비스에서 분리함으로써 고객 서비스 요청이 가장 높은 우선순위로 보장됩니다.
- 안전한 컨테이너 격리: 기존 CCE 컨테이너는 cgroup을 기반으로 격리되어 고객 수가 증가하고 고객 호출 수가 늘어나면 고객 간 상호 간섭이 발생하는 경우가 있습니다. 보안 컨테이너를 통해 고객 서비스가 서로 간섭하지 않도록 가상 머신 수준의 격리를 달성할 수 있습니다.
논리적 멀티 테넌시 서비스는 업그레이드에 문제가 발생하면 그 영향은 통제할 수 없습니다. FunctionGraph는 링 업그레이드(지역 내 비즈니스 위험에 따라 구분), 블루-그린 릴리스, 카나리아 릴리스 전략을 지원합니다. 업그레이드 작업은 세 단계로 간략하게 설명됩니다.
- 업그레이드 전 클러스터의 트래픽 격리: 현재 FunctionGraph가 업그레이드되면 업그레이드된 클러스터에 새로운 트래픽이 유입되지 않도록 업그레이드된 클러스터의 트래픽을 격리하는 데 우선순위가 부여됩니다.
- 업그레이드 전 트래픽 마이그레이션 및 클러스터 정상 종료: 트래픽을 다른 클러스터로 마이그레이션하고, 클러스터 업그레이드 요청이 정상적으로 종료된 후 업그레이드 작업을 수행합니다.
- 업그레이드된 클러스터는 고객별 트래픽 마이그레이션을 지원합니다. 업그레이드가 완료된 후 전화 접속 테스트 고객의 트래픽은 모든 전화 접속 테스트 사용 사례가 성공적으로 실행된 후 업그레이드된 클러스터로 전달됩니다. 이사했습니다.
FunctionGraph에서 시스템이 피할 수 없는 오류가 발생하는 경우 모니터링 및 알람 기능을 구축하여 이상 지점을 빠르게 발견하고, 미세한 장애 복구 및 시스템 중단 시간을 최소화하는 솔루션을 제공합니다. 시스템 고가용성을 위한 최후의 방어선으로서 문제를 신속하게 감지하는 능력은 매우 중요합니다. FunctionGraph는 비즈니스에 중요한 경로 주위에 여러 경보 지점을 구축했습니다. 표 2에 표시된 바와 같습니다.
표 2: FunctionGraph가 구축한 모니터링 알람
공정 사양위의 조치 중 일부는 기술 설계 수준에서 시스템 가용성 문제를 해결하며, 기술이 단기간에 문제를 해결할 수 없는 경우에는 프로세스에서 일련의 규칙과 규정을 형성하기도 합니다. 간섭. 구체적으로 다음과 같은 팀 운영 사양이 있습니다.
- 내부 상황실 프로세스: 라이브 네트워크에서 긴급 문제가 발생하면 팀은 팀 내 주요 역할을 신속하게 구성하여 라이브 네트워크 장애를 최대한 빨리 복구합니다.
- 내부 변경 검토 프로세스: 시스템 버전이 테스트 환경에 몰입되어 문제가 없음을 확인한 후, 라이브 네트워크로 공식 변경하기 전에 변경된 기능 포인트와 위험 포인트를 식별하기 위한 변경 지침을 작성해야 합니다. 팀의 주요 역할에 대한 평가를 라이브 네트워크에 적용할 수 있으며, 표준 프로세스 관리를 통해 인적 변화로 인한 이상 현상을 줄입니다.
- 정기적인 라이브 네트워크 문제 분석 및 검토: 정기적인 주간 라이브 네트워크 위험 평가, 경보 분석 및 검토, 문제를 통해 시스템 설계의 결함을 식별하고, 한 인스턴스에서 추론을 도출하고, 시스템을 최적화합니다.
클라이언트 재해 복구
업계에서 가장 발전된 클라우드 서비스라도 외부 세계에 100% SLA를 약속할 수는 없습니다. 따라서 시스템 자체나 사람의 개입조차도 짧은 시간 내에 시스템 상태를 신속하게 복원할 수 없는 경우 고객과 공동으로 설계한 재해 복구 계획이 중요합니다. 일반적으로 FunctionGraph는 고객과 협력하여 클라이언트를 위한 재해 복구 계획을 설계합니다. 시스템에 계속해서 예외가 발생하면 클라이언트는 실패 횟수가 특정 수준에 도달하면 반환을 다시 시도해야 합니다. 즉시 탈출 옵션으로 전환하는 동안 다운스트림 시스템 액세스에 대한 영향을 제한하기 위해 클라이언트 측에 회로 차단기를 설치합니다.
요약하다
FunctionGraph는 고가용성 설계를 수행할 때 일반적으로 다음과 같은 "중복성 + 장애 조치" 원칙을 따르며 비즈니스의 기본 요구 사항을 충족하면서 시스템의 안정성을 보장하고 점차적으로 아키텍처를 개선합니다.
" 중복성 + 장애 조치 "에는 다음 기능이 포함됩니다.
재해 복구 아키텍처 : 다중 클러스터 모드, 활성-대기 모드
과부하 보호 : 흐름 제어, 비동기식 피크 감소, 리소스 풀링
오류 관리 : 재시도, 캐시, 격리, 다운그레이드, 회로 차단기
그레이스케일 릴리스 : 그레이스케일 스트리밍 및 우아한 종료
클라이언트 재해 복구 : 재시도, 회로 차단기, 탈출
앞으로도 FunctionGraph는 시스템 설계, 모니터링, 프로세스 차원에서 더 많은 서비스를 구축해 나갈 것입니다. 그림 7에서 볼 수 있듯이 모니터링 기능을 구축하여 문제를 빠르게 발견하고, 신뢰성 설계를 통해 문제를 빠르게 해결하고, 프로세스 사양을 통해 문제를 줄이고, 시스템의 가용성 기능을 지속적으로 향상시켜 고객에게 더 높은 SLA 서비스를 제공할 수 있습니다.
그림 7: FunctionGraph 고가용성 반복 사례
참고자료
[1] 고가용성 정의: https://zh.wikipedia.org/zh-hans/%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7
[2]SLA 정의: https://zh.wikipedia.org/zh-hans/%E6%9C%8D%E5%8A%A1%E7%BA%A7%E5%88%AB%E5%8D%8F %E8%AE%AE
저자: 교정자: Jiulang, Wenruo