docs: 完善分布式部署指南并增加端口映射表

> ```

#### 命令区别与集群部署指南：

*   **`make up`**：启动核心调度服务（Scheduler、API Server、DAG Processor）、API Gateway (网关 38000 端口) 以及数据库组件（Postgres、Redis、Elasticsearch、Kibana 等）。**注意：它不会启动实际执行任务的 Celery Worker。**

*   **`make up-master`**：不仅执行 `make up` 的所有内容，还会**额外启动 Flower 服务**（一个用于监控 Celery 队列状态的 Web UI）。

    *   *为什么 Flower 不作为默认启动？* 因为它是可选的可视化组件。官方出于节省服务器资源和安全考量，将其设置为按需启动。

*   **`make up-worker`**：**专门用于启动 Celery Worker 容器**。

    *   *分布式部署场景*：您可以在多台不同的机器上克隆本代码，并**仅运行** `make up-worker` 来横向扩展计算能力。

在分布式部署场景中，我们将系统分为“主控节点（Master）”和“计算节点（Worker）”。

*   **`make up` (启动主控节点基础组件)**：

    此命令会启动主控节点运行所需的**所有核心组件**，包括：

    1. **调度与接口**：Airflow Scheduler（负责调度任务）、Airflow API Server（提供官方接口）、API Gateway（对外提供 38000 端口的高并发网关）。

    2. **底层数据库与缓存**：PostgreSQL（元数据库）、Redis（消息队列中间件）。

    3. **日志平台**：Elasticsearch、Kibana、Filebeat（负责收集和展示任务日志）。

    > **⚠️ 注意**：它**不会**启动真正执行任务的 `Celery Worker`。如果只运行此命令，您的任务会一直卡在 `queued`（排队）状态。

*   **`make up-master` (启动主控节点完整组件)**：

    此命令包含了 `make up` 的**所有上述核心组件**，并且**额外启动了 Flower 监控面板**（运行在 35555 端口）。

    *   *什么是 Flower？* 它是 Celery 的可视化监控工具，供管理员实时查看集群中有多少个 Worker 在线、任务在队列中的积压情况等。

    *   *为什么推荐在主节点使用此命令？* 在完整的生产环境中，主控节点通常需要提供完善的监控能力，因此推荐使用此命令拉起整个控制平面。

*   **`make up-worker` (启动计算节点)**：

    **专门用于启动 `Celery Worker` 容器**。

    *   *单机部署*：在同一台机器上，执行完 `make up-master` 后，必须再执行此命令，系统才算真正拥有了算力，任务才会开始执行。

    *   *分布式扩展*：您可以在 10 台不同的物理机上克隆本代码，修改它们 `.env` 文件中的 `MASTER_IP` 指向主控节点，然后**仅运行 `make up-worker`**，即可实现计算算力的无限横向扩展。

---

| `make clean` | 停止服务并清理容器 |

| `make ps` | 列出运行中的服务 |

## 访问服务与系统

## 访问服务与系统端口映射

在完整的分布式或单机部署中，各个组件所占用的宿主机端口如下。**请在部署前确保宿主机的这些防火墙端口已开放且未被占用**。

- **统一 API Gateway**: `http://<MASTER_IP>:38000` (业务系统唯一对接入口)

- **Airflow Web UI**: `http://<MASTER_IP>:38080` (账号/密码默认: `airflow`/`airflow`)

- **Kibana (日志中心)**: `http://<MASTER_IP>:35601` (直接在 Discover 页面选择 `airflow-*` 视图检索日志)

- **Elasticsearch API**: `http://<MASTER_IP>:39200`

- **Flower (Celery 监控)**: `http://<MASTER_IP>:35555`

- **PostgreSQL**: `localhost:35432`

- **Redis**: `localhost:36379`

### 主控节点 (Master Node)

执行 `make up` 或 `make up-master` 的机器上将暴露以下核心服务端口：

| 服务组件 | 宿主机端口 | 用途说明 | 访问地址示例 |

| :--- | :--- | :--- | :--- |

| **API Gateway** | `38000` | **业务系统唯一对接入口**。提供高并发任务提交与基于 JSONB 的状态检索 | `http://<MASTER_IP>:38000` |

| **Airflow Web UI** | `38080` | Airflow 原生控制台与官方 API (账号密码默认: `airflow`/`airflow`) | `http://<MASTER_IP>:38080` |

| **Kibana** | `35601` | 集中式日志可视化中心 (直接在 Discover 页面选择 `airflow-*` 视图检索日志) | `http://<MASTER_IP>:35601` |

| **Flower** | `35555` | Celery 集群状态监控面板 (**仅在执行 `make up-master` 时启动**) | `http://<MASTER_IP>:35555` |

| **Elasticsearch** | `39200` | 存储运行日志的底层搜索引擎 API | `http://<MASTER_IP>:39200` |

| **PostgreSQL** | `35432` | 核心元数据库，存储 Airflow 数据及 API Gateway 的 `csst_task_records` 表 | `<MASTER_IP>:35432` |

| **Redis** | `36379` | Celery 消息队列中间件 | `<MASTER_IP>:36379` |

### 计算节点 (Worker Node)

执行 `make up-worker` 的机器：

*   **不暴露任何宿主机端口**。

*   Worker 节点只需通过 `.env` 中的 `MASTER_IP` 主动连接到主控节点的 Redis 和 Postgres 即可静默消费任务。

---

## DAG 任务的触发与状态查询

为了避免 Airflow 3 升级鉴权体系（强制 JWT）带来的对接复杂性，以及为了解决海量异构任务数据的检索问题，本系统**强力推荐业务方直接对接自定义的 API Gateway**。