MonaNorouzi/GitHub-architecture-reverse-engineering

# GitHub 全面逆向工程：架构、SCM 与数据库设计 ## 执行摘要 本仓库包含对 GitHub 平台的高层架构与数据级逆向工程，其基础源于软件配置管理 (SCM) 和分布式系统的原理。通过结合自上而下（从 UI 到架构）和自下而上（从 GraphQL 到数据库）的分析方法，我们揭示了平台底层的结构范式。 本文档记录的关键技术发现包括： * **SCM 引擎与 Git DAG：** 作为内容寻址文件系统运行的基础版本控制机制，依赖于由 `Blob`、`Tree` 和 `Commit` 对象组成的有向无环图 (DAG) 的数学遍历。 * **架构演进：** 从单体 Ruby on Rails 核心向事件驱动的微服务生态系统（例如 GitHub Actions）的过渡，并受到高可用缓存层（Redis/Memcached）的强力支持。 * **数据库多态：** 关系型数据库的实现，其中 `Pull Requests` 和 `Issues` 利用了单表继承概念，这可以通过 GitHub 的 GraphQL API 结构进行验证。 * **状态转换：** 在 Pull Request 生命周期中发生的异步、事务性数据库状态变更，由后台 worker 和外部 CI Webhook 协同编排。 ## 1. 自上而下发现：用例与行为建模 下图说明了 Pull Request 生命周期中的主要系统参与者和核心操作处理逻辑。 ``` flowchart LR %% External Actors Dev([Developer]) Maintainer([Repository Maintainer]) CIBot([CI/CD Microservice]) %% System Boundary subgraph GitHub Core Platform UC1((Initialize Branch & Push)) UC2((Instantiate Pull Request)) UC3((Execute Integration Tests)) UC4((Conduct Code Review)) UC5((Execute Merge Transaction)) end %% Actor Relationships Dev --> UC1 Dev --> UC2 CIBot --> UC3 Maintainer --> UC4 Maintainer --> UC5 %% Internal Dependencies UC2 -. Async Trigger .-> UC3 UC3 -. CI Status Payload .-> UC5 ``` ## 2. 自下而上发现：多态数据架构 通过逆向工程 GraphQL API 端点，我们映射了底层的关系型数据库结构。请注意其中的多态关系，即 Pull Request 充当了 Issue 的专门扩展。 ``` erDiagram USER ||--o{ REPOSITORY : owns USER ||--o{ ISSUE : authors REPOSITORY ||--o{ ISSUE : contains REPOSITORY ||--o{ COMMIT : stores ISSUE ||--o| PULL_REQUEST : "polymorphic extension" PULL_REQUEST ||--o{ COMMIT : encapsulates USER { int id PK string username string email } REPOSITORY { int id PK int owner_id FK string repository_name } ISSUE { int id PK int repository_id FK int author_id FK string lifecycle_state "Open / Closed" } PULL_REQUEST { int issue_id PK, FK string head_branch_ref string base_branch_ref boolean mergeable_status } COMMIT { string sha_hash PK int repository_id FK string tree_sha_pointer } ``` ## 3. SCM 处理逻辑：Pull Request 状态转换 此序列图细致地追踪了数据库状态转换，以及 Rails 单体架构、后台 Worker（可合并性检查）和 GitHub Actions (CI) 之间的协同编排。 ``` sequenceDiagram actor Dev as Developer participant API as API Gateway (Routing) participant Rails as Rails Monolith participant DB as Relational DB (MySQL) participant Worker as Async Job (Diffing) participant CI as GitHub Actions actor Maint as Maintainer Dev->>API: POST /pulls (Create PR) API->>Rails: Route Request Rails->>DB: INSERT Issue (State: Open) Rails->>DB: INSERT PR (Mergeable: NULL) Rails-->>API: 201 Created Response Rails->>Worker: Enqueue Background Mergeability Check Rails->>CI: Dispatch Webhook (Event: pull_request) Worker->>Worker: Traverse Git DAG & Calculate Diff Worker->>DB: UPDATE PR (Mergeable: True) CI->>CI: Execute CI/CD Pipeline CI->>Rails: PATCH /status (Payload: Success) Rails->>DB: UPDATE Commit Status (Status: Success) Maint->>API: POST /merge (Accept PR) API->>Rails: Route Merge Request Rails->>Worker: Execute Low-level `git merge` Worker-->>Rails: Merge Confirmation Rails->>DB: UPDATE Issue (State: Closed) Rails->>DB: UPDATE PR (State: Merged) Rails-->>API: Return Finalized State UI Render ``` ## 4. 高层系统组件架构 GitHub 分布式组件的物理部署与交互，突出了集中式 Rails 单体架构、缓存优化层和解耦的微服务。 ``` flowchart TB %% External Interfaces Client[Client Browser / Git CLI] %% Network Routing LB[Load Balancers / HAProxy] %% Transient Data / Optimization subgraph Caching Layer Redis[(Redis / Memcached Clusters)] end %% Core Application subgraph Monolithic Core Routing[API Gateway / Router] Rails[Ruby on Rails Application] Routing --> Rails end %% Decoupled Services subgraph Event-Driven Architecture Kafka[Kafka Message Broker] Actions[GitHub Actions K8s Cluster] Kafka --> Actions end %% Persistent Storage subgraph Persistence Layer DB[(MySQL / Vitess Shards)] GitFS[(Spokes / Git File Servers)] end %% Component Interconnections Client --> LB LB --> Routing Routing --> Redis Rails --> DB Rails --> GitFS Rails --> Kafka Actions -. Status Callback .-> Routing ```

标签：子域名突变, 搜索引擎查询