GH GambleHub

리버스 피라미드 모델

건축에서 "역 피라미드 모델" 은 무엇입니까?

리버스 피라미드 모델은 가장 중요하고 필요한 정보/기능이 먼저 전송되고 보장되며 덜 중요한 세부 사항이 점진적이고 선택적으로 추가되는 시스템 및 프로토콜을 설계하는 방법입니다. 이 용어는 저널리즘에서 아이디어를 빌려 주지만 (가장 중요한 것은 처음에는) 엔지니어링 작업에 적합합니다. 중요한 경로는 모든 조건에서 작동하며 다른 모든 것은 "강화 계층" 입니다.

직관적 인 그림: 맨 위의 좁은 상단은 "최소 보증 계약" (MGC) 이며, 다음은 리소스/호환성이있는 경우 시스템이 적용하는 확장, 최적화 및 풍부한 기능입니다.


적용되는 곳

네트워크 프로토콜 및 API: REST/gRPC/GraphQL, 웹 후크, 이벤트 브로커.
스트리밍 채널: WebSo, SSE, Kafka/NATS, RTC.
서비스 아키텍처: 중요한 경로 대 부작용 (감사, 분석, 캐시 온난화).
모바일/웹 클라이언트: 먼저 "스켈레톤" UI 및 키 데이터, 미디어 및 권장 사항의 게으른로드.
지불 및 위험 체인: 승인/예약 - 우선 순위; 사기 방지/분석-마감일과 함께 비동기식.
관찰 가능성: 항상 로그/최소 레벨 메트릭; 추적/프로파일 링-샘플링으로.


모델 원칙

1. 최소 보증 계약 (MGC)

스크립트가 의미가없는 일련의 필드와 작업. 안정적이고 역 호환되며 먼저 통과합니다.

2. 점진적 강화

추가 필드/기능은 선택적 확장 (기능/기능 플래그/협상) 으로 제공됩니다.

3. 실패없이 분해

과부하되거나 부분적으로 사용할 수없는 경우 시스템은 선택적 레이어를 버리고 MGC를 계속 작동시킵니다.

4. 명시 적 우선 순위 및 SLA

각 계층에는 자체 SLO (대기 시간, 가용성), 대기열 및 서비스 클래스 (QoS) 가 있습니다.

5. 회로의 첨가제 진화

새로운 필드는 nullable/옵션으로 추가되며 클라이언트를 깨뜨리지 마십시오. 새로운 버전을 통해서만 어려운 변화.

6. 계층 별 관찰 가능

메트릭스와 로그는 '핵심' 이라는 비판으로 표시됩니다. ',' enh. ',' 배치. 시스템이 무엇을 희생하는지 확인합니다.


"클래식" 레이어 피라미드와 비교

고전적인 아키텍처 (하단-기본, 상단-UI) 는 종속성을 강조합니다.
리버스 피라미드는 전달의 중요성과 순서를 강조합니다. 첫 번째 "핵심", "좋아요".


모델 프로토콜 설계

1) REST/HTT

MGC: 최소 리소스/엔드 포인트 및 필요한 필드.

확장:
  • 콘텐츠 부정 ('수락', '선호'),
  • 매개 변수 '? = '/' 를 포함합니까? 선택적 세분성을 위해 fields = ',
  • 인라인 대신 "무거운" 첨부 파일 (사전 서명 된 GPS) 에 연결합니다.
  • 분해: 타임 아웃시 중첩 된 컬렉션없이 MGC를 제공하십시오. 큰 몸을위한 206 부분 내용
  • Versioning: 오래된 계약을 변경하지 않고 추가 분야; 변경 사항 위반에 대해서만 주요 버전.

2) gRPC

프로토: 안전한 태그 번호를 가진 새로운 '선택적' 필드; 삭제된 태그를 재사용하지 않습니다.
서버 측 마감일 및 방법 별 QoS (우선 순위보다 중요한 RPC).
스트리밍: 첫 번째 메시지-헤더/합계, 청크로 디테일.

3) 이벤트 버스 (Kafka/NATS)

이벤트 코어: 최소한의 비즈니스 분야 인 '이벤트 _ 유형', 'id', '발생 _ at'.
농축: 우리는 아웃 박스/CDC 및 개별 주제 '강화' 를 사용합니다.

먼저, 세부 사항을 요약하십시오. 소비자는 핵심적으로 비즈니스 프로세스를 완료 할 수 있으며 세부 사항은 비동기식으로로드됩


리버스 피라미드에 잘 맞는 패턴

기능 검색 - 서버/클라이언트는 어떤 확장이 지원하는지 명시 적으

중요 경로 우선: 비동기 부작용과 동기식 "필수" 를 분리하십시오.
쓰기/전송: 이벤트의 사실을 기록하고 나머지는 배경 전달입니다.
게으름 및 증분 가져오기: 페이지 매김, 커서, 'If-Modified-Since '/ETag.
역압 및 예산: 마감일, 계층 당 CPU/IO 제한; 로드중인 2 차 작업 취소.
SLO-Scoped Caching: "핵심" 을보다 적극적으로 풍부하게 캐시합니다.


구현 알고리즘

1. 시나리오 매핑: 사용자 여행을 적고 "가치의 순간" 을 강조하십시오.
2. MGC 정의: 가치를 달성하기위한 최소 필드/작업.
3. '핵심', '확장', '분석/배치' 레이어로 나뉩니다.
4. 각 레이어에 대해 SLO/SLA 및 QoS를 설정하십시오.
5. 설계 저하: N% 고장/p95 성장시 무엇을 버립니까?
6. 체계의 진화: 버전 정책, 첨가제.
7. 관찰 가능성: 메트릭/로그/트랙의 레이어 태그, "코어" 에 대한 경고.
8. 테스트: 혼돈 공학 및 계층별 결함 주입.
9. 출시 및 피드백: 가상의 확장을 켜고 카나리아에서 출시하십시오.


계층별로 측정 및 SLO

핵심: p95/p99 대기 시간, 성공적인 중요 작업의 백분율, 분해 중 내결함성.
확장: 농축 응답의 백분율, 평균 로딩 시간.
배치/분석: 실시간 지연, 창당 처리 된 이벤트의 비율.
비즈니스 지표: 대 과부하에서 "가치 지점" 으로 변환하는 것은 정상입니다.


반 패턴

"모든 것이 핵심입니다": 확장이 필수가되고 열화가 불가능 해집니다

새로운 메이저 버전없이 MGC를 깨뜨립니다.
숨겨진 취약성: 중요한 경로는 외부 "2 차" 종속성 (예: 동기 사기 방지 호출) 에 의존합니다.
암시 적 확장: 고객은 무엇을 활성화/비활성화 할 수 있는지 모릅니다.
관찰 가능성 부족: 시스템이 "조용히" 저하되고 어디에서 볼 수 없습니다.


A. 사용자 프로필 (REST)

MGC: 'id', 'display _ name', 'avatar _ url', 'tier'.
확장: 'badges []', 'social _ links []', '최근 _ activity []' by '? = '를 포함합니다.
분해: 타임 아웃시 MGC를 제공하고 공유 리소스 (HATEOAS/IM) 에 대한 링크를 제공하십시오.

B. 지불 승인

MGC: 승인 결과 (승인/거부), 'trange _ id', 'male', '통화'.
확장: 3DS 원격 측정, 위험률, 지리, 파트너 속성-이벤트 지불에 의한 비동기식. 승인 된 '.
분해: 분석이 실패하면 지불이 진행되고 감사/점수가 따라 잡습니다.

B. 스트림 인용구

MGC: 최신 가격 "스냅 샷".
확장: 유리 깊이, 집계 표시기-스냅 샷 후 스트리밍.
분해: 로드시 확장 업데이트 빈도는 떨어지지 만 스냅 샷은 안정적입니다.


진전과 진화

추가 우선: 새로운 필드 '선택/무효화', 오래된 필드가 남아 있습니다.
시맨틱 버전: 커널의 경우 'v1'; 'v1. x '- 확장;' v2 '-MGC가 변경 될 때.
코드 계약: "깨지지 않는" 확산의 JSON 스키마/프로토콜 + CI 유효성 검증.


안전 및 준수

MGC 서명/인증: 최소 필드 세트에는 암호화 무결성이 있습니다.
최소 특권: 개별 범위에 의한 농축 액세스.
PII/재무 데이터: 확장, 키 분리 및 TTL 테이크 아웃.


관찰 가능성 및 디버깅

메트릭 접두사: '핵심. 요청. 지속 시간 ',' enh. 첨부. (PHP 3 = 3.0.6, PHP 4) 지연 '.
샘플링: 핵심 오류에 대한 100% 로그; 샘플 확장.
기능 플래그 원격 측정: 어떤 고객을 위해 어떤 확장이 활성화되어 있는지 확인할 수 있습니다.


구현 점검표 (짧은)

  • MGC가 정의되고 문서화되었습니다.
  • 확장은 기능/플래그를 통해 선언됩니다.
  • 레이어별로 SLO/QoS/큐를 구성했습니다.
  • 혼돈 테스트로 테스트 된 분해.
  • 체계의 진화는 "브레이크" 가없는 추가적인 것입니다.
  • 메트릭/트레일/로그가 계층화되어 있습니다.
  • 고객이 확장을 가능하게하는 문서.

FAQ

리버스 피라미드가 레이어 아키텍처를 대체

아니요, 그렇지 않습니다. 이것은 직교 원리입니다. 친숙한 계층보다 기능을 제공하고 우선 순위를 정하는 방법.

신청하지 않을 때?
부분 전달이 의미가없는 오프라인 패키지 (원자 성이있는 암호화 프로토콜) 또는 모든 필드가 동일하게 중요한 경우.

우아한 타락과 다른 점은 무엇입니까?
리버스 피라미드는 처음에 최소 충분한 계약과 우선 순위를 투영하며 "사실 이후" 이미 과부하 된 시스템을 저장하려고 시도하지 않습니다.


결과

리버스 피라미드 모델은 아키텍처와 프로토콜이 모든 부하에서 유용하게 유지되도록 도와줍니다. 가장 먼저 중요한 것은 가능한 경우 나머지. 이것은 임계 경로의 가용성을 높이고 기능의 표시 속도를 높이며 고장없이 진화를 단순화합니다.

Contact

문의하기

질문이나 지원이 필요하시면 언제든지 연락하십시오.우리는 항상 도울 준비가 되어 있습니다!

통합 시작

Email — 필수. Telegram 또는 WhatsApp — 선택 사항.

이름 선택 사항
Email 선택 사항
제목 선택 사항
메시지 선택 사항
Telegram 선택 사항
@
Telegram을 입력하시면 Email과 함께 Telegram에서도 답변드립니다.
WhatsApp 선택 사항
형식: +국가 코드 + 번호 (예: +82XXXXXXXXX).

버튼을 클릭하면 데이터 처리에 동의하는 것으로 간주됩니다.