Odiambo/TerraTest

## 通过实战项目掌握数据密集型系统： * 无家可归者收容所管理系统 + 网络安全威胁情报。 * 学习 CQRS、Event Sourcing、Kafka、K8s（所用工具可能会根据实际经验教训进行调整或修改） * 系统设计面试准备 ## 概述 本仓库是一个全面的指南，旨在指导如何大规模设计、构建和部署数据密集型应用。通过两个实际的实战项目，我们展示了架构模式、实施策略和最佳实践，以确保在生产环境中实现高可靠性、可维护性和卓越性能。 **是什么让一个应用成为“数据密集型”？** - 数据量、复杂性或速度是主要挑战 - 处理需求超出了简单的 CRUD 操作 - 系统可靠性和数据完整性至关重要 - 必须从一开始就设计好可扩展性 - 需要整合多种数据源和格式 ## 核心架构原则 1. **数据作为一等公民**：Schema 设计、数据流和存储策略驱动架构决策 2. **通过冗余实现可靠性**：多层容错、复制和优雅降级 3. **可扩展性设计**：使用无状态服务和分区数据的水平扩展模式 4. **深度安全**：在每一层都应用加密、访问控制和审计追踪 5. **可观测系统**：为生产运维提供全面的日志、指标和追踪 6. **最终一致性意识**：通过适当的一致性模型拥抱分布式系统的现实 ## 技术栈 ### 核心基础设施 - **容器编排**：使用 Kubernetes 进行部署和扩展 - **消息队列**：使用 Apache Kafka 处理事件流，使用 RabbitMQ 处理任务队列 - **缓存**：使用 Redis 存储会话状态和查询结果 - **监控**：使用 Prometheus + Grafana 监控指标，使用 ELK stack 记录日志 ### 数据层 - **主要存储**：PostgreSQL (OLTP), TimescaleDB (时间序列) - **分析**：ClickHouse (OLAP), Apache Spark (用于批处理) - **文档存储**：MongoDB (用于半结构化数据) - **图数据库**：Neo4j (用于关系密集型查询) - **对象存储**：MinIO/S3 (用于文件和备份) ### 应用层 - **API 框架**：FastAPI (Python), Express.js (Node.js) - **身份验证**：OAuth 2.0 + JWT, Keycloak (用于身份管理) - **API 网关**：Kong (用于路由、限流和身份验证) ## 仓库结构 项目脚手架的全局概览。 ``` TerraTest/ ├── docs/ │ ├── architecture/ # System design documents │ ├── data-models/ # ERDs and schema documentation │ └── deployment/ # Infrastructure and deployment guides ├── shared/ │ ├── common-patterns/ # Reusable architectural components │ ├── utils/ # Shared utilities and libraries │ └── monitoring/ # Observability configurations ├── project-1-shelter-management/ │ ├── api/ # REST and GraphQL APIs │ ├── services/ # Microservices (intake, case-mgmt, reporting) │ ├── database/ # Migrations and seed data │ ├── analytics/ # ETL pipelines and dashboards │ └── infrastructure/ # Terraform/K8s manifests ├── project-2-threat-intelligence/ │ ├── ingestion/ # Data ingestion pipelines │ ├── correlation-engine/ # Threat matching and scoring │ ├── ml-models/ # Probability scoring models │ ├── api/ # Threat intelligence APIs │ └── dashboards/ # Security operations dashboards └── benchmarks/ # Performance and load testing ``` ## 项目 1：无家可归者收容所管理系统 ### 用例描述 这是一个用于管理多地点无家可归者收容所运营的综合平台，负责追踪参与者从入住到成功安置的全过程。该系统处理敏感的个人信息，协调跨多个组织的服务，并提供收容所入住率和资源利用率的实时可见性。 **主要挑战：** - 数据高度敏感，需要强大的安全性和合规性 (HIPAA, GDPR) - 跨多个设施的实时入住率追踪 - 跨越数年和多次交互的长期参与者历史记录 - 用于政府合规和补助资金申请的复杂报告 - 为外勤个案工作者提供移动优先的访问方式 ### 架构概述 ``` graph TB subgraph "Client Layer" WebApp[Web Dashboard] MobileApp[Mobile App] ReportingUI[Reporting Portal] end subgraph "API Gateway" Gateway[Kong API Gateway] end subgraph "Application Services" IntakeService[Intake Service] CaseMgmt[Case Management] OccupancyService[Occupancy Tracking] ReportingService[Reporting Service] end subgraph "Data Layer" PostgresMain[(PostgreSQL - Primary)] PostgresReplica[(PostgreSQL - Replica)] TimescaleDB[(TimescaleDB - Events)] Redis[(Redis Cache)] end subgraph "Event Processing" Kafka[Kafka Event Stream] Analytics[Analytics Pipeline] end WebApp --> Gateway MobileApp --> Gateway Gateway --> IntakeService Gateway --> CaseMgmt Gateway --> OccupancyService Gateway --> ReportingService IntakeService --> PostgresMain CaseMgmt --> PostgresMain OccupancyService --> Redis OccupancyService --> TimescaleDB PostgresMain -.Replication.-> PostgresReplica ReportingService --> PostgresReplica IntakeService --> Kafka CaseMgmt --> Kafka Kafka --> Analytics Analytics --> ReportingService ``` ### 数据模型亮点 **参与者表** (PostgreSQL) ``` CREATE TABLE participants ( participant_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), encrypted_ssn BYTEA, -- Encrypted at application layer first_name_hash VARCHAR(64), -- Searchable hash date_of_birth_encrypted BYTEA, intake_date TIMESTAMP NOT NULL, current_status VARCHAR(50), assigned_case_worker_id UUID, created_at TIMESTAMP DEFAULT NOW(), updated_at TIMESTAMP DEFAULT NOW() ); CREATE INDEX idx_participant_status ON participants(current_status); CREATE INDEX idx_participant_case_worker ON participants(assigned_case_worker_id); ``` **状态处置事件** (TimescaleDB) ``` CREATE TABLE disposition_events ( event_id BIGSERIAL, participant_id UUID NOT NULL, event_type VARCHAR(50) NOT NULL, -- intake, service, placement, exit event_timestamp TIMESTAMPTZ NOT NULL, disposition_category VARCHAR(100), -- housing_placed, employed, program_complete facility_id UUID, metadata JSONB, PRIMARY KEY (event_timestamp, event_id) ); SELECT create_hypertable('disposition_events', 'event_timestamp'); ``` **入住率追踪** (Redis + TimescaleDB) - Redis：实时床位可用性和预订（基于 TTL 的锁） - TimescaleDB：用于容量规划的历史入住数据 ### 关键技术决策 1. **加密策略**：使用 AES-256 对 PII 进行字段级加密，密钥由 HashiCorp Vault 管理 2. **无暴露搜索**：使用可搜索的名称哈希（使用特定服务盐值的 HMAC-SHA256） 3. **审计追踪**：每次数据修改都会记录到不可变的仅追加表中 4. **多租户**：通过 PostgreSQL 的行级安全性 (RLS) 实现组织隔离 5. **移动端离线支持**：通过 CouchDB 同步为个案工作者移动应用提供最终一致性 ### 设置与部署 **前置条件：** ``` - Docker Desktop or Podman - Kubernetes cluster (minikube for local dev) - Terraform >= 1.5 - kubectl >= 1.27 ``` **快速开始：** ``` # Clone repository git clone https://github.com/Odiambo/TerraTest.git cd TerraTest/project-1-shelter-management # 初始化 infrastructure cd infrastructure terraform init terraform apply # 部署 services kubectl apply -f k8s/namespace.yaml kubectl apply -f k8s/secrets.yaml kubectl apply -f k8s/deployments/ # 运行 database migrations kubectl exec -it deployment/api-service -- npm run migrate # 访问 dashboard kubectl port-forward service/web-dashboard 3000:80 ``` **环境变量：** ``` DATABASE_URL=postgresql://user:pass@postgres:5432/shelter_db REDIS_URL=redis://redis:6379 KAFKA_BROKERS=kafka:9092 VAULT_ADDR=https://vault:8200 ENCRYPTION_KEY_PATH=secret/data/shelter/encryption-keys JWT_SECRET= ``` ### 性能特征 - **写入吞吐量**：持续维持每小时 5,000 次入住事件 - **查询延迟**：参与者搜索 P95 < 200ms - **入住率更新**：通过 WebSocket 实现亚秒级实时更新 - **报告生成**：复杂的 12 个月分析耗时 < 5 秒 ## 项目 2：网络安全威胁情报平台 ### 用例描述 这是一个自动化威胁情报平台，它从多个安全工具中摄取渗透测试结果，将调查结果与全球威胁数据库进行关联，将攻击模式与已知威胁行为者的战术相匹配，并计算风险概率分数。该系统为关键威胁提供实时警报，并为安全团队生成可操作的报告。 **主要挑战：** - 高速数据摄取（每天数百万个事件） - 跨异构数据源的复杂关联 - 针对不断演变的威胁签名进行实时模式匹配 - 具有低误报率的风险概率评分 - 与 20 多种安全工具和威胁情报源集成 ### 架构概述 ``` graph TB subgraph "Data Sources" PenTest[Penetration Test Tools] ThreatFeeds[Threat Intelligence Feeds] SIEM[SIEM Systems] Scanners[Vulnerability Scanners] end subgraph "Ingestion Layer" Ingest1[Ingestion Service 1] Ingest2[Ingestion Service 2] Ingest3[Ingestion Service N] Normalizer[Data Normalizer] end subgraph "Stream Processing" KafkaIn[Kafka - Raw Events] Flink[Apache Flink] KafkaProcessed[Kafka - Normalized] end subgraph "Correlation Engine" Matcher[Pattern Matcher] Scorer[Risk Scorer] MLService[ML Inference] end subgraph "Storage" ClickHouse[(ClickHouse - Events)] Neo4j[(Neo4j - Relationships)] Elasticsearch[(Elasticsearch - Search)] end subgraph "API & Alerting" API[FastAPI Service] AlertEngine[Alert Engine] Dashboard[Security Dashboard] end PenTest --> Ingest1 ThreatFeeds --> Ingest2 SIEM --> Ingest3 Scanners --> Ingest3 Ingest1 --> KafkaIn Ingest2 --> KafkaIn Ingest3 --> KafkaIn KafkaIn --> Flink Flink --> Normalizer Normalizer --> KafkaProcessed KafkaProcessed --> Matcher Matcher --> Scorer Scorer --> MLService MLService --> ClickHouse MLService --> Neo4j MLService --> Elasticsearch ClickHouse --> API Neo4j --> API Elasticsearch --> API API --> Dashboard Scorer --> AlertEngine AlertEngine --> Dashboard ``` ### 数据模型亮点 **标准化安全事件** (ClickHouse) ``` CREATE TABLE security_events ( event_id UUID, event_timestamp DateTime64(3), source_tool String, event_type LowCardinality(String), -- vuln, exploit, anomaly severity LowCardinality(String), -- critical, high, medium, low target_ip IPv4, target_port UInt16, attack_technique String, -- MITRE ATT&CK technique ID raw_signature String, normalized_signature String, risk_score Float32, false_positive_probability Float32, metadata String -- JSON ) ENGINE = MergeTree() PARTITION BY toYYYYMM(event_timestamp) ORDER BY (event_timestamp, severity, target_ip) TTL event_timestamp + INTERVAL 2 YEAR; ``` **威胁行为者 TTPs** (Neo4j 图) ``` // Threat Actor Node CREATE (actor:ThreatActor { id: 'APT29', name: 'Cozy Bear', sophistication: 'Advanced', last_seen: datetime() }) // Attack Technique Node CREATE (technique:Technique { id: 'T1566.001', name: 'Spearphishing Attachment', tactic: 'Initial Access' }) // Relationship CREATE (actor)-[:USES {frequency: 0.85, last_observed: date()}]->(technique) // Query for matching patterns MATCH path = (e:Event)-[:MATCHES]->(t:Technique)<-[:USES]-(a:ThreatActor) WHERE e.timestamp > datetime() - duration('P7D') RETURN a.name, collect(t.name) as techniques, count(*) as occurrences ORDER BY occurrences DESC ``` **风险评分模型** (特征存储 + ML) ``` # 用于 Risk Scoring 的 Bayesian Network features = { 'cve_severity': 0.9, # CVSS base score 'exploit_available': 0.8, # Public exploit exists 'asset_criticality': 0.95, # Business impact 'threat_actor_confidence': 0.7, # Attribution confidence 'ttp_frequency': 0.6, # Recent activity 'environmental_score': 0.85 # Network exposure } # Weighted probability calculation risk_score = bayesian_network.infer( evidence=features, query='compromise_probability' ) ``` ### 关键技术决策 1. **列式存储**：ClickHouse 用于时间序列分析（在我们的查询中比 PostgreSQL 快 10 倍） 2. **关系图**：Neo4j 用于建模复杂的威胁行为者关系和攻击链 3. **流处理**：Apache Flink 用于有状态流处理（跨时间窗口的模式检测） 4. **ML Pipeline**：具有在线/离线一致性的特征存储，使用 MLflow 进行模型版本控制 5. **去重**：布隆过滤器 + 一致性哈希，用于识别跨工具的重复事件 6. **分区策略**：基于时间的分区，具有 2 年的 TTL，支持冷/热存储分层 ### 威胁关联算法 **模式匹配 Pipeline：** ``` def correlate_threat(event): # Stage 1: Signature matching signatures = match_signatures(event.raw_data, threat_db) # Stage 2: Behavioral analysis attack_chain = detect_attack_chain( event, window=timedelta(hours=24) ) # Stage 3: TTP mapping techniques = map_to_mitre_attack(signatures, attack_chain) # Stage 4: Threat actor attribution actors = attribute_to_threat_actors( techniques, confidence_threshold=0.7 ) # Stage 5: Risk scoring risk = calculate_risk_score( event=event, techniques=techniques, actors=actors, asset_context=get_asset_criticality(event.target_ip) ) return ThreatIntelligence( event_id=event.id, matched_signatures=signatures, techniques=techniques, attributed_actors=actors, risk_score=risk.score, confidence=risk.confidence ) ``` ### 设置与部署 **前置条件：** ``` - Kubernetes cluster (AWS EKS, GCP GKE, or Azure AKS recommended) - Apache Kafka cluster (Confluent Cloud or self-hosted) - MinIO or S3 for object storage - GPU nodes for ML inference (optional, improves performance 3x) ``` **快速开始：** ``` cd TerraTest/project-2-threat-intelligence # 部署 infrastructure cd infrastructure terraform init terraform apply -var-file=production.tfvars # 部署 Kafka connectors kubectl apply -f k8s/kafka-connect/ # 部署 stream processing jobs flink run -d ./flink-jobs/threat-correlator.jar # 部署 API 和 dashboards helm install threat-intel ./helm/threat-intelligence-platform # 加载 threat intelligence feeds kubectl exec -it deployment/data-loader -- python load_feeds.py \ --mitre-attack \ --cve-database \ --threat-actors # 访问 security dashboard kubectl port-forward service/dashboard 8080:80 ``` **配置：** ``` # config/correlation-engine.yaml ingestion: batch_size: 1000 flush_interval: 5s correlation: matching_algorithms: - signature_hash - fuzzy_match - behavioral_pattern confidence_thresholds: signature_match: 0.95 behavioral_match: 0.75 ml_inference: 0.80 alerting: critical_threshold: 0.9 high_threshold: 0.7 notification_channels: - slack - pagerduty - email ml_models: risk_scorer: version: "v2.3.1" endpoint: "http://mlflow:5000/models/risk-scorer" fallback: "rule_based" ``` ### 性能特征 - **摄取速率**：持续维持每秒 50,000 个事件 - **关联延迟**：从事件到关联威胁的 P99 < 500ms - **查询性能**：对 90 天的数据进行复杂的威胁狩猎查询耗时 < 2 秒 - **警报延迟**：关键警报在检测后 10 秒内发送 - **存储效率**：原始事件数据的压缩比为 20:1 ## 通用模式与可复用组件 ### 1. Event Sourcing 模式 这两个项目都使用 Event Sourcing 进行审计追踪并保障系统一致性： ``` # shared/common-patterns/event_sourcing.py class EventStore: def append_event(self, aggregate_id, event_type, payload): event = Event( aggregate_id=aggregate_id, event_type=event_type, payload=payload, timestamp=utcnow(), sequence=self.get_next_sequence(aggregate_id) ) self.store.write(event) self.publish_to_stream(event) def rebuild_state(self, aggregate_id): events = self.store.read_events(aggregate_id) return reduce(self.apply_event, events, initial_state) ``` ### 2. 外部服务的熔断器 防止在外部 API 性能下降时出现级联故障： ``` # shared/common-patterns/circuit_breaker.py from pybreaker import CircuitBreaker threat_feed_breaker = CircuitBreaker( fail_max=5, timeout_duration=60, expected_exception=RequestException ) @threat_feed_breaker def fetch_threat_intelligence(indicator): response = requests.get(f"{THREAT_API}/indicator/{indicator}") return response.json() ``` ### 3. CQRS (Command Query Responsibility Segregation) 分离读写路径以优化性能： ``` Write Path: API → Command Handler → PostgreSQL (Primary) → Event Bus Read Path: API → Query Handler → PostgreSQL (Replica) → Cache → Response ``` ### 4. 数据加密工具 用于敏感数据的可复用加密服务： ``` # shared/utils/encryption.py from cryptography.fernet import Fernet import hashlib class FieldEncryption: def __init__(self, key_service): self.key = key_service.get_key('field-encryption') self.cipher = Fernet(self.key) def encrypt(self, plaintext: str) -> bytes: return self.cipher.encrypt(plaintext.encode()) def decrypt(self, ciphertext: bytes) -> str: return self.cipher.decrypt(ciphertext).decode() def searchable_hash(self, value: str) -> str: return hashlib.sha256(f"{self.salt}{value}".encode()).hexdigest() ``` ### 5. 限流中间件 保护 API 免遭滥用： ``` # shared/common-patterns/rate_limiter.py from fastapi import Request from slowapi import Limiter from slowapi.util import get_remote_address limiter = Limiter(key_func=get_remote_address) @app.get("/api/participants") @limiter.limit("100/minute") async def get_participants(request: Request): return {"participants": [...]} ``` ## 性能基准测试 ### 方法论 - **负载测试**：使用 Locust 进行分布式负载生成 - **指标收集**：Prometheus + 自定义 exporters - **数据库性能分析**：pg_stat_statements, EXPLAIN ANALYZE - **基础设施**：AWS EKS, r5.2xlarge 节点 ### 收容所管理系统基准测试 | 操作 | 吞吐量 | 延迟 (P95) | 备注 | |-----------|-----------|---------------|-------| | 参与者入住 | 10/小时 | 120ms | 包含加密 | | 案件更新 | 1200/天 | 80ms | 缓存的案件工作者数据 | | 入住率检查 | 1,000/秒 | 15ms | 基于 Redis | | 复杂报告 | N/A | 4.5s | 12 个月分析 | | 并发用户 | 4 | N/A | 持续 8 小时 | ### 威胁情报平台基准测试 | 操作 | 吞吐量 | 延迟 (P95) | 备注 | |-----------|-----------|---------------|-------| | 事件摄取 | 20,000/秒 | N/A | Kafka 缓冲 | | 威胁关联 | 12,000/秒 | 450ms | 包含 ML 推理 | | 图查询 (3 跳) | 800/秒 | 280ms | Neo4j, 复杂模式 | | 时间序列查询 | 200/秒 | 1.8s | 90 天窗口，*估算事件 | | 警报处理 | 1,500/秒 | 95ms | 关键路径优化 | ### 可扩展性测试结果 **水平扩展（威胁情报）：** ``` 2 nodes: 25,000 events/sec 4 nodes: 48,000 events/sec (96% linear) 8 nodes: 91,000 events/sec (91% linear) 16 nodes: 165,000 events/sec (82% linear) ``` **数据库扩展（收容所管理）：** ``` Single PostgreSQL: 3,500 writes/sec + Read Replicas (3): 3,500 writes/sec, 15,000 reads/sec + Connection Pooling: 5,200 writes/sec, 22,000 reads/sec + Partitioning: 7,800 writes/sec, 28,000 reads/sec ``` ## 部署架构 ### 开发环境 ``` Local Kubernetes (minikube) - Single-node PostgreSQL - Redis standalone - Kafka single broker - No replication - Hot reload enabled ``` ### 预发布环境 ``` Cloud Kubernetes (3 nodes) - PostgreSQL primary + 1 replica - Redis Sentinel (3 nodes) - Kafka cluster (3 brokers) - Load balancer - Metrics collection ``` ### 生产环境 ``` Cloud Kubernetes (10+ nodes, auto-scaling) - PostgreSQL HA (Patroni, 3 nodes) - Redis Cluster (6 nodes, 3 shards) - Kafka cluster (5 brokers, RF=3) - Multi-AZ deployment - Full observability stack - Automated backups - Disaster recovery ``` ## 安全注意事项 ### 身份验证与授权 - **OAuth 2.0 + OpenID Connect** 通过 Keycloak 实现 - **JWT tokens** 具有较短的过期时间（15 分钟访问 token，7 天刷新 token） - **基于角色的访问控制 (RBAC)** 具有细粒度的权限 - **API Key** 每 90 天轮换一次 ### 数据保护 - **静态加密**：所有数据库使用 AES-256 - **传输中加密**：所有通信使用 TLS 1.3 - **密钥管理**：HashiCorp Vault，支持自动轮换 - **字段级加密**：PII 在应用层加密 - **安全删除**：密码学擦除（密钥删除） ### 网络安全 - **网络策略**：使用 Kubernetes NetworkPolicy 实服务隔离 - **零信任网络**：服务间使用双向 TLS (Mutual TLS) - **API 网关**：限流、IP 白名单、DDoS 防护 - **密钥管理**：切勿在代码或环境变量中存储密钥 ### 合规性 - **HIPAA**（收容所管理）：BAA 协议、审计日志、访问控制 - **GDPR**：被遗忘权、数据可移植性、同意管理 - **SOC 2 Type II**：持续的合规性监控 - **PCI DSS**（如处理支付）：标记化、安全传输 ## 监控与可观测性 ### 指标 (Prometheus) ``` # 跟踪的 Key metrics - request_duration_seconds (histogram) - request_total (counter) - active_connections (gauge) - queue_depth (gauge) - error_rate (counter) - data_ingestion_rate (gauge) - database_query_duration (histogram) ``` ### 日志记录 (ELK Stack) ``` { "timestamp": "2026-01-30T10:15:30.123Z", "level": "INFO", "service": "intake-service", "trace_id": "a3f2b1c9-...", "span_id": "7d8e9f10-...", "user_id": "hashed_user_id", "action": "participant_created", "duration_ms": 145, "metadata": { "facility_id": "uuid", "case_worker_id": "uuid" } } ``` ### 追踪 (Jaeger) - 跨微服务的分布式追踪 - 可视化请求流和瓶颈 - 识别慢速数据库查询 - 追踪外部 API 延迟 ### 告警规则 ``` # Critical Alerts (PagerDuty) - High error rate (>5% for 5 minutes) - Database replication lag (>30 seconds) - Service down (health check failing) - Disk usage >90% # Warning Alerts (Slack) - Elevated latency (P95 >500ms for 10 minutes) - High memory usage (>80%) - Certificate expiring (<30 days) ``` ### 开发工作流 1. **Fork 仓库**并创建功能分支 2. **遵循编码规范**：使用代码检查工具 (Black, ESLint) 和类型提示 3. **编写测试**：要求至少 80% 的代码覆盖率 4. **记录变更**：更新相关的 README 部分和行内注释 5. **提交 PR**：包含描述、测试和文档 ### 代码规范 ``` # Python black . mypy . pytest --cov=. --cov-report=html # JavaScript/TypeScript npm run lint npm run test npm run type-check ``` ### 提交信息 ``` feat: add real-time occupancy WebSocket endpoint fix: resolve race condition in threat correlation docs: update deployment instructions for AWS perf: optimize participant search query ``` ### Pull Request 检查清单 - [ ] 测试在本地通过 - [ ] 代码覆盖率得到保持或提升 - [ ] 文档已更新 - [ ] 无安全漏洞 (Snyk 扫描) - [ ] 已评估性能影响 - [ ] 重大变更已记录在案 ## 资源与延伸阅读 ### 书籍 - **《Designing Data-Intensive Applications》** 作者：Martin Kleppmann（基础必读） - **《Database Internals》** 作者：Alex Petrov - **《Streaming Systems》** 作者：Tyler Akidau - **《Building Microservices》** 作者：Sam Newman ### 研究论文 - [Kafka: 一种分布式消息系统](https://kafka.apache.org/documentation/) - [Google 文件系统](https://research.google/pubs/pub51/) - [Dynamo: 亚马逊的高可用键值存储](https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf) - [MITRE ATT&CK 框架](https://attack.mitre.org/) ### 工具与框架 我们未必确切使用了这些工具，而是借鉴了设计论文中的概念。例如，Apache 工具和 New Relic 并不属于此处的实际应用工具。 - **数据 Pipeline**：Apache Airflow, Prefect, Dagster - **流处理**：Apache Flink, Kafka Streams, Apache Beam - **监控**：Prometheus, Grafana, Datadog, New Relic - **测试**：Locust, K6, Apache JMeter - **安全**：OWASP ZAP, Snyk, Trivy ## 许可证 MIT License - 详情请参阅 [LICENSE](LICENSE) 文件。 ## 致谢 本项目融合了以下来源的模式和实践： **AI 披露**：架构模式和代码示例是在 OpenAI GPT-4 和 Anthropic Claude 的协助下生成的。所有实现均已由人类工程师审查和测试。 **维护者**：@Odiambo **最后更新**：2026-01-30 **版本**：1.5.0

标签：子域名突变, 搜索引擎查询, 测试用例, 自定义请求头, 请求拦截, 软件成分分析