干旱监测并非简单的降水量统计，它需要综合降水、温度、蒸散和植被状态等多种因素。DeDrought项目选择Node.js作为核心运行时，是为了在数据采集、指标计算和接口发布之间保持一套统一的异步模型。本文会从架构设计开始，逐步展示一个可运行的干旱监测系统是如何构建的。
一、系统架构与数据源选择
DeDrought的整体架构可以拆成三个层次：数据采集层、指标计算层和结果发布层。数据采集层负责从外部气象服务拉取降水、温度等基础数据；指标计算层将原始数据处理成标准化干旱指数；结果发布层通过REST API把监测结果交给前端或第三方系统。Node.js在这三层之间起到粘合作用，非阻塞I/O使多个数据源的批量请求可以并行完成，而不需要额外的多线程调度。
数据源方面，降水与温度适合使用Open-Meteo的历史与预报接口，该服务免费且无需密钥，适合原型系统快速验证。植被状态可以使用NASA的NDVI产品，但为了降低复杂度，本系统允许以模拟NDVI或哨兵数据预处理后的值作为输入。无论选择哪一种，都需要在采集阶段统一成内部结构，例如包含日期、站点编号、降水量、平均温度和NDVI值。
相比用Python单独写采集脚本再通过消息队列传递数据，Node.js可以直接在同一个进程内用定时任务触发采集与计算。这样做减少了组件数量，也方便在云函数或小型服务器上部署。缺点是重度科学计算库不如Python丰富，因此DeDrought在计算SPI时采用简化方法或调用编译好的模块来实现。
二、数据获取与标准化流水线
数据获取模块的核心任务是请求外部API并把响应整理成后续计算可用的格式。以Open-Meteo为例，一个完整的降水数据请求需要传入经纬度、起止日期和日粒度参数。Node.js中的axios可以很自然地处理Promise，配合async函数让错误处理更直观。
下面的代码展示了如何获取某个站点过去90天的日降水数据，并转换成内部记录数组。这里把日期和降水量单独提取出来，避免后续计算时重复解析JSON结构。
const axios = require('axios');
async function fetchPrecipitation(lat, lon, days) {
const end = new Date();
const start = new Date();
start.setDate(end.getDate() - days);
const format = (d) => d.toISOString().slice(0, 10);
const url = 'https://archive-api.open-meteo.com/v1/archive'
+ '?latitude=' + lat
+ '&longitude=' + lon
+ '&start_date=' + format(start)
+ '&end_date=' + format(end)
+ '&daily=precipitation_sum';
const response = await axios.get(url);
const daily = response.data.daily;
const records = [];
for (let i = 0; i < daily.time.length; i++) {
records.push({
date: daily.time[i],
precipitation: daily.precipitation_sum[i]
});
}
return records;
}
除了降水，温度和NDVI也需要类似处理。温度数据可以通过同一接口的daily=temperature_2m_mean参数获得。NDVI如果是本地GeoTIFF文件，解析门槛较高，常见的折中方案是使用预处理后的CSV或JSON，由采集模块读取并合并。所有数据最终写入一个统一的数组，每个元素包含日期和三个指标。
标准化流水线还要处理缺失值和异常值。一般可以用前一日值填补或直接跳过该日。实际业务中建议对连续缺失超过7天的情况发出告警，避免计算出的干旱指数失真。
三、SPI与NDVI融合计算
标准化降水指数SPI是目前应用较广的气象干旱指标。严格计算需要将降水序列拟合Gamma分布后做正态化处理，但为了在Node.js中轻量运行，DeDrought采用滑动窗口的Z-score方法作为近似。具体来说，对某个时间窗口内的降水总量计算均值和标准差，再用当前值减去均值后除以标准差，得到一个标准分数。该分数可以映射到干旱等级。
下面的函数接收一个降水数组和窗口大小，返回最近一个窗口的SPI近似值。窗口通常选择30天、60天或90天，短期农业干旱常用30天SPI。
function calculateSpi(records, windowSize) {
if (records.length < windowSize) {
return null;
}
const window = records.slice(-windowSize);
const sum = window.reduce((acc, item) => acc + item.precipitation, 0);
const mean = sum / windowSize;
const variance = window.reduce((acc, item) => {
return acc + Math.pow(item.precipitation - mean, 2);
}, 0) / windowSize;
const std = Math.sqrt(variance);
if (std === 0) {
return 0;
}
return (window[window.length - 1].precipitation - mean) / std;
}
NDVI反映植被生长状况，SPI反映降水异常。单一指数容易误报，例如灌溉地区降水少但植被正常，因此DeDrought将两者结合。可以给SPI和NDVI分别设置权重，例如SPI权重0.6、NDVI权重0.4，将NDVI归一化到与SPI相同的尺度后计算综合干旱指数。综合指数低于-1.5判为严重干旱，-1.0到-1.5为中度，-0.5到-1.0为轻度。
这种融合方式计算简单，适合实时监测场景。对于更精确的业务，可以引入SPEI或Palmer指数，但Node.js生态没有现成库时，直接实现复杂统计会提升维护成本。DeDrought选择先落地可用的简化版本，再逐步替换计算核心。
四、Express API与监测结果输出
监测结果需要通过接口对外发布。使用Express可以快速定义REST端点，配合MongoDB存储每日计算结果。定时任务可以用node-cron在每日固定时间触发采集与计算流程，结果写入数据库后，前端随时可以查询。
下面是一个简单的Express路由，假设已经完成了计算并存储到MongoDB。客户端可以指定站点编号和日期范围，服务端返回对应的干旱等级。
const express = require('express');
const app = express();
app.get('/api/drought', async function(req, res) {
const station = req.query.station || 'default';
const days = parseInt(req.query.days || '30', 10);
const records = await DroughtRecord.find({
station: station
}).sort({ date: -1 }).limit(days);
res.json({
station: station,
records: records
});
});
app.listen(3000, function() {
console.log('DeDrought API running on port 3000');
});
实际部署时，还需要处理跨域、鉴权和请求限流。可以把Express服务放在反向代理后面，或直接通过云函数暴露接口。DeDrought因为把计算和API放在同一服务中，冷启动时间比传统科学计算服务更短，适合在容器环境里水平扩展。
此外，可以在结果中加入更新时间、数据来源和置信度字段，方便前端展示时说明数据质量。监测系统最怕静默失败，因此每次计算后应记录日志，一旦发现数据源连续请求失败，立即通过邮件或消息推送告警。
五、DeDrought落地时的注意事项
Node.js并不是干旱监测的唯一选择，但DeDrought的实现说明它在数据聚合型服务中具备足够的灵活性。异步I/O降低了多数据源采集的复杂度，Express让结果发布变得直白，而定时任务和MongoDB的组合能满足中小规模系统每日更新的需求。
如果后续要接入更多气象指标或更复杂的统计模型，建议把计算模块独立成微服务，或者在Node.js中通过子进程调用Python脚本。不要试图在单个JavaScript文件中塞入所有逻辑，否则随着站点数量增加，维护难度会迅速上升。合理的分层会让系统在半年后依然容易被理解和修改。