Open-Meteo 自托管天气API 本地部署与运维指南【免费下载链接】open-meteoFree Weather Forecast API for non-commercial use项目地址: https://gitcode.com/GitHub_Trending/op/open-meteoOpen-Meteo 是一个开源的气象数据平台核心是把商业天气 API 的那套 REST 接口搬到你自己的服务器上一个 Swift 编写的单二进制 HTTP 服务一套面向时间序列优化的二进制文件格式OM 格式作为文件型数据库外加可从模型原始数据或 AWS 公开分发拉取数据的多组下载程序。本文面向想本地部署天气服务的新手、数据工程师和气象应用开发者读完后你会得到一套从选型、跑通到日常运维的完整动作清单。能力边界它能做什么不适合做什么适合场景本地气象查询在自己的坐标和变量范围内提供温度、降水、辐射等要素查询替代直接调用免费公共接口。数据实验在固定数据集上复现实验、做离线回测查询路径完全可控。替代商业天气 API接口结构与 open-meteo.com 一致迁移成本低适合非商用项目商用也允许但源码遵循 AGPL-3.0数据为 CC-BY-4.0 需署名改源码对外提供服务需开源。不适合场景大规模商用 SLA自托管实例的响应通常慢于官方免费 API一次预报需要读数百个压缩文件的小片段冷缓存时可能耗时数秒官方明确不承诺小部署支持。复杂气象建模它提供现成模型输出的查询不提供建模管线。无持久化场景数据依赖磁盘缓存纯内存或一次性环境收益很小。选 Docker 还是原生安装先确认三件事决策只看三点数据目录落在哪里、版本怎么更新、排障有多难。对比项Docker 容器Ubuntu 22.04 原生包适用场景快速验证、开发环境生产环境、长期运行数据目录挂载卷open-meteo-data到/app/data/var/lib/openmeteo-api/data更新方式换镜像重建容器apt 升级软件包排障难度低容器日志集中中依赖 systemd 与日志服务生产推荐不适合更推荐自带openmeteo-sync服务注意原生 APT 源目前只支持 Ubuntu 22.04。若你有长期服务、定时同步和多节点分发需求优先选原生安装只是验证接口用 Docker 更快。硬件与存储怎么配才不浪费项目最低推荐说明CPU带 SIMD 的现代处理器支持 AVX2解码压缩数据依赖向量指令x86-64 与 Arm 均可内存8 GB16 GB内存缓存默认可设CACHE_SIZE8GBSSD100 GB完整数据集约 150 GB NVMe只同步少量变量时 32–48 GB 起步变量范围按需按业务裁剪每多一个变量存储与带宽都线性增加为什么强调 AVX2SIMD 指令让 CPU 一次处理多个浮点数解码速度差异明显但不是硬性门槛缺 AVX2 也能跑。为什么强调 NVMe SSD本地存储同时充当 LRU 缓存每次查询要随机读多个小文件块高 IOPS 的 SSD 能直接把冷查询时间压下来机械盘会明显拖慢响应。30 分钟跑通一个最小可用服务Docker 最小流程目标起一个只监听本地的 API能查到温度即可。先建数据卷再启动容器最后用 curl 验证。docker volume create --name open-meteo-data docker run -d --rm -v open-meteo-data:/app/data \ -p 127.0.0.1:8080:8080 ghcr.io/open-meteo/open-meteo curl http://127.0.0.1:8080/v1/forecast?latitude47.1longitude8.4modelsecmwf_ifs025hourlytemperature_2m如果想在容器内落一份自己的数据而不是走远端分发可再跑一次容器执行同步命令例如sync ecmwf_ifs025 temperature_2m把指定模型域的指定变量拉到本地数据卷。首次请求会慢几秒属正常现象。原生安装要点顺序固定为添加带签名的 APT 源并安装openmeteo-api软件包编辑/etc/default/openmeteo-api.env打开REMOTE_DATA_DIRECTORY与CACHE_SIZE两项systemctl restart openmeteo-api重启用openmeteo-api sync 域 变量补一份本地数据。软件包自带 systemd 单元openmeteo-api服务管理 APIopenmeteo-sync服务管理同步两者分开控制。数据从哪里来同步策略与变量选择数据来源有两条路从 AWS 上的公开分发拉现成的 OM 数据库sync命令最省事或从各气象机构原始数据自行下载处理download-*系列命令流量巨大官方提醒全量每天可达 4–8 TB不建议新手直接全量。变量选择原则先问业务只需要什么。只需要温度就只同步temperature_2m不要顺手把整个模型域拉全。原生安装下定期同步用环境变量控制写在/etc/default/openmeteo-api.env改完重启openmeteo-sync服务SYNC_ENABLEDtrue SYNC_DOMAINSdwd_icon SYNC_VARIABLEStemperature_2m SYNC_REPEAT_INTERVAL5各字段含义SYNC_ENABLED决定是否启用同步服务SYNC_DOMAINS是逗号分隔的模型域列表SYNC_VARIABLES是逗号分隔的变量列表SYNC_REPEAT_INTERVAL为每轮重试间隔分钟。多节点部署时节点间通过 S3 兼容列表接口拉取差异文件细节见 docs/sync-command.md。日常维护清理、备份与排障数据保留策略先确认路径无误、保留期符合业务再用定时任务清理避免误删近期数据压力层数据文件名含hPa生命周期短可只保留 10 天。表层数据业务需要多久就留多久示例中按 90 天处理。完整数据集不要盲目全量清理先统计目录占用再定保留窗口。官方给出的参考写法是每小时执行find /var/lib/openmeteo-api/data/ -type f -name chunk_*并按-mtime 10压力层或-mtime 90其余删除来源见 docs/sync-command.md。建议先在目标目录加-print试运行确认命中文件再追加-delete。状态检查sudo systemctl status openmeteo-api sudo journalctl -u openmeteo-api.service -f docker logs open-meteo --tail 100前两条查原生服务与日志第三条查容器。同步异常通常先看openmeteo-sync单元的日志再看磁盘余量。安全与性能优化清单保持默认绑定8080 端口默认只监听127.0.0.1外部不可达确需直接暴露才在 env 文件里设API_BIND0.0.0.0:8080否则一律走 Nginx 等反向代理加 TLS 与访问控制。只读挂载API 容器对数据卷只读、只让同步侧可写防止异常写坏数据文件。调缓存变量多或查历史时调大CACHE_SIZE官方支持 TB 级缓存同区域云部署可显著降低远端拉取延迟。加应用层缓存对重复坐标和变量的请求在前端加短 TTL 缓存直接削减 API 负载。优先 SSD存储即缓存磁盘延迟就是查询延迟这是性价比最高的一项优化。下一步行动清单用 curl 请求一次 forecast 接口确认坐标、模型域、变量名都正确。执行一次sync只同步一个业务必需的变量验证落盘。配置SYNC_DOMAINS与SYNC_REPEAT_INTERVAL让数据自动更新。给压力层和表层数据分别设置保留策略先试运行再开启删除。用反向代理接管 8080 端口加上 TLS 与访问控制。在应用层加缓存并监控冷查询耗时。完整安装细节可参考 docs/getting-started.md多模型下载参数见 docs/downloading-datasets.md。【免费下载链接】open-meteoFree Weather Forecast API for non-commercial use项目地址: https://gitcode.com/GitHub_Trending/op/open-meteo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考