이벤트 주도 커널
이벤트 주도 커널은 무엇입니까?
EDC (Event-Driven Core) 는 비즈니스 사실을 불변의 이벤트로 캡처 및 배포하는 아키텍처의 "척추" 이며 나머지 기능 (읽기, 통합, 분석, 캐시, 알림) 은 흐름 위에 구축됩니다. 이러한 이벤트의. 커널은 이벤트 계약, 배송 규칙 및 주문/dedempotency 불변량을 설정하여 연결성과 확장 성이 약합니다.
핵심 아이디어: 먼저 사실 (핵심) 을 기록한 다음 독립적으로 풍부하게하고 원하는 모델에 투영하십시오. 이렇게하면 연결성이 줄어들고 부분 장애에 대한 복원력이
EDC 목표 및 속성
사실의 진실: 각 사건은 "무슨 일이 있었는지" 에 대한 불변의 기록입니다.
약한 연결성: 생산자는 소비자를 모른다. 가입자를 추가하여 시스템 확장.
스케일링: 파티/주제, 독립 소비자에 의한 수평 성장.
관찰 및 감사: 엔드 투 엔드 식별자, 재현성, 보류 및 재생.
관리 진화: 스키마 버전, 호환성, 감소.
건축 구성 요소
1. 버스/이벤트 중개인: Kafka/NATS/Pulsar/SNS + SQS-채널, 파티, 보류.
2. 스키마 등록 소: 호환성과 진화를위한 JSON 스키마/아브로/프로토 파.
3. 전송/CDC 윤곽: "이중 쓰기" 없이 원자 사실 수정 + 게시.
4. CQRS (Projections/Reads): 빠른 쿼리에 대한 구체화 된보기.
5. 사가/오케스트레이션: 이벤트/팀을 통한 장기 프로세스 조정.
6. 농축: 중요한 경로에 영향을 미치지 않으면 서 개별 주제 '.enriched '/' .parmed'.
7. 관찰 가능성: 추적, 로깅, 이벤트 별 지표 및 지연.
이벤트 모델
이벤트 유형
도메인 이벤트: 비즈니스 사실 ('결제. 승인 된 ',' kyc. 승인 된 ').
통합 이벤트: 외부 시스템에 중점을 둡니다 (안정적이고 천천히 변경).
CDC (Change Data Capture): 레코드에 대한 기술적 변경 (마이그레이션/통합에 사용).
감사/원격 측정: 행위자 행동, 보안, SLA.
필수 속성 (핵심)
json
{
"event_id": "uuid",
"event_type": "payment. authorized. v1",
"occurred_at": "2025-10-31T11:34:52Z",
"producer": "payments-service",
"subject": { "type": "payment", "id": "pay_123" },
"payload": { "amount": 1000, "currency": "EUR", "method": "card" },
"schema_version": 1,
"trace_id": "abc123",
"partition_key": "pay_123"
}
권장 사항: '이벤트 _ id' 는 전 세계적으로 고유하며 '파티션 _ key' 는 엔터티의 순서를 설정하고 'trace _ id' 는 상관 관계를 제공합니다.
배달 의미론 및 demmpotency
적어도 한 번 (많은 중개인의 기본 설정): 소비자는 유쾌해야합니다.
최대 한 번만: 2 차 원격 측정에만 허용됩니다.
정확히 한 번: 트랜잭션/dedempotent 키/급수 캔을 통해 흐름 및 저장 수준에서 달성되었습니다 (더 비싸고 합당한 이유가 필요함).
소비자 demempotency 패턴
'이벤트 _ id '/' (이벤트 _ id, 소비자 _ id)' 에 의한 TTL
삽입 대신 업저트; 'sequence '/' arched _ at' 에 의한 프로젝션 버전.
거래 내 거래: "saw" + 상태 변경 표시.
주문 및 분할
당사자 내에서 보장 된 명령.
동일한 집계 엔티티의 모든 이벤트가 동일한 배치 ('user _ id', 'payment _ id') 에 속하도록 'partition _ key' 를 선택하십시오.
"핫 키" 를 피하십시오: 로드를 분배해야하는 경우 소금/하위 키로 해시.
계획과 진화
첨가제 우선: 새로운 옵션 필드, 주요 버전없이 유형/의미 변경 금지.
호환성: 스키마 레지스트리의 BACKWARD/FORWARD; CI는 호환되지 않는 변경 사항을 차단합
명명: '도메인. 행동. v {major} '(' 지불. 승인 된. v1 ').
마이그레이션: 쌍 'v1' 및 'v2' 를 병렬로 게시하고, 아웃 박스를 통해 이중 쓰기를 제공하고, 전환 후 'v1' 을 촬영하십시오.
전송자 우편 번호 CDC
전송 (거래 서비스에 권장)
1. 하나의 데이터베이스 트랜잭션에서: 도메인 레코드 및 이벤트를 아웃 박스에 저장
2. 배경 게시자는 아웃 박스를 읽고 브로커에게 게시하며 "전송 된" 마크를 표시합니다.
3. 보장: 사실의 "손실", 비동기화 없음.
CDC (데이터 캡처 변경)
기존 시스템/마이그레이션에 적합합니다. 소스-DB 복제 로그.
도메인 이벤트에 필터링/트랜스 코딩이 필요합니다 (외부에서 원시 테이블을 변환하지 마십시오).
CQRS 및 프로젝션
명령은 상태를 변경하고 (종종 동기식으로) 이벤트는 투영을 형성합니다 (비동기식으로
프로젝션은 가입자가 업데이트 한 쿼리 (검색, 목록, 보고서) 를 위해 설계되었습니다.
임시 비 동기화가 표준입니다. 안정적인 UX를 보여줍니다 ("데이터는 몇 초 안에 업데이트 될 것입니다").
사가: 프로세스 조정
오케스트레이션: 한 코디네이터가 명령을 보내고 이벤트를 기다립니다.
안무: 참가자들은 서로의 사건에 반응합니다 (간단하지만 계약에 대한 징계가 필요합니다).
규칙: 명확한 보상 및 타임 아웃, 반복 가능한 단계, demotent 처리기.
관찰 가능성
추적/스팬: 이벤트를 생성 할 때 헤더를 통해 'trace _ id '/' span _ id' 추적.
지표: 소비자 지연, 출판/소비율, 데드 레터 비율, 중복 제거 점유율.
DLQ/주차장: 실패한 메시지-경고가있는 별도의 주제로; 재 처리를 제공합니다.
보안 및 준수
데이터 분류: 코어에는 필요한 최소 PII/재무 데이터 (역 피라미드 모델), 세부 정보 만 포함됩니다.
중요한 속성의 서명/해시, 무결성 제어.
기내 및 기내 암호화, 주제/컨 서머 (IAM/ACL) 별 분할 권한.
잊을 수있는 유지 정책 및 권리: 각 주제에 대해 명확하게 정의됩니다.
성능과 안정성
역압: 소비자는 경쟁이 제한되어 있고 중개인은 할당량/제한이 있습니다.
오버 헤드를 줄이기위한 배치 및 압축 그룹 레코드.
끝없는 시도 대신 지터와 DLQ가있는 Retrai.
재 균형 저항: 트랜잭션/외부에서 오프셋을 저장하고 스냅 샷으로 콜드 스타트 속도를 높입니다.
일반적인 이벤트 템플릿
지불 핵심
'지불. 시작되었습니 v1 '→' 지불. 승인 된. v1 '→' 지불. 캡처. v1 '→' 지불. 정착. v1 '
거부: '지불. 거절했다. v1 ',' 지불. 환불. v1 '
파티션: 'payment _ id'
SLA: 코어 지연 λ2c p95; 소비자 demempotence는 필수입니다.
CCM/검증
'kyc. 시작되었습니다. v1 '→' kyc. 문서. 받았다. v1 '→' kyc. 승인 된. v1 '/' kyc. 거부되었습니다. v1 '
PII - 최소; 문서 세부 정보-in 'kyc. 풍부합니다. 액세스가 제한된 v1 '.
감사/보안
'감사. 기록. v1 '은 속성' 배우 ',' 주제 ',' 동작 ',' 생성 ',' 추적 _ id '입니다.
연속 보존/보관; 강화 된 무결성 (WORM)
안티 패턴
뚱뚱한 이벤트: 불필요하게 과부하 된 페이로드, PII 누출.
이벤트를 통한 숨겨진 RPC: 동기식 "여기 및 지금" 응답을 기다립니다.
원시 CDC 외부: DB 스키마에 밀접하게 연결됩니다.
소비자의 치명적이지 않음: 두 배의 부작용으로 두 배의 부작용이 발생합니다.
"모든 것을위한" 하나의 일반적인 주제: 이해의 상충, 문제가있는 질서, 복잡한 진화.
단계별 EDC 구현
1. 도메인 매핑: 키 집계 및 수명주기 강조.
2. 이벤트 카탈로그: 이름, 의미, 불변, 필요한 필드.
3. Schemas and Registry-형식을 선택하고 호환성 규칙을 활성화하십시
4. 전송/CDC: 각 생산자에 대해 사실 게시 메커니즘을 정의하십시오.
5. 파티션: 키를 선택하고 핫 키/재 파티션을 평가하십시오.
6. 이념성: 중복 제거 패턴 + 소비자 거래성.
7. 구체화 된 모델을 정의하고 SLA를 업데이트하십시오.
8. 관찰 가능성: 추적, 지연, DLQ, 경고.
9. 보안/PII: 데이터 분류, 암호화, ACL.
10. 진화 안내: 이주를위한 버전 정책, 폐기, 이중 쓰기.
생산 점검표
- 각 이벤트에는 '이벤트 _ id', 'trace _ id', 'arsed _ at', 'partition _ key' 가 있습니다.
- 레지스트리의 계획, 호환성 검사가 활성화되었습니다.
- 소비자 신원이 구현 및 테스트되었습니다.
- DLQ/주차장 및 경고는 오류를 게시/소비하도록 구성됩니다.
- 허용 가능한 시간으로 로그 (재생) 에서 투영이 재현됩니다.
- PII에 대한 제한된 액세스; 커널에 최소 페이로드가 있습니다.
- 지연/전달에 의한 SLA는 대시 보드에서 측정되고 보입니다.
- 이벤트 버전을 마이그레이션하고 창을 제거 할 계획이 있습니다.
FAQ
EDC는 "버스" 와 어떻게 다릅니 까?
핵심은 중개인뿐만 아니라 이벤트 계약, 주문/dedempotency 규칙, 진화 프로세스 및 관찰 가능성입니다.
우리는 CDC를 기반으로 만 구축 할 수 있습니까?
CDC는 통합/마이그레이션에 적합하지만 도메인 이벤트는 의미를보다 명확하게 표현하고 데이터베이스 변경을보다 안정적으로 경험합니
일관성은 어떻습니까?
우리는 최종 일관성을 수용하고 UX/프로세스 (업데이트, 재 트레이, 보상 지표) 를 설계합니다.
정확히 한 번 필요한가요?
희귀: 배가가 엄격히 용납 될 수 없으며 보상하기가 불가능한 경우. 더 자주, 적어도 한 번 + demempotency로 충분합니다.
합계
Event-Driven 커널은 비즈니스 사실의 흐름을 시스템의 안정적인 기초로 바꿉니다. 명확한 이벤트 계약, 전달 규율 및 관찰 가능성은 취약한 동기식 연결과 변화하는 회귀의 "폭풍" 없이 확장 성, 탄력성 및 진화 속도를 산출합니다.